From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 7DCD33858C29; Mon,  5 Feb 2024 18:38:31 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7DCD33858C29
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1707158311;
	bh=ckbk+1MgTTdf6ynrChrEwRESBUEpagthxzYD8H5j+f0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=YsrUj7LDMPBsVM6x56JRK9nriblOylfdbvf2z93NVqnQpWEIYh+OQpz+1+Q5kfPiJ
	 GaRitGRFX58v5/Kabucz0k3Htr1TGF9Vc9SMTdvhsKHSYLazDWXVtQ2ldvWSoEmQUS
	 PNV+wtpnYSxkRdoRR9ShpmFnQf6sAG1aj7GdGSX0=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/113214] false-positive -Wstringop-overflow warning
 with thread sanitizer
Date: Mon, 05 Feb 2024 18:38:30 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 13.2.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-113214-4-cMAVlh3twd@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113214-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113214-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think the reason for the warning is fre5 optimizing
   _21 =3D &MEM[(struct xe_gt *)uc_8(D) + -2072B].tile;
...
-  _20 =3D uc_8(D) + 18446744073709549544;
-  _2 =3D _20 + _19;
+  _2 =3D _21 + _19;
...
   _5 =3D _4 * 4;
   _6 =3D _2 + _5;
...
   MEM <uint128_t> [(char * {ref-all})_6] =3D _13;
and the -Wstringop-overflow warning stuff (done during the strlen pass)
considering it then to be access into the tile member rather than anywhere =
into
the structure.

Sure, if one writes:
void foo (struct xe_gt *p, int i) { uint128_t *q =3D (uint128_t *) &p->tile=
; q +=3D
i; *q =3D 0; }
in the source, then it will be UB not just because of the most likely alias=
ing
violation, but also because the pointer in some kind of Martin's strict rea=
ding
is just to the particular element rather than whole structure.
But=20
void baz (struct xe_tile **);
void bar (struct xe_gt *p, int i) { baz (&p->tile); uint128_t *q =3D (uint1=
28_t
*) p; q +=3D i; *q =3D 0; }
should be fine.
The reason it doesn't trigger without -fsanitize=3Dthread is that then noth=
ing
takes address of the &(uc + cst)->tile in that case, it is just read, so th=
ere
is nothing to CSE.
Before IPA we try to maintain what the address taking refers to exactly for
builtin {,dynamic} object size 1/3 modes, but afterwards such distinctions =
are
lost.=