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

["Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>]

 > 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