Export fast *rint* functions
Sat Dec 29 18:10:00 GMT 2007
On Sat, Dec 29, 2007 at 05:57:51PM -0000, Dave Korn wrote:
>On 29 December 2007 17:30, Christopher Faylor wrote:
>> On Sat, Dec 29, 2007 at 05:22:31PM -0000, Dave Korn wrote:
>>> On 29 December 2007 17:04, Christopher Faylor wrote:
>>>> I assume that the above comment about aliasing needs to know right?
>>> Sorry, can't parse that. ENOCOFFEE? ;-)
>> I meant "go" above. I got distracted by my stupid turtle who, after
>> twelve years of docility in the tank behind me, has decided to spend the
>> last two months frantically trying to claw his way out of his tank.
>> I guess I just don't understand what the aliasing is all about here.
> Right, it goes like this:
>- At the moment, all the new x87 *rint* functions are implemented as fast
>math variants in newlib, with '_f_' prefixes to the function names. (I'm not
>convinced this is necessarily correct, but that's the way it is right now;
>when Jeff gets back I'll discuss whether and why they can or can't be
>considered first-class implementations).
>- For the functions that didn't already exist (i.e., all except
>rint/rintf/lrint/lrintf), Jeff added wrappers using the POSIX standard names
>that call through to the equivalent _f_ hard-fp version of the same function.
> Now, these wrappers are fairly superfluous. They set up a stack frame,
>immediately tear it down, then tail-call to the underlying _f_ function.
> So, I figured, if someone's linking against the DLL and needs one of these
>functions, why not get the link to resolve directly to the _f_ function and
>avoid the wrapper? It won't make a great deal of impact to debuggability or
>stack traces and it saves a few wasted instructions.
> Also, the existing soft-float implementations of rint/rintf/lrint/lrintf are
>still present in newlib; they are not overridden by the _f_ versions. So any
>app that links against these will continue to get the old slow soft float
>version. By exporting the _f_ version with the name of the non-_f_ version,
>apps will link against the hard fp version instead.
> OTOH, I can see how this could be a bit confusing and make setting
>breakpoints a bit tricky. I could remove the aliasing for the new functions
>and make calls go through the wrapper, but there aren't any wrappers for the
>existing functions, just soft-float implementations, so at least those
>functions would still need to be aliased to the _f_ versions. Long-term, my
>plan is to either provide wrappers for those existing functions (in a
>cygwin-only patch to newlib), or if there are no compliance problems to
>promote all the _f_*rint* functions to first-class versions, losing the _f_
>prefix and wrapper altogether.
Ok. Thanks very much for the explanation.
Since we're still tinkering with 1.7.x, I think it's ok to check these in
even if things may change eventually.
So check this in but you do also have to bump CYGWIN_VERSION_API_MINOR
and document what you're exporting in include/cygwin/version.h along with
More information about the Cygwin-patches