public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] lower-bitint: Fix up handle_operand_addr for 0 constants [PR112771]
@ 2023-12-01  8:05 Jakub Jelinek
  2023-12-01  8:34 ` Richard Biener
  0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2023-12-01  8:05 UTC (permalink / raw)
  To: Richard Biener; +Cc: gcc-patches

Hi!

handle_operand_addr for INTEGER_CSTs uses wi::min_precision (UNSIGNED
for non-negative constants, SIGNED for negative ones) and from that
computes mp as minimum number of limbs which can represent that value,
and in some cases creates a test BITINT_TYPE with that precision to
categorize it and decide based on that what types to use on the constant
emitted into memory.  For the actual precisions (what will be passed
to libgcc) it actually already uses MAX/MIN to adjust the corner cases:
          *prec = MAX (min_prec, 1);
...
          *prec = MIN ((int) -min_prec, -2);
but for integer_zerop min_prec will be 0,
mp = CEIL (min_prec, limb_prec) * limb_prec;
will be also 0 and we ICE trying to build unsigned BITINT_TYPE with
0 precision.

Fixed thusly by noting even 0 has to be encoded at least as one limb.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2023-12-01  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/112771
	* gimple-lower-bitint.cc (bitint_large_huge::handle_operand_addr):
	Use mp = limb_prec if it is zero.

	* gcc.dg/bitint-44.c: New test.

--- gcc/gimple-lower-bitint.cc.jj	2023-11-30 17:24:59.828026693 +0100
+++ gcc/gimple-lower-bitint.cc	2023-11-30 17:42:07.172487347 +0100
@@ -2179,6 +2179,8 @@ bitint_large_huge::handle_operand_addr (
 	  *prec = MIN ((int) -min_prec, -2);
 	}
       mp = CEIL (min_prec, limb_prec) * limb_prec;
+      if (mp == 0)
+	mp = limb_prec;
       if (mp >= (unsigned) TYPE_PRECISION (TREE_TYPE (op)))
 	type = TREE_TYPE (op);
       else
--- gcc/testsuite/gcc.dg/bitint-44.c.jj	2023-11-30 17:45:02.421017172 +0100
+++ gcc/testsuite/gcc.dg/bitint-44.c	2023-11-30 17:39:51.968393081 +0100
@@ -0,0 +1,10 @@
+/* PR middle-end/112771 */
+/* { dg-do compile { target bitint575 } } */
+/* { dg-options "-std=c23" } */
+
+_BitInt(575)
+foo (_BitInt(575) a)
+{
+  a /= 0;	/* { dg-warning "division by zero" } */
+  return a;
+}

	Jakub


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] lower-bitint: Fix up handle_operand_addr for 0 constants [PR112771]
  2023-12-01  8:05 [PATCH] lower-bitint: Fix up handle_operand_addr for 0 constants [PR112771] Jakub Jelinek
@ 2023-12-01  8:34 ` Richard Biener
  0 siblings, 0 replies; 2+ messages in thread
From: Richard Biener @ 2023-12-01  8:34 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: gcc-patches

On Fri, 1 Dec 2023, Jakub Jelinek wrote:

> Hi!
> 
> handle_operand_addr for INTEGER_CSTs uses wi::min_precision (UNSIGNED
> for non-negative constants, SIGNED for negative ones) and from that
> computes mp as minimum number of limbs which can represent that value,
> and in some cases creates a test BITINT_TYPE with that precision to
> categorize it and decide based on that what types to use on the constant
> emitted into memory.  For the actual precisions (what will be passed
> to libgcc) it actually already uses MAX/MIN to adjust the corner cases:
>           *prec = MAX (min_prec, 1);
> ...
>           *prec = MIN ((int) -min_prec, -2);
> but for integer_zerop min_prec will be 0,
> mp = CEIL (min_prec, limb_prec) * limb_prec;
> will be also 0 and we ICE trying to build unsigned BITINT_TYPE with
> 0 precision.
> 
> Fixed thusly by noting even 0 has to be encoded at least as one limb.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

> 2023-12-01  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR middle-end/112771
> 	* gimple-lower-bitint.cc (bitint_large_huge::handle_operand_addr):
> 	Use mp = limb_prec if it is zero.
> 
> 	* gcc.dg/bitint-44.c: New test.
> 
> --- gcc/gimple-lower-bitint.cc.jj	2023-11-30 17:24:59.828026693 +0100
> +++ gcc/gimple-lower-bitint.cc	2023-11-30 17:42:07.172487347 +0100
> @@ -2179,6 +2179,8 @@ bitint_large_huge::handle_operand_addr (
>  	  *prec = MIN ((int) -min_prec, -2);
>  	}
>        mp = CEIL (min_prec, limb_prec) * limb_prec;
> +      if (mp == 0)
> +	mp = limb_prec;
>        if (mp >= (unsigned) TYPE_PRECISION (TREE_TYPE (op)))
>  	type = TREE_TYPE (op);
>        else
> --- gcc/testsuite/gcc.dg/bitint-44.c.jj	2023-11-30 17:45:02.421017172 +0100
> +++ gcc/testsuite/gcc.dg/bitint-44.c	2023-11-30 17:39:51.968393081 +0100
> @@ -0,0 +1,10 @@
> +/* PR middle-end/112771 */
> +/* { dg-do compile { target bitint575 } } */
> +/* { dg-options "-std=c23" } */
> +
> +_BitInt(575)
> +foo (_BitInt(575) a)
> +{
> +  a /= 0;	/* { dg-warning "division by zero" } */
> +  return a;
> +}
> 
> 	Jakub
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-12-01  8:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-01  8:05 [PATCH] lower-bitint: Fix up handle_operand_addr for 0 constants [PR112771] Jakub Jelinek
2023-12-01  8:34 ` Richard Biener

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).