[bug][clang] SBC when generating code for calls to explicitly defined ctors of implicit specializations

[cdacamar]

Here's the smallest repro:

void doit();

template <typename>
struct Z {
  Z() = delete;
};

template <>
Z<int>::Z() { doit(); }

int main() {
    Z<int> z;
}

When clang compiles this sample, the call to the ctor is completely gone in the generated code regardless of optimization level.

This is the more elaborate repro: https://godbolt.org/z/PM1vx7oa5.

[llvmbot]

@llvm/issue-subscribers-c-1

Author: Cameron DaCamara (cdacamar)

Here's the smallest repro:

void doit();

template <typename>
struct Z {
  Z() = delete;
};

template <>
Z<int>::Z() { doit(); }

int main() {
    Z<int> z;
}

When clang compiles this sample, the call to the ctor is completely gone in the generated code regardless of optimization level.

This is the more elaborate repro: https://godbolt.org/z/PM1vx7oa5.

[AaronBallman]

I think Clang is getting confused by the = delete; when that is removed, the constructor is correctly called. CC @erichkeane for confirmation this is a valid Clang bug and not an IFNDR thing.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Cameron DaCamara (cdacamar)

Here's the smallest repro:

void doit();

template <typename>
struct Z {
  Z() = delete;
};

template <>
Z<int>::Z() { doit(); }

int main() {
    Z<int> z;
}

When clang compiles this sample, the call to the ctor is completely gone in the generated code regardless of optimization level.

This is the more elaborate repro: https://godbolt.org/z/PM1vx7oa5.

[erichkeane]

Ooof... this is curious.

Though, this is an awful lot like: https://eel.is/c++draft/temp#inst-example-3

But I don't have a good idea of what to expect from the above example otherwise.

interestingly:
https://godbolt.org/z/ohrjxcnsW

GCC is the only one who calls BOTH functions (Ctor + foo). NVC++(aka EDG) + Clang both emit calls to foo (which the above example should show is ill-formed? Perhaps NDR?) but not the ctor.

[shafik]

@erichkeane based on CWG1840 and CWG2260 I think this is meant to be valid.

I am happy to ask core if we feel like this is not clear enough.

CC @zygoloid @hubert-reinterpretcast

[erichkeane]

@erichkeane based on CWG1840 and CWG2260 I think this is meant to be valid.

I am happy to ask core if we feel like this is not clear enough.

CC @zygoloid @hubert-reinterpretcast

Looks like CWG2260 has been integrated into the standard (Despite that page not saying so, the example in the proposed resolution is the one I quoted above), so I think the intent is for this to be ill-formed.

[shafik]

@erichkeane based on CWG1840 and CWG2260 I think this is meant to be valid.
I am happy to ask core if we feel like this is not clear enough.
CC @zygoloid @hubert-reinterpretcast

Looks like CWG2260 has been integrated into the standard (Despite that page not saying so, the example in the proposed resolution is the one I quoted above), so I think the intent is for this to be ill-formed.

So if you instantiate the specialization before the explicit specialization then everyone rejects it (except MSVC), like the DR is talking about: https://godbolt.org/z/MWorEe7rj so I believe that is meant to be ill-formed not the case we have in the issue but maybe I am being slow here.

[zygoloid]

Under CWG2260 (which was accepted in DR status, so should be applied retroactively), this example is ill-formed. Instantiating Z<int> instantiates the deleted definition of Z<int>::Z(), so the explicit specialization should result in a redefinition error.