From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EBE3E393FC3F; Tue, 10 Mar 2020 09:39:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EBE3E393FC3F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1583833191; bh=UrqhM2wLEdcBxujL0XC99bm9UkNDKuIroz+O5CsOFIE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Blxrzq1aKMhjyzNu2C+E2kFldcJey/oox5Qd5F0gbZGtXZnWQdKwio5Xcg58UUHED t4Pw0cLzOkvB4dmzASZwzEnpqweXnT4oAhmyrLBQSmOumtKrhYHHde42m9moFpycNW IG39febnFBdIDxT2JvM28vPmMtZwWcLgHvPiN57Q= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/94103] Wrong optimization: reading value of a variable changes its representation for optimizer Date: Tue, 10 Mar 2020 09:39:51 +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: 10.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org 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: component keywords bug_status cf_reconfirmed_on cf_gcctarget cc everconfirmed 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, 10 Mar 2020 09:39:52 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94103 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Component|middle-end |target Keywords| |wrong-code Status|UNCONFIRMED |NEW Last reconfirmed| |2020-03-10 Target| |x86_64-*-*, i?86-*-*, | |m68k-*-* CC| |law at gcc dot gnu.org, | |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- There's a related bug about x87 stores not storing all bytes which was clos= ed as INVALID, the testcase was using a union to pun long double and a charact= er array IIRC. Here the situation is quite similar - the IL has (from your unused load): x.1_6 =3D x; _18 =3D MEM[(char * {ref-all})&x]; MEM[(char * {ref-all})&u] =3D _18; _7 =3D u[0]; _8 =3D u[1]; printf ("%016lX %016lX\n", _8, _7); where x.1_6 is of type long double and _18 is __int128. Value-numbering then decides that it can elide the load to _18 and also optimize the loads from u[] as: x.1_6 =3D x; _31 =3D VIEW_CONVERT_EXPR<__int128 unsigned>(x.1_6); MEM[(char * {ref-all})&u] =3D _31; _32 =3D (long unsigned int) _31; _33 =3D BIT_FIELD_REF <_31, 64, 64>; printf ("%016lX %016lX\n", _33, _32); which is because the backend tells us the FP load x.1_6 =3D x loads all bits and do not modify the underlying representation. Now, for x87 modes GET_MODE_SIZE isn't in agreement with what the actual instruction does nor does the load reflect the fact that a x87 load (not the long double variant) can end up doing a rounding step. m68k is probably similarly affected. And yes, compared to the other bug I was able to close as INVALID conveniently this one looks "real" (if also artificially constructed and unfortunate...). Jeff, you also were involved in the other bug, do you agree here? I still don't see any good solution though. I agree that the decimal float variant is an entirely different bug, maybe you can open a new one for this?=