[Bug rtl-optimization/64158] New: [5.0 regression] FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"

[Bug rtl-optimization/64158] New: [5.0 regression] FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"

[schwab@linux-m68k.org]

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

            Bug ID: 64158
           Summary: [5.0 regression] FAIL: gcc.dg/pr44194-1.c
                    scan-rtl-dump dse1 "global deletions = (2|3)"
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: schwab@linux-m68k.org
            Target: powerpc64-*-*

$ grep "global deletions =" pr44194-1.c.209r.dse1 
dse: local deletions = 0, global deletions = 0, spill deletions = 0

[Bug rtl-optimization/64158] [5.0 regression] FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"

[schwab@linux-m68k.org]

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

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

[Bug rtl-optimization/64158] [5 Regression] FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |macro at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Is this a regression though?
I see the
FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"
even with gcc 4.7.x, 4.8.x, 4.9.x on ppc64.
There was an attempt to avoid running this test on ppc64-linux:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00299.html
r213657 and r213677
but clearly that is not working well.
Don't have a ppc64 box readily available now, so can't quickly analyze what's
going on though.  I see:

Executing on host:
/builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/xgcc
-B/builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/ 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -c   -o
powerpc_elfv216903.o powerpc_elfv216903.c    (timeout = 300)
spawn -ignore SIGHUP
/builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/xgcc
-B/builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/
-fno-diagnostics-show-caret -fdiagnostics-color=never -c -o
powerpc_elfv216903.o powerpc_elfv216903.c
powerpc_elfv216903.c:3:7: error: #error not ELF v2 ABI
compiler exited with status 1
output is:
powerpc_elfv216903.c:3:7: error: #error not ELF v2 ABI
...
Executing on host:
/builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/xgcc
-B/builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/
/builddir/build/BUILD/gcc-5.0.0-20150217/gcc/testsuite/gcc.dg/pr44194-1.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never  -O2 -fdump-rtl-dse1
-fdump-rtl-final -ffat-lto-objects -ffat-lto-objects -S   -o pr44194-1.s   
(timeout = 300)
spawn -ignore SIGHUP
/builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/xgcc
-B/builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/
/builddir/build/BUILD/gcc-5.0.0-20150217/gcc/testsuite/gcc.dg/pr44194-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-rtl-dse1
-fdump-rtl-final -ffat-lto-objects -ffat-lto-objects -S -o pr44194-1.s
PASS: gcc.dg/pr44194-1.c (test for excess errors)
FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"
PASS: gcc.dg/pr44194-1.c scan-rtl-dump-not final "insn[: ][^\n]*set
\\(mem(?![^\n]*scratch)"

in the gcc.log from our rpm build, so I'd expect that powerpc_elfv2 is 0 and
therefore the pr44194-1.c test should be skipped as unsupported.

[Bug testsuite/64158] [5 Regression] FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 34816
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34816&action=edit
gcc5-pr64158.patch

Untested fix.  Seem tcl is picky about the {}s, doesn't want cond1 && cond2 &&
cond3, but instead { { cond1 && cond2 } && cond3 }.  That is one of the pairs,
why is the second one needed is beyond my current understanding.
Tested just by replacing the various ! sometarget cases with ! x86_64-*-* and
checking whether they indeed made the test unsupported on my x86_64-linux.
s390, hppa and alpha replacement worked expectedly, for the powerpc case it was
enough to add one {} pair, for nvptx I had to add another one.

[Bug testsuite/64158] [5 Regression] FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"

[schwab@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
It's a restriction of the selector expression parser.

[Bug testsuite/64158] [5 Regression] FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed now.

[Bug testsuite/64158] [5 Regression] FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Looks reasonable to me if it works properly.