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 587BA3858D38; Wed,  6 Dec 2023 10:50:31 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 587BA3858D38
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1701859831;
	bh=vrDFU84ZdAKnUiYePYgGwBKmFT4GcrR5Qfe5zbXi74g=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=pAzXMiN3RyK2ohV1I0j3ai/lrlZtR+eNckvYRrk1Q/iuZcY8U80BbCgV82XJWFG9p
	 JyKNVb8MoJHCjb4a6VeVuMJJua+5stew7E0P79p/MMCSCc5Tf9XWnmbnrgpK3On/v0
	 xXutzqK6E3Yct8kumnZfmX84uwfqePDOaNABpIW4=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/105562] [12 Regression]
 std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex
 move with -fno-strict-aliasing
Date: Wed, 06 Dec 2023 10:50:30 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 12.1.0
X-Bugzilla-Keywords: diagnostic, missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.2
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-105562-4-ctkh7ppZzC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-105562-4@http.gcc.gnu.org/bugzilla/>
References: <bug-105562-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=3D105562

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is just a very partial solution.  As mentioned in lots of other
bugreports, one should simply ignore or take with a grain of salt  warnings
from the instrumented builds (whether it is -fsanitize=3Dundefined,
-fsanitize=3Daddress, -fsanitize=3Dthread or I think -fprofile-generate or =
similar
as well).  Any such instrumentation significantly modifies the intermediate
language and prevents various optimizations which necessarily lead to more
false positives in the non-frontend warnings.
So, best similarly to what libtool does when compiling a file twice, once w=
ith
-fpic, once without, redirects diagnostics of one to /dev/null, go with 2
builds, one sanitized/instrumented with -w, another non-instrumented with f=
ull
warnings.
The big question is if the compiler should do that by default (simply ignore
all middle-end warnings in instrumented functions), or if we should provide
some support in the driver for building stuff twice, once instrumented with=
out
middle-end warnings, once non-instrumented with warnings.  We already have
-fcompare-debug which does something similar (build normally and -gtoggle -=
w.=