Re: [RFC] Enable math functions linking with static library for LTO

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Aug 21, 2019 at 9:56 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> I'm afraid I'm not clear on the semantics of builtin_with_linkage_p (as in
> the current checked-in version).  It says:
>
> /* Return true if the builtin DECL is implemented in a standard library.
>    Otherwise returns false which doesn't guarantee it is not (thus the list of
>    handled builtins below may be incomplete).  */
>
> But what does "is implemented in a standard library" mean?  Certainly
> plenty of GCC ports are for systems that e.g. don't have fmaf64 which is
> included in that switch statement, and calls to fmaf64 on such systems
> will result in an undefined reference unless it's on an architecture where
> GCC can expand that inline.
>
> Specifically: does Tejas's roundeven patch (and likewise the fadd patch)
> need updating to add those functions to the switch statement in
> builtin_with_linkage_p?  What are the correct semantics for a built-in
> function with the following properties: it may not be in the system libc /
> libm on all systems, but GCC can't always expand it inline either, so it
> may result in an undefined reference on systems where it's not in system
> libc / libm?
>
> If it's only meant to be for functions you *know* are in a standard
> library on the system used, I'd expect checks of the libc_has_function
> target hook.  If, however, it's meant to be for functions that might
> result in an undefined reference (where GCC expects there to be a library
> function to satisfy that reference, but some systems don't have that
> function), I'd expect it to be based on whether a library name was passed
> when add_builtin_function was called, if that's something you can
> determine by examining the DECL - and in that case I wouldn't expect
> there to be a long switch statement listing particular functions, because
> the relevant information is specified when the built-in functions are
> created in the first place.

So before the patch we did not tell the linker that we have UNDEFs
to any of those symbol in the IL which means its resolution computation
could be off if for example static libraries were involved.  Usually at
final link time it fixed things for us as those UNDEFs then eventually
appeared out of nothing (as if GCC late generated them).

With the patch I wanted to make sure we never end up link-failing
(due to unresolved symbols) on the IL output of UNDEFs, so we
now have the explicit list of builtins I believe always come from
some library that the GCC link or the user eventually appends to
the linker command line.

Not sure if that helps answering your question.  In essence,
this function should tell whether we would emit an UNDEF
in the end and we want to know that early, at LTO IL generation
time to communicate this to the linker plugin.  Given previous
behavior I want to error on the side of rather omitting the UNDEF.

Richard.

>
> --
> Joseph S. Myers
> joseph@codesourcery.com