[Bug tree-optimization/46232] New: [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[Bug tree-optimization/46232] New: [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232

           Summary: [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c
                    FAILs on SPARC
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ro@gcc.gnu.org
              Host: sparc-sun-solaris2.*
            Target: sparc-sun-solaris2.*
             Build: sparc-sun-solaris2.*


Since about 20100929, the 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on Solaris
2/SPARC.  This is a regression from 4.4/4.5:

FAIL: gcc.dg/tree-ssa/pr14814.c scan-tree-dump-times forwprop2 "&" 0

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2010.10.29 23:25:16
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-10-29 23:25:16 UTC ---
Please help us and attach the dump file at least.

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232

--- Comment #2 from Rainer Orth <ro at gcc dot gnu.org> 2010-11-02 20:15:45 UTC ---
Created attachment 22236
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22236
-fdump-tree-forwprop2 output

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.0

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-04 14:52:31 UTC ---
I wonder where this aggregate copy comes from:

  D.1987 = r_2(D)->v;
  D.1986 = D.1987;

it's not there on x86_64-linux where we use return slot optimization for
the call to direction.  Thus the .ssa dump has

<bb 2>:
  t = direction (r_2(D)); [return slot optimization]
  D.2694_3 = y (&t);

is sparc-solaris returning struct YY in registers?

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

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

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-04 18:39:23 UTC ---
> is sparc-solaris returning struct YY in registers?

Yes, it does in 64-bit mode, see config/sparc/sparc.c lines 4800 and below.

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
                 CC|                            |jamborm at gcc dot gnu.org

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-15 12:18:04 UTC ---
On x86_64-linux early SRA manages to look through the single copy

  t = r_2(D)->v;
  D.2695_4 = t.e[1];

when scalarizing t and thus loads indirectly from r_2.  On sparc we
instead see

  D.1987 = r_2(D)->v;
  D.1986 = D.1987;
  D.2695_4 = D.1986.e[1];

and SRA doesn't manage to look through both.  One might be able to
create an equivalent testcase on x86_64 that doesn't rely on inlining
or return-value optimization.

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232

--- Comment #6 from Martin Jambor <jamborm at gcc dot gnu.org> 2010-12-15 15:05:40 UTC ---
Well, SRA currently propagates sub-accesses across assignments only
from the RHS to the LHS.  I will have a look at how intrusive it would
be to add the other direction as well.

Nevertheless, this has been the case in 4.5 as well, how come the
testcase does not fail there?

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-12-15 17:07:44 UTC ---
> Nevertheless, this has been the case in 4.5 as well, how come the
> testcase does not fail there?

The generated code is identical on mainline and 4.5 branch so there is no
actual regression.  It's simply the confusing notation

  t$e$1_10 = MEM[(struct YY *)&D.1994 + 8B]

on the mainline instead of

  t$e$1_10 = D.1994.e[1];

on the 4.5 branch that lets you think there is still an indirection.  It is
introduced during ESRA:

  D.1995 = r_2(D)->v;
  D.1994 = D.1995;
  t = D.1994;
  D.1980_4 = t.e[1];

becomes

  D.1995 = r_2(D)->v;
  D.1994 = D.1995;
  t = D.1994;
  t$e$1_10 = MEM[(struct YY *)&D.1994 + 8B];
  D.1980_4 = t$e$1_10;

instead of

  D.1995 = r_2(D)->v;
  D.1994 = D.1995;
  t = D.1994;
  t$e$1_10 = D.1994.e[1];
  D.1980_4 = t$e$1_10;

on the 4.5 branch.  This looks totally useless.

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[jamborm at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232

--- Comment #8 from Martin Jambor <jamborm at gcc dot gnu.org> 2010-12-15 17:40:00 UTC ---
I see.  I think this is not a P1 stuff then and should definitely not
block a release.  I'd rather not promise anything, but I'll add this
to my TODO list and hope I will try to address this for 4.7.

As far as the MEM_REF instead of ARRAY_REF awkwardness is concerned, I
don't feel like discussing merits of the former here but trust me
there are reasons for this.  If you want to have a look for yourself,
compare 4.5 and 4.6 build_ref_for_offset implementations (including
build_ref_for_model in 4.6) and especially their callers (and the
number of them).  And of course there was PR 44972.

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232

--- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-12-15 17:58:51 UTC ---
> I see.  I think this is not a P1 stuff then and should definitely not
> block a release.  I'd rather not promise anything, but I'll add this
> to my TODO list and hope I will try to address this for 4.7.

Right, I think it should be marked XFAIL on the mainline.

> As far as the MEM_REF instead of ARRAY_REF awkwardness is concerned, I
> don't feel like discussing merits of the former here but trust me
> there are reasons for this.  If you want to have a look for yourself,
> compare 4.5 and 4.6 build_ref_for_offset implementations (including
> build_ref_for_model in 4.6) and especially their callers (and the
> number of them).  And of course there was PR 44972.

Look at PR 46801 though.  Scalarization of these records in simple contexts
(i.e. no indirection in sight) worked in GCC 4.x up to very recently.  Now it
seems that MEM_REF has introduced artificial indirections all over the place,
leading to the pessimization of these cases.

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232

--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-12-18 12:52:45 UTC ---
Author: ebotcazou
Date: Sat Dec 18 12:52:41 2010
New Revision: 168023

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168023
Log:
    PR tree-optimization/46232
    * gcc.dg/tree-ssa/pr14814.c: Add -fno-tree-sra.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/tree-ssa/pr14814.c

[Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

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

--- Comment #11 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-12-18 12:54:27 UTC ---
It should pass now.