[4.5] pragma FLOAT_CONST_DECIMAL64 for decimal float support

[Janis Johnson]

On Sat, 2009-02-28 at 00:36 +0000, Joseph S. Myers wrote:
> On Fri, 27 Feb 2009, Janis Johnson wrote:
> 
> > This patch implements pragma FLOAT_CONST_DECIMAL64 from draft N1312 of
> > DTR 24732, the decimal float extension for C.  The pragma specifies
> > whether an unsuffixed float constant has type double or _Decimal64 and
> > takes effect until the next FLOAT_CONST_DECIMAL64 pragma or the end of
> > the current scope.  The pragma is ignored for C++.
> 
> It seems a bit surprising that this applies to hexadecimal floating-point 
> constants.  The draft doesn't exclude them, but are we sure that was 
> actually what was intended?

Hexadecimal floating-point constants aren't allowed for decimal float,
so they should be rejected without a suffix with FLOAT_CONST_DECIMAL64
is in effect.  That was an oversight, and will probably require some
shuffling of where the default is detected and handled.

> What is your strategy for dealing with unsuffixed constants in headers, 
> especially in macros?

N1312 talks about that in 7.1.1: "But unless and until it is known that
all the headers used by a program have been modified to use an explicit
d or D suffix on constants of type double, setting this pragma to the
"on" state requires extreme caution."

Does that mean we let users shoot themselves in the foot, or that we
shouldn't support this pragma until decimal float support, or at least
the use of d or D in header files, is widespread?

> Let's divide this into four cases:
> 
> * Macros predefined by GCC.  In particular, all the __DBL_* macros.  
> Enabling the variant definitions of these macros (casting a long double 
> value to double) used for -fsingle-precision-constant when decimal 
> floating point is supported, or unconditionally, should solve this issue.
> 
> * Headers installed by all-languages-enabled GCC on any target supporting 
> DFP for use in C code.  I don't know if any of these contain unsuffixed 
> floating-point constants at all.  You need to determine that and adjust 
> them if so.
> 
> * Headers from the GNU C library.  For example, the M_* values in math.h.  
> Do you have a plan for handling these and keeping up with future macro 
> definitions, that is practical given what the GNU C library maintainers 
> will accept?  Will you be adding fixincludes support to adjust definitions 
> in headers predating your plan?
> 
> * Other headers commonly used on GNU/Linux systems.  Do you expect library 
> maintainers to adapt them to support code using this pragma?

Not in the forseeable future, certainly.

> I think the first two should be resolved before this can go in.  The 
> second two are factors determining how useful this feature can be in 
> practice on GNU/Linux (and DFP is only supported at present on GNU/Linux).
> 
> > When it's merged to trunk the docs will need an update since they now
> > say that the pragma is not supported.
> 
> No, you should update docs on the branch with the same patch that changes 
> the code.

That particular section of documentation went into trunk on 2009-02-11
and is not yet in the c-4.5 branch.

> > +  if (!strcmp (arg, "ON"))
> > +    set_float_const_decimal64 ();
> > +  else if (!strcmp (arg, "OFF"))
> > +    clear_float_const_decimal64 ();
> > +  else if (!strcmp (arg, "DEFAULT"))
> > +    clear_float_const_decimal64 ();
> > +  else
> > +    GCC_BAD ("malformed %<#pragma STDC FLOAT_CONST_DECIMAL64%>, ignored");
> > +
> > +  if (pragma_lex (&t) != CPP_EOF)
> > +    GCC_BAD ("junk at end of %<#pragma STDC FLOAT_CONST_DECIMAL64%>");
> 
> I think the ON/OFF/DEFAULT parsing should be split out into a separate 
> small function; it's relevant to other STDC pragmas as well.

OK.

> > +{
> > +  /* Use value from outer scope, which is OFF.  */
> > +  double a = 1.0 * 2.0d;
> > +#pragma STDC FLOAT_CONST_DECIMAL64 ON
> > +  double b = 2.0 * 3.0dd;
> > +#pragma STDC FLOAT_CONST_DECIMAL64 OFF
> > +  double c = 3.0 * 4.0d;
> > +#pragma STDC FLOAT_CONST_DECIMAL64 ON
> > +  double d = 4.0 * 5.0dd;
> > +#pragma STDC FLOAT_CONST_DECIMAL64 DEFAULT
> > +  double e = 5.0 * 6.0d;
> > +#pragma STDC FLOAT_CONST_DECIMAL64 ON
> > +  double f = 6.0 * 7.0dd;
> 
> This is not defined code.  "The pragma shall occur either outside external 
> declarations or preceding all explicit declarations and statements inside 
> a compound statement.".  Diagnosing this isn't required (by the TR or by 
> me for this patch to go in), but tests should be valid (you could add some 
> extra brace levels to make it valid) and it would probably be best to 
> diagnose misuse of this pragma.  Registering it as a deferred pragma 
> processed in the course of parsing should allow it to be properly 
> restricted (note there are various places the parser allows pragmas that 
> may be appropriate for OpenMP but not for this particular pragma).

Oops, another big oversight.

> I think there should also be tests verifying that defining STDC or 
> FLOAT_CONST_DECIMAL64 or ON or OFF or DEFAULT as macros does not affect 
> recognition of this pragma (STDC pragmas are explicitly not macro 
> expanded).

OK.

Thanks for the quick feedback, I've got lots more work to do.

Janis