Re: [PATCH] Implement range-op entry for sin/cos.

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

On 2023-04-20 10:02, Jakub Jelinek wrote:
> 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.

Would there be a reason to not consider these as bugs?  I feel like 
these should be fixed in glibc, or any math implementation that ends up 
doing this.

I suppose one reason could be the overhead of an additional branch to 
check for result bounds, but is that serious enough to allow this 
imprecision?  The alternative of output range being defined as 
[-1.0-ulp, 1.0+ulp] avoids that conversation I guess.

Thanks,
Sid