[cfe-dev] BUG: complete misunterstanding of the MS-ABI

[Jean-Daniel via cfe-dev]

> Le 5 sept. 2020 à 23:42, Stefan Kanthak <stefan.kanthak at nexgo.de> a écrit :
> 
> "Jean-Daniel" <mailing at xenonium.com <mailto:mailing at xenonium.com>> wrote:
> 
>>> Le 3 sept. 2020 à 23:25, Stefan Kanthak via cfe-dev <cfe-dev at lists.llvm.org> a écrit :
>>> 
>>> "Anton Korobeynikov" <anton at korobeynikov.info> wrote:
>>> 
>>>>> Since MSVC does NOT support an (unsigned) __int128 data type, __uint128_t
>>>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>> is a user-defined type there, for which the cited specs clearly state how
>>>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>> to return it.
>>>>> 
>>>> WRONG USER INTERPRETATION:  __uint128_t is not a user-defined type.
>>> 
>>> OUCH!
>>> Which part of my underlined words are not understood?
>>> In the MS-ABI, it is an user-defined type.
>>> clang claims to be ABI-compatible, but it's implementations fails
>>> to support that claim!
>>> 
>> 
>> If MSVC does not support __int128, how could compile code that use it in the first place ?
> 
> Please read my initial post, CAREFULLY: it shows the source I used.
> 
>>> You probably define a custom type (user defined).
> 
> Yes, with MSVC: see above!
> 

The clang version is fine, this the the MSVC version that define a type using a compiler reserved name and make assumptions about it.

>> The fact that you choose to use an other (incompatible) type when compiling with
>> clang (a compiler define __int128) can hardly be considered a compiler bug.
> 
> Don't try to make up any "facts": READ the source I posted!
> 
> LLVM/clang CLAIMS(!) to be ABI-compatible with MSVC, for example there
> <https://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html <https://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html>>
> 
> | Clang is the first-ever open-source C++ compiler that's ABI-compatible with
> | Microsoft Visual C++ (MSVC) - meaning you can build some parts of your program
> | (for example, system libraries) with the MSVC compiler ("cl.exe"), other parts
> | with Clang, and when linked together (either by MSVC's linker, "link.exe", or
> | LLD, the LLVM project's linker - see below) the parts will form a working program.
> 
> Now read the specification of the Microsoft ABI
> <https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention <https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention>>
> 
> | User-defined types can be returned by value from global functions and
> | static member functions. To return a user-defined type by value in RAX,
> | it must have a length of 1, 2, 4, 8, 16, 32, or 64 bits. [...]
> | Otherwise, the caller must allocate memory for the return value and
> | pass a pointer to it as the first argument. The remaining arguments
> | are then shifted one argument to the right. The same pointer must be
> | returned by the callee in RAX.
> 
>> Just use the same user defined type with clang, and you will get the right behaviour.
> 
> Again: start to read what I already posted!
> I use clang's own __uint128_t data type and show the assembly it generates,
> which is but INCOMPATIBEL with the MS-ABI.

And this is perfectly legit. As the MS-ABI does not support the __int128 type, using it with MSVC is an undefined behaviour.


> 
>> That the kind of issue you get when defining custom type using compiler
>> reserved name (double underscore).
> 
> OUCH: read again what I wrote, CAREFUL, especially the source I posted.
> I don't use a compiler reserved name!

How do you call that then ?

>> typedef struct {
>>    unsigned __int64 low;
>>    unsigned __int64 high;
>> } __uint128_t;


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200906/045ef189/attachment-0001.html>