[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #18 from Richard Biener ---
(In reply to Jakub Jelinek from comment #13)
> Seems get_ref_base_and_extent already has code for some cases of the
> flexible array members, but it has apparently some dead code in it that
> wasn't really meant to be dead (hint, this check is after a while (1) {
> switch (TREE_CODE (exp)) { ... } exp = TREE_OPERAND (exp, 0); } loop, thus
> break inside of the switch does not terminate the loop and the only way to
> get out of the loop is then goto done;, but that bypasses the stmt):
>
> --- gcc/tree-dfa.c.jj 2016-01-21 08:58:44.0 +0100
> +++ gcc/tree-dfa.c2016-02-04 11:18:40.061621702 +0100
> @@ -588,6 +588,7 @@ get_ref_base_and_extent (tree exp, HOST_
>exp = TREE_OPERAND (exp, 0);
> }
>
> + done:
>/* We need to deal with variable arrays ending structures. */
>if (seen_variable_array_ref
>&& maxsize != -1
> @@ -597,7 +598,6 @@ get_ref_base_and_extent (tree exp, HOST_
> == wi::to_offset (TYPE_SIZE (TREE_TYPE (exp))
> maxsize = -1;
>
> - done:
>if (!wi::fits_shwi_p (bitsize) || wi::neg_p (bitsize))
> {
>*poffset = 0;
>
> But I guess even this doesn't help, while it will help poor man's flexible
> array members in C/C++,
get_ref_base_and_extent is supposed to properly detect trailing arrays in
case the size cannot be adjusted by the underlying decls size. You don't
mention which goto done you think is broken here, the only relvant one is
that from the [TARGET_]MEM_REF case which sets maxsize to -1 itself.
I don't remember what the seen_variable_array_ref case after the while (1)
loop body was for.
Care to build a C testcase that goes wrong and that your patch would fix?
> in this Fortran case the problem is that there is
> COMMON /FMCOM/ X(1)
> in this TU, while
> COMMON /FMCOM / X(100)
> in some other TU, and get_ref_base_and_extent caps maxsize at DECL_SIZE -
> bit_offset (which is generally right, but Fortran COMMON is just weird).
> So, perhaps we want some flag on the Fortran COMMON decls that would be set
> on COMMON that ends with an array and would tell get_ref_base_and_extent
> (and other spots?) that accesses can be beyond end of the decl?
We certainly don't want to do that, it will pessimize all code that wants
max_size != -1 for commons.
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #13 from Jakub Jelinek ---
Seems get_ref_base_and_extent already has code for some cases of the flexible
array members, but it has apparently some dead code in it that wasn't really
meant to be dead (hint, this check is after a while (1) { switch (TREE_CODE
(exp)) { ... } exp = TREE_OPERAND (exp, 0); } loop, thus break inside of the
switch does not terminate the loop and the only way to get out of the loop is
then goto done;, but that bypasses the stmt):
--- gcc/tree-dfa.c.jj 2016-01-21 08:58:44.0 +0100
+++ gcc/tree-dfa.c 2016-02-04 11:18:40.061621702 +0100
@@ -588,6 +588,7 @@ get_ref_base_and_extent (tree exp, HOST_
exp = TREE_OPERAND (exp, 0);
}
+ done:
/* We need to deal with variable arrays ending structures. */
if (seen_variable_array_ref
&& maxsize != -1
@@ -597,7 +598,6 @@ get_ref_base_and_extent (tree exp, HOST_
== wi::to_offset (TYPE_SIZE (TREE_TYPE (exp))
maxsize = -1;
- done:
if (!wi::fits_shwi_p (bitsize) || wi::neg_p (bitsize))
{
*poffset = 0;
But I guess even this doesn't help, while it will help poor man's flexible
array members in C/C++, in this Fortran case the problem is that there is
COMMON /FMCOM/ X(1)
in this TU, while
COMMON /FMCOM / X(100)
in some other TU, and get_ref_base_and_extent caps maxsize at DECL_SIZE -
bit_offset (which is generally right, but Fortran COMMON is just weird).
So, perhaps we want some flag on the Fortran COMMON decls that would be set on
COMMON that ends with an array and would tell get_ref_base_and_extent (and
other spots?) that accesses can be beyond end of the decl?
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #16 from Jakub Jelinek --- (In reply to Dominique d'Humieres from comment #14) > > But I guess even this doesn't help, while it will help poor man's flexible > > array members in C/C++, in this Fortran case the problem is that there is > > COMMON /FMCOM/ X(1) > > in this TU, while > > COMMON /FMCOM / X(100) > > in some other TU, and get_ref_base_and_extent caps maxsize at > > DECL_SIZE - bit_offset (which is generally right, but Fortran COMMON > > is just weird). > > This invalid Fortran. Yes, but this is SPEC2k6, so we need some workaround or workaround option or something for that I'm afraid. > > So, perhaps we want some flag on the Fortran COMMON decls that would be > > set on COMMON that ends with an array and would tell get_ref_base_and_extent > > (and other spots?) that accesses can be beyond end of the decl? > > Related to/ duplicate of pr44882?
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #15 from Jakub Jelinek --- Note the dead code is there since r204391. Perhaps we need goto done; vs. goto done2;, so that for MEM_REF/TARGET_MEM_REF we bypass this check?
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #17 from Richard Biener --- (In reply to Jakub Jelinek from comment #16) > (In reply to Dominique d'Humieres from comment #14) > > > But I guess even this doesn't help, while it will help poor man's flexible > > > array members in C/C++, in this Fortran case the problem is that there is > > > COMMON /FMCOM/ X(1) > > > in this TU, while > > > COMMON /FMCOM / X(100) > > > in some other TU, and get_ref_base_and_extent caps maxsize at > > > DECL_SIZE - bit_offset (which is generally right, but Fortran COMMON > > > is just weird). > > > > This invalid Fortran. > > Yes, but this is SPEC2k6, so we need some workaround or workaround option or > something for that I'm afraid. No, tonto had this same crap and we required patching it. That said, all users of get_ref_base_and_extent are effected here (SRA, FRE, PRE, DSE), so this isn't sth new - it's just that now we catch this as well after loop opts did enough massaging to the IL to expose it. > > > So, perhaps we want some flag on the Fortran COMMON decls that would be > > > set on COMMON that ends with an array and would tell > > > get_ref_base_and_extent > > > (and other spots?) that accesses can be beyond end of the decl? > > > > Related to/ duplicate of pr44882?
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #14 from Dominique d'Humieres --- > But I guess even this doesn't help, while it will help poor man's flexible > array members in C/C++, in this Fortran case the problem is that there is > COMMON /FMCOM/ X(1) > in this TU, while > COMMON /FMCOM / X(100) > in some other TU, and get_ref_base_and_extent caps maxsize at > DECL_SIZE - bit_offset (which is generally right, but Fortran COMMON > is just weird). This invalid Fortran. > So, perhaps we want some flag on the Fortran COMMON decls that would be > set on COMMON that ends with an array and would tell get_ref_base_and_extent > (and other spots?) that accesses can be beyond end of the decl? Related to/ duplicate of pr44882?
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #10 from alalaw01 at gcc dot gnu.org --- The stores are getting optimized out because equal_mem_array_ref_p considers equal pairs of MEM_REFS like fmcom.x[_168] and fmcom.x[_208] That is, a ARRAY_REF whose first operand is a COMPONENT_REF fmcom.x (of a VAR_DECL and a FIELD_DECL), and whose second operand is an SSA_NAME _168 or _208; I don't see anything obvious to suggest that they should be equal). get_ref_base_and_extent then returns base=fmcom, size=64, max_size=64 (so not a variable-sized access), and offset 0 :-(.
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #11 from Jakub Jelinek --- Bet we shouldn't use get_ref_base_and_extent comparisons if there is a variable ARRAY_REF index and the corresponding array is flexible array member or poor man's flexible array member.
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #12 from Jakub Jelinek ---
Otherwise, we happily consider in
struct S { char a[1]; int b; char c[1]; };
void
foo (struct S *p, int i, int j)
{
p->c[i]
...
p->c[j]
}
the above two as equivalent, while we should only consider those for p->a[i]
and p->a[j], where it is only valid to use i == j == 0. If char c[2]; is used,
then max_size would indicate variable access, but for poor man's flexible array
member of size 1 array we need to avoid this, both during hashing and during
equality comparison.
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target|powerpc*-*-*|powerpc*-*-*, aarch64 Status|RESOLVED|REOPENED Keywords||wrong-code Last reconfirmed||2016-02-01 CC||ktkachov at gcc dot gnu.org Resolution|DUPLICATE |--- Ever confirmed|0 |1 Summary|spec2006 test case |[6 Regression] spec2006 |416.gamess fails with the |test case 416.gamess fails |g++ 6.0 compiler starting |with the g++ 6.0 compiler |with r232508|starting with r232508 Target Milestone|--- |6.0 --- Comment #3 from ktkachov at gcc dot gnu.org --- Reopening at Wilco's request
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #5 from Wilco --- This still fails on AArch64 in exactly the same way with latest trunk - can someone reopen this? I don't seem to have the right permissions... (In reply to Richard Biener from comment #4) > So - can you please bisect to a source file (just drop all others to -O0) at > least? Yes I am working on that. It's OK with O2, but starts failing with -O3/-Ofast.
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|REOPENED|NEW CC||rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- So - can you please bisect to a source file (just drop all others to -O0) at least?
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #8 from Wilco --- In a few functions GCC decides that the assignments in loops are redundant. The loops still execute but have their loads and stores removed. Eg. the first DO loop in MP2NRG should be: .L1027: add w7, w7, 1 add w8, w8, w10 cmp w7, w26 beq .L1026 .L1029: add w0, w11, w7 add x0, x2, x0, sxtw 3 ldr x1, [x0, -8] add x0, x2, x7, sxtw 3 str x1, [x0, -8] cmp w9, 0 ble .L1027 But with the scopedtables change it becomes: .L1027: add w2, w2, 1 cmp w2, w3 beq .L1026 .L1029: cmp w4, 0 ble .L1027
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #6 from Wilco --- This still fails on AArch64 in exactly the same way with latest trunk - can someone reopen this? I don't seem to have the right permissions... (In reply to Richard Biener from comment #4) > So - can you please bisect to a source file (just drop all others to -O0) at > least? It looks like the failure is in mp2.fppized.o. Compiling it with -O3 -fomit-frame-pointer -fno-aggressive-loop-optimizations -fno-inline causes it to fail the exam29 test with the recent tree-ssa-scopedtables.c changes, while it passes without them. The diff is quite large so it's hard to tell which function it is...
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #7 from rguenther at suse dot de --- On Mon, 1 Feb 2016, wdijkstr at arm dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 > > --- Comment #6 from Wilco --- > This still fails on AArch64 in exactly the same way with latest trunk - can > someone reopen this? I don't seem to have the right permissions... > (In reply to Richard Biener from comment #4) > > So - can you please bisect to a source file (just drop all others to -O0) at > > least? > > It looks like the failure is in mp2.fppized.o. Compiling it with -O3 > -fomit-frame-pointer -fno-aggressive-loop-optimizations -fno-inline causes it > to fail the exam29 test with the recent tree-ssa-scopedtables.c changes, while > it passes without them. The diff is quite large so it's hard to tell which > function it is... Probably easier to look at a diff backing out the mem-ref hashing changes.
[Bug tree-optimization/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #9 from Wilco --- The loops get optimized away in dom2. The info this phase emits is hard to figure out, so it's not obvious why it thinks the array assignments are redundant (the array is used all over the place so clearly cannot be removed).
