From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 99CEA3858D28; Tue, 23 Nov 2021 10:41:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 99CEA3858D28 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/103376] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5453-ga944b5dec3adb28e Date: Tue, 23 Nov 2021 10:41:38 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: unknown X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 10:41:38 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103376 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- So, we have: e_11 =3D a; ... a.3_5 =3D a; _17 =3D a.3_5 ^ e_11; and no stores in between those 2 reads, initially there has been a bb that could fall through and that is the reason why the two loads are still there, but it has been changed a few passes back to end with __builtin_trap. bswap pass changes this to: e_11 =3D a; ... + load_dst_9 =3D MEM[(long long int *)&a]; + _17 =3D (long long int) load_dst_9; a.3_5 =3D a; - _17 =3D a.3_5 ^ e_11; For | instead of ^ that is a correct optimization a | a is still a, but for= the newly added operations a ^ a is 0 rather than a and a + a is usually differ= ent than a too. So, I guess for ^ and + we need to perform extra checking. perform_symbolic_merge is doing: for (i =3D 0, mask =3D MARKER_MASK; i < size; i++, mask <<=3D BITS_PER_MA= RKER) { uint64_t masked1, masked2; masked1 =3D n1->n & mask; masked2 =3D n2->n & mask; if (masked1 && masked2 && masked1 !=3D masked2) return NULL; } which is correct solely for bitwise or. For other operations it would need= to do instead if (masked1 && masked2) return NULL; instead.=