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 these changes. cgf
