January 26th, 2008
|11:47 pm - GCC 4.3 status update|
I'm still plugging away at getting the tree ready for GCC 4.3. This version ranks near the high end of the disruptive scale, unlike the 4.2 upgrade, with many packages needing patching to build. Users wanting to experiment will find many breakages in the current portage tree and will likely want to use an overlay. Mine is available through layman, and there are a few others available that can be found through the dedicated work of the people in the GCC 4.3 testing thread in the Unsupported Software forum.
Rather than go over the major porting issues here, I'll point people to the excellent porting document put together by Benjamin Kosnik and the GCC team located at http://gcc.gnu.org/gcc-4.3/porting_to.html
One recent development was the revert of a patch that made redefinitions errors. With this patch, whose intent was to make the C++ frontend and the preprocessor's pedantic warnings consistent, something like this would cause an error:
$ cat test.cpp
#define foo bar
#define foo baz
$ g++ -c test.cpp
test.cpp:2:1: error: "foo" redefined
test.cpp:1:1: error: this is the location of the previous definition
The problem is many many packages have code like this in their configure scripts. Whether this is a problem in autoconf, or lazy programming, or just the compiler being completely anal (which many have suggested), it's still a hell of lot of packages to fix. A conversation on the gcc-dev mailing list resulted in a compromise where a new system of pendantic warnings/errors was agreed upon. However, being too close to the release of 4.3 to make major changes, it was decided to integrate it into 4.4 and revert the original patch for 4.3.
So most of what remains is missing header fixes and the odd -std=99 inline error. Unfortunately there's still a lot of them.
Interested parties can follow along on bug #198121. If you want to file bugs please include (a) patches (b) the error message (c) a link to the upstream bug (if there is none, file one ;]) or cvs checkin if they've already fixed it (in which case we probably will just wait till they release rather than patch our version).
|Date:||January 28th, 2008 01:46 pm (UTC)|| |
more like 4.0 to 4.1, but without the assyness. and most everyone has said "yeah, forget 4.2 and move on to 4.3".
-march=native is in 4.2 and it is cool. i have a Core (not Core 2) so foo on you. :P
|Date:||March 2nd, 2008 07:16 pm (UTC)|| |
-march=core2 and -mtune=core2 are present and functional. I'm beating on dirtyepic's gcc-4.3.0-pre20080227 SVN ebuild and emerge -e world only fails to compile 4 or 5 packages at this point. Everything that does compile appears to be working correctly as well.
Good riddance to -march=nocona -mtune=generic!!
|Date:||February 18th, 2008 09:03 am (UTC)|| |
I can't wait for GCC-4.3.0 to be in the tree. And it'd be nice in someways if GCC really went out and made C/C++ offically strict. like you can still omit the return(0); in the main function etc. And for the love of god they need to fix the C bug with the useless thing it does which can make buggy code of, assign a value to a function and with multiple values even if the function doesn't receive multiple values.
|Date:||February 19th, 2008 04:14 am (UTC)|| |
Actually, standard C++ is guaranteed implicitly return 0 from main if you don't explicitly specify a return value.
And if you want a C that forces you to be more careful, just use C++ as though it were C.