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

["aldyh at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #19 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #16)
> (In reply to Nick Clifton from comment #13)
> > Hi Aldy,
> > 
> > 
> > > 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:
> > 
> > >     8ca4:       e1c520fc        strd    r2, [r5, #12]
> > > 
> > > It seems that last store is corrupting things and making us jump to a PC of
> > > 4???
> > 
> > Address 4 is the "undefined instruction" vector.  If the simulator thinks
> > that the instruction is illegal/unknown then it will branch to address 4
> > and start executing from there.  (Or else it loads the value stored at 
> > address 4 and starts executing from that address.  I forget which).
> > 
> > So, this basically means that the simulator does not like that STRD 
> > instruction. :-(  Looking at the code in Handle_Store_Double() in 
> > sim/arm/armemu.c, I think that the reason is probably because the address
> > for the store is not double word aligned.  Which leads me to wonder,
> > what value is stored in r5 when the STRD instruction is being executed ?
> 
> You wouldn't take the undef vector for an alignment issue: that would take a
> data abort.
> 
> Sounds like your simulator is built for an older architecture, that doesn't
> have strd (ie it's pre-armv5te).

Actually, Nick is correct.  The simulator stops around here:

  /* The address must be aligned on a 8 byte boundary.  */
  if (addr & 0x7)
    {
#ifdef ABORTS
      ARMul_DATAABORT (addr);
#else
      ARMul_UndefInstr (state, instr);
#endif

(gdb) p/x addr
$26 = 0x1b6f4
(gdb) p/x addr & 7
$27 = 0x4

and ARMul_UndefInstr() is:

void
ARMul_UndefInstr (ARMul_State * state, ARMword instr ATTRIBUTE_UNUSED)
{
  ARMul_Abort (state, ARMul_UndefinedInstrV);
}

#define ARMUndefinedInstrV 4L
...
#define ARMul_UndefinedInstrV ARMUndefinedInstrV

The 4 is not exactly intuitive...

I still think someone with access to a working environment should reduce or
debug this further :(.