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 977463856DD5; Mon,  5 Sep 2022 13:36:00 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 977463856DD5
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1662384960;
	bh=roUm0rg5ksM+ZWLp655CP1iB1GUxlsOftbKSNAxy9NA=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=GLDDgGm/0FmNWzEFeoxHxu3YZW9jjaoCNbYcXZutcEMzthN3pwF9jCq9NKjQKAR9c
	 Hz52lGe04H3MA8PdR3Y0cZNrctEoaCAo/CH5XQ5JWgSMynwJiMX0VBomGk+Cgtvj07
	 QfQFh3JEOL1B3io0jN4VSx+Xsr8z0mQ3CCcbLaqg=
From: "aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/106831] [13 Regression] mpfr-4.1.0 started failing 2
 tests: tget_set_d64 and tget_set_d128
Date: Mon, 05 Sep 2022 13:35:59 +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: 13.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aldyh 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: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106831-4-HkJYdrqYfR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106831-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106831-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=3D106831

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> BTW, I admit I don't know much about decimal{32,64,128}, but
> https://en.wikipedia.org/wiki/Decimal32_floating-point_format
> says:
> Because the significand is not normalized (there is no implicit leading
> "1"), most values with less than 7 significant digits have multiple possi=
ble
> representations; 1 =C3=97 10^2=3D0.1 =C3=97 10^3=3D0.01 =C3=97 10^4, etc.=
 Zero has 192 possible
> representations (384 when both signed zeros are included).
> So, I think singleton_p should just always return false for
> DECIMAL_FLOAT_TYPE_P (at least for now).

Interestingly, frange_drop_*inf() bails on DECIMAL_FLOAT_MODE_P because
build_real() will ultimately ICE when trying to make a tree out of the max/=
min
representable number for a type:

  /* dconst{0,1,2,m1,half} are used in various places in
     the middle-end and optimizers, allow them here
     even for decimal floating point types as an exception
     by converting them to decimal.  */
  if (DECIMAL_FLOAT_MODE_P (TYPE_MODE (type))
      && (d.cl =3D=3D rvc_normal || d.cl =3D=3D rvc_zero)
      && !d.decimal)
...
...

I know even less about decimal floats.  Jakub, should we disable them
altogether from the frange infrastructure, or is that too big of a hammer? =
 I'm
just afraid we'll keep running into limitations when we start implementing
floating operations in range-op-float.cc.  Or worse, have to special case t=
hem
all over.

bool frange::supports_p (const_tree type)=20
{=20
  return SCALAR_FLOAT_TYPE_P (type) && !DECIMAL_FLOAT_MODE_P (type);
}

??=