g:b3e98eb3396e16ae8b20c94916bc2bd7862d2c97, r13-89-gb3e98eb3396e16 make -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr102950.c" FAIL: gcc.dg/pr102950.c (test for excess errors) # of unexpected failures 1 FAIL: gcc.dg/vect/bb-slp-pr104240.c -flto -ffat-lto-objects scan-tree-dump slp2 "optimized: basic block" FAIL: gcc.dg/vect/bb-slp-pr104240.c -flto -ffat-lto-objects scan-tree-dump slp2 "optimized: basic block" FAIL: gcc.dg/vect/bb-slp-pr104240.c scan-tree-dump slp2 "optimized: basic block" FAIL: gcc.dg/vect/bb-slp-pr104240.c scan-tree-dump slp2 "optimized: basic block" Seeing this on all powerpc64 machines. commit b3e98eb3396e16ae8b20c94916bc2bd7862d2c97 (HEAD, refs/bisect/bad) Author: Roger Sayle <roger@nextmovesoftware.com> Date: Tue May 3 14:38:50 2022 -0400 PR tree-optimization/102950: Improved EVRP for signed BIT_XOR_EXPR.
The testcase is from my r13-71-g41e3db05d69740. Can you attach the slp2 dump file please? I suspect we're missing vect_hw_misalign support checking (but altering the testcase to use __builtin_assume_alignment () on all args should work as well). Can you check?
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:000f4480005035d0811e009a7cb25b42721f0a6e commit r13-130-g000f4480005035d0811e009a7cb25b42721f0a6e Author: Richard Biener <rguenther@suse.de> Date: Thu May 5 10:41:08 2022 +0200 testsuite/105486 - adjust testcase to avoid misaligned accesses This properly aligns data, increasing test coverage. 2022-05-05 Richard Biener <rguenther@suse.de> PR testsuite/105486 * gcc.dg/vect/bb-slp-pr104240.c: Align all data.
So alignment is definitely going to be a problem so I fixed that. Does this resolve the FAIL on ppc64?
I think the mention of slp2 and pr104240.c in the bug report is bogus, and is a glitch in the automated regression checking scripts. The real problem is that my new test case for pr102950.c is failing on powerpc64. After a great deal of head scratching on why EVRP is producing different results on this platform, I've just realized that "char" must be unsigned on this target. Replacing "char" with "signed char" in gcc.dg/pr102950.c fixes the problem. I'll commit this fix as obvious. But I want to avoid anyone wasting time (like I did) trying to figure out why my patch should be the cause of an -flto failure of bb-slp-pr104240.c [which might be failure, but unrelated to the pr102950.c issue/bisect].
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>: https://gcc.gnu.org/g:92fff39f06449f907d8781a5dcaad0e8b9743480 commit r13-136-g92fff39f06449f907d8781a5dcaad0e8b9743480 Author: Roger Sayle <roger@nextmovesoftware.com> Date: Thu May 5 08:30:27 2022 -0400 [Committed] PR testsuite/105486: Use "signed char" in gcc.dg/pr102950.c Although the automated regression testing scripts for powerpc64 appear to be somewhat garbled at the moment, they've correctly identified that my new test case for pr102950.c is failing on powerpc64, as char by default is unsigned on this target. This patch tweaks the new testcase by explicitly using "signed char" so that it's testing the intended EVRP behaviour portably. Committed as obvious. 2022-05-05 Roger Sayle <roger@nextmovesoftware.com> gcc/testsuite/ChangeLog PR testsuite/105486 * gcc.dg/pr102950.c: Use explicit "signed char" in test case.
Fixed on mainline. According to https://gcc.gnu.org/pipermail/gcc-testresults/2022-May/761073.html neither pr102950.c nor vect/bb-slp-pr104240.c are currently failing on powerpc64.