login
Search
[ I had to resend this message. Sorry if you received two copies. ] Nick Piggin writes: > Can you retain cc list, please? > > On Friday 26 October 2007 07:42, David Schwartz wrote: > > I asked a collection of knowledgeable people I know about the > > issue. The consensus is that the optimization is not permitted in > > POSIX code but that it is permitted in pure C code. The basic > > argument goes like this: > > > > To make POSIX-compliant code even possible, surely > > optimizations that add writes to variables must be > > prohibited. That is -- if POSIX prohibits writing to a variable > > in certain cases only the programmer can detect, then a > > POSIX-compliant compiler cannot write to a variable except where > > explicitly told to do so. Any optimization that *adds* a write to > > a variable that would not otherwise occur *must* be prohibited. I don't think that POSIX is quite as explicit as that. See http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf > > Otherwise, it is literally impossible to comply with the POSIX > > requirement that concurrent modifications and reads to shared > > variables take place while holding a mutex. > > Now all you have to do is tell this to the gcc developers ;) We're listening, really. It's unacceptable that gcc should break code. However, fixing it is hard. The best plan is probably to implement (part of) the proposed standard memory model, and that requires careful consideration. We could in theory simply disable this particular optimization, but that probably isn't a good idea on its own because other optimizations might well break other code in a similar way. We need to have a very close look at the thread-safe memory model in order to determine where we do things that might break. An official standard containing this is still at least two years out. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 -
