Ticket #1176 (new bug)

Opened 5 years ago

Last modified 4 years ago

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

Reported by: dukeleto Owned by:
Priority: normal Milestone:
Component: build Version: 1.7.0
Severity: medium Keywords: rtems
Cc: Language:
Patch status: Platform: all

Description

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.

Change History

  Changed 5 years ago by 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

  Changed 5 years ago by dukeleto

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

  Changed 5 years ago by dukeleto

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

follow-up: ↓ 7   Changed 5 years ago by dukeleto

  • priority changed from blocker to normal
  • severity changed from high to medium

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.

  Changed 5 years ago by dukeleto

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

  Changed 5 years ago by 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
    

in reply to: ↑ 4   Changed 5 years ago by 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

follow-up: ↓ 11   Changed 5 years ago by 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.

  Changed 5 years ago by 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.

  Changed 5 years ago by 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.

in reply to: ↑ 8   Changed 5 years ago by 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.

  Changed 5 years ago by coke

  • milestone changed from 1.8 to 1.9

  Changed 5 years ago by coke

  • milestone changed from 1.9 to 2.0

  Changed 5 years ago by chromatic

  • milestone changed from 2.0 to 2.1

  Changed 5 years ago by 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

  Changed 4 years ago by coke

  • milestone 2.2 deleted
Note: See TracTickets for help on using tickets.