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 ADC3D3858D32; Sun, 31 Mar 2024 03:08:19 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ADC3D3858D32
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1711854499;
	bh=Us2R8fE9WR0oFVAYYtOQF2ijBqZ54R5bTT9Ir7fzqNc=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=tmz5G2ccSJdNhNzNOVLuEIACfHQOISNe4UPHVMMcZ900y5qE150KVcZserLdKexqh
	 Tfxmjdz0n/ja6jurfKI70vz9yZraPnFD4rt00RKMix8JqVX5Odsbbc75Sfo2kxI1tf
	 xvETtBlwFAyZ+Wqou79PodfwSAHGR22EpdIx7vms=
From: "absoler at smail dot nju.edu.cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/114030] redundant load due to unions and different
 size loads
Date: Sun, 31 Mar 2024 03:08:18 +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: 13.2.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: absoler at smail dot nju.edu.cn
X-Bugzilla-Status: NEW
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-114030-4-nUMABjqq2O@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114030-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114030-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=3D114030

--- Comment #3 from absoler at smail dot nju.edu.cn ---
(In reply to Andrew Pinski from comment #1)
> Reduced testcase:
> ```
> union U0 {
>    int  f2;
>    char  f4;
> };
>=20
> int g_3;
> union U0 g_34 =3D {-1L};
> char func_1() {
>   int t11 =3D g_34.f2;
>   char t1 =3D g_34.f4;
>   g_3 =3D t11;
>   return t1;
> }
> ```
>=20
> This is just due to unions. I am not sure if this is important to optimize
> really since techincally the original code is undefined by the C/C++
> standard (though GCC does an extension which makes it defined). Unions us=
ed
> in this way is not used much either.

reading different field of a union seems defined in C11 standard (maybe not=
 in
C++11).

"If the member used to read the contents of a union object is not the same =
as
the member last used to store a value in the object, the appropriate part of
the object representation of the value is reinterpreted as an object
representation in the new type as described in 6.2.6 (a process sometimes
called =E2=80=98type punning=E2=80=99). This might be a trap representation=
."=