This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA:] Fix PR optimization/15296, delayed-branch-slot bug.


> From: Eric Botcazou <ebotcazou@libertysurf.fr>
> Date: Tue, 11 May 2004 19:54:50 +0200

> > Still, again, since *you* can help with the doubt you cast,
> > could you please help with a separate bootstrap and test on
> > SPARC on the 3.3 and 3.4 branches, preferably sparc64 and
> > solaris2.8 if there's a choice?
> 
> Done.  A full cycle of bootstraps (32-bit/64-bit, Solaris 2.5.1, 2.6, 7, 8 
> and 9, Java, Ada) has successfully completed on mainline, 3.4 branch and 3.3 
> branch with your patch (and some others on mainline and 3.4 branch).

Wow.  Thank you very much!
Was that also including running the test-suite before and after
with no regressions?

> Needless to say this doesn't change my position :-)

But it strengthens mine. ;-)

Out of curiosity, what would change your position (that the
correction is inappropriate for the 3.3 branch IIRC)?
A test-case that exposes this bug for SPARC (3.3 and 3.4
respectively)?
That this bug through other changes gets exposed in a SPARC
bootstrap (3.3 and 3.4 respectively)?

> > (My sparc-sun-solaris2.7 tests
> > have been successful on the 3.3 and 3.4 branches, but I've
> > verified that they have been "contaminated" in that the built
> > gcc used GNU binutils, so e.g. all or most g++ test-cases
> > failed.  Doh!)
> 
> Could that be the same problem as PR target/15253?

No, it doesn't look similar at all to what I remember, except
for failing at link time.  (I don't remember details about the
failure I saw except it wasn't __eprintf; I think it was a SEGV.
I hope to get to the details in a PR soon.)

brgds, H-P


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]