[Bug c/54149] write introduction incorrect wrt the C11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54149
--- Comment #1 from Francesco Zappa Nardelli 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_70 4Init
g_3720 4Init
g_70 4Load
g_70 4Load
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_70 4Init
g_3720 4Init
g_3720 4Load
g_70 4Load
g_70 4 Store
[ gcc version 4.8.0 20120627 (experimental) (GCC) ]
[Bug tree-optimization/54458] New: get_loop_body, at cfgloop.c:830
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54458 Bug #: 54458 Summary: get_loop_body, at cfgloop.c:830 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: francesco.zappa.narde...@gmail.com
[Bug tree-optimization/54458] ICE get_loop_body, at cfgloop.c:830
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54458
--- Comment #1 from Francesco Zappa Nardelli 2012-09-02 15:42:45 UTC ---
$ 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)
[a recent but not the latest svn trunk]
$ cat input.c
int a, b, c, d;
void
func_34 () {
lbl_424:
if (c ? 0 : 0 % 0)
for (; a; a--)
lbl_130: {
}
else if (d)
for (;;) {
}
if (b)
goto lbl_130;
goto lbl_424;
}
void
main () {
}
$ gcc -O3 input.c
input.c: In function 'func_34':
input.c:5:17: warning: division by zero [-Wdiv-by-zero]
if (c ? 0 : 0 % 0)
^
input.c:3:1: internal compiler error: in get_loop_body, at cfgloop.c:830
func_34 () {
^
Please submit a full bug report.
[Bug tree-optimization/54458] ICE get_loop_body, at cfgloop.c:830
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54458
--- Comment #2 from Francesco Zappa Nardelli 2012-09-02 16:23:35 UTC ---
Can reproduce with the latest svn trunk as well:
$ 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 --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/yquem/moscova/zappa/source/gcc-svn-bin
: (reconfigured) ../gcc-svn/configure --disable-bootstrap --enable-languages=c
--prefix=/home/yquem/moscova/zappa/source/gcc-svn-bin
Thread model: posix
gcc version 4.8.0 20120902 (experimental) (GCC)
and the exact error message now is:
input.c:3:1: internal compiler error: in get_loop_body, at cfgloop.c:823
func_34 () {
^
Please submit a full bug report.
[Bug tree-optimization/54458] [4.8 Regression] ICE get_loop_body, at cfgloop.c:830
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54458
--- Comment #4 from Francesco Zappa Nardelli 2012-09-02 17:55:10 UTC ---
Just to be precise, the program has an undefined behaviour in the test of the
first 'if':
(c ? 0 : 0 % 0)
because the right operand of % cannot be 0 (according to the standard,
§6.5.5#5). Unclear to me if a compiler is allowed to crash on programs with
undefined behaviours or not.
However an undefined-behaviour free (I believe) variant of that code makes gcc
crash similarly:
int g_24[][0];
int g_42;
int g_168[];
void func_34 (p_38) {
lbl_424:
if (g_24[0][0] == 0 ? 1 : 1 % (g_24[0][0]))
for (; g_42; g_42--)
lbl_130: {
}
else if (p_38)
for (;;) {
}
if (g_168[0])
goto lbl_130;
goto lbl_424;
}
void main () {
g_24[0][0] = 1;
func_34(0);
}
$ gcc -O3 input.c (gcc version 4.8.0 20120902 (experimental) (GCC) )
input-hand.c: In function 'func_34':
input-hand.c:5:6: internal compiler error: in get_loop_body, at cfgloop.c:823
void func_34 (p_38) {
^
Please submit a full bug report.
Not sure that it helps, but while I was performing test-case reduction I
noticed that the % operator plays a key role in making gcc crash here.
[Bug tree-optimization/54900] New: write introduction incorrect wrt the C11 memory model (2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54900
Bug #: 54900
Summary: write introduction incorrect wrt the C11 memory model
(2)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: francesco.zappa.narde...@gmail.com
This program:
#include
#include
int g_8 = 1;
int g_140;
int *g_139 = &g_140;
int **g_138 = &g_139;
int g_182;
void func_2 (p1) {
**g_138 = 0;
}
int func_11 (int p1, int p2, int p3, int p4) {
if (g_8)
return 0;
++g_182;
return 0;
}
void *context (void *ptr) {
g_182 = 1;
printf ("%d\n",g_182);
}
void main () {
pthread_t thread1;
int iret1;
iret1 = pthread_create( &thread1, NULL, context, (void*) 0);
func_2 (func_11 (0, 0, 0, 0) );
pthread_join( thread1, NULL);
}
is miscompiled by gcc --param allow-store-data-races=0 -O2 (or -O3) on x86_64.
[ gcc version 4.8.0 20121011 (experimental) (GCC) ]
The program has no data-races because the ++g_182 instruction in func_11 is
never executed by the main thread, and the context thread is expected to always
print 1.
The -O2 and -O3 optimisers (invoked with --param allow-store-data-races=0)
compile main as:
main:
subq$24, %rsp
xorl%ecx, %ecx
xorl%esi, %esi
leaq8(%rsp), %rdi
movl$context, %edx
callpthread_create
xorl%eax, %eax
cmpl$1, g_8(%rip)
movq8(%rsp), %rdi
setb%al
(**)addl%eax, g_182(%rip)
movqg_138(%rip), %rax
xorl%esi, %esi
movq(%rax), %rax
movl$0, (%rax)
callpthread_join
addq$24, %rsp
ret
The problem is in the (**) instruction:
addl%eax, g_182(%rip)
which inserts a write of the value 0 in the run-time trace of the main thread,
possibly resulting in the context thread printing 0.
[Bug tree-optimization/54906] New: write introduction incorrect wrt the C++11 memory model (case with atomic accesses)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54906
Bug #: 54906
Summary: write introduction incorrect wrt the C++11 memory
model (case with atomic accesses)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: francesco.zappa.narde...@gmail.com
The program below is miscompiled by g++ --param allow-store-data-races=0 -O2
(or -O3).
$ g++ -v
gcc version 4.8.0 20121011 (experimental) (GCC)
#include
using namespace std;
uint8_t g_5;
atomic_ushort a_9;
atomic_schar a_24;
void func_1 () {
if (a_9.load ())
for (g_5 = 0; 0; g_5++) {
}
a_24.store (0);
}
int main () {
func_1 ();
return 0;
}
The assembly code generated by -O3 for func_1 is:
_Z6func_1v:
movzwl a_9(%rip), %edx
xorl%eax, %eax
testw %dx, %dx
movzbl g_5(%rip), %edx
cmove %edx, %eax
movb%al, g_5(%rip)
movb$0, a_24(%rip)
mfence
ret
This code loads and restores the global variable g_5, while the reference
semantics for the source program does not perform a write to g_5. It is easy
to write a non-racy context that observes this unexpected behaviour.
[Bug 54900 might be related or not; in the example here the write is introduced
only if a_24 is an atomic variable].
[Bug rtl-optimization/54900] write introduction incorrect wrt the C11 memory model (2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54900 --- Comment #4 from Francesco Zappa Nardelli 2012-10-18 13:39:30 UTC --- gcc version 4.8.0 20121018 (experimental) - which includes revision 192548 - compiles this example correctly. It also fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54906 . Great, thanks.
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
Francesco Zappa Nardelli changed:
What|Removed |Added
CC||francesco.zappa.nardelli@gm
||ail.com
--- Comment #16 from Francesco Zappa Nardelli ---
Dear all
a possibly related issue. Consider
struct S1 {
long f;
};
volatile struct S1 g;
struct S1 func_1 () {
return g;
}
void main () {
func_1 ();
}
This program, if compiled with a recent gcc svn:
$ gcc -v
Target: x86_64-unknown-linux-gnu
gcc version 4.9.0 20130625 (experimental) (GCC)
correctly loads the long at g.f at -O0. However the assembly generated at -O2:
func_1:
movqg(%rip), %rax
ret
main:
rep; ret
does not perform the volatile load access, which, as far as I understand, is
incorrect.
-francesco
[Bug c/58409] New: wrong reordering of volatile writes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58409
Bug ID: 58409
Summary: wrong reordering of volatile writes
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: francesco.zappa.nardelli at gmail dot com
In the program below, at least according to the C11 standard, there is a
sequence point between the volatile store to g_3[0][0][0] and the volatile
store to *g_6 (that is, to the volatile int g_5). As a consequence, the store
to g_3 should be performed before the store to g_5.
struct {
volatile int f1;
} g_1, *g_2 = &g_1, g_3[1][1][1], **g_4 = &g_2;
volatile int g_5;
static volatile int *g_6 = &g_5;
int func_2 () {
g_3[0][0][0] = **g_4;
return 0;
}
int func_1 () {
*g_6 = func_2 ();
return 0;
}
void main () {
func_1 ();
}
If the program is compiled with a recent svn trunk
$ gcc -v
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
gcc version 4.9.0 20130912 (experimental) (GCC)
at optimisation level -O2 or -O3 then the generated assembler swaps the store
to g_5 with the store to g_3:
main:
movqg_4(%rip), %rax
movq(%rax), %rax
movl(%rax), %eax
movl$0, g_5(%rip)
movl%eax, g_3(%rip)
ret
As far as I can tell, this reordering should be considered as a compiler bug.
The same happens with gcc 4.8.1.
[Bug c/58409] wrong reordering of volatile writes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58409 --- Comment #2 from Francesco Zappa Nardelli --- Yes, it does fix the issue. So this reordering is another effect of gcc not considering accessing volatile fields in non-volatile structs as volatile access (as in bug 47409). Can I ask about gcc plans for bug 47409? It has been opened for a couple of years without a clear decision at the end.
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409 --- Comment #19 from Francesco Zappa Nardelli --- >> does not perform the volatile load access. > It does starting with GCC 4.8.2 and was a bug in older GCC versions. I just tested my example (comment 16) against yesterday trunk gcc version 4.9.0 20130912 (experimental) (GCC) and indeed the volatile load access is no longer removed. This is a good news. However the code I reported in bug 58409, which has been marked duplicate of this bug, still exhibits the incorrect reordering of volatile accesses. It thus seems to me that either bug 58409 is not a duplicate of this one, or the fix is incomplete. -francesco
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409 --- Comment #21 from Francesco Zappa Nardelli --- (In reply to Richard Biener from comment #20) > > However the code I reported in bug 58409, which has been marked duplicate of > > this bug, still exhibits the incorrect reordering of volatile accesses. It > > thus seems to me that either bug 58409 is not a duplicate of this one, or > > the fix is incomplete. > > It is a duplicate of this one because it is about a volatile struct member > in a not volatile object g_3[1][1][1]. And it is about the aggregate > assignment to that struct. Agreed. What I don't understand is the fact that the commits that led to the recent gcc svn trunk gcc version 4.9.0 20130912 (experimental) (GCC) solve the problem with the code in comment 16, but do not prevent the reordering of volatile writes described in bug 58409. As a consequence, it seems to me that gcc does not yet implement a correct semantics for accesses to volatile struct members in non volatile objects. Am I missing something or another fix is to be expected? Thanks. -francesco
[Bug c/54149] New: write introduction incorrect wrt the C11 memory model
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: unassig...@gcc.gnu.org
ReportedBy: francesco.zappa.narde...@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:
movlg_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_131 4Init
g_131 4Load
g_131 4 Store
However the reference trace for the C11 program above never performs a write to
g_13:
g_131 4Init
g_131 4Load
g_131 4Load
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++/52558] New: write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558
Bug #: 52558
Summary: write introduction incorrect wrt the C++11 memory
model
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: francesco.zappa.narde...@gmail.com
The program below:
int g_1 = 1;
int g_2 = 0;
int func_1(void) {
int l;
for (l = 0; (l != 4); l++) {
if (g_1)
return l;
for (g_2 = 0; (g_2 >= 26); ++g_2)
;
}
}
int main (int argc, char* argv[]) {
func_1();
}
is miscompiled by
gcc -v : gcc version 4.7.0 20120215 (experimental) (GCC)
(a recent svn snapshot) on x86-64 when -O2 is passed.
Observe that the inner loop of func_1 is never executed, and this program
should never perform any read/write to g_2. This means that func_1 might be
executed in a thread in parallel with another thread that performs:
g_2 = 42;
printf ("%d",g_2)
The resulting system is data-race free and the only value that should be
printed is 42.
However gcc -O2 generates the following x86-64 assembler for func_1:
func_1:
movlg_1(%rip), %edx
movlg_2(%rip), %eax
testl %edx, %edx
jne .L2
movl$0, g_2(%rip)
ret
.L2:
movl%eax, g_2(%rip)
xorl%eax, %eax
ret
and this code always performs a write to g_2. If this asm code runs in
parallel with "g_2 = 42; printf g_2", then the system might also print 0: this
behaviour is introduced by the compiler and should not have happened.
The command line to generate the assembler above is:
$ g++ -std=c++11 read_and_write_introduced.c -O2 -S
It might be the case that in the C++11 memory model it is safe for the compiler
to introduce a write provided that there is an earlier write to the same
location, but this testcase shows that introducing a write is unsafe whenever
there are no previous writes.
I labelled this as g++, but the bug will also affect the (future) c11 memory
model.
For reference:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/riob/zappanar/tools/gcc-bin/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-src/configure --prefix=/home/zappanar/tools/gcc-bin
--with-gmp=/home/zappanar/tools/lib/ --with-mpfr=/home/zappanar/tools/lib/
--with-mpc=/home/zappanar/tools/lib/ --enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20120215 (experimental) (GCC)
[Bug tree-optimization/52558] write introduction incorrect wrt the C++11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 --- Comment #11 from Francesco Zappa Nardelli 2012-03-13 07:29:51 UTC --- Just one remark: in this case the write introduction is incorrect wrt the C++11 memory model because there are no previous write to the same location. If there had been a previous write to the same location, then the discriminating context would have been racy and the code generated by -O2 sound. I believe that the above argument generalises to all write introductions but I don't yet have a proof of this, so take it with a pinch of salt.
[Bug tree-optimization/56150] New: ICE segfault in do_pre / tail_merge_optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56150
Bug #: 56150
Summary: ICE segfault in do_pre / tail_merge_optimize
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: francesco.zappa.narde...@gmail.com
The program below makes
gcc version 4.8.0 20130130 (experimental) (GCC)
crash (ICE) at optimisation level -O2 and -O3:
$ gcc -O2 5-min.c
5-min.c: In function ‘func_1’:
5-min.c:9:6: internal compiler error: Segmentation fault
void func_1 () {
^
0x8e59af crash_signal
../../gcc-svn-src/gcc/toplev.c:332
0xa434a7 vn_valueize
../../gcc-svn-src/gcc/tree-ssa-sccvn.h:226
0xa434a7 gimple_equal_p
../../gcc-svn-src/gcc/tree-ssa-tail-merge.c:1124
0xa434a7 find_duplicate
../../gcc-svn-src/gcc/tree-ssa-tail-merge.c:1214
0xa434a7 find_clusters_1
../../gcc-svn-src/gcc/tree-ssa-tail-merge.c:1409
0xa434a7 find_clusters
../../gcc-svn-src/gcc/tree-ssa-tail-merge.c:1430
0xa455ec tail_merge_optimize(unsigned int)
../../gcc-svn-src/gcc/tree-ssa-tail-merge.c:1634
0xa0b69c do_pre
../../gcc-svn-src/gcc/tree-ssa-pre.c:4754
Here is the program 5-min.c:
struct {
int f4;
} g1;
long g2;
volatile long g3;
void func_1 () {
if (g2)
g1 = g1;
else
g3;
}
void main () {
}
[Bug tree-optimization/56150] ICE segfault in do_pre / tail_merge_optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56150 --- Comment #1 from Francesco Zappa Nardelli 2013-01-30 14:44:45 UTC --- Sorry, forgot to specify: Target: x86_64-unknown-linux-gnu
