Using __extension__ in a struct with a GTY(()) mark

Using __extension__ in a struct with a GTY(()) mark

[Kaveh R. Ghazi]

Geoff,

I'm trying to enable compiling the G++ frontend using any ISOC
compiler.  In effect, this means getting it to compile with gcc
-pedantic.  I've zapped all problems except one in which I'm running
into a problem with gengtype and a structure using GTY(()) when I try
to use the __extension__ keyword.

The last warnings I get are:
cp-tree.h:1045: warning: bit-field `has_type_conversion' type invalid in ISO C
cp-tree.h:1046: warning: bit-field `has_init_ref' type invalid in ISO C
cp-tree.h:1047: warning: bit-field `has_default_ctor' type invalid in ISO C
cp-tree.h:1048: warning: bit-field `uses_multiple_inheritance' type invalid in ISO C
cp-tree.h:1049: warning: bit-field `const_needs_init' type invalid in ISO C
cp-tree.h:1050: warning: bit-field `ref_needs_init' type invalid in ISO C
cp-tree.h:1051: warning: bit-field `has_const_assign_ref' type invalid in ISO C

These come from this struct in cp-tree.h:

struct lang_type_header GTY(())
{
  unsigned char is_lang_type_class : 1;

  unsigned char has_type_conversion : 1;
  unsigned char has_init_ref : 1;
  unsigned char has_default_ctor : 1;
  unsigned char uses_multiple_inheritance : 1;
  unsigned char const_needs_init : 1;
  unsigned char ref_needs_init : 1;
  unsigned char has_const_assign_ref : 1;
};

I added code in system.h to appropriately use int or char depending on
whether we're using GCC via a macro CHAR_BITFIELD.

The I replaced the above "unsigned char" with CHAR_BITFIELD.  I found
that gengtype chokes on this.  That I fixed by adding CHAR_BITFIELD to
IWORD in gengtype-lex.l.

The problem I'm having now is that I need to add the __extension__
keyword to the struct so that it doesn't get a complaint from GCC.
Not being very fluent in bison or flex, I can't seem to get gengtype
to accept it.

In the end, I'm trying to get this struct parsed by gengtype:

struct lang_type_header GTY(())  __extension__
{
  CHAR_BITFIELD is_lang_type_class : 1;

  CHAR_BITFIELD has_type_conversion : 1;
  CHAR_BITFIELD has_init_ref : 1;
  CHAR_BITFIELD has_default_ctor : 1;
  CHAR_BITFIELD uses_multiple_inheritance : 1;
  CHAR_BITFIELD const_needs_init : 1;
  CHAR_BITFIELD ref_needs_init : 1;
  CHAR_BITFIELD has_const_assign_ref : 1;
};

Please help?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Using __extension__ in a struct with a GTY(()) mark

[Geoffrey Keating]

On Wednesday, April 2, 2003, at 03:00  PM, Kaveh R. Ghazi wrote:

> The problem I'm having now is that I need to add the __extension__
> keyword to the struct so that it doesn't get a complaint from GCC.
> Not being very fluent in bison or flex, I can't seem to get gengtype
> to accept it.

You want to simply ignore the __extension__, right?

If so, you can put it after

"const"/[^[:alnum:]_]           /* don't care */

like

"__extension__"/[^[:alnum:]_]   /* ignore */

in gengtype-lex.l.

> In the end, I'm trying to get this struct parsed by gengtype:
>
> struct lang_type_header GTY(())  __extension__
> {
>   CHAR_BITFIELD is_lang_type_class : 1;
>
>   CHAR_BITFIELD has_type_conversion : 1;
>   CHAR_BITFIELD has_init_ref : 1;
>   CHAR_BITFIELD has_default_ctor : 1;
>   CHAR_BITFIELD uses_multiple_inheritance : 1;
>   CHAR_BITFIELD const_needs_init : 1;
>   CHAR_BITFIELD ref_needs_init : 1;
>   CHAR_BITFIELD has_const_assign_ref : 1;
> };
>
> Please help?
>
> 		Thanks,
> 		--Kaveh
> --
> Kaveh R. Ghazi			ghazi@caip.rutgers.edu
>
-- 
Geoff Keating <geoffk@apple.com>

Re: Using __extension__ in a struct with a GTY(()) mark

[Jason Merrill]

On Wed, 2 Apr 2003 18:00:52 -0500 (EST), "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:

> I'm trying to enable compiling the G++ frontend using any ISOC
> compiler.  In effect, this means getting it to compile with gcc
> -pedantic.  I've zapped all problems except one in which I'm running
> into a problem with gengtype and a structure using GTY(()) when I try
> to use the __extension__ keyword.

If you need to use __extension__, it won't work on other ISO C compilers.
If you really want to compile g++ with other C compilers, you need to avoid
using char bitfields.

> I added code in system.h to appropriately use int or char depending on
> whether we're using GCC via a macro CHAR_BITFIELD.

Why?  If they're interchangeable, why not always use int?  The problem is
that they aren't interchangeable on PCC_BITFIELD_TYPE_MATTERS targets;
using int will impose int alignment on the struct, which breaks its
intended use (if I understand it properly).

> Please help?

I'd be inclined to give up.  What's wrong with requiring gcc for building
the other frontends?

Jason

Re: Using __extension__ in a struct with a GTY(()) mark

[Kaveh R. Ghazi]

 > From: Jason Merrill <jason@redhat.com>
 > 
 > On Wed, 2 Apr 2003 18:00:52 -0500 (EST), "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:
 > 
 > > I'm trying to enable compiling the G++ frontend using any ISOC
 > > compiler.  In effect, this means getting it to compile with gcc
 > > -pedantic.  I've zapped all problems except one in which I'm running
 > > into a problem with gengtype and a structure using GTY(()) when I try
 > > to use the __extension__ keyword.
 > 
 > If you need to use __extension__, it won't work on other ISO C compilers.
 > If you really want to compile g++ with other C compilers, you need to avoid
 > using char bitfields.

We often use __extension__ when we do one thing conditioned on GNUC
and another when we don't have gcc.  This is specifically to silence
-pendatic warnings, when we know we have acceptable code for both gcc
and non-gcc.  E.g. see the tree/rtl "checking" macros.


 > > I added code in system.h to appropriately use int or char depending on
 > > whether we're using GCC via a macro CHAR_BITFIELD.
 > 
 > Why?  If they're interchangeable, why not always use int?  The problem is
 > that they aren't interchangeable on PCC_BITFIELD_TYPE_MATTERS targets;
 > using int will impose int alignment on the struct, which breaks its
 > intended use (if I understand it properly).

They're interchangable functionally but of course the char bitfield
uses less space.  So if the bootstrap compiler is not gcc, then stage1
cc1plus will use slightly more memory, but stage2 and stage3 will
appropriately have a smaller memory footprint as originally intended.


 > > Please help?
 > 
 > I'd be inclined to give up.  What's wrong with requiring gcc for building
 > the other frontends?

I guess you missed this discussion:
http://gcc.gnu.org/ml/gcc/2003-03/msg00146.html

This is what I'm trying to facilitate.  Since we've approved requiring
ISO C to bootstrap, if cc1plus eliminates gnuc-isms we could build it
in stage1 and allow Tom to use C++ in the java frontend while still
having a 3-stage process (instead of 4.)

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu

Re: Using __extension__ in a struct with a GTY(()) mark

[Jason Merrill]

On Wed, 2 Apr 2003 21:08:23 -0500 (EST), "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> wrote:

> They're interchangable functionally but of course the char bitfield
> uses less space.  So if the bootstrap compiler is not gcc, then stage1
> cc1plus will use slightly more memory, but stage2 and stage3 will
> appropriately have a smaller memory footprint as originally intended.

True, I suppose it doesn't matter if layout changes between stages.

Jason

Re: Using __extension__ in a struct with a GTY(()) mark

[Kaveh R. Ghazi]

 > From: Geoffrey Keating <geoffk@apple.com>
 > 
 > On Wednesday, April 2, 2003, at 03:00  PM, Kaveh R. Ghazi wrote:
 > 
 > > The problem I'm having now is that I need to add the __extension__
 > > keyword to the struct so that it doesn't get a complaint from GCC.
 > > Not being very fluent in bison or flex, I can't seem to get gengtype
 > > to accept it.
 > 
 > You want to simply ignore the __extension__, right?
 > 
 > If so, you can put it after
 > 
 > "const"/[^[:alnum:]_]           /* don't care */
 > 
 > like
 > 
 > "__extension__"/[^[:alnum:]_]   /* ignore */
 > 
 > in gengtype-lex.l.
 > 
 > > In the end, I'm trying to get this struct parsed by gengtype:
 > >
 > > struct lang_type_header GTY(())  __extension__


Thanks, that worked.  However in the mean time I was able to get
__extension__ to work in gengtype without this change by putting the
keyword at the beginning of the line instead of the end.
http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00175.html

Still, having gengtype quietly ignore __extension__ might nevertheless
be a useful change to consider.  I could imagine someone else might
need to do it.  Thoughts?

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu