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 D08CB3858C50; Tue, 16 Apr 2024 10:34:46 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D08CB3858C50
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1713263686;
	bh=/4BRFEo0OgWDfrJFPJiuULgFtFNXodMwLyRQ8TKtudY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=yKieK+q/NGGHP+kPXbkCdw69obg6E2A3HfuXrvZn71qJuBDcn2qIHkdYyrLYCHgyS
	 S12y0fcQaL82u3tAjDoRJXuj213EmYI7ITHKO67Dpn0UcfQr06Om2dJdz0FnrKF6RK
	 ZSbra4Cmt1XeK5oYBbc+UCxo0sE6bzDhDpIPnX6s=
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/111231] [12/13/14 regression] armhf: Miscompilation with
 -O2/-fno-exceptions level (-fno-tree-vectorize is working)
Date: Tue, 16 Apr 2024 10:34:44 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 13.2.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-111231-4-uffUEI0in2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111231-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111231-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=3D111231

--- Comment #35 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 16 Apr 2024, rearnsha at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111231
>=20
> --- Comment #34 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
> To be honest, I'm more concerned that we aren't eliminating a lot of these
> copies during the gimple optimization phase.  The memcpy is really a type
> punning step (that's strictly ISO C compliant, rather than using the GCC =
union
> extension), so ideally we'd recognize that and eliminate as many of the c=
opies
> as possible (perhaps using some form of view_convert or whatever gimple is
> appropriate for changing the view without changing the contents).

Yeah, there's currently no way to represent a change just in the
effective type that wouldn't generate code in the end but still
serves as barrier for these type related optimizations.

When modifying the earlier store is an option then another possibility
would be to attach multiple effective types to it in some way.  Of course
that's pessimizing as well.

That said, the choice has been made to prune those "invalid" redundant
store removals but as we see here the implemented checks are not working
as intended.=