Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 1 Sep 2002 11:30:43 -0700
From:      "David O'Brien" <obrien@FreeBSD.ORG>
To:        leimy2k@mac.com
Cc:        Terry Lambert <tlambert2@mindspring.com>, freebsd-current@FreeBSD.ORG, Alexander Langer <alex@big.endian.de>, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
Subject:   Re: gcc 3.1 / streambuf.h broken with "using namespace std;"
Message-ID:  <20020901183043.GF94999@dragon.nuxi.com>
In-Reply-To: <1FFDCCFF-BDA8-11D6-9DF6-0003937E39E0@mac.com>
References:  <3D714B7F.CE386B65@mindspring.com> <1FFDCCFF-BDA8-11D6-9DF6-0003937E39E0@mac.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 01, 2002 at 07:41:24AM -0500, leimy2k@mac.com wrote:
> >I thought it was the general consensus that the 3.1 version of
> >the compiler was broken, and generated bad code, and that the 3.2
> >compiler had a lot of these problems corrected, but destroyed
> >binary compatability with 3.1.
> 
> Yes but if you go through and read gcc.gnu.org you will see that 3.2 
> can be configured on linux to use the "multi-vendor ABI standard".  

The "multi-vendor ABI standard" (agreed upon by all that care about
IA-64), was supposed to be properly implemented in 3.1.x.  Due to a bug
in the implementation 3.1.x wasn't compliant to the new "multi-vendor ABI
standard".

THAT IS THE ONLY REASON 3.2 CAME INTO EXISTENCE.  FreeBSD, SuSE, RedHat,
Mandrake all have new OS releases coming out this Fall and did not want
to go thru an ABI change between 3.1.1 and what was then 3.2 (and is now
3.3).  I led the push, strongly supported by some SuSE folks to create a
3.2 which was exactly 3.1.1 + "multi-vendor ABI standard" compliance
fixes.  Along the way to 3.2.0 a few other bugs got fixed that would have
been in 3.1.2 had the 3.2 we have today not been created.  The
"multi-vendor ABI standard" fixes could not go into 3.1.1 or 3.1.2
because the GCC developers have a rule that ABI changes cannot happen in
mid-branch.  We have the same with our RELENG_X branches.

It is *that* simple.

Rather than bitch that 3.1.1 "sucks"; we should thanking the GCC Steering
Committee that after much thought they were willing to take the vendors'
needs into account.  I am not sure FreeBSD would have done the same.


> Actually they have been trying to make this work all along and is 
> probably why they break ABI compatibility.   3.1 has issues with 
> template classes that use functions containing static variables [at 
> least a pre-release of it did on Darwin/OS X].

Apple highly modifies the GCC sources.  So any bugs/problems/issues you
find in their compiler you cannot blame on the GCC developers w/o
researching the bug/problem/issue.


> 3.2 necessary for some people [though I hope every time the fix 
> something that their test-cases increases by one.... that would be 
> smart anyway].

The test suite does.  We should be so lucky to have such a test suite.



> 3.2 is the "more confident" ABI and while there are no guarantees that 
> 3.3 will work with 3.2... there seems to be better feelings about it.

Correct.  Not only "better feelings" but "fully intended".  But as we saw
with 3.1.0, bugs happen.


 
> >It was my understanding that FreeBSD 5.0 release was not going
> >to be GCC 3.3 (because GCC 3.3 would not be released in time for
> >FreeBSD to not be "pulling a RedHat" if they shipped a beta and
> >called it 3.3) , might be GCC 3.2, and was currently down-rev
> >from there.

3.3.0 will be released before FreeBSD 5.1.  It is my advice to
FreeBSD'ville that we go with a GCC 3.3 snapshot for FBSD 5.0 and a GCC
3.3.0 release for FBSD 5.1.  That way we can get the new features of 3.3
into our 5.x branch.  AND get bug fixes by importing 3.3.1 and 3.3.2 into
later FBSD 5.x releases.



> RedHat actually created a release that never occurred [2.96] in the gcc 
> release chain... and if you use it, its actually a pretty nice 
> compiler.... I know the ABI doesn't work with anything but 2.96 though.

The ABI was in flux during those times -- the "2.96" ABI is compatabile
with nothing else.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




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