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>