[Bug sanitizer/110799] [tsan] False positive due to -fhoist-adjacent-loads

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 25 Jul 2023, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799
> 
> Alexander Monakov <amonakov at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |amonakov at gcc dot gnu.org
> 
> --- Comment #5 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #1)
> > We consider introducing load data races OK, what's the difference here? 
> > There are other passes that would do similar things but in practice the
> > loads would be considered to possibly trap so the real-world impact might be
> > limited?
> 
> What are the examples of other transforms that can introduce data races?

Off-head it would be loop invariant motion and partial-PRE, loop
if-conversion and if-combine.  All of those could speculate loads
when there's no trapping possibility but the values wouldn't be used
when not used without the transform.

> This trips Valgrind's data race detector (valgrind --tool=helgrind) too. So I
> don't think checking SANITIZE_THREAD is the correct approach.

I can see that it's difficult for those tools to avoid those false
positives but eventually valgrind might be able to see the values loaded
are not used (hopefully the register content is overwritten "soon").