compiler bugs (was Re: lang/ezm3 "runtime error: Segmentation
pdseniura at techie.com
Tue May 25 10:28:29 PDT 2004
----- 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.
-- thx, Paul Seniura.
Sign-up for Ads Free at Mail.com
More information about the freebsd-ports