Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17

Dennis Gilmore dennis at ausil.us
Sat Dec 31 14:55:53 UTC 2011


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 at 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.

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 at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20111231/fd944266/attachment.html>


More information about the devel mailing list