On Wed, 12 Nov 2014, Thomas Preud'homme wrote:
> In several occasions (see [1][2] people requested a switch to tell GCC
> that a given compilation unit should not contain any float and that GCC
> should warn about any violation of this assumption. Such a switch would
> ensure that no softfloat library is going to be pulled in by the linker
> and would also allow to notify the linker that the resulting file is
> float ABI independent (a feature useful for [3]). A previous patch was
> posted here [4] and this patch tries to address all the comments that
> were done.
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60070
> [2] https://answers.launchpad.net/gcc-arm-embedded/+question/254345
> [3] http://jira.arm.com/browse/GCC32RM-276
> [4] https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01099.html
>
> This patch modifies the C parser to give an error if:
> - any variable or function parameter is declared with a float type or
> a type containing a float (prototype are ignored)
But if you ignore prototypes at the time of declaration, don't you need to
diagnose if a function with a floating-point parameter or return type gets
called? I don't see anything to do that. (This includes the
__builtin_sqrt case from the previous discussion.)
> specified by user and a float litteral is found.
"literal" (throughout).
> @@ -1874,6 +1925,12 @@ c_parser_declaration_or_fndef (c_parser *parser, bool
> fndef_ok,
> }
> else if (c_parser_next_token_is (parser, CPP_SEMICOLON))
> {
> + /* Forbidden declaration of floating point variable. */
> + if (flag_no_float && declarator->kind != cdk_function
> + && contains_floating_point_type (specs->type))
> + error_at (specs->locations[cdw_typespec],
> + "use of floating point data types forbidden in this "
> + "translation unit");
> c_parser_consume_token (parser);
> return;
> }
No, this is wrong. (a) By tying this to CPP_SEMICOLON you'll only catch
it if the variable is last in the list of declarators (consider "float f,
g (void);", where what comes before the semicolon is a function
declaration); better to check on each declarator, not just the last. (b)
declarator->kind reflects the outermost declarator, but what determines
whether it's a function declaration is the innermost declarator (other
than cdk_id or cdk_attrs declarators), so this looks like it would give an
error for "float *f(void);" (wrongly treating it as a variable because the
outermost declarator is cdk_pointer), but not for "float (*f)(void);"
(wrongly treating it as a function because the outermost declarator is
cdk_function ... you could of course decide that function pointers
involving floating-point types are OK if you want). (c) specs->type only
covers the type specifiers, so if you want to diagnose function pointer
variables you need to allow for "int (*f)(float);" where the declaration's
type involves floating point but the type specifiers don't. (d) What do
you want to do with typedef declarations (right now it looks like they'll
be handled as variables, but your testcases don't consider them)?
I'd also suggest some refactoring: have a function that takes as arguments
a location and a type, and does the
if (flag_no_float && contains_floating_point_type (type))
error_at (loc, ...);
to avoid repeating that pattern in several places.
--
Joseph S. Myers
[email protected]
