On Tue, Aug 12, 2014 at 11:47:28AM +0200, Marc Glisse wrote:
> Are you sure you want something that strict? If there are floats in the
> code but the compiler manages to get rid of them, it won't cause any
> trouble with the ABI. Besides, if you #include a header that declares a
> function returning a double, but you don't use that function, the
> compilation will still fail. And if you only want to forbid float/double
> at the source level, grep is a pretty good tool. I can't see a test for
> __builtin_sqrt(42). No ObjC?
>
> I am not at all saying the approach is wrong, just making sure that's
> what we want.
Yeah. I bet different people need different levels of this.
E.g. if float/double/long double are the same types in all subABIs, just
passing them by value/returning by value changes between different subABIs,
then complaining about sizeof(double), or say double x = 5.0; global var
etc. is unnecessary, all you care about is whether you aren't using those
types in function args/return values you emit into the code.
Somebody else might want to avoid all floating point instructions in their
code (so, static double x = 5.0; is fine, but e.g. initializer that needs
in C++ runtime code to initialize a static double already would not).
Then if some float/double/long double/_Decimal* type actually changes
the layout in between different ABIs, you might want to complain if
it appears in sizeof/__alignof__ etc.
Jakub
