[Bug 220989] lib/msun/trig_test fails with clang 5.0+

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220989

Dimitry Andric <dim at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|freebsd-testing at freebsd.org |dim at FreeBSD.org
                 CC|                            |davide at FreeBSD.org,
                   |                            |emaste at freebsd.org

--- Comment #3 from Dimitry Andric <dim at FreeBSD.org> ---
I tried adding a bit of debug info, and with a "good" libm, the first result
is:

DBG: ld_pi_odd[0] = 1.18918869603738415962e+101,
     sinl() = 2.47267281071058784804e-22,
     fabsl() = 2.47267281071058784804e-22,
     LDBL_EPSILON = 1.08420217248550443401e-19

With a "bad" libm (compiled by clang 5.0.0), it becomes:

DBG: ld_pi_odd[0] = 1.18918869603738415962e+101,
     sinl() = 6.81892800593498228635e-01,
     fabsl() = 6.81892800593498228635e-01,
     LDBL_EPSILON = 1.08420217248550443401e-19

E.g. the sinl() result is completely off.  I did some bisection, and it seems
to have regressed with this upstream commit:

  https://reviews.llvm.org/rL307529
  ("This patch completely replaces the scheduling information for the
SandyBridge architecture target by modifying the file X86SchedSandyBridge.td
located under the X86 Target")

I am not entirely sure why such a commit would influence the operation of e.g.
sinl() on generic amd64, since it does not use any Sandy Bridge specific
assembly or the like.  Maybe it exposes some other bug in the X86 code
generation for long doubles?  Or maybe there is some sort of undefined behavior
in our sinl() implementation that is now being over-optimized?

The challenge here is to come up with a good minimized test case for upstream,
so we can submit this as a concrete bug.  Maybe it is easiest to just copy
paste all of the sinl() implementation plus the relevant part of trig_test.c
into one big .c file, and make it print and/or check the end result.

-- 
You are receiving this mail because:
You are the assignee for the bug.