From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8675E385800B; Tue, 13 Feb 2024 15:36:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8675E385800B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1707838581; bh=X4wY0HkQ3t/jd0zKdEKaoo0yR7pa/8EjSH3J41eZQFE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qxM3jmcm7u2SnQhwHKpDh0qsNspHk1wzTNeguruvWeTjivLGdvNTIXyR7UUTcaAGQ 8GpjESjvkruR6qFPC1QGhTfJj4ouJcjzzicHJOU0zmSsxc1+PDqC9063suO81qGFYi OM5XtyfLJ2Sy7zTmxyIoCS8X6oA/Lo5elUSMv7ZM= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41 Date: Tue, 13 Feb 2024 15:36:21 +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: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 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=3D113907 --- Comment #17 from Jakub Jelinek --- One set of range changes in evrp is more precise ranges in return values of uprv_swapArray{16,32,64}, those contain early return 0 if length<0 || (length&1)!=3D0 or length<0 || (length&3)!=3D0 or length<0 || (length&7)!=3D0 so changing those return ranges from [0, +INF] to [0, 0][4, +INF] (for the second, 2 or 8 instead of 4 for the first/last) seems completely reasonable. And uprv_copyArray{16,32,64} has something very similar, length<0 || (length&{1,3,7})!=3D0 early exit and length > 0 guarded memcpy. So, even there it is completely reasonable to change - # RANGE [irange] unsigned int [1, 2147483647] MASK 0x7ffffff8 VALUE 0x0 + # RANGE [irange] unsigned int [8, 2147483647] MASK 0x7ffffff8 VALUE 0x0 length.37_10 =3D (unsigned int) length_25(D); memcpy (outData_26(D), inData_24(D), length.37_10); for the copy and - # RANGE [irange] int32_t [0, +INF] MASK 0x7fffffff VALUE 0x0 + # RANGE [irange] int32_t [0, 0][8, +INF] MASK 0x7fffffff VALUE 0x0 # _12 =3D PHI <0(4), 0(9), length_25(D)(12)> return _12; for the return, but naturally copyData16 uses 2 instead of 8 and copyData32= 4 instead of 8. What seems wrong is that the 8 in the ranges somehow leaks into copyData16 during IPA. IPA-ICF?=