https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 25 Jul 2023, vries at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799 > > --- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> --- > (In reply to Alexander Monakov from comment #5) > > This trips Valgrind's data race detector (valgrind --tool=helgrind) too. So > > I don't think checking SANITIZE_THREAD is the correct approach. > > Can you elaborate on what you consider a correct approach? If we decide that speculating loads is a no-go we should instead go for a flag similar to -fallow-store-data-races. Maybe -fno-speculate-loads or so. I do wonder whether TSAN instrumentation can be made more clever here, like instrument the load together with the condition under which the loaded value will be used? The only downside of speculating loads is possible cachline/locking conflicts across CPU cores and thus impacted runtime performance. So this isn't really a wrong-code issue. How do helgrind / TSAN handle masked loads (and stores) in this context? I think those still possibly have the runtime impact, on the masked store side I'm not sure how those interact with concurrent atomic operations on the masked parts.
