[Bug tree-optimization/68775] [6 Regression] spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, it looks like a ppc64le cross happily (eh) accepts sources preprocessed on
x86_64-linux and even required built modules.

So I have the dump files myself and the -fopt-info-vec difference (for BB
vectorization only) is empty.  It looks like the only code difference is
for the vectorization of the BB in loop

shell2.fppized.f90:971

that is

                  do k = 1, k_max
                    k1 = k_x(k);    k2 = k_y(k);    k3 = k_z(k)
                    dot1 = k1*P1+k2*P2+k3*P3
                    dot2 = g4 * (k1*k1+k2*k2+k3*k3)
                    res_ij(k) = res_ij(k) + therm(k) * (fac1 *
exp(cmplx(dot2,dot1,kind=kind((1.0d0,1.0d0)))))
                  end do

which has now one less vector operand.

If you can confirm this by "bisecting" the file with -fdbg-cnt=vect_slp:N
that would be nice.

The vectorized code looks ok to me so I suspect a target issue here.

Note that we do both a vector load from the realpart of a complex and
a scalar load of the imaginary part and then use that to construct
another vector:

  _1371 = REALPART_EXPR <[shell2.fppized.f90:975:0] [shell2.fppized.f90:975:0]
MEM[(complex(kind=8)[0:] *)res.0_420][_960]>;
  vectp.6451_10558 = &REALPART_EXPR <[shell2.fppized.f90:975:0]
[shell2.fppized.f90:975:0] MEM[(complex(kind=8)[0:] *)res.0_420][_960]>;
  vect__1371.6452_10556 = MEM[(real(kind=8) *)vectp.6451_10558];
  _395 = IMAGPART_EXPR <[shell2.fppized.f90:975:0] [shell2.fppized.f90:975:0]
MEM[(complex(kind=8)[0:] *)res.0_420][_960]>;

  [shell2.fppized.f90:975:0] _177 = _964 * _3980;
  [shell2.fppized.f90:975:0] vect_cst__10554 = {_177, _395};
  [shell2.fppized.f90:975:0] vect__455.6453_5427 = vect_cst__10554 +
vect__1371.6452_10556;
  [shell2.fppized.f90:975:0] _389 = _395 + _3549;
  vectp.6455_5409 = &REALPART_EXPR <[shell2.fppized.f90:975:0]
[shell2.fppized.f90:975:0] MEM[(complex(kind=8)[0:] *)res.0_420][_960]>;
  [shell2.fppized.f90:975:0] MEM[(real(kind=8) *)vectp.6455_5409] =
vect__455.6453_5427;

in .optimized the above looks like

  vect__1371.6452_10556 = MEM[base: _9159, offset: 0B];
  _395 = MEM[base: _9159, offset: 8B];
  _9158 = (void *) ivtmp.7110_9170;
  [shell2.fppized.f90:975:0] _964 = MEM[base: _9158, offset: 0B];
  [shell2.fppized.f90:975:0] _486 = __builtin_exp (dot2_958);
  [shell2.fppized.f90:975:0] _508 = REALPART_EXPR <sincostmp_3746>;
  _1815 = _486 * fac1$real_1370;
  [shell2.fppized.f90:975:0] _518 = IMAGPART_EXPR <sincostmp_3746>;
  [shell2.fppized.f90:975:0] _178 = _508 * _1815;
  [shell2.fppized.f90:975:0] _201 = _518 * _1815;
  [shell2.fppized.f90:975:0] _967 = COMPLEX_EXPR <_178, _201>;
  [shell2.fppized.f90:975:0] _968 = ((_967));
  _3980 = REALPART_EXPR <_968>;
  [shell2.fppized.f90:975:0] _177 = _964 * _3980;
  [shell2.fppized.f90:975:0] vect_cst__10554 = {_177, _395};
  [shell2.fppized.f90:975:0] vect__455.6453_5427 = vect_cst__10554 +
vect__1371.6452_10556;
  [shell2.fppized.f90:975:0] MEM[base: _9159, offset: 0B] =
vect__455.6453_5427;

which might be enough to trigger later RTL opt confusion.  I can just guess
at something CSEing the scalar load with the vector load and getting
lane ordering (endianess) wrong.

Maybe you can extract a small testcase from the above info that reproduces
the difference.