This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH: Add -fabi-version
- From: Fergus Henderson <fjh at cs dot mu dot OZ dot AU>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 23 Sep 2002 20:35:57 +1000
- Subject: Re: C++ PATCH: Add -fabi-version
- References: <200209230922.g8N9MdS23181@gandalf.codesourcery.com>
On 23-Sep-2002, Mark Mitchell <mark@codesourcery.com> wrote:
>
> An early version of CodeSourcery's C++ ABI testsuite found a new C++
> ABI bug in G++:
...
> I added detection of this case to -Wabi.
...
> --- cp/class.c 23 Sep 2002 09:12:34 -0000
> --- 4878,4898 ----
> field. We have to back up by one to find the largest
> type that fits. */
> integer_type = integer_types[itk - 1];
> !
> ! if (abi_version_at_least (2) && TREE_CODE (t) == UNION_TYPE)
> ! /* In a union, the padding field must have the full width
> ! of the bit-field; all fields start at offset zero. */
> ! padding = DECL_SIZE (field);
> ! else
> ! {
> ! if (warn_abi && TREE_CODE (t) == UNION_TYPE)
> ! warning ("size assigned to `%T' may not be "
> ! "ABI-compliant and may change in a future "
> ! "version of GCC",
> ! t);
> ! padding = size_binop (MINUS_EXPR, DECL_SIZE (field),
> ! TYPE_SIZE (integer_type));
> ! }
Shouldn't this issue a warning even if abi_version_at_least (2)
returns fails? E.g. something like
warning ("ABI change: versions 3.2 and earlier of GCC "
"used a different ABI for `%T'", t);
That way, library developer can avoid using constructs that would
cause their uses trouble, if their users happen to be using an
earlier version of GCC.
Perhaps -Wabi should be extended to take a version number as
an argument (-Wabi=<n>), and to issue warnings about compatibility
with *earlier* versions of GCC only if the issue would be a problem
for the specified version number or later.
> Index: doc/invoke.texi
...
> --- 1249,1263 ----
> Here is a list of options that are @emph{only} for compiling C++ programs:
>
> @table @gcctabopt
> +
> + @item -fabi-version=@var{n}
> + @opindex fabi-version
> + Use version @var{n} of the C++ ABI. Version 1 is the version of the C++
> + ABI that first appeared in G++ 3.2. Version 0 will always be the
> + version that conforms most closely to the C++ ABI specification.
> + Therefore, the ABI obtained using version 0 will change as ABI bugs are
> + fixed.
It would be helpful to document what the default is.
Perhaps even something like
In the FSF distribution of GCC, the default is version 0.
However, other distributions may use a different default.
@c Note:
@c Implementations which use a different default should
@c document their default here.
> Index: testsuite/g++.dg/abi/bitfield7.C
> ===================================================================
> RCS file: testsuite/g++.dg/abi/bitfield7.C
> diff -N testsuite/g++.dg/abi/bitfield7.C
> *** /dev/null 1 Jan 1970 00:00:00 -0000
> --- testsuite/g++.dg/abi/bitfield7.C 23 Sep 2002 09:12:38 -0000
> ***************
> *** 0 ****
> --- 1,7 ----
> + // { dg-do compile }
> + // { dg-options "-Wabi" }
> +
> + union U { // { dg-warning "ABI" }
> + int i: 4096; // { dg-warning "exceeds" }
> + };
With your current code, I think this test will fail if compiled with
-fabi-version=1, since the warning won't be issued. That might make
life slightly more difficult for OS vendors who want to ship a version
of GCC in which -fabi-version=1 is the default.
If you don't change the code so that it issues a warning here, then
would it be better for this test to explicitly pass -fabi-version=0?
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.