From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id E5A793851416; Tue, 30 Mar 2021 08:09:22 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E5A793851416
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/99824] [10 Regression] ICE in
 wide_int_to_tree_1, at tree.c:1572
Date: Tue, 30 Mar 2021 08:09:22 +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: 10.2.1
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: WAITING
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 10.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-99824-4-6ek50q0kot@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-99824-4@http.gcc.gnu.org/bugzilla/>
References: <bug-99824-4@http.gcc.gnu.org/bugzilla/>
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 <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2021 08:09:23 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99824

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so I guess that things go wrong in wi::min_value where we nowhere check
that the precision we're asking for (384) fits in a wide_int,
WIDE_INT_MAX_PRECISION should be 160 (MAX_BITSIZE_MODE_ANY_INT) rounded up
to 64bits thus 192.  That then clobbers the stack somewhere and things go
wrong.

This is likely uncovered by the PR98834 "fix"
g592388d4f6e8a6adb470428fef6195694f4a3dce (but this fix shouldn't expose
such large precisions by itself)

I still like to reproduce it to see what events lead to such large requested
precision.  On trunk sth like

diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index 784f131ebb8..94b8b21c7a8 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -2838,6 +2838,8 @@ set_min_and_max_values_for_integral_type (tree type,
   if (precision < 1)
     return;

+  gcc_assert (precision <=3D WIDE_INT_MAX_PRECISION);
+
   TYPE_MIN_VALUE (type)
     =3D wide_int_to_tree (type, wi::min_value (precision, sgn));
   TYPE_MAX_VALUE (type)

should uncover any similar issue and eventually allow producing smaller
testcases.=