|Anonymous | Login | Signup for a new account||2020-02-28 04:10 CET|
|Main | My View | View Issues|
|Viewing Issue Simple Details|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0000174||[libFirm] x86 ia32 backend||minor||always||2016-01-24 12:39||2016-01-31 00:39|
|Summary||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
I have included a tar file with all source files.
:debug $ clang --version
Apple LLVM version 7.0.2 (clang-700.1.81)
Thread model: posix
|Tags||No tags attached.|
bug.tar.gz [^] (1,579 bytes) 2016-01-24 12:39
bug-m32.tar.gz [^] (1,541 bytes) 2016-01-25 09:17
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).
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
edited on: 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:
|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.|
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).
|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|
|Mantis 1.1.5[^] Copyright © 2000 - 2008 Mantis Group|