On Thu, 4 Dec 2014, Richard Biener wrote:
>
> Currently even when I prototype
>
> double exp10 (double);
>
> this function is not available to optimizers for code generation if
> they just check for builtin_decl_implicit (BUILT_IN_EXP10).
> Curiously though the function is identified as BUILT_IN_EXP10 when
> used though, thus the middle-end assumes it has expected exp10
> semantics. I see we already cheat with stpcpy and make it available
> to optimizers by marking it implicit when we've seen a prototype.
>
> The following patch proposed to do that for all builtins.
>
> At least I can't see how interpreting exp10 as exp10 but then
> not being allowed to use it as exp10 is sensible.
>
> Now one could argue that declaring exp10 doesn't mean there is
> an implementation available at link time (after all declaring
> exp10 doesn't mean I use exp10 anywhere). But that's true
> for implicit decls as well - I might declare 'pow', not use
> it and not link against libm. So if the compiler now emits
> a call to pow my link will break:
>
> extern double pow (double, double);
> double x;
> int main ()
> {
> return x*x*x*x*x*x*x*x*x*x*x*x*x*x*x*x*x*x;
> }
>
> links fine with -O0 but fails to link with -Os -ffast-math where
> I have to supply -lm.
>
> So the following patch extends the stpcpy assumption to all builtins.
I think it would be nice if -ffreestanding could be used to disable this kind
of transformations. Compare with folding a loop to memset in a libc function
implementing memset itself.
Thanks.
Alexander
