https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538
Christophe Lyon changed:
What|Removed |Added
CC||akhilesh.k at samsung dot com
---
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
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
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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target||arm
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
