public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] lower-bitint: Fix up handle_operand_addr for 0 constants [PR112771]
Date: Fri, 1 Dec 2023 09:34:05 +0100 (CET)	[thread overview]
Message-ID: <p87o1r0s-13rr-0n87-3pso-9no08on295rs@fhfr.qr> (raw)
In-Reply-To: <ZWmTzwDzPS0bLtv9@tucnak>

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)

      reply	other threads:[~2023-12-01  8:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-01  8:05 Jakub Jelinek
2023-12-01  8:34 ` Richard Biener [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=p87o1r0s-13rr-0n87-3pso-9no08on295rs@fhfr.qr \
    --to=rguenther@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).