RE: [PATCH, RFC, C] Add -fno-float to forbid floating point data types

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 13 Nov 2014, Thomas Preud'homme wrote:

> > From: Joseph Myers [mailto:joseph@codesourcery.com]
> > Sent: Wednesday, November 12, 2014 10:11 PM
> > >
> > > 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.)
> 
> It would work by transitivity. To call a function with a float you'd have to
> either declare a float variable or pass it a float literal.

Or pass in an integer value, which gets implicitly converted to floating 
point because of the prototype.  Detecting that case requires checking 
calls.

> Thanks a lot for the review. Except on the patch itself, what do you think of
> the general approach? Do you think doing this in the frontend is the right
> approach?

If you want to define a language subset, where it is predictable what is 
accepted, then doing it in the front end is right.

If you want to accept as much code as possible and only give errors if 
floating-point code would actually be generated - for example, if you want 
to be able to #include <stdlib.h> with glibc (where it defines an inline 
version of atof) - then you need to look at GIMPLE after optimization, 
taking into account which functions will actually be output so as to 
ignore unused inline functions.

-- 
Joseph S. Myers
joseph@codesourcery.com