> On 27 Sep 2026, at 21:13, Jason Merrill <[email protected]> wrote:
>
> On 9/27/26 1:12 PM, Iain Sandoe wrote:
>> Hi Jason,
>>> On 27 Sep 2026, at 17:59, Jason Merrill <[email protected]> wrote:
>>>
>>> On 9/27/26 11:01 AM, Iain Sandoe wrote:
>>>> While chasing two testsuite fails for -Os this wrong-code bug surfaced.
>>>> Fix tested on x86_64-linux/darwin. OK for trunk / backports?
>>>> thanks
>>>> Iain
>>>> --- 8< ---
>>>> For Darwin, at least, when -Os is selected we attempt to declone cdtors
>>>> since the platform does not support strong symbol aliases the clones
>>>> are emitted verbatim, leading to larger binaries.
>>>> The unified cdtor is a private implementational detail local to a TU
>>>> and so we should not emit a thunk if that will not be emitted.
>>>
>>> Hmm, isn't the unified ctor linkonce when the separate ctors are?
>> The bug I was seeing was that the thunk got inlined leaving a reference to
>> a C4 that was not emitted; It is quite hard to reproduce since it requires
>> the
>> right combination of sizes - but the libstdc++ testsuite triggers it
>> reliably (was
>> just not able to simplify that). Maybe your comment means that there’s
>> another issue (although the prohibition of the vague-linkage solves it,
>> perhaps
>> that’s a side-effect).
>>>> Likewise, a thunk and the unified body must be selected together at
>>>> link time; for a vague-linkage cdtor COMDAT groups support this but,
>>>> without COMDAT, there is no guarantee and so we have to decline the
>>>> declone and emit ordinary clones instead.
>>>
>>> It's desirable that they are selected together, but is it really necessary?
>>> As long as one is selected, I'd think they should work interchangeably.
>> In principle, I suppose so - they are all supposed to be token-identical
>> (let’s not get into the ‘different TUs with different opts’).
>> So long as the call to the thunkee is properly indirected (either through
>> the GOT [64b] or a machopic indirect symbol [32b]), the static linker should
>> be ok. If the call goes directly we would get a warning.
>> Not sure exactly what avenue to explore on this - it’s a real end-user issue
>> since -Os is a “recommended setting” on the platform.
> This sounds like a duplicate of 125359. As I wrote in response to a patch a
> few months ago which would have similarly disabled -fdeclone-ctor-dtor:
>
> --
> I can see the same failure on x86_64-pc-linux-gnu if I change
> can_alias_cdtor to always return false.
>
> I suspect the problem is that we instantiate the constructor for
> inlining, and we inline the C1 thunk, but then decide not to inline the
> C4 constructor, and don't realize that this means we can't inline C1
> either.
> --
>
> I imagine this breaks with libstdc++ specifically because the extern template
> causes us to avoid emitting an out-of-line copy of the C4, and instead
> referring to the one in the library...but there isn't one, because the
> library wasn't built with -fdeclone-ctor-dtor. Or, on a platform with COMDAT
> groups, because it's an internal symbol anyway.
Yes that all stacks up with what I’m seeing.
It seems that what’s needed is a statement of dependency - if the thunk is
built then
- either c4 must be emitted (private to the TU)
- or the thunk must not be inlined without also inlining c4.
So it seems that we should never be refusing to emit a c4 if a thunk refers to
it?
- one strategy would be to mark the c4 at the point we decide to have the
thunk (mark_needed, maybe?)
- another strategy would be to teach the middle end that if cannot inline a
thunk to a c4 if the c4 is not also inlinable (if the cicumstance is
recognisable). Although that still needs an emitted local c4 to work,
I will continue in the PR, for now - but welcome any guidance about viability
of those two approaches (or suggested alternates).
thanks
Iain
>
> Jason
>
