Re: ping^n: C front end change for decimal floating types

[Mark Mitchell <mark at codesourcery dot com>]

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)				\
> +  (SCALAR_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
REAL_TYPEs from BFP REAL_TYPEs.  I suggest TYPE_STRING_FLAG, which
should presently only be used for ARRAY_TYPEs.

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

 #define DECIMAL_FLOAT_TYPE_P(TYPE) \
   (SCALAR_FLOAT_TYPE_P (TYPE) \
    && DECIMAL_FLOAT_MODE_P (TYPE_MODE (TYPE))

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
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713