GCC 4.2.0 Status Report (2007-02-19)

Daniel Berlin dberlin@dberlin.org
Wed Feb 21 03:51:00 GMT 2007

On 2/19/07, Joe Buck <Joe.Buck@synopsys.com> wrote:
> On Tue, Feb 20, 2007 at 12:27:42AM +0000, Joseph S. Myers wrote:
> >...  *All* releases seem to have the
> > predictions that they are useless, should be skipped because the next
> > release will be so much better in way X or Y, etc.; I think the question
> > of how widely used a release series turned out to be in practice may be
> > relevant when deciding after how many releases the branch is closed, but
> > simply dropping a release series after the branch is created is pretty
> > much always a mistake.  (When we rebranded 3.1 as 3.2 in the hopes of
> > getting a stable C++ ABI, I think that also with hindsight was a mistake,
> > given that the aim was that the stable ABI would also be the correct
> > documented ABI but more ABI bugs have continued to turn up since then.)
> I agree.  To me, the only issue with 4.2 is the performance drop due to
> aliasing issues; whether to address that by reverting patches to have 4.1
> performance + 4.1 bugs, or by backporting fixes from 4.3, I would leave
> for the experts to decide (except that I don't think it's shippable
> without some solution to the performance drop).
Fixing bugs is always harder than reverting patches.
You can get 4.1 performance with 4.1 bugs simply by reverting the
patches and turning off pruning (In particular, making
access_can_touch_variable always return true).
This hides pretty much all of the aliasing bugs that were reported,
except one (which was due to TBAA pruning of sets in a case we
shouldn't have).

BTW, I hope nobody was surprised by the performance drop.  I did warn
it was going to happen. I only fixed those bugs because they were
listed as blockers.  I'm still of the opinion that even though you can
write relatively simple testcases for them, they are actually pretty
rare.  In most of the bugs, it is in fact, the absence of any real
code (or local variables in one case) that triggers the bad result.
Anything more complex and we get the right answer.  Strange but true.


More information about the Gcc mailing list