[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 seurer at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from seurer at gcc dot gnu.org --- Last failure I see in test results was on 7/17 so I am closing.
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #10 from Bill Schmidt --- Where does this one stand now?
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #9 from Carl Love --- Commit 250295 reverts commit 249424 which was causing issues. commit 249424 is actually a fix for the vec_mule and vec_mulo support that was added in commit 248125. The original commit was using the wrong word size for the half word builtin, hence the need for commit 249424 to fix that.
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #8 from Bill Schmidt --- Carl, please revert the patch until you have time to investigate. This will cause havoc every time we vectorize with these patterns.
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 Bill Schmidt changed: What|Removed |Added CC||carll at gcc dot gnu.org --- Comment #7 from Bill Schmidt --- (In reply to Bill Schmidt from comment #5) > The code is being vectorized in the "fails" dump and not being vectorized in > the "works" dump. This cannot be due to r249424, which does gimple folding > on some Power-specific built-ins, for this is a generic test case that makes > no use of such built-ins. > > So either you have misidentified the revision responsible, or the code is > somehow being compiled differently so that vectorization happens in one case > and not the other. > > Bill Sorry, I got mixed up. In introducing new multiply built-ins, Carl also introduced some of the standard patterns that were previously not supported for the POWER back ends, which allowed vectorization to occur that wouldn't have before. Very sorry for the mischaracterization. Carl, we'll need you to investigate. I assume that the semantics for the standard patterns have been implemented incorrectly. Let me know if you want to discuss. Bill
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #6 from seurer at gcc dot gnu.org --- So here is comparing 249423 (works) with 249424 (fails): seurer@genoa:~/gcc/build/gcc-test2$ svn info $GCC_SRC . . . Revision: 249423 . . . seurer@genoa:~/gcc/build/gcc-test2$ /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90 -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/../../include -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -O3 -g -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs -fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs -lgfortran -foffload=-lgfortran -lm -o ./a.16.1.exe seurer@genoa:~/gcc/build/gcc-test2$ ./a.16.1.exe X( 1 ) =55000. , Y( 1 ) =2. X( 2 ) =45010. , Y( 2 ) =4. X( 3 ) =45020. , Y( 3 ) =6. X( 4 ) =45030. , Y( 4 ) =8. X( 5 ) =45040. , Y( 5 ) =10.000 X( 6 ) =45050. , Y( 6 ) =12.000 X( 7 ) =45060. , Y( 7 ) =14.000 X( 8 ) =45070. , Y( 8 ) =16.000 X( 9 ) =45080. , Y( 9 ) =18.000 X( 10 ) =45090. , Y( 10 ) =20.000 seurer@genoa:~/gcc/build/gcc-test$ svn info $GCC_SRC Path: /home/seurer/gcc/gcc-test Working Copy Root Path: /home/seurer/gcc/gcc-test . . . Revision: 249424 . . . seurer@genoa:~/gcc/build/gcc-test$ /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90 -B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/gcc-test/libgomp/testsuite/../../include -I/home/seurer/gcc/gcc-test/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -O3 -g3 -B/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs -fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp -L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/.libs -L/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp/../libgfortran/.libs -lgfortran -foffload=-lgfortran -lm -o ./a.16.1.exe seurer@genoa:~/gcc/build/gcc-test$ ./a.16.1.exe Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x3fff98cb9a9f in ??? Segmentation fault (core dumped) The options were the same: < .string "8 8.0.0 20170620 (experimental) [trunk revision 249424] -mcpu=power8 -g3 -O3 -fmessage-length=0 -fopenmp -fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgomp -foffload=-lgfortran -fintrinsic-modules-path finclude" --- > .string " 8.0.0 20170620 (experimental) [trunk revision 249423] > -mcpu=power8 -g3 -O3 -fmessage-length=0 -fopenmp > -fintrinsic-modules-path=/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp > -foffload=-lgfortran -fintrinsic-modules-path finclude" 11c11 < .file 1 "/home/seurer/gcc/gcc-test/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90" --- > .file 1 > "/home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.fortran/appendix-a/a.16.1.f90" 171d170 < addis 8,2,.LC1@toc@ha 174,187d172 < addi 8,8,.LC1@toc@l < addis 10,2,.LC3@toc@ha < std 22,-80(1) < std 23,-72(1) < addi 10,10,.LC3@toc@l < std 24,-64(1) < std 25,-56(1) < addis 9,2,.LC2@toc@ha < std 26,-48(1) < std 27,-40(1) < addi 9,9,.LC2@toc@l < vspltisw 4,4 < std 28,-32(1) < std 30,-16(1) 190,191c175,176 < vspltisw 6,6 < vspltisw 7,5 --- > li 9,1 > mtctr 9 194,196c179,180 < std 0,16(1) < lis 0,0xfffe < std 31,-8(1) --- > std 22,-80(1) > std 23,-72(1)
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #5 from Bill Schmidt --- The code is being vectorized in the "fails" dump and not being vectorized in the "works" dump. This cannot be due to r249424, which does gimple folding on some Power-specific built-ins, for this is a generic test case that makes no use of such built-ins. So either you have misidentified the revision responsible, or the code is somehow being compiled differently so that vectorization happens in one case and not the other. Bill
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #4 from seurer at gcc dot gnu.org --- Looking at the difference in generated code. The more recent (failing) builds are generating a whole bunch of vector ops where the old (working) code did not. < failing code (r250280) > last working code (r249423) 171d170 < addis 8,2,.LC1@toc@ha 174,187d172 < addi 8,8,.LC1@toc@l < addis 10,2,.LC3@toc@ha < std 22,-80(1) < std 23,-72(1) < addi 10,10,.LC3@toc@l < std 24,-64(1) < std 25,-56(1) < addis 9,2,.LC2@toc@ha < std 26,-48(1) < std 27,-40(1) < addi 9,9,.LC2@toc@l < vspltisw 4,4 < std 28,-32(1) < std 30,-16(1) 190,191c175,176 < vspltisw 6,6 < vspltisw 7,5 --- > li 9,1 > mtctr 9 194,196c179,180 < std 0,16(1) < lis 0,0xfffe < std 31,-8(1) --- > std 22,-80(1) > std 23,-72(1) 199c183 < vspltisw 8,2 --- > lis 7,0x1062 202,203c186,187 < ori 0,0,0xb560 < lxvd2x 45,0,8 --- > std 24,-64(1) > std 25,-56(1) 206,210c190 < lxvd2x 37,0,10 < li 10,2500 < mtctr 10 < lxvd2x 44,0,9 < vspltisw 9,3 --- > ori 7,7,0x4dd3 212a193,201 > li 10,1 > std 26,-48(1) > std 27,-40(1) > std 28,-32(1) > std 30,-16(1) > std 0,16(1) > lis 0,0xfffe > std 31,-8(1) > ori 0,0,0xb560 227,232d215 < .LBB28: < .loc 1 31 0 < vspltisw 10,1 < .LBE28: < .loc 1 26 0 < xxpermdi 45,45,45,2 234,236c217,219 < addis 9,29,0x1 < addi 9,9,-25536 < .p2align 4,,15 --- > addis 8,29,0x1 > addi 8,8,-25540 > .p2align 5,,31 238c221 < .LBB29: --- > .LBB28: 240,256c223,230 < vmulosw 11,13,12 < vmulesw 0,13,12 < vsraw 1,13,5 < vmrgew 0,11,0 < vsraw 0,0,6 < vsubuwm 1,0,1 < vslw 0,1,7 < vsubuwm 0,0,1 < vslw 0,0,8 < vadduwm 0,0,1 < vslw 0,0,9 < vsubuwm 0,13,0 < vadduwm 13,13,4 < vadduwm 0,0,10 < xxpermdi 0,32,32,2 < stxvd2x 0,0,9 < addi 9,9,16 --- > mulhwu 9,10,7 > srwi 9,9,6 > mulli 9,9,1000 > subf 9,9,10 > addi 10,10,1 > addi 9,9,1 > stwu 9,4(8) > .loc 1 30 0
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #3 from seurer at gcc dot gnu.org --- Created attachment 41777 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41777=edit Assembler for works
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #2 from seurer at gcc dot gnu.org --- Created attachment 41776 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41776=edit Assembler for fails
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug libgomp/81386] [8 regression] libgomp.fortran/appendix-a/a.16.1.f90 fails starting with 249424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81386 --- Comment #1 from seurer at gcc dot gnu.org --- I looked back through the tester logs and noticed that the test case doesn't always fail and there are two different failures and always with -O3 PASS: libgomp.fortran/appendix-a/a.16.1.f90 -O0 (test for excess errors) PASS: libgomp.fortran/appendix-a/a.16.1.f90 -O0 execution test PASS: libgomp.fortran/appendix-a/a.16.1.f90 -O1 (test for excess errors) PASS: libgomp.fortran/appendix-a/a.16.1.f90 -O1 execution test PASS: libgomp.fortran/appendix-a/a.16.1.f90 -O2 (test for excess errors) PASS: libgomp.fortran/appendix-a/a.16.1.f90 -O2 execution test PASS: libgomp.fortran/appendix-a/a.16.1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: libgomp.fortran/appendix-a/a.16.1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test PASS: libgomp.fortran/appendix-a/a.16.1.f90 -O3 -g (test for excess errors) FAIL: libgomp.fortran/appendix-a/a.16.1.f90 -O3 -g execution test PASS: libgomp.fortran/appendix-a/a.16.1.f90 -Os (test for excess errors) Oddly in many test runs the two errors occur equally often (about 87% of the time for each one) but not always together. Neither error occurs in just 1.5% of the runs.
