This is the mail archive of the
mailing list for the GCC project.
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) \
> + (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.
(650) 331-3385 x713