Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Dec 2006 22:27:13 -0800
From:      Steve Kargl <sgk@troutmask.apl.washington.edu>
To:        Scott Long <scottl@samsco.org>
Cc:        freebsd-current@freebsd.org, Peter Jeremy <peterjeremy@optushome.com.au>
Subject:   Re: Let's use gcc-4.2, not 4.1 -- OpenMP
Message-ID:  <20061215062713.GA9843@troutmask.apl.washington.edu>
In-Reply-To: <458235EC.80300@samsco.org>
References:  <20061213192150.CF83D16A417@hub.freebsd.org> <20061214183026.GA1532@turion.vk2pj.dyndns.org> <4581A3E3.9060807@samsco.org> <200612151450.39260.doconnor@gsoft.com.au> <20061215044453.GB9381@troutmask.apl.washington.edu> <458235EC.80300@samsco.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 14, 2006 at 10:43:08PM -0700, Scott Long wrote:
> Steve Kargl wrote:
> 
> >Actually, 4.1.x will produce much worse code than 3.4.6.
> >You can search the gcc mail listings for extensive comparison
> >by Clinton Whaley (the author of math/atlas) for details.
> >
> 
> Has this been fixed in GCC 4.2?  If the FSF claims to have fixed it,
> has it been actually verified?  I thought that gcc 4 was supposed to 
> solve the world's problems with vectorization.
> 

I was hoping to avoid participation in this thread, but ...

gcc-4.0.0 == freebsd-5.0
gcc-4.1.0 == freebsd-5.5
gcc-4.2.x == freebsd-6.0

Now for the details.  gcc-4.0 completely replaced the intermediate
representation (IR) of the parsed language with the tree-ssa form.
This IR sits between the frontend and the backend code generator.
I would call 4.0 the "make it work" stage.  gcc 4.1 concentrated 
on bug fixes, and gcc 4.2 has started to remove the warts (e.g.,
slow compilation times, bloated generated code, etc.)

Pushing to include 4.2 over 4.1, based on OpenMP, is a red herring,
IMHO.  -fopenmp does not magically include OpenMP directives in
code.  That is, -fopenmp is useless for the code in the FreeBSD
base system, and anyone that needs OpenMP for a port can install 4.2
or even 4.3 (head of gcc tree).  For the record, -ftree-vectorize
may be more important then -fopenmp for out-of-box compilation.

As to stability, 4.2 is fairly good.  There are, of course, bugs and
some regressions, but these get addressed quickly.  Additionally,
4.2 may have better support for ARM and newer processors. 
Also note that the system compiler on newer versions of Redhat and
SuSe is 4.1.

The biggest concern is the strictness of the C and C++ frontends.
GCC has moved to better adherence to the Standards, which will
impact the ports collections.

Finally, for the record.  I routinely bootstrap GCC 4.1-branch, 
4.2-branch, and 4.3 (mainline) on FreeBSD-amd64 6.2-prerelease and
7.0.  I've contributed hundreds of patch to the Fortran frontend
and runtime library, and I'm listed as a Fortran maintainer.
Other than FreeBSD's libm lack of long double function (which
I've tried submitting code to rectify), the Fortran compiler 
works great under FreeBSD.

In the end, GCC and FreeBSD development is simply governed by
the principle of "Too few developer, too much to do".  At some
point the development decides that a version is no longer 
supported.  For GCC, it is 3.4.x, and for FreeBSD, it is 4.11.

Scott, if you want to discuss other concerns, contact me off-list.

PS: Peter Jeremy has had one of the few valid reason for going 
directly to 4.2.
-- 
Steve



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061215062713.GA9843>