Re: Building the whole Debian archive with GCC 4.1: a summary

[René Rebe <rene at exactcode dot de>]

Hi,

well too bad some news sites pick this mail up as rather bad news for
the GCC compiler and project as it.

However the opposite is the truth, I'm a long term system integrator
contributing to ROCK Linux since 1998 and nowadays leading the
T2 SDE fork of it. It is a development environment allowing the
automated build including cross compilation, including C++
cross compilation (a bit like Gentoo, just for professional developers).

  http://www.t2-project.org/

In this time I experienced the big 2.95 -> 3.{0,1} and the other
but not that big 3.4, 4.0 migrations. I can only say never was
a major GCC release that pleasing. With GCC 4.1 the ill-formed
code of the _packages_ compiled with GCC that has been uncovered
was rather just minor - just a few compared to e.g. the 2.95 -> 3.0
migration or update within the 3.x series.

Even as one having to do a lot patching for each of the GCC
releases I appreciate the stricter language checking even if
not as long warned about as the friend injection or the extra
qualificatoin. Those are rather trivial changes anyway.

That said with the over 2400 packages in T2 (no -devel packages
thus not directly comparable to others with tons of -devel and
other split packages) including modular X11R7 and a lot of
custom cross build stuf,f GCC 4.1 is already the default compiler in
the T2 development trunk to be released as a stable series in the next
weeks.

Best regards,

PS: If some company has too much money the T2 project
also always happy to find some sponsors, e.g. to regularly
rebuild the whole source repository one a week or so with
GCC trunk:HEAD, including cross builds if interesting.

On Saturday 25 March 2006 22:56, Martin Michlmayr wrote:
> Over the last 2.5 weeks I have built the complete Debian archive
> on a quad-core MIPS machine donated by Broadcom using the recently
> released version 4.1 of GCC.  In parallel, I have done the same
> on an EM64T box donated to Debian by Intel.
> 
> The purpose of this exercise was three-fold:
>  - Find out about compiler problems in GCC 4.1 itself as well
>    as in packages that may fail with the new version *before*
>    GCC 4.1 is uploaded to Debian.
>  - Find out about MIPS specific problems in GCC 4.1 and to answer
>    the question of Matthias Klose, Debian's GCC maintainer, [1]
>    as to which platforms can move to GCC 4.1 as the default compiler.
>  - Find MIPS specific assembler warnings and create a list of all
>    users of xgot (a MIPS specific toolchain problem).
> 
> I thought I'd summarize my findings for the GCC developers so you know
> what kind of broken code is out there in the wild.  Given that Debian
> is a fairly large distribution, we probably have a better coverage of
> the "typical free software" project (i.e. not just the successful
> projects everyone talks about) than most other distros.
> 
> 
> Executive summary
> -----------------
> 
> GCC 4.1 itself appears to be very stable, both on MIPS and AMD64.
> There are, however, a large number of packages using code (especially
> C++) which GCC 4.1 treats as errors.  Fortunately, most of them are
> trivial to fix.  By compiling about 6200 software packages (see [2]
> for the list), over 500 new bugs have been discovered and submitted:
> 280 of which are specific to the increased strictness of GCC 4.1.
> Patches for 2/3 of those GCC 4.1 specific bugs have been submitted.
> 
> 
> Detailed summary of problems
> ----------------------------
> 
> Basically, it all boils down to broken C++ code.  There were a few
> bugs in C code, but the majority was in C++.   The most common
> errors I found (and some *approximate* numbers) are:
> 
>  - extra qualification: about 187 bugs
>  - reliance on friend injection: 26 bugs
>  - wrong escape characters (e.g. "\."; most commonly seen in regular
>    expressions): 6 bugs
>  - iterator problems (such as assigning 0 or NULL to an iterator): 3
>  - template specialisation in wrong namespace
>  - template reliance on a function declared later
>  - use of template's base class members, unqualified, where the base class
>    is dependent
>  - use of "assert" without #include <cassert>: 5 bugs
>  - dereferencing type-punned pointer will break strict-aliasing rules
>    together with -Werror: 6 bugs
>  - the use of "mips" as a variable name when GCC on mips defines it
>    as a constant (arg!) and you end up with: const 1 = -1: 1 bug
> 
> A list of all GCC 4.1 specific bugs in packages can be found at [3].
> The single biggest syntax error found is the use of extra qualification,
> which fortunately are trivial to fix.
> 
> 
> Compiler bugs in GCC 4.1
> ------------------------
> 
> I've found a number of GCC bugs in this process (the # bug numbers refer
> to bugs in the Debian bug tracker, please use http://bugs.debian.org/nnn):
> 
>  - gcc ICE: #356231 (when building gnubik_2.2-5)
>    http://gcc.gnu.org/PR26672 - fixed
> 
>  - g++ ICE: #356569 (when building 3ddesktop_0.2.9-5.1)
>    http://gcc.gnu.org/PR26757 - test case needs further reduction
> 
>  - gcc bug: #356574 (address of register requested)
>    http://gcc.gnu.org/PR26004 - fixed
> 
>  - g++ bug: #356548 (cannot bind packed field)
>    http://gcc.gnu.org/PR26670 - not yet assigned but related to known bugs
> 
>  - g++ bug: #356435 (no constructor)  [package bug: #356245]
>    http://gcc.gnu.org/PR26755 - waiting
>    This is a binary incompatibility!  4.0 has a different behaviour to
>    3.3 and 4.1, which means that linking 4.1 code against 4.0 libraries
>    may fail.  4.0 and 4.1 were supposed to be binary compatible so I'm not
>    sure what will be done about this.
> 
>  - gcc bug: #356896 (miscompiles code, leading to segfault in program)
>    http://gcc.gnu.org/PR26763 - confirmed
> 
>  - gcc or autoconf bug: #358644 (change in behaviour on mips regarding
>    -fstack-protector)
>    In the past, the use of -fstack-protector on MIPS would result in
>    an error.  Now it succeeds (with a warning) but then fails to link.
>    autoconf expects it to fail, however.
> 
>    It's not clear right now whether this behaviour change was correct and
>    autoconf should be changed or whether GCC should revert that change.
>    Fortunately, this change only breaks 2 packages out of ~6200.
> 
>    Maybe other people can look at http://bugs.debian.org/358644 and
>    comment.
> 
> 
> Musing from the point of view of a distro
> -----------------------------------------
> 
> I think GCC is a really solid tool and I was surprised not to see more
> problems related specifically to MIPS given that it's not one of the
> mainstream platforms.  As someone involved in a major Linux distribution,
> I'm not terribly happy about the way errors are handled.  I'm specifically
> talking about the extra qualification error here, which to the best of
> my knowledge was never treated as a warning: -pedantic in 4.0 would cause
> an error and now 4.1 causes an error by default.
> 
> While I appreciate G++ becoming more standards compliant, I think you
> should do it in steps: issue a warning in one release (unconditionally,
> i.e. without the need for -pedantic) and *then* in the next release make
> it an error.  This gives developers a change to fix their bugs before
> they become errors.  Granted the extra qualification bugs are trivial
> to fix, but as a major distro we now have almost 200 packages that will
> fail because of this error and this slows down our adoption of GCC 4.1.
> 
> I'd like to propose that you explicitly make it part of your process to
> generate a warning in one release of GCC and only in the next one to
> change it to an error.  Please give developer some advance warning.  As
> you can see from my examples above, there is *lots* of broken code out
> there.
> 
> 
> Further work
> ------------
> 
> Given that I have fast MIPS hardware (thanks to Broadcom) I will try to
> test GCC snapshots on MIPS from time to time and report problems to you.
> If someone needs access to a fast MIPS machine for some testing, I may
> be able to arrange something on a temporary basis.  Please contact me
> privately if this is the case.
> 
> 
> Acknowledgements
> ----------------
> 
>  - Google for supporting my PhD, thereby allowing me to spend two weeks
>    compiling the archive with GCC 4.1 and sorting out failures.
>  - Intel for supporting some PhD work which led to this experiment.
>  - Broadcom for supporting Debian's MIPS port through the donation of
>    hardware to the project and individual developers.
>  - Ben Hutchings for explaining many of the C++ bugs I found to me.
>    I've learned more about C++ in these two weeks than I ever wanted to
>    know. ;-)  Ben also submitted a number of patches for tricky bugs I
>    couldn't fix.
>  - Intel for donating an EM64T machine to Debian.
>  - The GCC project for creating a great compiler, and in particular
>    Andrew Pinski for doing lots of bug triaging work.
> 
> 
> References
> ----------
> 
> [1] http://lists.debian.org/debian-gcc/2006/02/msg00173.html
> [2] http://people.debian.org/~tbm/logs/gcc-4.1/PACKAGES
> [3] http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=submitter&includesubj=4.1&data=tbm%40cyrius.com&archive=no&version=&dist=unstable
> 

-- 
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
            http://www.exactcode.de | http://www.t2-project.org
            +49 (0)30  255 897 45