Re: [PATCH] Mark explicit decls as implicit when we've seen a prototype

[Alexander Monakov <amonakov at ispras dot ru>]

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