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.)

Reply via email to