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 5DC68385E013; Wed, 25 Mar 2020 17:49:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5DC68385E013
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1585158543;
 bh=hoaEI25B9jYbjlRljxO9HrcpSHCDXdZCd8D1nMKnRoI=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=f231oytI6O6axVhHJAqa82KB21tHzBmxy0enRmHYPW1yntxnSvf+/HS84OpItyBtP
 uuE96X1it5G7R0BF4xkv7sbhrUwbUb1wF86PUDDB71ZaD3KtEG0VPxhsCd07eqkPDS
 eNG+fBEri2Edo/+W8C+YovgRyV3kNSKO77uxWywI=
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/94313] stores into string literals sometimes
 silently eliminated
Date: Wed, 25 Mar 2020 17:49:03 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 10.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
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-94313-4-rBnEDo9EOa@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-94313-4@http.gcc.gnu.org/bugzilla/>
References: <bug-94313-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <http://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2020 17:49:03 -0000

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

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 25 Mar 2020, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94313
>=20
> --- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
> Removing invalid code not isn't wrong (as in non-conforming), but it's
> decidedly unhelpful in avoiding the undefined behavior that doesn't neces=
sarily
> go away just because the invalid statement is gone.  It makes finding the
> underlying bugs difficult.  My solution for pr90404 detects most of these=
 bugs
> (and can also eliminate the buggy code) except those that are removed by =
DSE.=20
> The intent of this report isn't so much to complain that GCC is doing som=
ething
> wrong but to document the rationale for doing something different (i.e.,
> diagnose these bugs consistently and leave it up to the user whether to
> eliminate the code or replace it with a trap or something else).

Usually the whole point of undefined behavior is that you do not
need to detect it.  When you detect undefined behavior you can try
to do something sensible (try to second guess DWIM) like for example
how we allow invalid type-punning when we see a trivial must-alias.

In this case points-to analysis does not bother to invent something
to represent not useful information because it's not useful and just
wastes resources.=