Re: gcc 4.3: when will it become standard compiler?

From: B. Estrade <estrabd_at_gmail.com>
Date: Fri, 9 Jan 2009 07:52:15 -0600
On Fri, Jan 09, 2009 at 02:47:25PM +0100, Roman Divacky wrote:
> On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote:
> > Roman Divacky schrieb:
> > >>I'm not saying it's wrong to look for alternatives, but you cannot just 
> > >>change your system compiler like you change underwear.
> > > 
> > >well... the first step is imho starting to compile world with C99...
> > >that might reveal some bugs, note that as of a few months ago
> > >8-current compiles cleanly with C99, that does not mean that it's
> > >working when you run those programs correctly :)
> > 
> > One step in the right direction is embracing the nice features modern C 
> > offers you. For example declaring a variable right were you need it 
> > instead of dozens of lines away is one such nice thing which improves 
> > readability. Designated initializers improve readability, too.
> > But I'm not exactly sure what you mean by "compile world with C99". C99 
> > is pretty much backwards compatible to C89.
>  
> sorry for the bad wording - I meant to turn C99 compilation on default.
> We compile in gnu89 mode now.

This is slightly off topic, but how important might it be wrt SMP
progress for there to be OpenMP support in the C compiler? I am not
suggesting this be part of any FreeBSD code, but I find having OpenMP
support in the base compiler very appealing for many reasons - one of
which is SMP benchmarking/testing.

I ask because while shared memory executables produced by 4.2.1 are
not the fastest (when using OpenMP), the directives are at least mostly 
supported. And I suppose that the later version of gcc will only get 
better. On the otherhand, other solutions don't seem to have this 
support whatsoever - so I ask again, how important might this kind of 
support be when considering /which/ compiler to use?

Thank you,
Brett

> 
> > >>PCC cannot seriously be considered. Its design is stuck in the 
> > >>seventies. From the point of view of compiler construction it is plain 
> > >>plain out of question. I especially was amused by the statement of the 
> > >>author who claimed PCC supports SSA - except for phi-functions.
> > >
> > >what's wrong with design stuck in 70's when it compiles the whole 
> > >world/kernel?
> > >
> > >I would not use it for default compilation of releases but it might be
> > >useful when you are developing - because of its fast compilation times
> > 
> > If you want a real speed devil, try TCC.
> 
> well.. tcc does not seem to be integrated by any *BSD while pcc has been
> adopted by netbsd and openbsd :) that shows it has something good (at least
> good promotion *grin*)
>  
> > >btw.. are you sure the design is stuck in the 70's? the author claims
> > >to have rewritten almost the whole thing. have you looked at the recent
> > >code?
> > 
> > It's still a simple tree based approach. From point of view of 
> > optimisations this often gets in the way. For example you need temporary 
> > variables as helper construct which just complicates things (yes, there 
> > are intermediate representations which do not have temporary variables 
> > at all). Much has happend in compiler land in the last 30 years. Now we 
> > have stuff like SSA and some are even doing code generation in this 
> > form. I can go into more details, but this is not the right place.
> 
> ok.. I just wanted to be sure you looked at the new version.
>  
> > >another question - how is libfirm/cparser? last time I tried it didnt
> > >support much of the gcc options (-Wsomething -f-something etc.) so
> > >it could not be used as a direct drop-in
> > 
> > The next release will support several more switches for GCC 
> > compatibility. Here's the latest manpage: 
> > http://tron.homeunix.org/cparser.1 - you can view it with "nroff -man 
> > cparser.1". Switches like -Wl, and -Wp, are supported. Many bugs have 
> > been resolved. More warning options have been added - many similar to 
> > what GCC does, some doing a better job. We plan to make a new release 
> > Really Soon Now(TM).
> 
> ok.. looking forward :)
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"

-- 
B. Estrade
Louisiana Optical Network Initiative
+1.225.578.1920 aim: bz743
:wq
Received on Fri Jan 09 2009 - 13:09:46 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:40 UTC