[Bug c/54149] New: write introduction incorrect wrt the C11 memory model

[Bug c/54149] New: write introduction incorrect wrt the C11 memory model

[francesco.zappa.nardelli at gmail dot com]

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

             Bug #: 54149
           Summary: write introduction incorrect wrt the C11 memory model
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: francesco.zappa.nardelli@gmail.com


[ possibly related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 ]

Consider this program:

int g_13 = 1;

void main () {
int l_245;
for (l_245 = 0; l_245 <= 1; l_245 += 1)
 for (; g_13 <= 0; g_13 = 1);
}

If I compile it with 

 gcc --param allow-store-data-races=0 -S -O1 

(I am running gcc (GCC) 4.8.0 20120627 (experimental) on Linux - x86_64 -- the
same applies to -O2 and -O3 and compilation with g++ -std=c++11 -O1)

I get the following optimised assembler (I just hand removed some noise):

main:
     movl    g_13(%rip), %eax
     testl   %eax, %eax
     movl    $1, %edx
     cmovle  %edx, %eax
     movl    %eax, g_13(%rip)
     ret

g_13:
     .long   1

which always performs a write to g_13 and executes with this memory trace (I am
tracing only the accesses to the global - potentially shared - variables):

          g_13                    1  4                Init
          g_13                    1  4                Load
          g_13                    1  4               Store

However the reference trace for the C11 program above never performs a write to
g_13:

          g_13                    1  4                Init
          g_13                    1  4                Load
          g_13                    1  4                Load

This looks related to the problem I reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 , as the optimiser introduces
a memory write which should not be there (and in turn performs an optimisation
not correct wrt the C11 or the C++11 memory model).  The same discriminating
context of bug 52558 applies.

For reference: 

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/yquem/moscova/zappa/source/gcc-svn-bin/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure
--prefix=/home/yquem/moscova/zappa/source/gcc-svn-bin/
Thread model: posix
gcc version 4.8.0 20120627 (experimental) (GCC)

[Bug c/54149] write introduction incorrect wrt the C11 memory model

[francesco.zappa.nardelli at gmail dot com]

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

--- Comment #1 from Francesco Zappa Nardelli <francesco.zappa.nardelli at gmail dot com> 2012-08-23 16:34:38 UTC ---
Here is another C program that hits a similar write-introduction problem:

int g_7, g_372;

char func_10 () {
  for (; g_7 < 0; ++g_7) {
  }
  return 0;
}

void main () {
  int l_8;
lbl_914:
  (l_8 = g_7) <= func_10 ();
  if (l_8)
    if (g_372) {
    } else
      goto lbl_914;
}

The reference trace is:

*** unoptimised trace: gcc --param allow-store-data-races=0 8-min.c -o
8-min_unopt

              g_7                    0  4                Init
            g_372                    0  4                Init
              g_7                    0  4                Load
              g_7                    0  4                Load

while the optimised trace (requires -O2 or -O3 to be observable) is

*** optimised trace: gcc --param allow-store-data-races=0 -O3 8-min.c -o
8-min_opt

              g_7                    0  4                Init
            g_372                    0  4                Init
            g_372                    0  4                Load
              g_7                    0  4                Load
              g_7                    0  4               Store

[ gcc version 4.8.0 20120627 (experimental) (GCC) ]

[Bug c/54149] write introduction incorrect wrt the C11 memory model

[aldyh at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-09-07
                 CC|                            |amacleod at redhat dot com
         AssignedTo|unassigned at gcc dot       |aldyh at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-09-07 19:45:29 UTC ---
This looks like a data race introduced by LIM.  Ughh, I thought I had this pass
all fixed... I'll take a look.

[Bug middle-end/54149] write introduction incorrect wrt the C11 memory model

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-09-11 12:28:11 UTC ---
Author: aldyh
Date: Tue Sep 11 12:28:02 2012
New Revision: 191179

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191179
Log:
        PR middle-end/54149
        * tree-ssa-loop-im.c (execute_sm_if_changed_flag_set): Only set
        flag for writes.

Added:
    trunk/gcc/testsuite/gcc.dg/simulate-thread/speculative-store-4.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-loop-im.c

[Bug middle-end/54149] write introduction incorrect wrt the C11 memory model

[aldyh at gcc dot gnu.org]

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

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

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

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-09-11 12:30:36 UTC ---
fixed on trunk