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

[Paul Brook <paul at codesourcery dot com>]

> I know what your answer will be to the following, but it's really
> becoming a pain to try to help solve issues with the compiler when all
> you get back is complaints that this and that and a third rule isn't
> being fulfilled. I got complaints before stating that I didn't run the
> testsuites. I'm running them now. I got complaints that I just built
> (not bootstrapped) the compiler. I'm bootstrapping it now. I got
> complaints that I'm not diff-ing against the mainline. I'm doing so now.
> I got complaints that I didn't write ChangeLog entries. I'm writing them
> now. I maybe got other complaints I don't even recall at the moment (I
> tried to avoid one by now also building at least all default languages).
> No-one seems to care that all these rules require an awful lot of time
> (bootstrapping the compiler takes hours, the testsuite runs take hours,
> using the mainline is wasted time to me and my employer since we
> obviously can't/don't want to use this for general consumption, so
> importance to us have only changes on top of a released compiler), and
> that instead of doing useful work I'm spending days on fulfilling just
> these rules (this might be less extreme if I worked on just a single fix
> or a couple of them, but over the last two or three years, prior to
> having an FSF copyright assignment, a couple of dozen changes have piled
> up and I'd really like to get them out rather than dropping them and
> later running into the same problem again). As said above (and as got to
> hear previously), everyone's (supposedly) playing by these rules.
> Whether everyone's pleased by them doesn't matter. Whether this severly
> limits productivity doesn't matter either.

All the requirements you mention are documented on the gcc webpages, so they 
shouldn't really come as a surprise: http://gcc.gnu.org/contribute.html

I disagree that these requirements take a lot of time. Yes a full bootstrap 
and test can take several hours of *machine* time.
However even if you run this manually it only takes five minutes to check out 
a clean tree, apply a patch and type "make bootstrap; make -k check". You can 
then go and do something more productive for a few hours, or just leave it 
running overnight. If you have lots of patches it's not that hard to write a 
script to iterate over all of them.

You've got to remember that there are dozens, maybe even hundreds of 
developers working from gcc HEAD. If a patch isn't sufficiently tested and 
breaks bootstrap then all these developers are effected.

Personally I am very pleased that we have a fairly rigorous patch acceptance 
policy. I think that the overall productivity of gcc developers is improved 
by this.

Adding new changes to a release branch without adding them to mainline only 
has very short-term benefit, and potentially causes extra problems on the 
(stable) release branch. This is why we don't allow it.
Once you have put in the effort to update everything to mainline your 
maintenance burden for future releases should be reduced.

Paul