This is the mail archive of the gcc-help@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: Need clarification on mixing GCC 4.5 with earlier versions


Kristofer Wempa <wempa@sig.com> writes:

> I am looking to build an entire set of tools using GCC 4.5 for SLES10,
> which is based on GCC 4.1.2.  According to the GCC 4.4 release notes,
> there is an ABI change that causes it to be incompatible with earlier
> GCC versions.  My initial plan was to build GCC 4.5 and then build the
> remaining software with 4.5 using the .-fabi-version. option to make
> it generate binaries compatible with GCC 4.1.2.  However, the GCC man
> page and other documentation I have come across says that GCC 4.4 and
> 4.5 still using version 2.0 of the ABI, which was introduced in GCC
> 3.4.  Now, I.m confused.  If GCC 4.4 introduces an ABI change, then
> how can it still be the same ABI version as the earlier GCC versions ?
> It sounds almost like there is a minor change to the ABI, but that
> they still want to consider it compatible with the previous ABI
> version.  Can somebody please clarify this for me ?  I have bounced
> this off of a couple of other people who are familiar with these
> concepts and they also agree that it.s unclear.  Any help would be
> greatly appreciated.

The issue is unfortunately more complex than it should be.  The
-fabi-version option is not well named.  As the documentation states, it
refers only to the C++ ABI.  The documentation is also clear that the
default value is 2, and describes the changes in later versions.  This
is for C++ only.

gcc 4.4 made two ABI changes that apply to all language, not just C++.

The first affects all targets: structs with the packed attribute which
contained bitfields of type char were changed to avoid introducing
incorrect padding.  If your code does not such a struct, nothing has
changed.  Note that this is an unusual case in two respects: you have to
explicitly use __attribute__ ((packed)), and you have to use bitfields
of type char.

The second ABI change is specific to x86_64.  The way in which certain
types of structs are passed to a function or returned from a function
has changed.  The structs in question are 1) structs with a flexible
array member; 2) structs with a complex float member; 3) unions with a
long double member.  This change only affects code which actually passes
a struct to a function, rather than, say, a pointer to a struct.  This
change was made to conform to the public x86_64 ABI.

For both ABI changes, gcc 4.4 and later will print a message if your
code uses the construct.  This note be disabled via
-Wno-packed-bitfield-compat for the first change and -Wno-abi for the
second change.  This is only a note, not a warning or an error.

So, you should simply use the compiler as usual, but watch for
occurrences of that note, perhaps in a script.  If you don't see the
note, you are fine.

There is no way to tell gcc 4.4 and later to use the earlier ABI.  The
earlier ABI was buggy.  I'm not sure I agree with this decision, but it
is what the gcc maintainers decided.

Ian


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