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 1684D3858C60; Tue, 20 Feb 2024 07:32:15 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1684D3858C60
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1708414336;
	bh=crVN93RkJkGdQ1OzXMkMexMrDlgv3Hj7Wc6tSi8Ryws=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=SjigChx7R4q4rmFOLtXg2aGpYqCba/KjUrvqdfragufh0Y8tpLUZIUjdLEOCACozE
	 Kz2UbR/vGW5Qcshnl+B0ii5CMJdMMVf1vDnQRyQw5Paex9pL7ITmXsrhEd3bArjkMc
	 4+eeU2G2TmKWS+d5Oa03AsZBtGoHcI6s/SLxb1SI=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.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: Tue, 20 Feb 2024 07:32:14 +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: <bug-113988-4-fVi6A29oXh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113988-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113988-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #14)
> --- gcc/gimple-fold.cc.jj	2024-02-06 12:59:58.343050621 +0100
> +++ gcc/gimple-fold.cc	2024-02-19 19:48:11.162126759 +0100
> @@ -995,9 +995,27 @@ gimple_fold_builtin_memory_op (gimple_st
>  		if (warning !=3D OPT_Wrestrict)
>  		  return false;
>=20=20
> -	      scalar_int_mode mode;
> -	      if (int_mode_for_size (ilen * 8, 0).exists (&mode)
> -		  && GET_MODE_SIZE (mode) * BITS_PER_UNIT =3D=3D ilen * 8
> +	      machine_mode mode =3D BLKmode;
> +	      scalar_int_mode imode;
> +	      if (ilen * BITS_PER_UNIT <=3D MAX_FIXED_MODE_SIZE)
> +		{
> +		  if (int_mode_for_size (ilen * BITS_PER_UNIT,
> +					 0).exists (&imode)
> +		      && GET_MODE_SIZE (imode) =3D=3D ilen)
> +		    mode =3D imode;
> +		}
> +	      else if (int_mode_for_size (ilen * BITS_PER_UNIT,
> +					  0).exists (&imode))
> +		{
> +		  /* For > MAX_FIXED_MODE_SIZE, use a vector mode if
> +		     it exists rather than a barely supported huge
> +		     INTEGER_TYPE.  */
> +		  if (!mode_for_vector (QImode, ilen).exists (&mode)
> +		      || !VECTOR_MODE_P (mode)
> +		      || !targetm.vector_mode_supported_p (mode))
> +		    mode =3D BLKmode;
> +		}
> +	      if (mode !=3D BLKmode
>  		  /* If the destination pointer is not aligned we must be able
>  		     to emit an unaligned store.  */
>  		  && (dest_align >=3D GET_MODE_ALIGNMENT (mode)
> @@ -1005,7 +1023,12 @@ gimple_fold_builtin_memory_op (gimple_st
>  		      || (optab_handler (movmisalign_optab, mode)
>  			  !=3D CODE_FOR_nothing)))
>  		{
> -		  tree type =3D build_nonstandard_integer_type (ilen * 8, 1);
> +		  tree type;
> +		  if (VECTOR_MODE_P (mode))
> +		    type =3D build_vector_type_for_mode (char_type_node, mode);
> +		  else
> +		    type =3D build_nonstandard_integer_type (ilen
> +							   * BITS_PER_UNIT, 1);
>  		  tree srctype =3D type;
>  		  tree desttype =3D type;
>  		  if (src_align < GET_MODE_ALIGNMENT (mode))
> does something like that (kept the int_mode_for_size (ilen * BITS_PER_UNI=
T,
> 0).exists (&imode) in there even for the large modes for now so that it
> doesn't try to use it for sizes for which it previously did nothing).
> That said, with that now both PR113783 and following ICE.  Guess I should
> add VCE support to arbitrary types from and to large/huge BITINT_TYPE + m=
ore
> testsuite coverage, and guess even handling the conversions to the barely
> supported huge INTEGER_TYPEs won't hurt, so perhaps the above patch just =
for
> stage1?

If we can deal with the current situation in lowering I think yes, this loo=
ks
like for stage1 (and then the int_mode_for_size could be skipped).  I do
wonder if using mode_for_size (..., MODE_VECTOR_INT) would be better though.

Also you could use bitwise_type_for_mode (mode) which should work for both
vector and integer modes.

That said, I'm sure using vector types might end up uncovering its own
share of (latent) issues ;)=