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

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> Of course I had already done so and of course you still may.
> (I don't know why people keep insisting that I've goofed on
> basic stuff when I spot a problem.  Ah, maybe it's because I
> actually *do* now and then! :-)

Ok.  I just wanted to be sure because AFAIK problems like yours have not been 
reported for a couple of years at least and sparc-sun-solaris2.7 was until 
very recently a primary platform.

What I find strange is that you couldn't build libgcc_s.so.  I've never seen 
this problem reported, except because of configuration problems  Are you 
sure you don't have GNU binutils lying somewhere and being inadvertently 
picked up?  How did you configure?

> I checked again, and can't say I missed anything.  Last time I
> read it, I basically ignored the stuff about "sun patches",
> because the error descriptions didn't match what I saw, and I
> didn't know how to check and shouldn't mess with system patches
> anyway...  I've now STFW and found a reference to "showrev -p"
> which says there's 106950-03 installed but no 107058-01, so I
> don't think any of the system-specific installation items apply,
> except the one about --disable-multilib.  Bootstrap compiler is
> "gcc version 2.95.3 20010315 (release)" so it shouldn't matter
> that 112760-07 isn't installed.

Is your sparc-sun-solaris2.7 box actively administered?

> If you "in return" or something, could do an extra round of
> checking of this patch on some or all of 3.3, 3.4 and trunk, on
> your favorite SPARC-based system (preferably different from
> sparc-sun-solaris2.7 to cover more ground), that'd be great.

Is the bug a regression from an earlier release?

Since the patch was approved for trunk, put it there and it will be included 
in Kaveh's testing and mine.  I'll report any problem as soon as possible.

-- 
Eric Botcazou