This is the mail archive of the gcc-patches@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]

Re: [cxx-mem-model] disallow load data races (1 of some)



But hoisting global in this case doesn't result in a data race, since the
loop always accesses global and contains no synchronisation code.  If it
were only accessed conditionally, as in the examples under "Avoiding
Speculation" on that page, then there would be a race in hoisting it, but
not for the code you gave; any data races with the hoisting would still
have been present without it.

My fault for not being specific about it... I tend to just use data race as
a catch all for all these types of things when talking about them with Aldy.

Arghh... I took Andrew's testcase unmodified, and assumed it did not conform to the model. Sorry for the confusion.


the testcase should have      for (x=0; x<  limit; x++)  sum[x] = global;
rather than x<5,  so that its not a known loop count.

And in this variant, we no longer have a data race. The load from global is guarded by the limit check.


But speculative loads are never a problem.  So I'd like to avoid cluttering
GCC code with stuff to avoid them.  I honestly don't care about diagnostic
tools that fail to see if a value read is used or not.

Frankly, I agree. The standard (and the aforementioned paper) says that load data races are disallowed...


"If we had hypothetical hardware (or a virtual machine) that aborted the program when a race was detected, compilers would not be allowed to introduce potentially racing loads... even if the result of the load were unused would change the semantics of the program. Although such environments are not commonplace, they have certainly been proposed, and may well turn out to be very useful."

...but, if there's no hardware for it, I see no need for spending time on this. Do y'all agree, so I can drop this witch hunt?

In which case, unfortunately, all the tests I had from Andrew (that actually trigger) are load data races. So I'll have to hunt for invalid speculative stores instead.

Back to the drawing board.

Thanks folks.


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