--- 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 de
--- 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 ba
--- 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 y
--- 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.
--
http://gcc.gnu.org/bugzilla/show
--- 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 transfor
--- 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 #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
wrote:
>
>
> --- Comment #18 from davids at webmaster dot com  2009-02-25 16:
--- 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 canno
--- 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
Status|UNC
--- 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 = v
--- 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;
:
:
# i_12 = PHI
if (x_3(D) < i_12)
goto ;
else
--- 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 #12 from tomash dot brechko at gmail dot com 2007-10-14 14:15
---
I wish I could reopen the bug, but the only option I see is "Leave as
UNCONFIRMED".
(In reply to comment #9)
> So it sounds like you don't any thing about threading programming. People
> have
> to use mutex
--- 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 messa
--- 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 thr
17 matches
Mail list logo
