Re: Slush: Bug-Fixes Only for Middle End and Primary Platforms

[Mark Mitchell]

Mark Mitchell wrote:

 We're in Stage 1, and in Stage 1 big changes happen -- and then there is
 naturally some instability.  We clearly have some instability at
 present, so we need to slow down until that's resolved.

It looks like we have successfully resolved many of the problems.  I
still see a bootstrapping PR (PR39929), but it's unclear to me whether
there are still problems there or not.  Given the progress, the slush is
over.

However, Paolo Bonzini has announced the intention to merge the
cond-optab branch on Friday.  Therefore, until that is done, please do
not make any major check-ins (e.g., branch merges).

Thanks,

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Slush: Bug-Fixes Only for Middle End and Primary Platforms

[Mark Mitchell]

We're in Stage 1, and in Stage 1 big changes happen -- and then there is
naturally some instability.  We clearly have some instability at
present, so we need to slow down until that's resolved.

Therefore, effective immediately, please commit only bug fixes to the
middle end and to architectures that are designated as primary
platforms.  Please hold off on new features for these areas of the
compiler, until things stabilize.  It's OK to continue to add new
features to secondary platforms and front ends, but I suggest that we
exercise caution there as well.  We'll stay in this mode until we've
gotten back to the point where test results are looking pretty good on
all of the primary platforms -- hopefully just a few days.

With the benefit of hindsight, I think that committing both the SSA
expansion and type-checking changes in close succession was probably a
bit too much change a bit too quickly.  When changes of this magnitude
go in, we should probably wait a few days to see if stabilization is
required before introducing another change of large magnitude.

Thank you,

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: Slush: Bug-Fixes Only for Middle End and Primary Platforms

[Steven Bosscher]

On Tue, Apr 28, 2009 at 11:12 PM, Mark Mitchell m...@codesourcery.com wrote:
 We're in Stage 1, and in Stage 1 big changes happen -- and then there is
 naturally some instability.  We clearly have some instability at
 present, so we need to slow down until that's resolved.

Bah.


 With the benefit of hindsight, I think that committing both the SSA
 expansion and type-checking changes in close succession was probably a
 bit too much change a bit too quickly.  When changes of this magnitude
 go in, we should probably wait a few days to see if stabilization is
 required before introducing another change of large magnitude.

Many of the changes that have gone in simply lacked testing. You
mention the type-checking changes, but that is probably the only big
change that *was* properly tested and where the failures it has caused
are just small but easily (and already) fixed.

On the other hand: It cannot be that the SSA expansion goes in without
working on half the primary targets.  That means it just wasn't tested
properly, for such a big-impact.  Was it really only tested on x86-64
before going onto the trunk?  Isn't there the test-on-three-targets
rule for big-impact merges?

Likewise for much of the pretty-ipa patches, which go in as merges
but haven't been in the branch for more than a few days in some cases.
Plus, many of the regressions were just test suite failures that, for
some reason, were overlooked or ignored before committing the patches.

Looks like the dumpgo approach to me.

By contrast: I held off the gcse DF-ify patch for two weeks because I
found one (1) regression on an obscure libgomp test case during
re-testing *after* the patch had been approved. I didn't want to cause
breakage and so I first tracked down and fixed this one regression
before committing.
Now I have a backlog of ~5 tested patches to submit, but I have to
wait thanks to less careful people  :-(

Next time, a much better approach IMHO would be to just revert the
offending patches until they're properly tested and most issues are
fixed *before* the patches go on the trunk.

Ciao!
Steven