https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113425
--- Comment #6 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Torbjorn SVENSSON from comment #5)
> @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
>
It looks like the optimization applied to both of them. So I guess
check_effective_target_ifn_copysign needs something other than arm_neon.
>
>
> 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.)
fp needs to have the same value as otherwise any fp relative addressing would
be broken. bar doesn't need a framepointer but it's saving it because the
original copysign was a function call and fp never got cleaned up.
