https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #11 from David Crocker ---
As the master branch was updated a year ago according to comment 10, does this
mean that there is now a stable release of gcc that incudes the patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #10 from CVS Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:1dca4ca1bf2f1b05537a1052e373d8b0ff11e53c
commit r12-7894-g1dca4ca1bf2f1b05537a1052e373d8b0ff11e53c
Author: Richard Earnshaw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
David Crocker changed:
What|Removed |Added
CC||dcrocker at eschertech dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #8 from Richard Earnshaw ---
(In reply to emilie.feral from comment #7)
> Hello,
> Any news on the subject?
> Would you advise in the meantime to discard the LTO (with the -fno-lto
> option) on the compilation unit containing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #7 from emilie.feral at numworks dot com ---
Hello,
Any news on the subject?
Would you advise in the meantime to discard the LTO (with the -fno-lto option)
on the compilation unit containing the failing code?
The bug occurred for us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #6 from Richard Earnshaw ---
Yes, the problem is related to returning values in memory and the ABI variants
we have. If we have hardware floating-point we generally use registers to
return values; if we don't, then we have to return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #5 from emilie.feral at numworks dot com ---
When compiling without the lto using the command:
arm-none-eabi-gcc main.c -Os -mfloat-abi=hard -mthumb -mcpu=cortex-m4
-ffreestanding -nostdlib -lgcc -save-temps -o a.elf
I get the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
Richard Earnshaw changed:
What|Removed |Added
Target||arm
--- Comment #4 from Richard
