http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> 2012-03-12 15:45:39 UTC --- On Mon, 12 Mar 2012, aldyh at redhat dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52558 > > --- Comment #6 from Aldy Hernandez <aldyh at redhat dot com> 2012-03-12 > 15:42:45 UTC --- > On 03/12/12 10:32, rguenther at suse dot de wrote: > es, 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. > > > > They won't cause problems in a single threaded environment, but will > cause problems in a multi threaded environment. Even if you're writing > the value g_2 originally had, another thread may have written to g_2 > right before. Yes, that's clear to me. > Just to get this straight, am I to assume that the default code > generation for GCC is a single threaded environment? I just want to > make sure I get these variants right in my head, and can properly > separate what is and is not allowed in default GCC, and what only > pertains to the C11 memory model (or transactional stuff). It certainly is, though we are getting more careful about this stuff in recent years and generally only read data-races are ok. Richard.
