From: Jakub Jelinek <jakub@redhat.com>
To: Siddhesh Poyarekar <siddhesh@gotplt.org>
Cc: Aldy Hernandez <aldyh@redhat.com>,
"Joseph S. Myers" <joseph@codesourcery.com>,
GCC patches <gcc-patches@gcc.gnu.org>,
Andrew MacLeod <amacleod@redhat.com>
Subject: Re: [PATCH] Implement range-op entry for sin/cos.
Date: Thu, 20 Apr 2023 16:02:02 +0200 [thread overview]
Message-ID: <ZEFF2l+KePBP2qnN@tucnak> (raw)
In-Reply-To: <cc08dc41-b90a-9012-58e7-3a7ec2c3cfa1@gotplt.org>
[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]
On Thu, Apr 20, 2023 at 09:17:10AM -0400, Siddhesh Poyarekar wrote:
> On 2023-04-20 08:59, Jakub Jelinek via Gcc-patches wrote:
> > > + r.set (type, dconstm1, dconst1);
> >
> > See above, are we sure we can use [-1., 1.] range safely, or should that be
> > [-1.-Nulps, 1.+Nulps] for some kind of expected worse error margin of the
> > implementation? And ditto for -frounding-math, shall we increase that
> > interval in that case, or is [-1., 1.] going to be ok?
>
> Do any math implementations generate results outside of [-1., 1.]? If yes,
Clearly they do.
> then it's a bug in those implementations IMO, not in the range assumption.
> It feels wrong to cater for what ought to be trivially fixable in libraries
> if they ever happen to generate such results.
So, I wrote following test.
On x86_64-linux with glibc 2.35, I see
for i in FLOAT DOUBLE LDOUBLE FLOAT128; do for j in TONEAREST UPWARD DOWNWARD TOWARDZERO; do gcc -D$i -DROUND=FE_$j -g -O1 -o /tmp/sincos{,.c} -lm; /tmp/sincos || echo $i $j; done; done
Aborted (core dumped)
FLOAT UPWARD
Aborted (core dumped)
FLOAT DOWNWARD
On sparc-sun-solaris2.11 I see
for i in FLOAT DOUBLE LDOUBLE; do for j in TONEAREST UPWARD DOWNWARD TOWARDZERO; do gcc -D$i -DROUND=FE_$j -g -O1 -o sincos{,.c} -lm; ./sincos || echo $i $j; done; done
Abort (core dumped)
DOUBLE UPWARD
Abort (core dumped)
DOUBLE DOWNWARD
Haven't tried anything else. So that shows (but doesn't prove) that
maybe [-1., 1.] interval is fine for -fno-rounding-math on those, but not
for -frounding-math.
Jakub
[-- Attachment #2: sincos.c --]
[-- Type: text/plain, Size: 1426 bytes --]
#define _GNU_SOURCE
#include <math.h>
#include <fenv.h>
#ifdef FLOAT
#define TYPE float
#define SIN sinf
#define COS cosf
#ifdef M_PI_2f
#define PI2 M_PI_2f
#else
#define PI2 1.570796326794896619231321691639751442f
#endif
#define NEXTAFTER nextafterf
#elif defined DOUBLE
#define TYPE double
#define SIN sin
#define COS cos
#ifdef M_PI_2
#define PI2 M_PI_2
#else
#define PI2 1.570796326794896619231321691639751442f
#endif
#define NEXTAFTER nextafter
#elif defined LDOUBLE
#define TYPE long double
#define SIN sinl
#define COS cosl
#ifdef M_PI_2l
#define PI2 M_PI_2l
#else
#define PI2 1.570796326794896619231321691639751442f
#endif
#define NEXTAFTER nextafterl
#elif defined FLOAT128
#define TYPE _Float128
#define SIN sinf128
#define COS cosf128
#ifdef
#define PI2 M_PI_2f128
#else
#define PI2 1.570796326794896619231321691639751442f
#endif
#define NEXTAFTER nextafterf128
#endif
int
main ()
{
#ifdef ROUND
fesetround (ROUND);
#endif
for (int i = -1024; i <= 1024; i++)
for (int j = -1; j <= 1; j += 2)
{
TYPE val = ((TYPE) i) * PI2;
TYPE inf = j * __builtin_inf ();
for (int k = 0; k < 1000; k++)
{
TYPE res = SIN (val);
if (res < (TYPE) -1.0 || res > (TYPE) 1.0)
__builtin_abort ();
res = COS (val);
if (res < (TYPE) -1.0 || res > (TYPE) 1.0)
__builtin_abort ();
val = NEXTAFTER (val, inf);
}
}
}
next prev parent reply other threads:[~2023-04-20 14:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 13:12 Aldy Hernandez
2023-04-20 12:59 ` Jakub Jelinek
2023-04-20 13:17 ` Siddhesh Poyarekar
2023-04-20 14:02 ` Jakub Jelinek [this message]
2023-04-20 14:20 ` Jakub Jelinek
2023-04-20 15:22 ` Siddhesh Poyarekar
2023-04-20 15:52 ` Jakub Jelinek
2023-04-20 17:57 ` Siddhesh Poyarekar
2023-04-21 1:14 ` Siddhesh Poyarekar
2023-04-21 6:52 ` Jakub Jelinek
2023-04-21 11:20 ` Siddhesh Poyarekar
2023-04-25 8:59 ` Aldy Hernandez
2023-04-24 16:03 ` Jakub Jelinek
2023-04-24 16:05 ` Siddhesh Poyarekar
2023-04-24 16:09 ` Jakub Jelinek
2023-04-24 16:33 ` Jeff Law
2023-04-21 16:40 ` Jakub Jelinek
2023-04-21 20:43 ` Mikael Morin
2023-04-21 20:45 ` Jakub Jelinek
2023-04-25 9:10 ` Aldy Hernandez
2023-04-25 9:08 ` Aldy Hernandez
2023-04-27 11:13 ` [PATCH] v2: " Jakub Jelinek
2023-04-27 11:46 ` Aldy Hernandez
2023-04-27 11:53 ` Jakub Jelinek
2023-04-27 12:03 ` Aldy Hernandez
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=ZEFF2l+KePBP2qnN@tucnak \
--to=jakub@redhat.com \
--cc=aldyh@redhat.com \
--cc=amacleod@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=siddhesh@gotplt.org \
/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).