This is the mail archive of the 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: ping^n: C front end change for decimal floating types

Janis Johnson wrote:

> Is this a reasonable way to check for a decimal float type, given that
> it is REAL_TYPE and has no real distinguishing characteristics other
> than the mode?  This "works" and I'm doing full testing now.

> +/* Nonzero if TYPE represents a decimal floating-point type.  */
> +#define DECIMAL_FLOAT_TYPE_P(TYPE)				\
> +   && (TYPE_MAIN_VARIANT (TYPE) == dfloat128_type_node		\
> +       || TYPE_MAIN_VARIANT (TYPE) == dfloat64_type_node	\
> +       || TYPE_MAIN_VARIANT (TYPE) == dfloat32_type_node))

That might work -- but I bet it will fail for something like:

  typedef __attribute__((packed)) _Decimal32 packed_decimal32;

I would expect that such a type would not have a TYPE_MAIN_VARIANT of
dfloat32_type_node.  In other words, I think TYPE_MAIN_VARIANT sees
through cv-qualification and through typedefs, but not through
attributes, which create a distinct type.

If I'm correct, then I think you would need a bit that distinguishes DFP
should presently only be used for ARRAY_TYPEs.

However, I think that for practical purposes you could also get away with:


This still isn't correct in concept, in that front ends really shouldn't
look at modes and that theoretically the compiler might for some
miraculous reason decide to put a BFP type in a DFP mode register, but
in practice I bet it's right enough.  It will fix the problem I
suggested about single-element structs that get placed into registers.

I'd be happy enough with the second option, as it will at least give us
a single chokepoint on any problems that do arise.

Mark Mitchell
(650) 331-3385 x713

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