codegen problem with 'complex' type on x86/linux #1362
Comments
|
I don't have access to a linux box. Can you compile the reduced testcase at -O3 with both llvm and gcc Thanks, -Chris |
|
LLVM definitely doesn't clean up stack properly. Adding "subl $4, esp" after |
|
Everything is ok for mingw32 target. It seems, something went odd in |
|
One small addition: "everything is ok for mingw32" was just because of |
|
Looks like we'll need to tweak struct return lowering a bit for linux. Unfortunately it's too late for this to -Chris |
|
Well, not only for linux but for mingw32 too. I'll try to figure out, what's |
|
Fixed with Will check linux nightlytesters for newly passed tests (should be at least |
|
Well, comparing Reid's current nightly test status and the same from prev. days, |
[NFC] Standardize the use of SomeExpr in lowering.
Extended Description
I've noticed a pattern in my testcase failures involving "csretcc". The bug
occurs with a simple testcase from the "cexp" man page:
// RUN: %llvmgcc -O2 -lm %s -o %s.exe
// RUN: ./%s.exe | grep "-1.000000+0.000000*i"
#include <stdio.h>
/* check that exp(ipi) == -1 /
#include <math.h> / for atan /
#include <complex.h>
int main(void) {
double pi = 4atan(1);
complex z = cexp(Ipi);
printf("%f+%f*i\n", creal(z), cimag(z));
}
With LLVM, this produces:
$ llvm-gcc -O0 csretcc.c -lm -o csretcc
$ ./csretcc
0.000000+0.000000*i
Segmentation fault
while with GCC, it works:
$ gcc -O0 csretcc.c -lm -o csretcc
$ ./csretcc
-1.000000+0.000000*i
In the bytecode, the call to "cexp" is called with "csretcc" calling convention.
The text was updated successfully, but these errors were encountered: