[Bug lto/91287] LTO disables linking with scalar MASS library (Fortran only)

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287

--- Comment #32 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 5 Aug 2019, luoxhu at cn dot ibm.com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> 
> --- Comment #31 from Xiong Hu XS Luo <luoxhu at cn dot ibm.com> ---
> (In reply to rguenther@suse.de from comment #30)
> > On Fri, 2 Aug 2019, luoxhu at cn dot ibm.com wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
> > > 
> > > --- Comment #28 from Xiong Hu XS Luo <luoxhu at cn dot ibm.com> ---
> > > (In reply to Richard Biener from comment #24)
> > > > Btw, this is controlled by symtab_node::output_to_lto_symbol_table_p which
> > > > has
> > > > 
> > > >   /* FIXME: Builtins corresponding to real functions probably should have
> > > >      symbol table entries.  */
> > > >   if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > > >     return false;
> > > > 
> > > > we could try to do sth like
> > > > 
> > > >   if (TREE_CODE (decl) == FUNCTION_DECL
> > > >       && (fndecl_built_in_p (decl, BUILT_IN_MD)
> > > >           || (fndecl_built_in_p (decl, BUILT_IN_NORMAL)
> > > >               && !associated_internal_fn (decl))))
> > > >     return false;
> > > > 
> > > > but that would still leave us with too many undefineds I guess
> > > > (gcc_unreachable for one).
> > > > 
> > > > We do not currently track builtins that do have a library implementation
> > > > (whether that it is used in the end is another thing, but less important).
> > > > 
> > > > What we definitely can do is put a whitelist above like via the following
> > > > which also catches the case of definitions of builtins.
> > > > 
> > > > Index: gcc/symtab.c
> > > > ===================================================================
> > > > --- gcc/symtab.c        (revision 273968)
> > > > +++ gcc/symtab.c        (working copy)
> > > > @@ -2375,10 +2375,24 @@ symtab_node::output_to_lto_symbol_table_
> > > >       first place.  */
> > > >    if (VAR_P (decl) && DECL_HARD_REGISTER (decl))
> > > >      return false;
> > > > +
> > > >    /* FIXME: Builtins corresponding to real functions probably should have
> > > >       symbol table entries.  */
> > > > -  if (TREE_CODE (decl) == FUNCTION_DECL && fndecl_built_in_p (decl))
> > > > -    return false;
> > > > +  if (TREE_CODE (decl) == FUNCTION_DECL
> > > > +      && !definition
> > > > +      && fndecl_built_in_p (decl))
> > > > +    {
> > > > +      if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
> > > > +       switch (DECL_FUNCTION_CODE (decl))
> > > > +         {
> > > > +         CASE_FLT_FN (BUILT_IN_ATAN2):
> > > > +         CASE_FLT_FN (BUILT_IN_SIN):
> > > > +           return true;
> > > > +         default:
> > > > +           break;
> > > > +         }
> > > > +      return false;
> > > > +    }
> > > >  
> > > >    /* We have real symbol that should be in symbol table.  However try to
> > > > trim
> > > >       down the refernces to libraries bit more because linker will otherwise
> > > 
> > > Hi Richard, no undefineds generated with below code, what's your opinion about
> > > the updated code, please? Thanks.
> > 
> > It will break code calling __builtin_unreachable for example since
> > we'll emit an UNDEF that cannot be satisfied.
> 
> Thanks. I tried to add __builtin_unreachable() in the test case, it can also
> works. As BUILT_IN_UNREACHABLE is defined in buitins.def instead of
> internal-fn.def, so associated_internal_fn will return IFN_LAST for it, then no
> UNDEF of __builtin_unreachable will be emitted to object file.
> 
> Most of functions in internal-fn.def are math functions, I am not sure whether
> you mean the BUILT_IN_NOP or something else?

OK, so a specific example woul dbe __builtin_clz.  IIRC the
DECL_ASSEMBLER_NAME of the functions which have a libgcc fallback is
_not_ the symbol in libgcc (you'd have to double-check).

That said, using associated_internal_fn is probably mostly safe but
not a complete fix since we have builtins like __builtin_strcpy
as well (but of course the C library is always linked).

But I'm fine with an approach that incrementally improves things
here, but without possibly causing link-failures due to bogus
UNDEFs