This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/52558] write introduction incorrect wrt the C++11 memory model


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

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> 2012-03-12 15:32:48 UTC ---
On Mon, 12 Mar 2012, aldyh at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558
> 
> --- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2012-03-12 15:29:06 UTC ---
> 
> > No, we don't want to fix this for 4.7 as this is not a regression.
> > 
> > Yes, LIM only avoids introducing traps, not data-races.  This was discussed
> > in the past already, btw, and we do not want to generally disallow this
> > optimization.  [The C++ memory model is stupid here, it should not treat
> > every variable raceable but only specially marked ones, oh well ...]
> > 
> > There will be very many other passes that are affected by this, and even more
> > very many passes that will be affected by load data-races.
> > 
> > You will for example slow down SPEC CPU 2006 quite a bit (though technically
> > it does not include C++11 benchmarks).
> 
> I thought we ignored *load* data races, but still cared about introducing write
> data races.  This test case has both.  I don't understand why we would allow
> introducing writes on paths that did not have it, but I will defer to you.

Why should we avoid them if we know they cannot cause problems?  This
will happen for every loop where we do not know if it iterates at least
once.  Store-motion is a very important optimization.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]