This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, rs6000] Fix PR target/71733, ICE with -mcpu=power9 -mno-vsx

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 (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 (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 ...


  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]