[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

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

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

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #2)
> > Confirmed.  The problem occurs in fwprop1 where instructions corresponding to the
> > following assembly
> >	addis r2,r31,ha16(_A.1.1600-L1$pb)
> >	la r9,lo16(_A.1.1600-L1$pb)(r2)
> >	ld r2,0(r9)
> > are combined to
> >	addis r2,r31,ha16(_A.1.1600-L1$pb)
> >	la r9,lo16(_A.1.1600-L1$pb)(r2)
> >	ld r2,lo16(_A.1.1600-L1$pb)(r2)
> > ie. the offset is propagated into the memory load.  This ought to give you
> > an error at assembly or link time.
> 
> No error at assembly or link time.

> > If not, you have a bad assembler or linker..
> 
> Well, we'll have to live with them!-(EOL target).

The system as is based on gas-1.38 and doesn't warn for this :-(
ld64 is slightly better and does catch a few more cases (where they resolve at
link-time).

.. there's some hope for my WIP GAS port and an updated ld64 (yeah, I know it's
taking a long time for these to appear) ..

> > movdi_low is the culprit, I think.  It should require a suitably aligned
> > offset (operand 2).
> 
> How?

In the mdynamic-no-pic case, the literal value should work the same as for
linux.

In the case of PIC, I suspect we need to look through the uspecs that wrap
mach-o PIC offsets and try to determine if the alignment of the referenced
symbol is guaranteed to be "enough".  The alignment of the picbase will always
be >= 4.

Some time ago I had a WIP patch to try and deal with this â but it's bit-rotted
so needs a significant re-visit.