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

[iains at gcc dot gnu.org]

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

--- Comment #28 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 46995
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46995&action=edit
[c] Update mem_operand_gpr


I started tracing through mem_operand_gpr at this point and discovered that

(a) it seems that rs6000_offsettable_memref_p() will never return true for
lo_sum

(b) even if it does,  address_offset () doesn't consider lo_sum so will always
return NULL_RTX for that and therefore the check at the end of the function
won't happen.

Now, I recall Alan saying that you wanted to keep the predicate loose (which it
is on movdi_internal64) but ISTM without a working constraint LRA can't do its
job.

....

this patch splits mem_operand_gpr () into a path for LO_SUM and a path the
everything else.

In the LO_SUM path, for Darwin only, we call out to the function that checks
the offset *and* the symbol .. for non-Darwin, we just carry out the checks
that were in the code path before.

Now, this *will* change things for non-Darwin - since before it, I don't think
the lo_sum case could ever have been executed.

== AFAICT my m64 code is now working ≈ 120 progressions across the testsuite, a
lot in Fortran but also elsewhere.

So..
1) Have I missed somewhere else that is supposed to fix things up?
 (for the record, I instrumented legitimate_address_p, legitimise_address and
delegitimise_addres and I could not see any place that they were called that
could fix up a broken lo_sum.

2) the patch(es) are not tidy or as widely tested as would be needed to post
them ... but I can tidy/test if the direction is reasonable./

3) If this is NOT the right direction, then what is?