"Wrong" name mangling for operator== in extern "C"

[Alcaro]

struct mytype {};

extern "C" {
bool operator==(const mytype & a, const mytype & b);
}

bool foo(const mytype & a)
{
 return a == a;
}

Clang:

_Z3fooRK6mytype:
        mov     rsi, rdi
        jmp     _ZeqRK6mytypeS1_@PLT

GCC:

_Z3fooRK6mytype:
        mov     rsi, rdi
        jmp     _Zeq

I don't particularly care which name is used, but you're supposed to match GCC, right? (Or is GCC the one that's wrong? I'll file this against them instead if you prefer that.)

https://godbolt.org/z/xhh7T7KGd

https://eel.is/c++draft/over.literal#6 bans extern "C" for user defined literals, and such language is absent on other operators, so I think extern "C" must be tolerated on other opeerators. But they should probably be a warning.

(Originally found in mingw headers https://godbolt.org/z/xx4EP9bxG - they forgot an extern "C++" in guiddef.h.)

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (Alcaro)

```c++ struct mytype {};

extern "C" {
bool operator==(const mytype & a, const mytype & b);
}

bool foo(const mytype & a)
{
return a == a;
}

Clang:
```asm
_Z3fooRK6mytype:
        mov     rsi, rdi
        jmp     _ZeqRK6mytypeS1_@<!-- -->PLT

GCC:

_Z3fooRK6mytype:
        mov     rsi, rdi
        jmp     _Zeq

I don't particularly care which name is used, but you're supposed to match GCC, right? (Or is GCC the one that's wrong? I'll file this against them instead if you prefer that.)

https://godbolt.org/z/xhh7T7KGd

<https://eel.is/c++draft/over.literal#6> bans extern "C" for user defined literals, and such language is absent on other operators, so I think extern "C" must be tolerated on other opeerators. But they should probably be a warning.

(Originally found in mingw headers https://godbolt.org/z/xx4EP9bxG - they forgot an extern "C++" in guiddef.h.)

[shafik]

I think gcc is "correct" here for some definition of correct. I am struggling to find any documentation that would explain how this is expected to work, I suppose if you know how to hold it just right it works.

If we modify the example we get more consistent results: https://godbolt.org/z/ehb3x9K1x so I think clang is not doing the "right thing"™️ for all cases.

CC @AaronBallman

[pinskia]

Note MSVC does:

bl          |==|

and note EDG does:

_Zeq

Both which match GCC idea here.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: None (Alcaro)

```c++ struct mytype {};

extern "C" {
bool operator==(const mytype & a, const mytype & b);
}

bool foo(const mytype & a)
{
return a == a;
}

Clang:
```asm
_Z3fooRK6mytype:
        mov     rsi, rdi
        jmp     _ZeqRK6mytypeS1_@<!-- -->PLT

GCC:

_Z3fooRK6mytype:
        mov     rsi, rdi
        jmp     _Zeq

I don't particularly care which name is used, but you're supposed to match GCC, right? (Or is GCC the one that's wrong? I'll file this against them instead if you prefer that.)

https://godbolt.org/z/xhh7T7KGd

<https://eel.is/c++draft/over.literal#6> bans extern "C" for user defined literals, and such language is absent on other operators, so I think extern "C" must be tolerated on other opeerators. But they should probably be a warning.

(Originally found in mingw headers https://godbolt.org/z/xx4EP9bxG - they forgot an extern "C++" in guiddef.h.)

[Alcaro]

MSVC literally emits a symbol named ==, not anything mangled. I'm about 99% sure that will interact interestingly with things like assemblers and debuggers, and is a bug of its own.

Anyway, feel free to tag this one diverges-from:msvc Does the clang frontend diverge from msvc on this issue as well. https://godbolt.org/z/134scsooz

[shafik]

I think we should at least diagnose this case, does anyone have a minimal example showing how this is supposed to work? We have three different approaches here, so at this point it is not very portable.

[AaronBallman]

From https://itanium-cxx-abi.github.io/cxx-abi/abi.html:

A "Y" prefix for the bare function type encodes extern "C" in implementations which distinguish between function types with "C" and "C++" language linkage. This affects only type mangling, since extern "C" function objects have unmangled names.

So it sounds like we should be mangling the function type but not the function name, which oddly matches the MSVC behavior... with the Itanium ABI... which is not what I was expecting to learn today.

CC @rjmccall @zygoloid for some more ABI expertise.