compiler bugs (was Re: lang/ezm3 "runtime error: Segmentation violation...")

[P.D. Seniura]

----- Original Message -----
From: Mark Linimon <linimon at lonesome.com>
Date: Mon, 24 May 2004 17:27:00 -0500 (CDT)
To: "P.D. Seniura" <pdseniura at techie.com>
Subject: Re: lang/ezm3 "runtime error: Segmentation violation..."

> > Do we blame the code or the compiler?
> 
> One of the things I just added to the PR Submission Guidelines is
> to explain what AFAICT is the current practice within FreeBSD with
> respect to anything other than -O: be prepared to send patches.
> Apparently few developers have sufficient time/understanding/interest.
> Executive summary: there's just not enough manpower.
> 
> Again, AFAICT.

Not having seen it mentioned yet on the PR submission website (does your guideline change need to go thru channels first?), all I can say is pretty-much what I said back in April.  I hit reproducable -O bugs with the gcc snapshots back then; now I see it happens (rarely) with the -Current system gcc, which again is a snapshot (still).

At least some of the -O bugs are known to the GCC team themselves.  I explained some of my wrestlin' with it back in mid-April: please see <http://docs.FreeBSD.org/cgi/mid.cgi?20040415191751.6A8DF5C17>.

Back then we had snapshots.  Since then, the compilers have been released.  We don't yet have the released versions -- and this is the point I am trying to make.  (I should've included that April link to my msg here, to tie this together.)  No use in wasting manpower on snapshots when there is a final release.

Also, I mentioned back in April that since the gcc code is patched by FreeBSD's ports system, for whatever reason, I cannot feel good about logging bugs at the GCC website.  The only place I can do so is 'here'.  I said it in April and say again that if optimization levels work well on say Linux/i386, using the same compiler, they should work on FreeBSD/i386, too.

I really wish manpower would be expended on providing trustful current tools, I don't know what else could be so important, it should go without saying.  ;)

If TPTB would let me, I'd stop what I'm doing and try helping on the released compilers.  Since we want to prove our points with 'free' software, icc and other co$tly software is moot.  At home, my G4 Sawtooth has everything working (OSX Panther XCode), and that's where I saw -Os being used as _default_ on gcc-3.3 (and mentioned in April).  But I cannot convince TPTB here to try anything non-Intel-ish.  Politics... I don't do that well... ;)

I'm hoping the _released_ compilers would have -Os fixed on the i386 side.  That's been my main point.  I'm now hitting this _known_ bug on the -Current system compiler (still a snapshot, albeit occurring very rarely, but it sure wasted several days here trying to figure out why apps linking with -lXaw kept griping about an undefined .L91).  I say 'known bug' meaning "known to the GCC team" and IMO not much a FreeBSD maintainer can do about it other than report it to them (I've recreated it twice already, takes about an hour for this puny pentium2 to compile XFree-libraries and test it again).

Thanks for letting me spew about it again.  I'll try helping as much as possible.

> mcl

  --  thx, Paul Seniura.


-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm