[Bug c/79717] New: [bug/not bug] [windows] ms_abi floating data type calling convention
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79717
Bug ID: 79717
Summary: [bug/not bug] [windows] ms_abi floating data type
calling convention
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rudyy.id at gmail dot com
Target Milestone: ---
Before I start, let me give you something:
1. I already report this on
https://sourceware.org/bugzilla/show_bug.cgi?id=21197 .
They say I should go here.
2. This is about ms_abi x64 calling convention.
Specified: this is about floating data type parameter passing.
More specified: this is about "long double" floating data type.
3. Since this is about ms_abi x64,
Let me quote something from
https://msdn.microsoft.com/en-us/library/ms235286.aspx :
"The x87 register stack is unused. It may be used by the callee,
but must be considered volatile across function calls.
All floating point operations are done using the 16 XMM registers.
Integer arguments are passed in registers RCX, RDX, R8, and R9.
Floating point arguments are passed in XMM0L, XMM1L, XMM2L, and XMM3L."
4. I already check some of ms binaries, it is the same like ms say on number 3.
5. I don't really care about this since I didn't use gnuc so often and
I'm already take care my problem by using simple inline assembler.
But, since I'm already report this on number 1 and I'm already check in some
microsoft binaries, why not post it again.
6. Compiler+linker "gcc 6.3-release and binutils 2.27-release" and
"gcc 6.3+rev. 245043 and binutils 2.27+git 1273da0".
7. This isn't about structure like the bug 64243 or 41013 or ...
Now lets go into our real problem.
Test case:
--
long double testldcall(long double value) {
return (value + value); /* ms_abi only see "value" in xmm register */
/* not a pointer for "value" */
}
int main() {
long double a = 2.3;
a = testldcall(a); /* gas passing 'a' into 'testldcall' as a "pointer to
value a" */
/* not as a "value of a" */
}
Lets take a look a log from another c source I'm build using gnuc compiler:
---
/* xmm6 is long double */
69660 2e392 0F29B424 movaps XMMWORD PTR 256[rsp], xmm6
69660 0001
/* xmm6 in the stack */
69661 2e39a 488DAC24 lea rbp, 256[rsp]
69661 0001
/* rcx is a pointer into xmm6 in the stack */
69662 2e3a2 4889E9 mov rcx, rbp
/* call ms_abi dll 'ldclass' */
/* is this correct? it is not according number 3 and */
/* it is not according what I read from ms_abi dll 'ldclass' */
69663 2e3a5 FF15 call[QWORD PTR .refptr.__imp__ldclass[rip]]
Now you see whats the problem, don't you?
GAs passing any 'long double' data type not as a value but a pointer into where
the value are.
In ms_abi, like I quote on number 3 above, using xmm register for passing all
floating data type.
It means its require a value not a pointer where the value are.
GAs did good job on 'float' and 'double', but didn't do the same job for 'long
double'.
[Bug target/80013] New: [ms_abi-windows x86-64] A Pointer Size 64-bit Wide or 32-bit Wide?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80013 Bug ID: 80013 Summary: [ms_abi-windows x86-64] A Pointer Size 64-bit Wide or 32-bit Wide? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rudyy.id at gmail dot com Target Milestone: --- This is a log from a c source I'm compile using -O2 (The weird stuff start on line 790 and so on): 614.p2align 3,,7 615.def_arc4random_buf.part.2; .scl3; .type 32; .endef 616.seh_proc _arc4random_buf.part.2 617_arc4random_buf.part.2: 618 0888 4157 pushr15 619.seh_pushregr15 620 088a 4156 pushr14 621.seh_pushregr14 622 088c 4155 pushr13 623.seh_pushregr13 624 088e 4154 pushr12 625.seh_pushregr12 626 0890 55pushrbp 627.seh_pushregrbp 628 0891 57pushrdi 629.seh_pushregrdi 630 0892 56pushrsi 631.seh_pushregrsi 632 0893 53pushrbx 633.seh_pushregrbx 634 0894 4883EC38 sub rsp, 56 635.seh_stackalloc 56 636.seh_endprologue 637 0898 488B0500 mov rax, QWORD PTR Arc4Rand_Mutex[rip] 637 00 638 089f 4989CEmov r14, rcx 639 08a2 4889D5mov rbp, rdx 640 08a5 4885C0testrax, rax 641 08a8 0F84BF01 je .L94 ... /* CreateMutexA(void* pMutexSecurity, int bOwner, char* pName) */ /* CreateMutexW(void* pMutexSecurity, int bOwner, wchar_t* pName) */ /* InterlockedCompareExchangePointer, basically this is just cmpxchg with a lock */ 789.L94: 790 0a6d 31C9 xor ecx, ecx /* Since the 1st argument is a pointer type, Isn't this suppose to be rcx? */ 791 0a6f 4531C0xor r8d, r8d /* Since the 3rd argument is a pointer type, Isn't this suppose to be r8? */ 792 0a72 31D2 xor edx, edx /* This is correct, since the 2nd argument is a BOOL (32-bit wide) */ GAS LISTING D:\Documents\GCC-MinGW\_Temp\ccwQlMZr.spage 20 793 0a74 FF15 call[QWORD PTR __imp_CreateMutexW[rip]] 793 794 0a7a 4889C1mov rcx, rax 795 0a7d 4885C0testrax, rax 796 0a80 743D je .L105 797.L47: 798 0a82 31C0 xor eax, eax /* Isn't this suppose to be rax? */ 799 0a84 F0480FB1 lock cmpxchgQWORD PTR Arc4Rand_Mutex[rip], rcx 799 0D00 799 00 800 0a8d 4885C0testrax, rax /* Hey its rax, but the comparand is eax? */ 801 0a90 0F8418FE je .L46 Using GNUC 6.3.0 + Binutils 2.28 + mingw64 header and libs 2017. Build by msys2. Using GNUC 7.x + Binutils 2.28 + mingw64 header and libs 2017. Build by someone from x265 developer. Both compiler show the same result but 7.x had better optimization than 6.x :) Both compiler also show the same result if I'm using ATT silent option (no log output except error stuff). Disassembler ms dll and take a look inside for CreateMutexW: test edx,edx /* 2nd argument from the caller */ mov rax,r8 /* 3rd argument is r8 from the caller but gnuc using r8d? */ jnz . xor r8d,r8d / 3rd Argument for CreateMutexExW ; its int/DWORD */ mov r9d,0001F0001 /* Access Method ; 4rd argument for CreateMutexExW ; its int/DWORD */ mov rdx,rax /* 2nd Argument for CreateMutexExW , taken from 3rd argument of the caller */ jmp CreateMutexExW nop nop
[Bug target/80013] [ms_abi-windows x86-64] A Pointer Size 64-bit Wide or 32-bit Wide?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80013 --- Comment #1 from Rudy Y. --- Disassembler 'libcrypto-41.dll' - LibreSSL x64 2.5.1 - compile by Libre developer itself using gnuc compiler ( version 5.4.0? ): xor ecx,ecx /* same as above! */ xor r8d,r8d /* same as above! */ xor edx,edx /* same as above! */ call CreateMutexA /* CreateMutex(NULL, FALSE, NULL) */ mov rcx,rax mov rax,rbx /* Different? */ lock cmpxchg [],rcx test rax,rax jz . call CloseHandle Event 5.x got this problem too.
