[Bug middle-end/54184] New: [4.8 Regression] gcc.dg/pr52558-1.c failure

[Bug middle-end/54184] New: [4.8 Regression] gcc.dg/pr52558-1.c failure

[hjl.tools at gmail dot com]

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

             Bug #: 54184
           Summary: [4.8 Regression] gcc.dg/pr52558-1.c failure
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hjl.tools@gmail.com
                CC: rguenth@gcc.gnu.org


On Linux/x86, revision 190067:

http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00041.html

caused:

FAIL: gcc.dg/pr52558-1.c scan-tree-dump-times lim1 "MEM count_lsm..
count_lsm_flag" 1
FAIL: gcc.dg/pr52558-2.c scan-tree-dump-times lim1 "MEM.*g_2_lsm_flag" 1
FAIL: gcc.dg/tm/reg-promotion.c scan-tree-dump-times lim1 "MEM count_lsm..
count_lsm_flag" 1

[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-08-06
          Component|middle-end                  |testsuite
                 CC|                            |aldyh at gcc dot gnu.org
     Ever Confirmed|0                           |1
   Target Milestone|---                         |4.8.0

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-08-06 08:33:38 UTC ---
As said in the commit mail, the testcase is "broken".  It scans for a random
string not in any way associated with what the testcase checks.  That random
string no longer appears - instead of just deleting the scan I've opted to
let the author of the patch figure a better way to check for a successful
testcase.

Confirmed anyway.

[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

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

--- Comment #2 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2012-08-06 14:24:37 UTC ---
cris-elf too, since it's global.  It should be xfailed until fixed; that is,
assuming it doesn't randomly succeed, which could be confusing.

[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-08-21 17:46:26 UTC ---
My bad... I'm on this.

[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

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

--- Comment #4 from John David Anglin <danglin at gcc dot gnu.org> 2012-09-02 16:36:13 UTC ---
hppa64-hp-hpux11.11 as well.

[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot       |aldyh at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-09-05 21:15:52 UTC ---
What I was trying to test here originally was whether the LIM pass kept a flag
of changes to "count" and only if the flag was true, allow the cached version
of "count" to be stored.

Technically, I could get away with only checking the presence of count_lsm_flag
in the dump, though I realize that this also is an imperfect solution if a
previous pass changed things around.

Apart from checking count_lsm_flag, the only thing I can think of is replacing
this test with one within the simulate-thread/ infrastructure that actually
checks that no caching occurs unless p->data > 0.

Richard, which solution do you prefer, or do you recommend something else?

void func()
{
  struct obj *p;
  for (p = q; p; p = p->next)
    if (p->data > 0)
      count++;
}

[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure

[aldyh at gcc dot gnu.org]

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

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-09-05 22:43:03 UTC ---
Created attachment 28137
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28137
proposed patch

Proposed patch using the simulate-thread harness.

[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> 2012-09-06 08:53:36 UTC ---
On Wed, 5 Sep 2012, aldyh at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54184
> 
> Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>          AssignedTo|unassigned at gcc dot       |aldyh at gcc dot gnu.org
>                    |gnu.org                     |
> 
> --- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-09-05 21:15:52 UTC ---
> What I was trying to test here originally was whether the LIM pass kept a flag
> of changes to "count" and only if the flag was true, allow the cached version
> of "count" to be stored.
> 
> Technically, I could get away with only checking the presence of count_lsm_flag
> in the dump, though I realize that this also is an imperfect solution if a
> previous pass changed things around.
> 
> Apart from checking count_lsm_flag, the only thing I can think of is replacing
> this test with one within the simulate-thread/ infrastructure that actually
> checks that no caching occurs unless p->data > 0.

Yes, that sounds like the proper solution.

> Richard, which solution do you prefer, or do you recommend something else?

Another way would be to make LIM emit something in the dump when
it did a "conditional" hoisting as opposed to an un-conditional one
and check that for the testcases the hoisting occurs but only conditional.

Richard.

[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-06 17:06:07 UTC ---
What about gcc.dg/pr52558-2.c and gcc.dg/tm/reg-promotion.c not handled by the
patch posted at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00390.html?

[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure

[aldyh at gcc dot gnu.org]

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

--- Comment #9 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-09-07 16:00:18 UTC ---
Author: aldyh
Date: Fri Sep  7 16:00:07 2012
New Revision: 191079

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191079
Log:
    PR testsuite/54184
    * gcc.dg/pr52558-1.c: Delete.
    * gcc.dg/simulate-thread/speculative-store-2.c: New.

Added:
    trunk/gcc/testsuite/gcc.dg/simulate-thread/speculative-store-2.c
Removed:
    trunk/gcc/testsuite/gcc.dg/pr52558-1.c
Modified:
    trunk/gcc/testsuite/ChangeLog

[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

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

--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-09-07 18:23:15 UTC ---
(In reply to comment #8)
> What about gcc.dg/pr52558-2.c and gcc.dg/tm/reg-promotion.c not handled by the
> patch posted at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00390.html?

I have pending patches for these too:

http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00485.html
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00487.html

Thanks for reporting this.

I will now close this PR, as the original problem reported has been fixed and
committed.