Created attachment 47837 [details] Fortran code that prints 0 if correct, and -9 if miscompiled The attached code prints -9.0000000000000000 if compiled using gfortran -O2 -march=haswell -ftree-vectorize bug.f90 -o bug ./bug -9.0000000000000000 using GNU Fortran (Debian 8.3.0-6) 8.3.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. also reproduceable on GCC 9.2.0, but not with GCC 7.3.0 and earlier. The correct answer is 1-1=0. (I found this issue first when compiling the reference BLAS using those options and running the "zblat2" tests, the test is a much reduced version of ztrsv, see http://www.netlib.org/lapack/explore-html/dc/dc1/group__complex16__blas__level2_ga99cc66f0833474d6607e6ea7dbe2f9bd.html#ga99cc66f0833474d6607e6ea7dbe2f9bd)
It works fine with GCC 7.5.
Hmm, it seems to be fixed on trunk. Testcase that aborts on failure, we probably have a duplicate. subroutine test(incx) implicit none integer i,incx,jx double complex a(5),x(9),temp a(1:4)=1 a(5)=10 x(1:9)=1 jx = 9 temp = x(9) do i = 4,1,-1 jx = jx - incx x(jx) = x(jx) - temp*a(i) enddo if (x(5).ne.0) call abort end subroutine test program bug call test(2) end program bug
I tried to make an equivalent C testcase, but complex ops don't map 1:1 from Fortran, so it's a bit difficult. Nevertheless, here's a somewhat similar testcase that aborts on 8/9, works on trunk, but IR and resulting assembly look quite different: ( needs -O2 -ftree-vectorize -mfma -fcx-limited-range ) __attribute__((noipa)) static _Complex double test(_Complex double * __restrict a, _Complex double * __restrict x, _Complex double t, long jx) { long i, j; for (j = 6, i = 3; i>=0; i--, j-=jx) x[j] -= t*a[i]; return x[4]; } int main() { _Complex double a[5] = {1, 1, 1, 1, 10}; _Complex double x[9] = {1,1,1,1,1,1,1,1,1}; if (test(a, x, 1, 2)) __builtin_abort(); }
#c2 isn't miscompiled since r10-4543-g599bd99078439b9f11cb271aa919844318381ec5 and the miscompilation started with r8-6708-g85c5e2f576fd41e1ab5620cde3c63b3ca6673bea
GCC 8.4.0 has been released, adjusting target milestone.
GCC 8 branch is being closed.
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
I can't reproduce the wrong code using either the fortran test case in #c2 or the C one in #c3 with gcc-9.4.0 on Kaby Lake R. If I revert the PR92420 fix both test cases do reproduce the wrong code. Thus I think this was fixed by PR92420 in gcc-8.4.0 and gcc-9.3.0.
Fixed for GCC 10.