Configure-time check for whether to use powl() or pow(), since powl() is an optional posix extension

[dukeleto]

This site lists powl() as an optional POSIX extension:

 http://www.mers.byu.edu/docs/standardC/math.html

We should have a Configure-time check for whether it exists.

This is currently blocking the porting of Parrot to the RTEMS real-time embedded operating system, which only implements the the mandatory core of POSIX.

[dukeleto]

This is what we currently have, and it is wrong:

/* local macro to call proper pow version depending on FLOATVAL */
#if NUMVAL_SIZE == DOUBLE_SIZE
 #  define POW pow
#else
#  define POW powl
#endif

[dukeleto]

That was from src/string/api.c around line 2325 .

[dukeleto]

'make fulltest' passes on darwin/x86 when I change POW=powl to POW=pow

[dukeleto]

I have redefined POW to be pow() unconditionally in r42217, and put a note referencing this TT.

This is no longer blocking the port of Parrot to RTEMS.

[dukeleto]

Also, 'fulltest' passed on linux-amd64 with POW=pow.

[doughera]

>  I have redefined POW to be pow() unconditionally in r42217, and put a note
>  referencing this TT.

This was originally there to support  Configure --floatval='long double', 
which used to mostly work. 

You could probably revert this patch and replace it with something like

    #if NUMVAL_SIZE > DOUBLE_SIZE
    #  define POW powl
    #else
    #  define POW pow
    #endif

--
    Andy Dougherty		doughera@lafayette.edu
    

[jkeenan]

Replying to dukeleto:

I have redefined POW to be pow() unconditionally in r42217, and put a note referencing this TT. This is no longer blocking the port of Parrot to RTEMS.

Could you check out Andy D's suggestion and let us know what you think of it?

It would then be good to know whether you think we should pursue the Configure-time check for powl OTOH or close the ticket on the other.

Thank you very much.

kid51

[dukeleto]

I've never seen the --floatval flag before. Does anyone run the test suite with it on? Does it work? I would prefer a configure-time check for powl, before using it.

[NotFound]

As reported by mikehh in #parrot, a c++ --optimize build in Ubuntu 9.10 (gcc version 4.4.1) fails the last test in t/op/comp.t Defining POW as powl it passes again.

[mikehh]

ref previous comment by NotFound

in the --optimize build with g++ 4.4.1 on Ubuntu 9.10 i386 it uses the long double (80 bits) in the test t/op/comp.t - test 7 in setting the string (i.e. powl is needed here) - it does not use it in the gcc 4.4.1 build with --optimize, or either without --optimize.

the test - t/op/comp-7.pasm

        new P0, 'Float'
        set P0, -1.2
        new P1, 'String'
        set P1, "-1.2"
        eq_num P0, P1, OK
        print "not "
OK:     print "ok\n"
        end

the test passes if the line set P1, "-1.2" is changed to set P1, "-1.2000000000". fewer zeros do not work (more ok).

It also passes if POW is defined as powl.

The standard allows the use of higher precision in intermediate calculations, which it appears the --optimize build with g++ 4.4.1 is doing here.

ref --floatval

I haven't used this recently in builds but I can envisage circumstances where I might need it. On the i386 platform double is 64 bits and long double is 80 bits. On the amd64 platform double is again 64 bits but long double is 128 bits, using different functionality in the x86_64 (intel or amd) processors rather than the old x87 functionality. This might be needed for higher precision calculations in certain circumstances which should be quicker than using bignum or whatever.

[doughera]

Replying to dukeleto:

I've never seen the --floatval flag before. Does anyone run the test suite with it on? Does it work? I would prefer a configure-time check for powl, before using it.

As I said above, it used to mostly work. As I recall, there were a few PBC issues and some broken tests, but they were mostly bad tests.

While you are correct that a Configure probe would be useful (see TT #1048 for some thoughts on that) I think my patch should be applied in the meantime. With my patch above, parrot won't normally try to use powl unless the user explicitly asks for --floatval='long double'. I don't think a user without a working powl function is likely to ask for long doubles.

I'm actually puzzled how the old version could have blocked RTEMS, unless they were somehow effectively using --floatval='float'. I don't know if that has ever worked.

[JoelSherrill]

After the IRC tonight, I was looking at the tickets and this one caught my eye. RTEMS via newlib does appear to have all of the powXXX variants. It is in libm.a:

$ i386-rtems4.10-nm -g /opt/rtems-4.10/i386-rtems4.10/lib/libm.a |grep "T po"

00000000 T powl 00000000 T pow10 00000000 T pow10f 00000000 T pow 00000000 T powf

So your probes have to be aware of which library the method is in. In this case, it is libm.a, not libc.a. So I think this may be a non-issue if you use the correct arguments.

And FWIW the definitive site for POSIX info is opengroup.org:

 http://www.opengroup.org/onlinepubs/009695399/functions/pow.html