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

[Janis Johnson]

On Wed, Jun 21, 2006 at 12:11:06PM -0700, Mark Mitchell wrote:
> 
> I'm concerned about the use of DECIMAL_FLOAT_MODE_P in this patch.  In
> general, the front ends shouldn't know/care about modes, except in a few
> situations: attributes that refer to modes explicitly, and, if
> necessary, calling convention issues that are visible to the front end.
>  The front ends should know about types, which are language entities,
> not modes, which are machine entities.
> 
> So, at the least, I think all occurrences of:
> 
>   DECIMAL_FLOAT_MODE_P (TYPE_MODE (t))
> 
> should become:
> 
>   DECIMAL_FLOAT_TYPE_P (t)
> 
> where the implementation of the macro uses modes.  That would give
> semantic clarity in the front end code.
> 
> Even better would be if we had a way to tell that a type was a DFP type
> without looking at the mode.  A practical case where this might matter
> is if the compiler gives "struct S { _Decimal_32 d; };" a DFP machine
> mode.  That's a reasonable thing to do -- but "S" is not a DFP type!

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.

Janis

Index: gcc/tree.h
===================================================================
--- gcc/tree.h	(revision 114849)
+++ gcc/tree.h	(working copy)
@@ -966,6 +966,13 @@
         || TREE_CODE (TYPE) == VECTOR_TYPE)	\
        && SCALAR_FLOAT_TYPE_P (TREE_TYPE (TYPE))))
 
+/* 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))
+
 /* Nonzero if TYPE represents an aggregate (multi-component) type.
    Keep these checks in ascending code order.  */