From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BBE0539CEBDF; Fri, 7 Jun 2024 08:35:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BBE0539CEBDF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1717749307; bh=AVS1XUg3JqRFD3LNcLQQvkvC9KWdidrdaM3j31kxovc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=XIY+EtzaluTeB8I8I6URDug+HNwtj1upaNEHe6U4o81IAO+3Oq3e/7KUU7XewVIAQ 3vt6c0qfcnji78mLr4QYo4cRKCEg0cRUcBvytv/DtVEs2he69j4qM3wZ2nZCAWyI4R iD8EJbqjoxi0rukCakZQCNiQPiHEESk+I0tUClBA= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/115352] wrong code with _BitInt() __builtin_sub_overflow_p() at -O0 Date: Fri, 07 Jun 2024 08:35:05 +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: 15.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D115352 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0f616e75f32083e1bc6d08f31e3fbc3dea41fa0c commit r14-10288-g0f616e75f32083e1bc6d08f31e3fbc3dea41fa0c Author: Jakub Jelinek Date: Fri Jun 7 10:32:08 2024 +0200 bitint: Fix up lower_addsub_overflow [PR115352] The following testcase is miscompiled because of a flawed optimization. If one changes the 65 in the testcase to e.g. 66, one gets: ... _25 =3D .USUBC (0, _24, _14); _12 =3D IMAGPART_EXPR <_25>; _26 =3D REALPART_EXPR <_25>; if (_23 >=3D 1) goto ; [80.00%] else goto ; [20.00%] : if (_23 !=3D 1) goto ; [80.00%] else goto ; [20.00%] : _27 =3D (signed long) _26; _28 =3D _27 >> 1; _29 =3D (unsigned long) _28; _31 =3D _29 + 1; _30 =3D _31 > 1; goto ; [100.00%] : _32 =3D _26 !=3D _18; _33 =3D _22 | _32; : # _17 =3D PHI <_30(9), _22(7), _33(10)> # _19 =3D PHI <_29(9), _18(7), _18(10)> ... so there is one path for limbs below the boundary (in this case there a= re actually no limbs there, maybe we could consider optimizing that furthe= r, say with simply folding that _23 >=3D 1 condition to 1 =3D=3D 1 and let= ting cfg cleanup handle it), another case where it is exactly the limb on the boundary (that is the bb 9 handling where it extracts the interesting bits (the first 3 statements) and then checks if it is zero or all ones= and finally the case of limbs above that where it compares the current resu= lt limb against the previously recorded 0 or all ones and ors differences = into accumulated result. Now, the optimization which the first hunk removes was based on the idea that for that case the extraction of the interesting bits from the limb don't need anything special, so the _27/_28/_29 statements above aren't needed, the whole limb is interesting bits, so it handled the >=3D 1 case like the bb 9 above without the first 3 statements and bb 10 wasn't there at all. There are 2 problems with that, for the higher limbs it only checks if the the result limb bits are all zeros or all ones, but doesn't check if they are the same as the other extension bits, and it forgets the previous flag whether there was an overflow. First I wanted to fix it just by adding the _33 =3D _22 | _30; statement to the end of bb 9 above, which fixed the originally filed huge testcase and the first 2 foo calls in the testcase included in the patch, it no longer forgets about previously checked differences from 0/1. But as the last 2 foo calls show, it still didn't check whether each even (or each odd depending on the exact position) result limb is equal to the first one, so every second limb it could choose some other 0 vs. all ones value and as long as it repeated in another limb above it it would be ok. So, the optimization just can't work properly and the following patch removes it. 2024-06-07 Jakub Jelinek PR middle-end/115352 * gimple-lower-bitint.cc (lower_addsub_overflow): Don't disable single_comparison if cmp_code is GE_EXPR. * gcc.dg/torture/bitint-71.c: New test. (cherry picked from commit a47b1aaa7a76201da7e091d9f8d4488105786274)=