[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862 Andrew Pinski changed: What|Removed |Added Component|middle-end |tree-optimization --- Comment #26 from Andrew Pinski --- I think the majority of these issues have been fixed since moving over to the C/C++ 11 memory model and there is an option to disable that via -fallow-store-data-races Is that correct?
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #1 from dnovillo at acm dot org 2007-05-08 14:10 --- Subject: Re: New: Loop IM and other optimizations harmful for -fopenmp On 8 May 2007 07:59:03 -, jakub at gcc dot gnu dot org [EMAIL PROTECTED] wrote: See http://openmp.org/pipermail/omp/2007/000840.html and the rest of the lengthy threads: Yes, I've been following the thread and I agree that we need to do something to avoid the problem. The real solution is, unfortunately, quite a bit of work. In the meantime, we should probably annotate the shared variables and consider them volatile. This should prevent most optimizers from messing things up inadvertently. This should be done within OMP regions. Orphaned functions may become a problem, so this should be implemented as an IPA pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-08 15:30 --- WTF, this is just sad we have to disable optimizations because openmp folks don't know how to program threaded code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-08 15:37 --- OMP is not a good generic programming model for threaded code. Exactly because of this issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #4 from dnovillo at acm dot org 2007-05-08 15:39 --- Subject: Re: Loop IM and other optimizations harmful for -fopenmp On 8 May 2007 14:30:45 -, pinskia at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-08 15:30 --- WTF, this is just sad we have to disable optimizations because openmp folks don't know how to program threaded code. No need to be insulting. Another possibility is to require shared variables to be declared volatile. It depends on the wording in the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #5 from dnovillo at acm dot org 2007-05-08 15:44 --- Subject: Re: Loop IM and other optimizations harmful for -fopenmp On 8 May 2007 14:37:05 -, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: OMP is not a good generic programming model for threaded code. Exactly because of this issues. No. This is wrong. The model simply requires the compiler to be smarter. Sequential compilers are not aware of parallel semantics. If the compiler was thread-aware, these issues would be transparent to the user (as they should be). The original code did not have a race condition. The compiler transformations introduced a race-condition. This *is* a compiler bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
Re: [Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
On 8 May 2007 14:44:16 -, dnovillo at acm dot org [EMAIL PROTECTED] wrote: The original code did not have a race condition. The compiler transformations introduced a race-condition. This *is* a compiler bug. Actually the original code has a race condition, if another thread is reading from var and then acting on that and writting back. This is why threading programming is considered hard.
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #6 from pinskia at gmail dot com 2007-05-08 15:59 --- Subject: Re: Loop IM and other optimizations harmful for -fopenmp On 8 May 2007 14:44:16 -, dnovillo at acm dot org [EMAIL PROTECTED] wrote: The original code did not have a race condition. The compiler transformations introduced a race-condition. This *is* a compiler bug. Actually the original code has a race condition, if another thread is reading from var and then acting on that and writting back. This is why threading programming is considered hard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #7 from jakub at gcc dot gnu dot org 2007-05-08 19:08 ---
This really is not specific to OpenMP, I believe the following is valid
threaded program:
#define _XOPEN_SOURCE 600
#include pthread.h
#include stdlib.h
int v;
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
pthread_barrier_t b;
void
foo (int x, int y)
{
int i;
for (i = 0; i 100; i++)
{
if (i x)
v = y;
}
}
void *
tf (void *arg)
{
pthread_barrier_wait (b);
if (arg == NULL)
{
pthread_mutex_lock (m);
if (v != 0)
abort ();
foo (50, 10);
pthread_mutex_unlock (m);
pthread_barrier_wait (b);
foo (120, 30);
}
else
{
foo (100, 20);
pthread_barrier_wait (b);
pthread_mutex_lock (m);
if (v != 10)
abort ();
foo (80, 40);
if (v != 40)
abort ();
pthread_mutex_unlock (m);
}
return NULL;
}
int
main (void)
{
pthread_t th[2];
pthread_barrier_init (b, NULL, 2);
if (pthread_create (th[0], NULL, tf, NULL)
|| pthread_create (th[1], NULL, tf, (void *) 1L))
return 1;
pthread_join (th[0], NULL);
pthread_join (th[1], NULL);
return 0;
}
and at -O0 works just fine and has no races in it, it is quite easy to show
the shared variable is only ever read or written inside of the critical
section.
But loop IM creates a race even when there is none in the code originally, if I
compile this with -O2 (both 4.1.x and trunk) it will abort after a couple of
attempts.
That's why I think we should have a generic option that disables optimizations
which are safe only in sequential programs (and -fopenmp would imply that
option).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
[Bug tree-optimization/31862] Loop IM and other optimizations harmful for -fopenmp
--- Comment #8 from pinskia at gmail dot com 2007-05-08 19:45 --- Subject: Re: Loop IM and other optimizations harmful for -fopenmp On 8 May 2007 18:08:26 -, jakub at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #7 from jakub at gcc dot gnu dot org 2007-05-08 19:08 --- This really is not specific to OpenMP, I believe the following is valid threaded program: This is not a valid program. You have to introduce mutexes to get it to be a valid program with threads. This is a common misunderstanding of thread programming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
