Re: Add __builtin_complex to construct complex values (C1X CMPLX* macros)

["Joseph S. Myers" <joseph@codesourcery.com>]

On Mon, 22 Aug 2011, Gary Funck wrote:

> 
> On 08/19/11 15:55:12, Joseph S. Myers wrote:
> > Index: gcc/c-family/c-common.h
> > ===================================================================
> > --- gcc/c-family/c-common.h	(revision 177894)
> > +++ gcc/c-family/c-common.h	(working copy)
> > @@ -103,7 +103,7 @@ enum rid
> >    /* C extensions */
> >    RID_ASM,       RID_TYPEOF,   RID_ALIGNOF,  RID_ATTRIBUTE,  RID_VA_ARG,
> >    RID_EXTENSION, RID_IMAGPART, RID_REALPART, RID_LABEL,      RID_CHOOSE_EXPR,
> > -  RID_TYPES_COMPATIBLE_P,
> > +  RID_TYPES_COMPATIBLE_P,      RID_BUILTIN_COMPLEX,
> >    RID_DFLOAT32, RID_DFLOAT64, RID_DFLOAT128,
> >    RID_FRACT, RID_ACCUM,
> 
> Joseph,
> 
> Does this comment also need to be adjusted?
> 
> /* Reserved identifiers.  This is the union of all the keywords for C,
>    C++, and Objective-C.  All the type modifiers have to be in one
>    block at the beginning, because they are used as mask bits.  There
>    are 28 type modifiers; if we add many more we will have to redesign
>    the mask mechanism.  */
> 
> That is: 28 -> 29?

This isn't a type modifier; neither is __builtin_types_compatible_p.  It's 
not within the first 28.

> BTW, unfortunately for GUPC, this will bump the number of bits
> it uses to *32*.  Thus, any subsequent addition of RID's will
> cause GUPC to exceed the 32-bit barrier.
> 
> Is it time to consider increasing the bit range of
> this set of flag bits?

I don't believe the comment is accurate; I'm not aware of any code for any 
C-family front end that uses these values as mask bits at all.

-- 
Joseph S. Myers
joseph@codesourcery.com