--- Comment #25 from ebotcazou at gcc dot gnu dot org 2009-02-26 08:26
---
Also, you can have the same problem with this kind of code without threads.
Imagine, for example, if the 'shared_variable' may be in read-only memory and
'can_write' indicates this case.
Then it must be
--- Comment #16 from bonzini at gnu dot org 2009-02-25 12:18 ---
The upcoming C++0x memory model forbids this; see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html (Concurrency
memory model compiler consequences). But it says that this is acceptable
instead:
tmp =
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-02-25 13:25
---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from davids at webmaster dot com 2009-02-25 16:06 ---
This is a real bug. There is simply no way to write correct threaded code if
the compiler is free to read a variable and write it back when the code didn't
specifically tell it to.
Optimizations on threaded code
--- Comment #19 from dnovillo at google dot com 2009-02-25 16:12 ---
Subject: Re: Loop IM and other optimizations harmful
for -fopenmp
On Wed, Feb 25, 2009 at 11:06, davids at webmaster dot com
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #18 from davids at webmaster
--- Comment #20 from davids at webmaster dot com 2009-02-25 17:53 ---
I don't like this either:
tmp = var;
modified = false;
for (i = 0; i 100; i++)
{
if (i x)
tmp = i, modified = true;
}
if (modified)
var = tmp;
This can be a pessimization as well.
--- Comment #21 from matz at gcc dot gnu dot org 2009-02-25 18:04 ---
The question if such transformation is or isn't worthwhile is independent from
the issue at hand (which is about the validity in the light of the new
memory model). If you find a clearly pessimizing but valid
--- Comment #22 from pinskia at gcc dot gnu dot org 2009-02-25 18:07
---
Really to me this is still a valid transformation even in the inside threads.
If you want to be able to access via different threads, use locks, heavy or
light weight ones.
--
--- Comment #23 from davids at webmaster dot com 2009-02-25 18:35 ---
Really to me this is still a valid transformation even in the inside threads.
If you want to be able to access via different threads, use locks, heavy or
light weight ones.
Absolutely, you do use locks everywhere
--- Comment #24 from bonzini at gnu dot org 2009-02-25 18:43 ---
Andrew, your comments #6 #8 #9 clearly show that you haven't understood the
issue and are just talking past others.
The other hand the transformation has been shown to be an optimization on
single-thread cases; if it is
--- Comment #15 from jakub at gcc dot gnu dot org 2007-11-12 19:11 ---
Sorry for the delay.
Unfortunately that doesn't help in this case:
on foo from #c7 it is not cselim pass, but lim, which changes:
foo (x, y)
{
int i;
bb 2:
bb 3:
# i_12 = PHI i_5(6), 0(2)
if (x_3(D) i_12)
--- Comment #14 from matz at gcc dot gnu dot org 2007-11-01 03:15 ---
I've checked in a patch for PR33961, which is similar to this one. Can
somebody check if anything here is still broken with trunk?
--
matz at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from amylaar at gcc dot gnu dot org 2007-10-22 23:17
---
(In reply to comment #0)
See http://openmp.org/pipermail/omp/2007/000840.html
and the rest of the lengthy threads:
Memory consistency contradiction between 2.5 specification and GCC
OpenMP spec 2.5 seems to
--- Comment #11 from theodore dot papadopoulo at sophia dot inria dot fr
2007-06-04 18:12 ---
(In reply to comment #8)
I suspect (unless I'm overlooked something) that this problem cause wrong
statistics when using jointly the -fopenmp and -profile-* flags.
I tried that and seen
--- Comment #10 from jakub at gcc dot gnu dot org 2007-05-09 07:30 ---
You are entitled to your opinion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-05-09 03:19 ---
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).
So it sounds like you don't any thing about
16 matches
Mail list logo
