On Thu, 13 Nov 2014, Thomas Preud'homme wrote: > > From: Joseph Myers [mailto:jos...@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 jos...@codesourcery.com
