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.
