ARC math test regressions (was Re: [PATCH v7 00/13] glibc port to ARC processors)

[Vineet Gupta <Vineet.Gupta1@synopsys.com>]

On 7/1/20 12:13 PM, Vineet Gupta via Libc-alpha wrote:
> On 6/30/20 6:44 PM, Adhemerval Zanella via Libc-alpha wrote:


> FAIL: math/test-float-exp10
> FAIL: math/test-float32-exp10

The exp10 tests needed regen-ulps and now fixed.

> FAIL: math/test-float32x-acos
> FAIL: math/test-float32x-asin
> FAIL: math/test-float64-acos
> FAIL: math/test-float64-asin
> FAIL: math/test-ldouble-acos
> FAIL: math/test-ldouble-asin

This is a regression, as we had no math errors before.

Here's my analysis of the issue so far (I don't have prior builds to corroborate
here).

The failures are following

| Failure: acos (inf): Exception "Invalid operation" not set
| Failure: acos (-inf): Exception "Invalid operation" not set
| Failure: acos (1.125): Exception "Invalid operation" not set
| Failure: acos (-1.125): Exception "Invalid operation" not set
| Failure: acos (max_value): Exception "Invalid operation" not set
| Failure: acos (-max_value): Exception "Invalid operation" not set
...
...
| similarly 6 for each of acos_downward(), acos_towardzero (), acos_upward ()


Simple testcase which confirms that Invalid Exception is *not* being raised

| double in = __builtin_inf ();
| acos(in);
| pass = fetestexcept(FE_INVALID);

Exception *is* raised for @in = __builtin_nans("")

Now acos can come from 2 places depending on LIBM_SVID_COMPAT
 - math/w_acos_template.c	<-- sets errno only
 - math/w_acos_compat.c	<-- raises exception FE_INVALID

For ARC, 1st variant is building, so explicit exception is NOT raised.
Is this the issue ?

Or is Invalid Exception supposed to be set by the prologue in acos (both variants)
which looks like following:

__acos (double x)
{
  if (__builtin_expect ((__builtin_isgreater(fabs (x), 1.0)), 0))

isgreater() is not unordered so it is not supposed to raise exception unless
signaling so it can't be, and fabs() doesn't seem be doing much except clipping
off some bits.

So I'm confused where the issue is
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc