> 
> 
> > > That said, I think it would not be bad to put 4.3 in stage3 mode until
> > > dataflow branch is ready and, at that point, rebranch 4.2 and soon
> > > after that merge dataflow branch.
> 
> FWIW I agree with Vlad and Paolo Bonzini.
> 
> It seems as if 4.2 was branched with critical flaws (it happens, no
> biggie). In addition to the alias issues, and the resulting SPEC
> issues, and the compilation slowdown issues vis-a-vis 4.1 and current
> mainline.... then seeing this kind of commentary in a patch:

4.0 branched with critical flaws that were not noticed until 4.2.0 which
is why we end up with the missed optimiation regression in the first place.

So the question is do we want to correct the regressions or not, because
right now we sound like we don't.  Which regression is more important?
Wrong code or missed optimiation, I still say wrong code.  I know other
people will disagree with me but guess what they can disagree with me all
they want, they will never win.  This is the same thing with rejecting
legal code and compile time regressions (I remember a patch Apple complained
about because it caused a compile time regression but it fixed a reject legal,
even recently with some ICE and -g and a compile time regression though it
does not effect C++).

I still say 4.2.0 is still better at a lot of things that the aliasing 
regression
does not hurt that much.  I wonder what the result, between the two revsions
that cause a regression on x86, on PowerPC is.  If it is better than I say this
is really a RA issue and I say call it a day and just release 4.2.0 as is.

We really need a new RA if x86 is getting worse as the rest of the targets are
getting better.


-- Pinski

Reply via email to