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?
