This is the mail archive of the gcc-patches@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: C++ PATCH: Add -fabi-version


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.


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