Re: [4.5] take 2: pragma FLOAT_CONST_DECIMAL64 for decimal float support

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 17 Mar 2009, Janis Johnson wrote:

>   - Disallow unsuffixed hex and imaginary constants when the pragma is
>     in effect.

Disallowing otherwise unsuffixed decimal imaginary constants seems 
plausible (but I'm not sure it's a good idea; it would prevent using 
<complex.h>'s definition of _Complex_I using 1.0iF, for example), but for 
unsuffixed hex constants I'd think it would be natural to follow N1369 and 
allow them as double.

> Index: gcc/c-cppbuiltin.c
> ===================================================================
> --- gcc/c-cppbuiltin.c	(revision 144896)
> +++ gcc/c-cppbuiltin.c	(working copy)
> @@ -626,7 +626,7 @@ c_cpp_builtins (cpp_reader *pfile)
>    if (flag_single_precision_constant)
>      builtin_define_float_constants ("DBL", "L", "((double)%s)", double_type_node);
>    else
> -    builtin_define_float_constants ("DBL", "", "%s", double_type_node);
> +    builtin_define_float_constants ("DBL", "L", "((double)%s)", double_type_node);

The effect of this is to use the new definition unconditionally, in which 
case you should remove the if and insert a comment explaining the use 
cases (-fsingle-precision-constant and this pragma) needing the definition 
as long double and the cast.

> +/* Warn about float constants without suffixes.  */
> +
> +extern int warn_unsuffixed_float_consts;

Is this actually needed when the c.opt entry should cause an automatically 
generated declaration?

> +	warning (OPT_Wunknown_pragmas,
> +		 "%<#pragma STDC_FLOAT_CONST_DECIMAL64%> is not supported"
                                ^ stray underscore here

> +	warning (OPT_Wunknown_pragmas,
> +		 "%<#pragma STDC_FLOAT_CONST_DECIMAL64%> is not supported"
                                ^ likewise

> +Wunsuffixed-float-constants
> +C ObjC Var(warn_unsuffixed_float_constants) Warning
> +Warn about unsuffixed float constants

> +    case OPT_Wunsuffixed_float_constants:
> +      warn_unsuffixed_float_consts = value;
> +      break;

Do you actually need this code, when you used Var in the option definition 
above?

You set current_scope->valid_for_stdc_pragma = false when processing 
declaration specifiers, but I don't see anything to do so when processing 
a statement in a scope with no declarations.  Also, do you require the 
pragmas to come before __label__ declarations?  It would seem natural to 
do so; either way, a testcase is needed.

As I understand it, you are implementing these as non-deferred pragmas 
which will be handled as soon as the preprocessor lexes them.  Given that 
I'd expect that as soon as c_parser_compound_statement_nostart looks at 
the next token, any of these pragmas before that token will be handled.  
And so the right place to set current_scope->valid_for_stdc_pragma = false 
would be in c_parser_compound_statement_nostart immediately after we've 
found the compound statement isn't empty.  Certainly putting the code in 
that function seems more reliable than basing it on addition of 
declaration specifiers.  In your test of invalid locations, I think the 
second pragma it toplevel is OK; it's outside external declarations, and 
having pragmas between two such declarations is OK.  You do however need 
to avoid the pragma being in a random place inside an external 
declaration, e.g. inside a struct definition.  I suppose that 
c_parser_translation_unit should clear the flag before calling 
c_parser_external_declaration and set it afterwards (the pragmas outside 
external declarations would be handled each time it checks if the next 
token is CPP_EOF).

-- 
Joseph S. Myers
joseph@codesourcery.com