From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E61553858D33; Mon, 19 Feb 2024 14:39:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E61553858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708353568; bh=VjaFmjDezC3DNS+yZwECYwl2wqZRL3bF5NZOomaft3Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=apBIXS6cVzy190Wq74d/uEojdhdy3rO/aujTH40l6a1ePZuf94qaC0Q5vrFgPghz9 8KYxkNVTJ7TBtS5sU2vzWeJBemv1XGyk8ND0yPysFBMO47HiaEqQ830IZLTvTUZw1K nbMKqfiGzqsjI8E/MFLpfpsCnNWFMsHMixYwSSsI= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/113988] during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5470 Date: Mon, 19 Feb 2024 14:39:28 +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: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth 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=3D113988 --- Comment #9 from Richard Biener --- (In reply to Richard Biener from comment #8) > (In reply to Jakub Jelinek from comment #7) > > I think I can handle it like the VIEW_CONVERT_EXPR case, bet with > > _BitInt(511) it would actually be a VCE, but when it is same size > > BITINT_TYPE to INTEGER_TYPE we choose NOP_EXPR. > > That said, I think it would be better if the memcpy folding used say ve= ctor > > types instead of these extra large integer types. >=20 > Hmm. Maybe we want a target hook to specify the "move mode" for a given > byte size and then we can use bitwise_type_for_mode to get a type? >=20 > Maybe we can even get rid of that large integer mode requirement that way= ... Or we refuse to use integer types for > MAX_FIXED_MODE_SIZE sizes and instead always try VNQImode? For memcpy folding I mean.=