On 6/13/19 4:44 AM, Jakub Jelinek wrote:
On Thu, Jun 13, 2019 at 10:53:55AM +0200, Rainer Orth wrote:
Even with that fixed, I see many failures:
+FAIL: g++.dg/tree-ssa/pr31146.C -std=gnu++14 scan-tree-dump forwprop1
"MEM\\\\[.*&i\\\\]\\\\[j.*\\\\] =.* 1;"
+FAIL: g++.dg/tree-ssa/pr31146.C -std=gnu++17 scan-tree-dump forwprop1
"MEM\\\\[.*&i\\\\]\\\\[j.*\\\\] =.* 1;"
+FAIL: g++.dg/tree-ssa/pr31146.C -std=gnu++98 scan-tree-dump forwprop1
"MEM\\\\[.*&i\\\\]\\\\[j.*\\\\] =.* 1;"
+FAIL: g++.dg/tree-ssa/ssa-dse-1.C scan-tree-dump-times dse1 "MEM <char\\\\[176]>
\\\\[\\\\(struct FixBuf \\\\*\\\\)&<retval> \\\\+ [0-9]+B\\\\] = {}" 1
on 32 and 64-bit i386-pc-solaris2.11 (and i686-pc-linux-gnu),
these failures remain...
On i686-linux I can reproduce just the above ones.
The following should fix it. As we don't match exact offset on the MEM
because it varries between different architectures (24 bytes on with -m64,
28 bytes with -m32), we shouldn't match the store size either, as it is
200 - that offset, so 176 or 172 etc.
Tested on x86_64-linux, -m32/-m64, ok for trunk?
2019-06-13 Jakub Jelinek <ja...@redhat.com>
* g++.dg/tree-ssa/ssa-dse-1.C: Don't match exact number of chars of
= {} store.
* g++.dg/tree-ssa/pr31146.C: Change -fdump-tree-forwprop to
-fdump-tree-forwprop1 in dg-options. Expect <int[5]> in MEM.
--- gcc/testsuite/g++.dg/tree-ssa/ssa-dse-1.C.jj 2019-06-13
00:35:49.654840275 +0200
+++ gcc/testsuite/g++.dg/tree-ssa/ssa-dse-1.C 2019-06-13 12:40:14.492568336
+0200
@@ -98,4 +98,4 @@ int main()
/* { dg-final { scan-tree-dump-times "MEM\\\[\\(struct FixBuf \\*\\)&<retval> \\+ \[0-9\]+B\\\] = {}" 1 "dse1" { target { ! store_merge } } } }
- { dg-final { scan-tree-dump-times "MEM <char\\\[176]> \\\[\\(struct FixBuf \\*\\)&<retval>
\\+ \[0-9\]+B\\\] = {}" 1 "dse1" { target { store_merge } } } } */
+ { dg-final { scan-tree-dump-times "MEM <char\\\[\[0-9\]+]> \\\[\\(struct FixBuf
\\*\\)&<retval> \\+ \[0-9\]+B\\\] = {}" 1 "dse1" { target { store_merge } } } } */
--- gcc/testsuite/g++.dg/tree-ssa/pr31146.C.jj 2015-05-29 15:04:33.039803414
+0200
+++ gcc/testsuite/g++.dg/tree-ssa/pr31146.C 2019-06-13 12:24:15.895576933
+0200
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O -fdump-tree-forwprop" } */
+/* { dg-options "-O -fdump-tree-forwprop1" } */
/* We should be able to optimize this to i[j] = 1 during
early optimizations. */
@@ -12,4 +12,4 @@ void foo (int j)
*q = 1;
}
-/* { dg-final { scan-tree-dump "MEM\\\[.*&i\\\]\\\[j.*\\\] =.* 1;" "forwprop1" } } */
+/* { dg-final { scan-tree-dump "MEM <int\\\[5\\\]> \\\[.*&i\\\]\\\[j.*\\\] =.* 1;"
"forwprop1" } } */
Thanks for cleaning this up.
The size of the access above doesn't look right. The test is:
int i[5];
void foo (int j)
{
void *p = &i[j];
int *q = (int *)p;
*q = 1;
}
and the MEM_REF is for the assignment *q = 1. It assigns a single
int, not the whole array. The -gimple output looks pretty much
the same:
__MEM <int[5]> ((int *)&i)[j_1(D)] = 1;
I expected it to mention the size of the access, e.g., like this:
__MEM <int> ((int *)&i)[j_1(D)] = 1;
It was the entire goal of the change I made to be able to be able
to see the size of the access so it doesn't look like I got it
right and some more tweaking is necessary. Which also raises
the question: what is the purpose of the MEM_REF type if not to
encode the size/alignment of the access?
Martin
