https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112601
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Sergei Trofimovich from comment #8)
> 1. Do I understand correctly that the rejection of `calls_comdat_local`
> inline is a correctness requirement to avoid different definitions of a
> comdat symbol in different translation units?
Yes. If TU#1 splits out part of a comdat function F into another comdat_local
function G, and a function H in TU#1 inlines F, it has a symbolic reference to
G.
If TU#2 then doesn't split F, and the linker chooses TU#2's F, TU#1 ends up
with an unresolved reference to G.
