Firm Bugtracker - libFirm
Viewing Issue Advanced Details
174 x86 ia32 backend minor always 2016-01-24 12:39 2016-01-31 00:39
lindig  
Matze  
normal  
resolved  
fixed  
none    
none  
0000174: OS X requires compound types with single float value to be returned in x87 register.
Is the code generated by cparser supposed to be linkable against code generated by other compilers? I have a test case where compiling one file with cparser and the other with clang leads to code that segfaults when executed. When cparser is replaced by gcc, the code works as expected. The code is designed to test the implementation of calling conventions. The segfaults suggests that the two compilers implement calling conventions differently.

./cparser -c quest-callee.c
clang -c quest-main.c
clang -o foo quest-callee.o quest-main.o
./foo

I have included a tar file with all source files.
:debug $ clang --version
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

gz file icon bug.tar.gz [^] (1,579 bytes) 2016-01-24 12:39
gz file icon bug-m32.tar.gz [^] (1,541 bytes) 2016-01-25 09:17
Issue History
2016-01-24 12:39 lindig New Issue
2016-01-24 12:39 lindig File Added: bug.tar.gz
2016-01-25 05:33 Matze Note Added: 0000260
2016-01-25 05:39 Matze Project cparser => libFirm
2016-01-25 05:39 Matze Severity crash => major
2016-01-25 05:39 Matze Status new => confirmed
2016-01-25 05:39 Matze Category targets => x86_64 backend (amd64)
2016-01-25 09:17 lindig Note Added: 0000261
2016-01-25 09:17 lindig File Added: bug-m32.tar.gz
2016-01-26 05:43 Matze Note Added: 0000262
2016-01-26 05:43 Matze Note Edited: 0000262
2016-01-26 05:44 Matze Severity major => minor
2016-01-26 05:44 Matze Reproducibility have not tried => always
2016-01-26 05:44 Matze Category x86_64 backend (amd64) => x86 ia32 backend
2016-01-26 05:44 Matze Summary Linking interoperability with other compilers => OS X requires compound types with single float value to be returned in x87 register.
2016-01-26 09:55 lindig Note Added: 0000263
2016-01-31 00:39 Matze Note Added: 0000264
2016-01-31 00:39 Matze Assigned To => Matze
2016-01-31 00:39 Matze Status confirmed => resolved
2016-01-31 00:39 Matze Resolution open => fixed
2016-01-31 00:40 Matze Note Edited: 0000264

Notes
(0000260)
Matze   
2016-01-25 05:33   
Yes of course we want to be compatible with the ABIs of the specific platforms.

Having said that, one of the reasons why we still consider the x86_64 backend experimental is that calling convention for struct parameters and return values is not correct yet. The ia32 backend (use with -m32) on the other hand has no known bugs on the ABI (at least on linux and OS/X).
(0000261)
lindig   
2016-01-25 09:17   
I've tried this again with gcc and -m32. This works much better and generally works. I still found a test case where a parameter is not passed correctly:

    ./cparser -m32 -c quest-callee.c
    gcc -m32 -c quest-main.c
    gcc -m32 -o foo quest-callee.o quest-main.o
    ./foo || break
Assertion failed: (b32.b31 == b42.b31), function caller_b1f, file quest-main.c, line 90.

I have uploaded the files as bug-m32.tar.gz
(0000262)
Matze   
2016-01-26 05:43   
I just tried this and it works fine on linux (phew).

But indeed the example fails on an OS X machine. Playing around with the example and looking at the assembler output it seems like gcc and clang return structs/unions with a single float/double element in an x87 register. In our defense, this isn't even documented here:

https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html#//apple_ref/doc/uid/TP40002492-SW4 [^]

(0000263)
lindig   
2016-01-26 09:55   
I've checked this with clang -m32 and gcc -m32 on OS X and they seem to agree on this. So while this may be undocumented, I'd argue what the compiler actually does is most important and would consider this still a bug in cparser.
(0000264)
Matze   
2016-01-31 00:39   
(edited on: 2016-01-31 00:40)
Thanks for the bugreport. The OS X float return issue was fixed in revision e585022ce1c0b256aa49ea21b881c4baf24cf26c. bug-m32.tar.gz works now (the original bug.tar.gz regarding the amd64/x86_64 is not fixed but I think we do not need to track bugs for the amd64 backend in that area as long as we don't consider that feature finished).