From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B1C4B3858D37; Tue, 29 Nov 2022 18:14:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B1C4B3858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669745661; bh=5e9Mg2C1tpmLWZK8mFEtrpZnhGzRKX2IgLGAQdAiE0o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gj8BnF7Q/FvhhkQAAjkOg2cvM0eprrrvvTd/TvnAVTiPs4Tdba3DxYPRgHGLHggsm kSDEBU198Veqhb3EoR/v3VnpTmevQkAkXVNuN+LWqw0ykx01GTNcRDa0wPIEJT6lyJ rtA5NqH4KCyWgYO8FExXzUc96pP6xwLE+/1iSY4E= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/105918] [12/13 Regression] Spurious Warray-bounds in std::to_chars since r12-2132-ga110855667782dac Date: Tue, 29 Nov 2022 18:14:20 +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: 12.1.0 X-Bugzilla-Keywords: diagnostic, needs-reduction X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.3 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=3D105918 --- Comment #4 from Richard Biener --- (In reply to Andrew Pinski from comment #1) > Shorter testcase (still need to reduce it futher): > #include > void toChars(int number) { > char temp[1]; > std::to_chars(temp, temp + 1, number); > } So the failure mode is std::to_chars treating a negative 'number' specially, in this case starting from the end. We get [local count: 536870912]: # __first_9 =3D PHI <&temp(4), &MEM [(void *)&temp + 1B](5)> # __unsigned_val_10 =3D PHI <__unsigned_val_5(4), __unsigned_val_8(5)> and [local count: 241591910]: __num_47 =3D __val_28 * 2; _48 =3D __num_47 + 1; _49 =3D __digits[_48]; MEM[(char *)__first_9 + 1B] =3D _49; _50 =3D __digits[__num_47]; *__first_9 =3D _50; here the __first_9 + 1 store is _always_ out of bounds. It might be that this block is never reachable but we couldn't prove that.=