[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518

--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
I'm having some trouble reproducing this bug.  I'm a little rusty on cross
builds, so perhaps someone can lend a hand.

I have a set of combined sources which I'm using to build a toolchain like
this:

~/src/combined/configure --host=x86_64-linux --build=x86_64-linux
--target=armeb-eabi --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon-fp16
--enable-languages=fortran  --disable-libgomp --disable-libsanitizer
--disable-werror

I then do:

cd gcc && make check-fortran RUNTESTFLAGS="execute.exp=in-pack.f90
--target_board=arm-sim"

                === gfortran tests ===

Schedule of variations:
    arm-sim

Running target arm-sim
Using /usr/share/dejagnu/baseboards/arm-sim.exp as board description file for
target.
Using /usr/share/dejagnu/config/sim.exp as generic interface file for target.
Using /usr/share/dejagnu/baseboards/basic-sim.exp as board description file for
target.
Using /home/cygnus/aldyh/src/combined/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running
/home/cygnus/aldyh/src/combined/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp
...
FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution,  -O0 
FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution,  -O1 
...

I get failures for everything, but it seems every execution test fails, even
simple C tests.  Tests fail with no messages, just a simple execution failure,
so I had to dig into the simulator.

I patched the gdb simulator to trace the instructions to see where we are
dying:

diff --git a/sim/arm/wrapper.c b/sim/arm/wrapper.c
index bc1a043..4492b19 100644
--- a/sim/arm/wrapper.c
+++ b/sim/arm/wrapper.c
@@ -53,7 +53,7 @@ int stop_simulator;
 #include "dis-asm.h"

This presumably gives us some tracing in gcc/testsuite/*/*.log:

 /* TODO: Tracing should be converted to common tracing module.  */
-int trace = 0;
+int trace = 1;
 int disas = 0;
 int trace_funcs = 0;

The GCC testsuite log file now shows:

pc: 8c8c, instr: e3530014
pc: 8c90, instr: 1afffffb
pc: 8c94, instr: e5952000
pc: 8c98, instr: e3a03000
pc: 8c9c, instr: e5856014
pc: 8ca0, instr: e5853018
pc: 8ca4, instr: e1c520fc
pc: 4, instr: ea00089b

I took a peek at the executable being run with "/my-arm-build/objdudump -D
the-executable.exe", and I see we are failing in initialise_monitor_handles(). 
This suggests we're failing during the start-up code:

    8c8c:       e3530014        cmp     r3, #20
    8c90:       1afffffb        bne     8c84 <initialise_monitor_handles+0x7c>
    8c94:       e5952000        ldr     r2, [r5]
    8c98:       e3a03000        mov     r3, #0
    8c9c:       e5856014        str     r6, [r5, #20]
    8ca0:       e5853018        str     r3, [r5, #24]
    8ca4:       e1c520fc        strd    r2, [r5, #12]

It seems that last store is corrupting things and making us jump to a PC of
4???

Before I bark up the wrong trees, I have some questions.

Am I running the simulator correctly?  Does it require a special flag for
cortex-a9?  

Is the cortex-a9 CPU even handled by the simulator?

Should I run the dejagnu tests with -mcpu=xxxx or whatever, or is the
--with-cpu=cortex-a9 configury flag enough?

Does the arm newlib/libgloss/whatever code have instructions that aren't
handled by the GDB simulator?

I don't want to dig too deep into this, only to find out that our simulator,
newlib, or whatever cannot handle cortex-a9 + neon-fp16.

For that matter, is this bug reproducible on a more generic Arm variant that
*IS* supported by gdb?

Sorry for the barrage of questions, but this is a P1, and there doesn't seem to
be an easy way to reproduce this.