From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 200993858C60; Wed, 6 Dec 2023 18:51:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 200993858C60 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1701888667; bh=XsIinBrRKy45CLSIOsywzGqXs5Q0L8wX0mKSoDpYCsU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=llRdgLEDpVhnbe1MAt8FQzT1AgcNEJnAA43t0log9YwOj28RIfjdYP64YyB0fqh4H 5/sq7EHKRHI5YuZyUX5TXpp++K098/SfoUTgTCD7X9xy63ldz/7gEOYBRTRsAMNjrb uLMybgrH/kjDUODWPVFbKyLxOIZ07ZbbvVIKSsEg= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/112411] ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu Date: Wed, 06 Dec 2023 18:51:06 +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: 14.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: 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=3D112411 --- Comment #9 from Jakub Jelinek --- If we wanted to support just INSN_UIDs up to 0x55555554, it could be even j= ust lra_insn_recog_data_len =3D index * 3U / 2 + 1; Looking around, vec.cc has similar limitation, it uses unsigned rather than= int alloc, and ... /* Grow slower when large. */ alloc =3D (alloc * 3 / 2); /* If this is still too small, set it to the right size. */ if (alloc < desired) alloc =3D desired; So, my understanding is for vectors up to 0x55555555 elements it will do the expected thing, for larger it will simply reallocate to the desired exact v= alue (i.e. as if it was an exact growth rather than the normal exponential one). Perhaps what we could do in both places use alloc =3D (alloc * (size_t) 3 / 2); plus the if (alloc < desired) alloc =3D desired;, such that at least on 64-= bit hosts we'd use an exponential growth even after 0x55555555 a little bit, bu= t on 32-bit hosts we'd keep what we do. On the lra side then lra_insn_recog_data_len =3D index * (size_t) 3 / 2; if (lra_insn_recog_data_len <=3D index) lra_insn_recog_data_len =3D index + 1;=