Alan Modra wrote: > On Tue, Jul 12, 2016 at 02:02:43PM +0200, Ulrich Weigand wrote: > > The second time around, get_secondary_mem should reuse the > > same stack slot it already allocated, and the elimination > > offsets should already be set to accommodate that stack slot, > > which means the second time around, the correct RTX should be > > generated for the memory access. > > > > Is this not happening somehow? > > Duh, yes, of course. Second time around the mem is > (mem/c:V16QI (plus:DI (reg/f:DI 1 1) > (const_int -16 [0xfffffffffffffff0])) [0 S16 A128]) > so we're checking the correct offset. > > The problem now is that this passes rs6000_legitimate_address_p due to > mode_supports_vsx_dform_quad and quad_address_p being true. That > doesn't seem correct for -mno-vsx.
Hmm, I see in rs6000_option_override_internal: /* ISA 3.0 D-form instructions require p9-vector and upper-regs. */ if ((TARGET_P9_DFORM_SCALAR || TARGET_P9_DFORM_VECTOR) && !TARGET_P9_VECTOR) { if (rs6000_isa_flags_explicit & OPTION_MASK_P9_VECTOR) error ("-mpower9-dform requires -mpower9-vector"); rs6000_isa_flags &= ~(OPTION_MASK_P9_DFORM_SCALAR | OPTION_MASK_P9_DFORM_VECTOR); } and *later*: /* ISA 3.0 vector instructions include ISA 2.07. */ if (TARGET_P9_VECTOR && !TARGET_P8_VECTOR) { if (rs6000_isa_flags_explicit & OPTION_MASK_P8_VECTOR) error ("-mpower9-vector requires -mpower8-vector"); rs6000_isa_flags &= ~OPTION_MASK_P9_VECTOR; } That seems the wrong way around ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com