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 2E21B385841D; Mon, 24 Oct 2022 21:06:07 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2E21B385841D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1666645570;
	bh=2EYg9fC4bzMpKCyECNQwejV5Q8n2I0CHUeoW3KDPh6Q=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Tqpiu3W/02oJ2uCwPsTemonOjZQjE3SEDMnu0g5ppCW+y871g+AgyPZ478CHQ/6+k
	 kC0mmYM3/egBySdYGsT5I9DJQ08zb9xmNnb244HPMuBhu5MfRL5gIqfoubtqS0hQRj
	 jEVAkIEH39TPvvwg8S39iEXGB8HRpw78sv30NuMI=
From: "jacob at jacob dot remcomp.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/107370] long double sqrtl constant folding is wrong
Date: Mon, 24 Oct 2022 21:06:07 +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: 10.2.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jacob at jacob dot remcomp.fr
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-107370-4-RJcCtXF5Dw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107370-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107370-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=3D107370

--- Comment #22 from jacob navia <jacob at jacob dot remcomp.fr> ---
(In reply to Jakub Jelinek from comment #20)
> All I'm arguing is that everything I see from gcc seems to be correct.
> 30 digits precision is not enough for IEEE quad, 36 is enough.
> If I try your sqrt (2^255) case on x86_64, I see:
> #define _GNU_SOURCE
> #include <stdlib.h>
> #include <stdio.h>
> #include <math.h>
>=20
> int
> main ()
> {
>   volatile _Float128 x =3D __builtin_sqrtf128(powf128(2, 225));
>   char buf[256];
>   strfromf128 (buf, 128, "%a", x);
>   strfromf128 (buf + 128, 128, "%.36f", x);
>   printf ("%s\t%s\n", buf, buf + 128);
>   x =3D x * x;
>   strfromf128 (buf, 128, "%a", x);
>   strfromf128 (buf + 128, 128, "%.36f", x);
>   printf ("%s\t%s\n", buf, buf + 128);
> }
>=20
> 0x1.6a09e667f3bcc908b2fb1366ea95p+112
> 7343016637207168931428032607349397.000000000000000000000000000000000000
> 0x1.ffffffffffffffffffffffffffffp+224
> 53919893334301279589334030174039256154977430310253516431710891278336.
> 000000000000000000000000000000000000
> so again, x * x is 1ulp from 0x1.0p+225.

OK, but you are NOT RUNNING IN AN ARM 64 do you? Because that's the machine=
 I
am using...=