This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Optimization of conditional access to globals: thread-unsafe?
- From: Daniel Jacobowitz <drow at false dot org>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Michael Matz <matz at suse dot de>, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Fri, 26 Oct 2007 17:39:40 -0400
- Subject: Re: Optimization of conditional access to globals: thread-unsafe?
- References: <e2e108260710260541n61462585u99de9bc0617720f4@mail.gmail.com> <e2e108260710260620k2a2e21b3t1d6c052f14d36094@mail.gmail.com> <20071026143334.GA5041@moonlight.home> <m38x5pj3ig.fsf@localhost.localdomain> <20071026155101.GB5041@moonlight.home> <016201c817e9$5454edd0$2e08a8c0@CAM.ARTIMI.COM> <20071026161739.GC5041@moonlight.home> <Pine.LNX.4.64.0710261836440.23011@wotan.suse.de> <m33avxfu2i.fsf@localhost.localdomain>
On Fri, Oct 26, 2007 at 02:24:21PM -0700, Ian Lance Taylor wrote:
> What do people think of this patch? This seems to fix the problem
> case without breaking Michael's case. It basically avoids store
> speculation: we don't write to a MEM unless the function
> unconditionally writes to the MEM anyhow.
>
> This is basically a public relations exercise. I doubt this
> optimization is especially important, so I think it's OK to disable it
> to keep people happy. Even though the optimization has been there
> since gcc 3.4 and nobody noticed.
>
> Of course this kind of thing will break again until somebody takes the
> time to fully implement something like the C++0x memory model.
Right. In fact it seems to me to be still broken; you just need a
bigger test case.
if (trylock)
{ var++; unlock; }
sleep
lock
var++;
unlock
I'm sure someone can turn that into a sensible looking example, with a
little inlining.
--
Daniel Jacobowitz
CodeSourcery