[Cython] Cygwin: Handling missing C99 long double functions

[Robert Bradshaw]

On Wed, Apr 27, 2016 at 3:07 AM, Erik Bray <erik.m.bray at gmail.com> wrote:

> On Tue, Apr 26, 2016 at 10:55 PM, Robert Bradshaw <robertwb at gmail.com>
> wrote:
> > On Tue, Apr 26, 2016 at 8:36 AM, Erik Bray <erik.m.bray at gmail.com>
> wrote:
> >>
> >> On Tue, Apr 26, 2016 at 5:16 PM, Dima Pasechnik
> >> <dimpase+github at gmail.com> wrote:
> >> > Hi,
> >> > certainly we did something with Sage on cygwin to work around these...
> >> > Just in case,
> >>
> >> From what I can tell there are several places where Sage has hacked
> >> around this issue in different packages, but it's not doing anything
> >> specifically with it for Cython.  Sage uses the Cephes math lib to
> >> support these functions on FreeBSD--and apparently used to use it on
> >> Cygwin too, but disabled that for some reason.
> >>
> >> Regardless, Cython should ultimately do something sensible in these
> cases.
> >>
> >> My general thinking is that in cases where Cython generates code
> >> containing C math functions, it ought to support a fallback.  This
> >> will require some feature checks so that Cython can generate wrappers,
> >> when necessary, around the double versions of those functions (as
> >> Numpy currently does).
> >
> >
> > Let's make things concrete. You're complaining that something like
> >
> > cdef extern from "math.h":
> >     long double sqrtl(long double)
> >
> > def foo(long double x):
> >     return sqrtl(x)
> >
> > Doesn't work on Cygwin?
> >
> > The same is true for *any* C function that you use that's not totally
> > portable (this is the bane of trying to use C). I don't think Cython
> should
> > be detecting this and substituting a (less accurate) sqrt for sqrtl in
> this
> > case. If you want do do this, write your own headers that (conditionally)
> > define these things however you want.
>
> No, not at all.  That would be silly.  Let me be clearer...
>
> > Or, are you complaining that Cython's test suite doesn't pass on some
> Cygwin
> > because there are tests of features not available on Cygwin? (Your
> original
> > email isn't clear.) If so, the test framework can be set up to exclude
> these
> > tests on that platform.
>
> There are really two concerns.  This is one of them, yes.  The first
> question is what would be the best way to exclude certain tests on
> certain platforms?  There's no clear documentation on that (which is
> fine, but it's why I'm asking :)
>

Probably add a tag and then modify runtests.py to detect Cygwin and
automatically add this to the exclusion list.

The second concern, and more serious, is that there *are* cases where
> Cython generates code that uses long double functions where, for
> example, long double is passed as an argument.  For example the
> following code
>
>     def truncate_long_double(long double x):
>         cdef float r = int(x)
>         return r
>
> compiles to something that includes:
>
>       /* "truncl.pyx":2
>      * def truncate_long_double(long double x):
>      *     cdef float r = int(x)             # <<<<<<<<<<<<<<
>      *     return r
>      */
>       __pyx_t_1 = truncl(__pyx_v_x);
>       __pyx_v_r = __pyx_t_1;
>
>       /* "truncl.pyx":3
>      * def truncate_long_double(long double x):
>      *     cdef float r = int(x)
>      *     return r             # <<<<<<<<<<<<<<
>      */
>       __Pyx_XDECREF(__pyx_r);
>       __pyx_t_2 = PyFloat_FromDouble(__pyx_v_r); if
> (unlikely(!__pyx_t_2)) __PYX_ERR(0, 3, __pyx_L1_error)
>
> It's not not clear what the best way would be to *not* use this code
> on platforms where truncl missing (and there are a handful of other
> examples besides truncl). This code is generated by an optimization
> that was added here: http://trac.cython.org/ticket/400  In this case
> replacing truncl with trunc shouldn't hurt.
>

Here, yes, but in general truncl(x) != trunc(x) for, say, 2**54 + 1.

It's not uncommon (I think) to ship pre-cythonized C sources in a
> package's source distribution so that it can be installed (especially
> by pip) without requiring the user to have Cython.  This code will
> fail to compile on platforms like Cygwin.
>
> But it's not clear how to handle this at Cythonization time either
> since it doesn't know in advance what platform it will be targeting.
> I'm suggesting that maybe rather than using these functions directly
> Cython should generate some fallbacks for where they're not available,
> or at least have the option to.


The safest is to never use the long double type in this case--we assume
that if long double is present (used), so are the corresponding functions
in math.h (which is wrong for this platform, but if we need to use powl I
don't know what else to do). Alternatively, ship your own (conditionally
defined) fallbacks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20160428/30d7d14f/attachment.html>