acidblood writes "GCC3.1.1 has been released. Many improvements in performance, code optimization, standards compliance, and a few bug fixes in the C++ ABI (full changelog here). Download from the main GNU FTP or use the nearest mirror."
If you plan on building a distribution (hello Redhat and Mandrake), it's probably wise to wait for gcc 3.2, since binary compatibility will change. Binaries from gcc 3.2 are binary incompatible with anything older.
-- DNA is the ultimate spaghetti code.
Re:Wait for 3.2
by
mbyte
·
· Score: 4, Informative
Yes.. esp. since 3.2 is only a bugfix release, that should only fix some C++ ABI bugs...
(there's quite some discussion about this now in the gentoo forums)
Re:Wait for 3.2
by
Anonymous Coward
·
· Score: 2, Insightful
if you're planning on building a distro (red hat, mandrake), you don't read slashdot for advice.
um, am I missing something?
by
Toraz+Chryx
·
· Score: 2
*reads changelog*
# MIPS:
* RiscOS, mips-*-riscos*
Um, I was under the impression that RiscOS was written for the ARM processor(s)? ARM processor(s)?
Did somebody just turn two pages at once?
Red Hat: 3.2 is in Rawhide
by
crow
·
· Score: 5, Informative
Well, 3.2 hasn't been released yet, but that hasn't stopped Red Hat from including it in their Rawhide release.
gcc-3.2-0.1.i386.rpm
I assume it's a pre-release, and they intend to move to a full release before Rawhide becomes 8.0. That should be a relatively safe bet for them, considering not only their unique position in regards to gcc, but also that the GCC web page cites an expected release date for 3.2 as being 2002-07-2x.
Re:Red Hat: 3.2 is in Rawhide
by
norwoodites
·
· Score: 2
This 3.2 might be what really what 3.3 is going to be.
Why does the ABI keep changing?
by
0x0d0a
·
· Score: 2
I mean, okay, I understand that at some point, there may be a good reason. But it seems that before releasing a new version of a compiler with a new ABI, you'd get everything *right* first, given the huge number of compatibility problems that this switch causes.
So maybe the move from gcc 2.7 to 3.0 was well-founded. Red Hat just happened to unfortunately release an interim release. But now there's going to be a release incompatible with 3.0/3.1? Come *on*, guys!
Gcc is great, but this causes tons of grief for all the developers out there trying to use C++ in their code and support users.
Re:Why does the ABI keep changing?
by
randombit
·
· Score: 3, Interesting
But now there's going to be a release incompatible with 3.0/3.1? Come *on*, guys!
And 3.2 is compatible with the V3 ABI. Sure, they could just keep the current ABI, and remain incompatible with compilers from Intel and other commercial vendors forever. That doesn't seem like a particularly great path to me, though.
The reason 3.2 is coming out a few days after 3.1.1 is so RedHat, Mandrake, FreeBSD, SuSE, etc can have time to QA it for their next releases. I don't know of any distributions using 3.0 or 3.1 anyway. Debian and *BSD are still on 2.95.x, Redhat/Mandrake are 3.0-beta. Not sure about SuSE though. So, basically, it's not as if the 3.{0,1}/3.2 ABI changes actually affect anyone, because while 3.2 is incompatible with previous 3.0 releases, 3.2 and 3.0/3.1 are "equally incompatible" with whatever the systems are using now.
SUSE was one of the parties which asked for an early 3.2 release, so they could base their distribution on that (instead of 3.1). Red Hat, Debian and FreeBSD was three other names I can remember from the discussion.
They are implementing a standard ABI
by
Per+Abrahamsen
·
· Score: 2
In contrast to earlier, the GCC 3.x ABI is based on a written, cross-vendor standard. This means the implementation can have bugs. The bugs was subtle enough not to be caught before 3.0, but given the diversity of C++ coding styles, it is really hard to say how common the affected code is.
Before, the GCC C++ ABI was whatever GCC produced, so the ABI couldn't really have bugs.
They could of course declare the GCC ABI to be the ABI descrbed in the standard, except for the bugs not caught by 3.0. However, I'm glad they are going with the written standard, rather than trying to Microsoft their bugs into being a de-facto standard.
Re:Speaking of standards ...
by
bunratty
·
· Score: 2
Why would it go against the spec? It's just an optimization. This means it affects the speed of the generated code, but not the behavior.
-- What a fool believes, he sees, no wise man has the power to reason away.
It does affect the behavior
by
Per+Abrahamsen
·
· Score: 2
since the A constructor and destructor will be called fewer times, and they may have side effects.
However, the optimization is explicitly allowed by the standard, thus code that depend on the side effects in the example is broken.
Slashdot Mirror
If you plan on building a distribution (hello Redhat and Mandrake), it's probably wise to wait for gcc 3.2, since binary compatibility will change. Binaries from gcc 3.2 are binary incompatible with anything older.
DNA is the ultimate spaghetti code.
# MIPS:
Um, I was under the impression that RiscOS was written for the ARM processor(s)? ARM processor(s)?* RiscOS, mips-*-riscos*
Did somebody just turn two pages at once?
Well, 3.2 hasn't been released yet, but that hasn't stopped Red Hat from including it in their Rawhide release.
gcc-3.2-0.1.i386.rpm
I assume it's a pre-release, and they intend to move to a full release before Rawhide becomes 8.0. That should be a relatively safe bet for them, considering not only their unique position in regards to gcc, but also that the GCC web page cites an expected release date for 3.2 as being 2002-07-2x.
I mean, okay, I understand that at some point, there may be a good reason. But it seems that before releasing a new version of a compiler with a new ABI, you'd get everything *right* first, given the huge number of compatibility problems that this switch causes.
So maybe the move from gcc 2.7 to 3.0 was well-founded. Red Hat just happened to unfortunately release an interim release. But now there's going to be a release incompatible with 3.0/3.1? Come *on*, guys!
Gcc is great, but this causes tons of grief for all the developers out there trying to use C++ in their code and support users.
May we never see th
SUSE was one of the parties which asked for an early 3.2 release, so they could base their distribution on that (instead of 3.1). Red Hat, Debian and FreeBSD was three other names I can remember from the discussion.
In contrast to earlier, the GCC 3.x ABI is based on a written, cross-vendor standard. This means the implementation can have bugs. The bugs was subtle enough not to be caught before 3.0, but given the diversity of C++ coding styles, it is really hard to say how common the affected code is.
Before, the GCC C++ ABI was whatever GCC produced, so the ABI couldn't really have bugs.
They could of course declare the GCC ABI to be the ABI descrbed in the standard, except for the bugs not caught by 3.0. However, I'm glad they are going with the written standard, rather than trying to Microsoft their bugs into being a de-facto standard.
Why would it go against the spec? It's just an optimization. This means it affects the speed of the generated code, but not the behavior.
What a fool believes, he sees, no wise man has the power to reason away.
since the A constructor and destructor will be called fewer times, and they may have side effects.
However, the optimization is explicitly allowed by the standard, thus code that depend on the side effects in the example is broken.