[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538 Christophe Lyon changed: What|Removed |Added CC||akhilesh.k at samsung dot com --- Comment #7 from Christophe Lyon --- *** Bug 90721 has been marked as a duplicate of this bug. ***
[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538 --- Comment #6 from avieira at gcc dot gnu.org --- I had a look at this and after some digging I found the bug is not due to LTO, but rather with "local" functions. If you make bar static you will end up with the same faulty behavior. After some more digging I found myself going through the 'untyped_call' code in arm.md. Here I found both 'untyped_call' and 'untyped_return' had not been adjusted to be able to cope with HardFP ABI's. I wrote a patch to mend this, needs a bit more work, but I think it's correct and I might put it on gcc-patches at a later time. However, when I started thinking of how I was going to "fix" this wrong-code generation, I realized that due to the way untyped_call's and untyped_return's are constructed and the nature of '__builtin_return' and '__builtin_apply', you do not know which registers are actually used to return the values, you only know it might be 'r0-r4' and 'd0-d7'. So even though I know the call-site would expect a return of type 'double' in 'r0-r1', because this is local function (aka 'ARM_PCS_AAPCS_LOCAL') and the target does not support double precision, there is no way for me to know in which of the registers the function is actually returning, so I dont know what registers to move to 'r0-r1'. So I don't think we can get this builtin to work for single precision VFPs, without compromising on the way we use local function returns.
[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538 --- Comment #5 from ktkachov at gcc dot gnu.org --- Patch posted at: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00634.html and Richards' reply at: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00388.html There's more digging to do in how we asses whether a function escapes the translation unit. I'm not currently working on this.
[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538 --- Comment #4 from ktkachov at gcc dot gnu.org --- So during LTO compilation inside aapcs_allocate_return_reg the pcs_variant used is ARM_PCS_AAPCS_LOCAL (/* Private call within this compilation unit. */) whereas for non-LTO it is: ARM_PCS_AAPCS_VFP (/* Use VFP registers for floating point values. */)
[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538 --- Comment #3 from ktkachov at gcc dot gnu.org --- I suspect the place to start at is looking what arm_function_value does for the lto case. This is where the code decides what register the function returns its value based on ABI. But I'm having a tough time getting gdb to attach properly to debug the final LTO combination :(
[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to fail||4.8.5, 4.9.4, 5.3.1, 6.0 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed on other branches too
[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||arm Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-28 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed on trunk at least
