Re: make #pragma pack() implementation consistent with other compilers(PR c/7054)

[Paolo Bonzini <bonzini at gnu dot org>]

> One thing I simply forgot to add before: With all these nice rules, why
> is it then that, in order to be sure my changes don't add regression
> failures, I have to first bootstrap an unmodified compiler and run the
> testsuite on it (so to identify all current failures), in order to then
> run the same stuff again to finally compare the set of failures with my
> changes to that without.

Almost often you just end up memorizing the failures on an unmodified 
compiler.  If you have some surprise, just check on gcc-testresults if 
somebody else had the same failure on i686-pc-linux-gnu.  If not, 
something wrong's with your patch, so you either debug the failure, or 
run the unpatched compiler.

> Certain tests appear to take quite long to compile (I measured 4 minutes
> on an otherwise idle system),

Ah, that's 20001226-1.c :-)

> then such tests are prone to time out (and thus
> fail).

No, if you find that the particular test is prone to time out, just run 
that test on its own, and see if it fails again.  Occasionally, failures 
may be introduced because of flaky RAMs or (especially on laptops) high 
CPU temperature.  Then run the single test, and if it is a small one you 
can run valgrind on cc1 to look for uninitialized memory -- if there's 
none, and it passes 2-3 times, you can be confident with your patch.

However bad this sentence may look, it's just a matter of getting 
accustomed to it.  More expert contributors have faster review times 
also because they know how to please the reviewers (splitting patches, 
writing good descriptions and preparing good changelogs).  Contributing 
to a big piece of open source software like GCC is harder despite the 
non-trivial amount of time that the global maintainers put in helping 
volunteers like us.  Suffice it to look at the volume of the GCC mailing 
lists.

Really, there's nothing we can do about it except listen for alternative 
proposals.  As long as they can handle a project with about 200 
developers, with a changes log taking a printed page per day (if you're 
lucky), and as incredibly data-driven (and thus prone to exposing latent 
bugs) as GCC.

Read Zack Weinberg's paper about GCC maintainance on 
www.codesourcery.com and you'll see that people often do not like the 
rules, but recognize that each one of them is necessary and ends up 
*saving* their time rather than wasting it.

Paolo