classification
Title: Enable short float repr() on Solaris/x86
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.1
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: mark.dickinson, skrah
Priority: normal Keywords: easy, patch

Created on 2009-04-19 12:33 by mark.dickinson, last changed 2009-11-15 13:49 by mark.dickinson. This issue is now closed.

Files
File name Uploaded Description Edit
sun_short_float_repr.patch mark.dickinson, 2009-11-09 14:45
Messages (22)
msg86168 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-04-19 12:33
The short float repr() that's in 3.1 (probably) doesn't work on 
Solaris/x86 when using Sun's compiler to build.  It would be nice to
fix this.

It probably works on Solaris/x86/gcc, though confirmation of that would be 
appreciated.

Marking as easy, because this should be an easy task for someone who has 
access to the appropriate setup.  I can probably do all the 
autoconf/define stuff required, but I need help from someone who has 
access to Solaris/x86 and who can be available to do testing.
msg86169 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-04-19 12:40
See the comments in the Include/pyport.h file for an explanation of
what's required. (Search for HAVE_PY_SET_53BIT_PRECISION.)
msg95065 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-09 10:43
There are some related comments in issue #7281.
msg95068 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2009-11-09 11:32
I can confirm that short float repr() is active and all float tests are
passed on this combination:

Ubuntu64bit -> KVM -> OpenSolaris32bit/Python3.2/gcc
msg95069 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-09 11:34
Stefan Krah mentions in the issue 7281 discussion that suncc supports
the C99 fenv functions.  I'm not sure how to use these to set the x87
precision, though.  (Setting the rounding mode is straightforward.)
msg95071 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-09 11:41
I see two alternatives:

(1) Use fesetenv.  I don't know what the appropriate value to pass would
be though, or even whether solaris lets you use fesetenv to control the
x87 precision.  It seems that its primary purpose is to set flags and traps.

(2) Use inline assembly, assuming that suncc supports this.  This seems
simpler.  It's just a matter of figuring out the syntax that suncc
expects for asm, and making sure the code is properly tested.
msg95072 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-09 11:46
Looking at:

http://docs.sun.com/app/docs/doc/816-5172/fesetenv-3m

it seems that fesetenv isn't what we want here.  It 'only installs the
state of the floating-point status flags represented through its argument'.
msg95073 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-09 11:53
Stefan, is it possible that suncc already accepts the assembler syntax
used in Python/pymath.h (py3k or trunk) for the functions
_Py_get_387controlword and _Py_set_387controlword?
msg95076 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2009-11-09 12:51
The inline asm compiles, but I don't know how good the GNU inline asm
support is with suncc in general. I'm not a heavy user of suncc, I just
use it for testing.

That said, perhaps fesetprec works, too:

http://docs.sun.com/app/docs/doc/816-5172/fesetprec-3m
msg95077 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-09 13:33
Excellent!  From a bit of searching, it looks as though this assembler
syntax works on icc as well, which is very good news.

Thanks for finding fesetprec as well.  It's a shame this isn't standard
C.  Oh well;  maybe for C201X.  I think I'd prefer to stick with the
inline assembly, since it seems that there's very little to do to make
this just work.

Next problem:  when compiling with suncc, how do I detect (in the
configure script)

(1) that I'm using suncc, and
(2) whether the hardware is x86 or not (preferably excluding the case of
x86-64).

For gcc, configure.in is using:

if test -n "`$CC -dM -E - </dev/null | grep i386`"

to detect whether we're on x86.  I guess it's too much to hope for that
this works for suncc as well.
msg95078 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-09 14:02
fesetprec and fegetprec are at least semi-standard, it seems.  They're
recommended in the C99 rationale (see page 121 of

http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf

).
msg95079 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2009-11-09 14:27
If gcc and suncc are present, ./configure chooses gcc and everything is
fine.

If only suncc is present, it's detected as cc. These tests should be
possible:

stefan@opensolaris:~/svn/py3k$ cc -V
cc: Sun C 5.9 SunOS_i386 Patch 124868-07 2008/10/07
usage: cc [ options] files.  Use 'cc -flags' for details
stefan@opensolaris:~/svn/py3k$ if cc -V 2>&1 | grep -q 'SunOS_i386';
then echo yes; fi
yes
stefan@opensolaris:~/svn/py3k$ uname -a
SunOS opensolaris 5.11 snv_101b i86pc i386 i86pc Solaris
stefan@opensolaris:~/svn/py3k$ if uname -a | grep -q i386; then echo yes; fi
yes
msg95080 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-09 14:33
Thanks.  uname looks like the way to go, then.

Is your copy of OpenSolaris running in 32-bit mode or 64-bit mode?  Does
the mode make a difference to the output of uname, or is uname -p always
i386, regardless of the mode?

I think the configure test for the inline assembly should go ahead on
both x86 and x86-64:  it seems likely that a 64-bit OS would be using
SSE2 instructions for floating-point (which would make setting and
getting the x87 control word unnecessary) instead of the x87 FPU, but I
don't know that for sure.

Actually, I guess I could just make that configure test unconditional.
It'll fail on non-x86 hardware, but that's no big deal.
msg95082 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-09 14:45
Stefan, please could you test the attached patch (against py3k) with
suncc?  With this patch, sys.float_repr_style should report 'short', and
'make test' should not produce any obviously float-related failures.
msg95083 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2009-11-09 14:55
My copy is 32-bit. I never installed a 64-bit version, but I strongly
assume that uname -p gives x86_64. BTW, uname -p works on Solaris, but
returns 'unknown' on my 64 bit Linux.
msg95085 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2009-11-09 15:36
Tested the patch against an updated 3.2. repr-style is 'short', and I
did not see obvious float errors. In particular, test_float.py is
passed. I also did not see new compile warnings.

As for the other tests, the errors I get seem to be the same with or
without the patch. Any other tests I should watch out for apart from
test_float.py?
msg95087 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-09 16:32
Many thanks for testing this, Stefan!  I'll tidy up the patch a little bit 
and add a Misc/NEWS entry, then commit this.
msg95088 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-09 16:37
> As for the other tests, the errors I get seem to be the same with or
> without the patch. Any other tests I should watch out for apart from
> test_float.py?

Well *ideally* you shouldn't be getting any test failures :-).  But I 
could imagine than running Solaris within a VM might cause some 
problems.  Which tests are failing?

Tests I'd be worried about for the float repr change include: 
test_float, test_complex, test_math, test_cmath, test_ast, test_format, 
test_marshal, test_pickle, test_json, test_builtin, test_capi.
msg95093 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2009-11-09 17:54
The tests that you mention run o.k., except capi, but that looks harmless:

stefan@opensolaris:~/svn/py3k/Lib/test# ../../python test_capi.py
test_instancemethod (__main__.CAPITest) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
internal test_L_code
internal test_Z_code
internal test_capsule
internalTraceback (most recent call last):
  File "test_capi.py", line 170, in <module>
    test_main()
  File "test_capi.py", line 130, in test_main
    print("internal", name)
ImportError: No module named _curses



Tests that fail:

test_ascii_formatd, test_calendar, test_datetime, test_distutils,
test_email, test_httpservers, test_mailbox, test_multiprocessing,
test_os, test_pipes, test_platform, test_poll, test_popen, test_pty,
test_pydoc, test_quopri, test_select, test_signal, test_strftime,
test_strptime, test_subprocess, test_sys, test_tempfile, test_threading


A lot of these fail either due to the inability to allocate resources or
the fact that strftime appears to give weird results.
msg95094 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-09 18:28
Is the test_ascii_formatd failure due to a failed 'from ctypes import 
...'?  That's the only failure that looks like it could be related.

Thanks for this.
msg95097 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2009-11-09 21:09
Yes, test_ascii_formatd fails with 'ImportError: No module named _ctypes'.
msg95289 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-11-15 13:49
Committed in r76300 (trunk) and r76301 (py3k).  Thanks for all your help, 
Stefan.
History
Date User Action Args
2009-11-15 13:49:49mark.dickinsonsetstatus: open -> closed
resolution: fixed
messages: + msg95289

stage: needs patch -> resolved
2009-11-09 21:09:20skrahsetmessages: + msg95097
2009-11-09 18:28:31mark.dickinsonsetmessages: + msg95094
2009-11-09 17:54:02skrahsetmessages: + msg95093
2009-11-09 16:37:18mark.dickinsonsetmessages: + msg95088
2009-11-09 16:32:11mark.dickinsonsetmessages: + msg95087
2009-11-09 15:36:50skrahsetmessages: + msg95085
2009-11-09 14:55:00skrahsetmessages: + msg95083
2009-11-09 14:45:30mark.dickinsonsetfiles: + sun_short_float_repr.patch
keywords: + patch
messages: + msg95082
2009-11-09 14:33:44mark.dickinsonsetmessages: + msg95080
2009-11-09 14:27:58skrahsetmessages: + msg95079
2009-11-09 14:02:49mark.dickinsonsetmessages: + msg95078
2009-11-09 13:33:55mark.dickinsonsetmessages: + msg95077
2009-11-09 12:51:19skrahsetmessages: + msg95076
2009-11-09 12:17:17mark.dickinsonsetassignee: mark.dickinson
2009-11-09 11:53:00mark.dickinsonsetmessages: + msg95073
2009-11-09 11:46:37mark.dickinsonsetmessages: + msg95072
2009-11-09 11:41:18mark.dickinsonsetmessages: + msg95071
2009-11-09 11:34:04mark.dickinsonsetmessages: + msg95069
2009-11-09 11:32:11skrahsetnosy: + skrah
messages: + msg95068
2009-11-09 10:43:34mark.dickinsonsetmessages: + msg95065
2009-04-19 12:40:24mark.dickinsonsetmessages: + msg86169
2009-04-19 12:33:18mark.dickinsoncreate