There's a test_float failure on HPUX (and many compiler warnings):

test test_float failed -- Traceback (most recent call last):
  File "/home/cpython/buildslave/2.7.snakebite-hpux11iv3-ia64-1/build/Lib/test/test_float.py", line 622, in test_format_testfile
    self.assertEqual(fmt % arg, rhs)
AssertionError: '9999999999999999464902769475481793200000000000000' != '9999999999999999464902769475481793196872414789632'

What's sys.float_repr_style on that machine?

From the buildbot configure output:

checking whether C doubles are little-endian IEEE 754 binary64... no
checking whether C doubles are big-endian IEEE 754 binary64... yes
checking whether C doubles are ARM mixed-endian IEEE 754 binary64... no
checking whether we can use gcc inline assembler to get and set x87 control word... no
checking for x87-style double rounding... yes

Judging by that, it'll probably be using the legacy float repr, since the configure script didn't find a way to set the FPU control word.

In that case this is just an overeager test: we expect 50 digits of accuracy but the system-supplied formatting only gives us 35.

But it would also be good to try to find a way to enable the short float repr on that box.

Without having looked too hard, the many warnings are almost certainly from our definition of Py_NAN.  That's been fixed in the default branch.  I'm not sure whether it's worth backporting just to fix warnings.

I wonder whether adding "-fpeval=float" to the CFLAGS would fix this.  There's a lot of information at 

http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=0008a22194f02110a22194f02110275d6e10RCRD

but I don't know whether it's relevant to this machine.  Trent?

For some reason ./configure detects x87-style-double-rounding=yes, but when
I compile the test manually with the same command line "cc -Ae -g", no
double rounding is detected.

On Fri, Nov 23, 2012 at 05:43:15AM -0800, Mark Dickinson wrote:
> 
> Mark Dickinson added the comment:
> 
> I wonder whether adding "-fpeval=float" to the CFLAGS would fix this.  There's a lot of information at 
> 
> http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=0008a22194f02110a22194f02110275d6e10RCRD
> 
> but I don't know whether it's relevant to this machine.  Trent?

    No idea.  I'll look into it.

The issue here is that the BASECFLAGS variable contains the mysterious 
option -Olimit 1500, which makes the X87_DOUBLE_ROUNDING test fail (i.e. 
X87_DOUBLE_ROUNDING is set to true when it should be false).

When BASECFLAGS is unset, test_float passes.


-Olimit gives problems with at least icc, suncc and HP C/aC++. So
propose to make this an -Olimit issue instead.

New changeset 5697387b0089 by Stefan Krah in branch '2.7':
Issue #16534: On HP-UX ac_cv_olimit_ok=yes is a false positive.
http://hg.python.org/cpython/rev/5697387b0089

./configure is fixed, sys.float_repr_style is 'short' now.


I agree that it's not worth backporting Py_NAN fixes; I guess we can
close this then.