Bug 202162 - Missing support for fpsetround()
Summary: Missing support for fpsetround()
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: arm64 Any
: --- Affects Only Me
Assignee: freebsd-arm mailing list
Depends on:
Blocks: 201763
  Show dependency treegraph
Reported: 2015-08-07 18:25 UTC by Sean Bruno
Modified: 2017-01-03 17:43 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Sean Bruno freebsd_committer 2015-08-07 18:25:37 UTC
TCL ports seem to have a need for fpsetround() on ARM64 that is missing.  I'm unsure where this would be added, so I'll just drop these logs here for future review.

Comment 1 Andrew Turner freebsd_committer 2015-08-08 11:22:51 UTC
I would like it if we don't need to implement these. I'm planning on a ports exp-run on amd64 to see what breaks when the fp* functions are removed.
Comment 2 Ed Maste freebsd_committer 2015-08-10 13:29:49 UTC
From tcl8.4.20/unix/tclUnixInit.c for reference:

> #if defined(__FreeBSD__) && defined(__GNUC__)
>     /*
>      * Adjust the rounding mode to be more conventional. Note that FreeBSD     
>      * only provides the __fpsetreg() used by the following two for the GNU    
>      * Compiler. When using, say, Intel's icc they break. (Partially based on  
>      * patch in BSD ports system from root@celsius.bychok.com)
>      */
>     fpsetround(FP_RN);
>     fpsetmask(0L);
> #endif
Comment 3 Ed Maste freebsd_committer 2016-06-22 14:37:48 UTC
Should we just add `&& !defined(__aarch64__)` to the conditional for now?
Comment 4 Ed Maste freebsd_committer 2016-09-07 13:56:52 UTC
lang/tcl86, failing due to lack of fpsetround, is responsible for 615 skipped ports in the arm64 quarterly ports build

Comment 5 Ed Maste freebsd_committer 2016-10-28 17:51:11 UTC
TCL has been fixed. Sean are you aware of any other ports affected by this?
Comment 6 Sean Bruno freebsd_committer 2016-10-28 18:33:37 UTC
no, I think we're good here.  I can't recall any others, but I'll keep my eye out.