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