https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113425
Torbjorn SVENSSON <azoff at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |azoff at gcc dot gnu.org --- Comment #5 from Torbjorn SVENSSON <azoff at gcc dot gnu.org> --- @Tamar: You can see the same fails with 14.2.Rel1 that is available for download from the Arm webpage. I see the following in my gcc.log for Cortex-A7 with -mfloat-abi=hard -mfpu=nenon: gcc.dg/fold-copysign-1.c: pattern found 0 times FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "__builtin_copysign" 1 gcc.dg/fold-copysign-1.c: pattern found 2 times FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "= ABS_EXPR" 1 And for Cortex-M3/4/7/33/55/85 and Cortex-A7 with -mfloat-abi=soft: gcc.dg/fold-copysign-1.c: pattern found 0 times FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "= -" 1 gcc.dg/fold-copysign-1.c: pattern found 1 times FAIL: gcc.dg/fold-copysign-1.c scan-tree-dump-times cddce1 "= ABS_EXPR" 2 Pardon me for perhaps a stupid side question, but what happens with the stack in the "bar" function of this testcase? bar: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. push {fp} @ 27 [c=8 l=4] *push_multi orr r1, r1, #-2147483648 @ 12 [c=4 l=4] *iorsi3_insn/0 ldr fp, [sp], #4 @ 30 [c=12 l=4] *thumb2_movsi_insn/5 bx lr @ 31 [c=8 l=4] *thumb2_return Lets say that there is an interrupt firing when PC points at the "orr" instruction. Will "fp" have the right value after the handler returns or can it get corrupted by the interrupt handler in that case? (I'm assuming the same SP is used for both the execution of "bar" and the handler and that the handler code does not have any stack corruption on its own.)