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

[Mark Mitchell <mark at codesourcery dot com>]

Janis Johnson wrote:
> Yet another ping for a patch to disallow operations on decimal floating
> types and generic floating types:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00712.html

I think it would be bad for our initial DFP release to be obviously out
of synch with the TR, and this patch has been around a long time, so I
guess it's reasonable to consider it in now.

I mentioned this to Joseph offline, and he indicated, reasonably, that
we should have a DFP maintainer for compiler bits.  (He also said he saw
no problems with the patch, from the general C perspective.)  Ben, would
you be interested in that role?  Or, Janis?  (Of course, this will
require SC approval, so I'm just seeing who we might be able to nominate.)

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!

I can't reasonably impose this cleanup on you, as part of this patch
submission, but I'll wheedle for the abstraction macro, and see if
you're willing. :-)

The patch is OK in 48 hours, if Ben doesn't disapprove.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713