https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111958
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> which we first ICF and then inline back. So it looks like when
> "materializing"
> the alias clone for getegid we get a wrong location (or the location for the
> alias clone is broken / not initialized?)
I think we don't set it at all (i.e. keep it UNKNOWN_LOCATION), after all, it
doesn't correspond to any particular source line in the function, e.g. even
just trying to use a location of a particular return stmt is wrong, the
function could have multiple returns.
So it is even in -fdump-{tree,ipa}-all-lineno dumps
retval.5_4 = setgid (gid_2(D)); [tail call]
return retval.5_4;
The unistd.h locus appears during expansion, seems to match the
DECL_SOURCE_LOCATION of the first declaration of the function or something like
that.
ICF is simply very much harmful to all the locations in the function, if it is
not inlined back, we have have the elsewhere tracked problem that the merged
function can have solely locations/scopes etc. of one of the functions and not
the others,
if it is inlined back, the debug info will pretend that another function has
been inlined into the current one even when that is not true.
The latter perhaps could be improved by somehow just noting to turn a function
into the thunk at the end of IPA passes and if we'd in between decide to inline
itself back into the function, somehow arrange to use the original body rather
than the thunk with the other function inlined into it. Similarly for
fnsplit...
