if we plan to do a mass rebuild for gcc 4.7 we need to start it next week.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Jakub Jelinek <jakub@redhat.com> wrote:
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.

CCin g 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 t hat 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 contain s 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 t o 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). T he 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel