This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 3.3 release notes


Joe, as usual, you have done a masterful job preparing these release
notes.  Stuff in [] is proposed new/changed.  Comments about proposed
new/changes are unmarked. - Loren

> [...] For shared library versions, C++ binaries produced
> by 3.2.x should work fine with the shared library from GCC 3.3, but we
> can't make any assurances about the reverse direction.

FYI, the above statement MAY only be true if said shared library was
produced with versioned symbol.  I'm not sure anyone has actually
tested forward ABI compatibility with an unversioned shared library.
Is "should work fine" enough guarded optimism here?  Or, do we need to
more fully state the conditions under which we have forward ABI
compatibility expectations?

> For hppa-linux-gnu and m68k-linux-gnu, you must configure with
> --enable-sjlj-exceptions to get binary compatibility with GCC 3.2.x.

[The version of libstdc++ included with 3.3 is intended to be
completely implementation compatible with that shipped with 3.2.X
EXCEPT on i386 ports (anything configured as i386-*-*, no matter the
real CPU) WHEN the generated code is actually used in a multi-threaded
context where the default spin-lock implementation has changed.
Luckily, the old and new implementations will correctly interoperate
without any link or run-time conflicts in single-threaded contexts.
However, the old and new implementations do not lock the bus accesses
in any manner that ensures thread safety when the implementations are mixed.

For i386-*-* which is really an i486 or greater, you may configure GCC
3.3 as i486-*-* to get binary compatibility with GCC 3.2.x configured
as i386-*-*.  This may be in issue for all operating systems targeting
i386 and above as a class since there is now a break-point in ABI
compatibility keyed off the CPU as configured.  The new spin-lock code
for i386-*-* is believed to work for i386 and all later CPUs in the
family in both single CPU and SMP configurations.]

> FreeBSD-specific[]:
> 7680 float functions undefined in math.h/cmath with #define _XOPEN_SOURCE

This issue MAY affect other BSDs and other systems (past PRs were
filed for Solaris but I was unable to find them and address them) but
only FreeBSD has the extra configuration to enable the actual fix.

> 7926 (c++) i486 instructions in header files make c++ programs crash on i386

FYI, this is the root reason for the aforementioned ABI change.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]