clang++-18/main miscompilation on windows

[egorpugin]

Windows, llvm v18.1.6 or 19 from main branch.

clang-cl -c main.cpp -std:c++17

or

clang++  -c main.cpp -std=c++17

struct A { int v; };
struct B { int v; };

template <auto Field>
void f() {}

int main() {
    f<&A::v>();
    f<&B::v>();
}

main.cpp(5,6): error: definition with same mangled name '??$f@$0A@@@YAXXZ' as another definition
    5 | void f() {}
      |      ^
main.cpp(5,6): note: previous definition is here
1 error generated.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Egor Pugin (egorpugin)

Windows, llvm v18.1.6 or 19 from main branch.

clang-cl -c main.cpp -std:c++17
or
clang++  -c main.cpp -std=c++17

struct A { int v; };
struct B { int v; };

template <auto Field>
void f() {}

int main() {
    f<&A::v>();
    f<&B::v>();
}

main.cpp(5,6): error: definition with same mangled name '??$f@$0A@@@<!-- -->YAXXZ' as another definition
    5 | void f() {}
      |      ^
main.cpp(5,6): note: previous definition is here
1 error generated.

[egorpugin]

If we write auto instead of void we get wrong results in runtime.

template <auto Field>
auto f() {
    printf("%s\n", __PRETTY_FUNCTION__);
}

results in

auto f() [Field = &B::v]
auto f() [Field = &B::v]

but must be

auto f() [Field = &A::v]
auto f() [Field = &B::v]

---

full

#include <stdio.h>

struct A { int v; };
struct B { int v; };

template <auto Field>
auto f() {
    printf("%s\n", __PRETTY_FUNCTION__);
}

int main() {
    f<&A::v>();
    f<&B::v>();
}

[Endilll]

It's worth noting that the diagnostic points to the declaration of enclosing function, instead of pointing to offending instantiation.

[llvmbot]

@llvm/issue-subscribers-c-17

Author: Egor Pugin (egorpugin)

Windows, llvm v18.1.6 or 19 from main branch.

clang-cl -c main.cpp -std:c++17

or

clang++  -c main.cpp -std=c++17

struct A { int v; };
struct B { int v; };

template <auto Field>
void f() {}

int main() {
    f<&A::v>();
    f<&B::v>();
}

main.cpp(5,6): error: definition with same mangled name '??$f@$0A@@@<!-- -->YAXXZ' as another definition
    5 | void f() {}
      |      ^
main.cpp(5,6): note: previous definition is here
1 error generated.

[Endilll]

Looks like Microsoft mangling of pointers to members is known to be problematic: #92033, #70899

[frederick-vs-ja]

Clang seems currently bug-compatible with MSVC before VS2019 16.0/19.20 (Godbolt link).

It's unfortunate that MSVC is still buggy on different variant members of the same type and at the same offset to a union (Godbolt link).

union MyUnion {
    int one;
    int two;
};

template <auto>
void f() {}

int main() {
    // There should be two specializations instantiated, but MSVC only gives one.
    // Both mangle names are collapsed into '??$f@$MPEQMyUnion@@H0A@@@YAXXZ'.
    f<&MyUnion::one>();
    f<&MyUnion::two>();
}

[egorpugin]

Maybe it should do so for clang-cl, but not for clang++?
Usual clang++ can also build a lot of software in non-msvc mode on windows these days.

[Endilll]

Usual clang++ can also build a lot of software in non-msvc mode on windows these days.

It can, but I don't think it would be the right default. I think Windows software expect Microsoft mangling.
Anyway, this is an RFC-level question. Feel free to post one on our Discourse!

[MaxEW707]

For reference I have a PR up which fixes this mangling since MSVC fixed it starting in 1920 (VS2019). MSVC 1914 (VS2017) really doesn't support C++17 well.

This is the PR, #97007, that fixes this issue so when that is merged we can close this issue out.

I am trying to fix as many mangling issues as I can as I run into them as well on my side :). Clang 19 should have a lot of MSVC specific fixes coming in.

Usual clang++ can also build a lot of software in non-msvc mode on windows these days.

It can, but I don't think it would be the right default. I think Windows software expect Microsoft mangling. Anyway, this is an RFC-level question. Feel free to post one on our Discourse!

I agree that it isn't the right default. I would expect we try to honour the msvc name mangling 1:1 by default.
I, at least the software I ship, relies on this because we get static library drops from some third parties that are compiled with MSVC and Clang must honour MSVC (including its faults in mangling). A lot of times we also get drops for different MSVC versions such as vc141 to vc143 since MSVC changed mangling between those versions.

Other times we have teams that pre-compile some of our internal support libs to save on build iteration time and that is usually done with MSVC as the core code of the software is transitioning towards Clang.

I also agree that for users who mostly care about C library interfaces or minimal C++ interfaces like interfacing with the DirectX APIs but the rest of the code is completely compiled from source and only compiled with Clang then we can have more leeway with the mangling to overcome MSVC bugs.

Recently I ran into this auto mangling issue, https://godbolt.org/z/r1oGP3jn9. I had code built with MSVC and Clang result in two different definitions of the same function instead of merging into one definition at link time.
This mangling appears to be explicit according original impl, 2e1e049.
From the godbolt you will also notice that VS2019+ mangles differently from VS2017. This isn't uncommon.

In this case I haven't dug deep enough to know if the VS2019 is sufficient or if a custom mangling is still technically necessary.
I need to dig more here once my PR above gets merged.

I do think that staying true to MSVC by default is ideal with an option for users to use an MSVC-[like] mangling which may fix any MSVC mangling issues for those who don't need full MSVC semantics including its bugs.
I'll start a Discourse which will take a week or so for me to get to it :).

[egorpugin]

Following ms abi is fine, but can't correct functioning be put behind a flag?
Like -fbreak-msabi?

Users wanting correct behavior should not suffer from it.

[Endilll]

Following ms abi is fine, but can't correct functioning be put behind a flag? Like -fbreak-msabi?

Users wanting correct behavior should not suffer from it.

A new triple, e.g. x86_64-pc-windows-clang, would be a better vehicle for that, I think.

[MaxEW707]

@egorpugin I merged #97007 which adds support for the new mangling used in VS2019 and VS2022. This issue should be fixed in mainline now. Feel free to test out mainline and close this issue out.

I still intend to get up a discourse to discuss other issues with MSVC mangling like the one @frederick-vs-ja mentioned with unions and how to go about that, likely with a new triple.

[egorpugin]

Confirmed, works on trunk.
Thank you.