<html><head></head><body>if we plan to do a mass rebuild for gcc 4.7 we need to start it next week.<br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br><br><div class="gmail_quote">Jakub Jelinek <jakub@redhat.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre style="white-space: pre-wrap; word-wrap:break-word; font-family: sans-serif">Hi!<br /><br />As part of preparations to switch GCC in F17 to GCC 4.7.0, I've performed<br />a test mass rebuild of rawhide (December 23th package list) using<br />gcc-4.7.0-0.1.fc17 on x86_64, and for those packages that failed also<br />rebuilt the same package with gcc-4.6.2-1.fc16 to quickly remove from the<br />list packages that fail for non-gcc related reasons.<br />Out of the 11270 packages I've built, 10056 packages built fine with<br />gcc-4.7.0-0.1.fc17 and 845 packages failed to build also with<br />gcc-4.6.2-1.fc16, so I'm ignoring those from any analysis.<br />I've analyzed some of the remaining failures and tried to categorize it<br />a little bit. There were 3 internal compiler errors seen during the<br />whole mass rebuild, <a href="http://gcc.gnu.org/PR5169">http://gcc.gnu.org/PR5169</a>{2,4,5} are currently<br />filed and slightly analyzed, but not fixed yet.<br /><br />CCin
g
Benjamin if he'd be interested to write<br /><a href="http://gcc.gnu.org/gcc-4.7/porting_to.html">http://gcc.gnu.org/gcc-4.7/porting_to.html</a> again this time.<br /><br />The common reasons for build failures were (I'm attaching srpm lists for<br />these categories):<br /><br /><a href="http://gcc.gnu.org/PR49745">http://gcc.gnu.org/PR49745</a> 119 failures<br /> <iostream>, <string> and other STL headers that previously<br /> included <unistd.h> as an implementation detail (to get some<br /> feature macros for gthr*.h purposes) no longer do so (it was<br /> a C++ standard violation), to fix this up just add<br /> #include <unistd.h> early in the sources (or headers) that need it.<br /><br /><a href="http://gcc.gnu.org/PR24163">http://gcc.gnu.org/PR24163</a> 60 failures<br /><a href="http://gcc.gnu.org/PR29131">http://gcc.gnu.org/PR29131</a> 28 failures<br /> C++ lookup fixes, the C++ FE no longer performs an extra unqualified<br /> lookup t
hat it
(incorrectly) performed in the past. In some cases the<br /> diagnostics includes hints how to fix the bugs, for PR24163 the<br /> diagnostics looks like:<br /> error: 'something' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]<br /> note: declarations in dependent base 'someclass<somearg>' are not found by unqualified lookup<br /> note: use 'this->something' instead<br /> and for PR29131 diagnostics looks like:<br /> error: 'something' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]<br /> note: 'template<class T1, class T2> sometype something(T1&, const T2&)' declared here, later in the translation unit<br /><br />checking for stdbool.h that conforms to C99... no 2 failures<br /> but affects other 150+ packages<br /> apparently autoconf 2.60 through autoconf 2.67 contain
s an
invalid<br /> check in its stdbool.h checking macro:<br /> # if defined __xlc__ || defined __GNUC__<br /> /* Catch a bug in IBM AIX xlc compiler version <a href="http://6.0.0.0">6.0.0.0</a><br /> reported by James Lemley on 2005-10-05; see<br /> <a href="http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html">http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html</a><br /> This test is not quite right, since xlc is allowed to<br /> reject this program, as the initializer for xlcbug is<br /> not one of the forms that C requires support for.<br /> However, doing the test right would require a runtime<br /> test, and that would make cross-compilation harder.<br /> Let us hope that IBM fixes the xlc bug, and also adds<br /> support for this kind of constant expression. In the<br /> meantime, this test will reject xlc, which is OK, since<br
/>
our stdbool.h substitute should suffice. We also test<br /> this with GCC, where it should work, to detect more<br /> quickly whether someone messes up the test in the<br /> future. */<br /> char digs[] = "0123456789";<br /> int xlcbug = 1 / (&(digs + 5)[-2 + (bool) 1] == &digs[4] ? 1 : -1);<br /> # endif<br /> As written, the test is not quite right and a conforming C compiler<br /> is not required to accept it and starting with<br /> <a href="http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958">http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958</a><br /> GCC rejects it (and similarly from what I understood from autoconf<br /> 2.68 notes recent xlc rejects it as well). autoconf 2.68 dropped<br /> this incorrect check, but apparently many packages include their<br /> own configure scripts without regenerating them. Wonder what is the<br /> best thing to do here, ask package maintainers t
o grep
for this<br /> int xlcbug = ...; in their packages and sedding that to<br /> int xlcbug = 0;, or dropping that || defined __GNUC__ above the<br /> invalid test, or asking where possible to regenerate configure with<br /> autoconf 2.68, perhaps some rpm-build script to do the sedding?<br /> Most of the 150+ packages just refused to use the system <stdbool.h><br /> because of this and did something else (either provided their own<br /> stdbool.h alternative, falled back to using int instead of bool,<br /> ...), the 2 failures were just cases where this was a fatal failure.<br /><br /><a href="https://svn.boost.org/trac/boost/ticket/6165">https://svn.boost.org/trac/boost/ticket/6165</a> 26 failures<br /> Apparently boost uses some libstdc++-v3 internal macros to determine<br /> if gcc has been configured with or without thread support, in GCC 4.7<br /> these internal macros changed and boost thinks GCC 4.7.0 no longer<br /> supports threads (e.g. in libstdc++ headers). T
he fix
here will be<br /> just to fix up boost package we include. <br /><br />gcc driver became more picky about<br />bogus options during linking 14 failures<br /> GCC 4.6 and earlier apparently didn't complain about completely<br /> invalid options on gcc/g++/gfortran etc. command lines, if<br /> nothing was compiled, but only linking was performed.<br /> E.g. gcc -Wl -o foo foo.o -mflat_namespace<br /> would work just fine, even when -Wl needs to have some option<br /> to pass to the linker after it and -mflat_namespace isn't supported<br /> at all. Garbage options just need to be removed from the command<br /> line or replaced by something that is actually supported.<br /><br /><a href="http://gcc.gnu.org/PR2288">http://gcc.gnu.org/PR2288</a> 8 failures<br /> For C++, GCC 4.6 and earlier incorrectly put the two<br /> declarations in different scopes in cases like:<br /> for (int i = 0; i < 10; i++)<br /> {<br /> int i = 2;<br /> }<br /> While that is valid C99
(where
there is a separate scope<br /> with the for declared vars and { int i = 2; } is another scope<br /> inside it), in C++ this is invalid, the int i = 0; declaration<br /> goes into the same scope as the body of the for cycle (similarly<br /> for if/switch). To fix this, either rename one of the decls,<br /> or if you really meant to have the same name and want to have<br /> them in different scopes, add another pair of {}s around the body.<br /> With<br /> for (int i = 0; i < 10; i++)<br /> {{<br /> int i = 2;<br /> }}<br /> the inner {} is already a nested scope.<br /><br />user defined literal support 3 failures<br /> When compiling C++ with -std={c++11,c++0x,gnu++11,gnu++0x} GCC 4.7.0<br /> unlike older versions supports user defined literals, which are<br /> incompatible with some valid ISO C++03 code.<br /> In particular, whitespace is now needed after a string literal<br /> before something that could be a valid user defined literal.<br /> Say const char *
p =
"foobar"__TIME__; is valid C++03, the __TIME__<br /> macro expands to some string literal and is concatenated with the<br /> other one. In C++11 __TIME__ isn't expanded, instead operator ""<br /> __TIME__ is being looked up. This applies to any string literal<br /> followed without whitespace by some macro. Just add some whitespace<br /> between the string literal and the macro name.<br /><br />-Werror 12 failures<br /> As usually, packages compiled with -Werror sometimes fail because<br /> newer GCC versions emit slightly different warnings (could be<br /> correct warnings, newly introduced warnings, could be even false<br /> positives, but with -Werror you need to be prepared to workaround<br /> them).<br /><br />libgcj 6 failures<br /> gcc-4.7.0-0.1.fc17 contained a packaging bug for libgcj, the<br /> <a href="http://libgcj.so">libgcj.so</a> symlink incorrectly pointed to <a href="http://libgcj.so">libgcj.so</a>.12 instead<br /> of <a
href="http://libgcj.so">libgcj.so</a>.13. Will fix this for -0.2.fc17, to this category<br /> I've also included package failures where non-indirect-dispatch<br /> gcj built packages failed to build due to their dependencies<br /> not finding <a href="http://libgcj.so">libgcj.so</a>.12 dependency. Those will just need to<br /> be rebuilt.<br /><br />unanalyzed 91 failures<br /> Ran out of time, haven't analyzed the remaining ones (other<br /> category), once gcc-4.7.0-0.*.fc17 hits the buildroots,<br /> please try to analyze these. Could be gcc bugs, but could<br /> very well be package bugs. E.g. in glibc (which built fine,<br /> just failed a couple of tests that previously succeeded),<br /> I've discovered it was a glibc bug:<br /> <a href="http://sources.redhat.com/ml/libc-alpha/2011-12/msg00091.html">http://sources.redhat.com/ml/libc-alpha/2011-12/msg00091.html</a><br /><br /> Jakub<br />-- <br />devel mailing list<br />devel@lists.fedoraproject.org<br /><a
href="https://admin.fedoraproject.org/mailman/listinfo/devel">https://admin.fedoraproject.org/mailman/listinfo/devel</a></pre></blockquote></div></body></html>