[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: The gcc optimization bug was fixed (with impressive speed!) upstream. I'm going to close this as 'won't fix'. It's probably possible to find a workaround, but the issue is minor, apparently only affects one platform, and relates to a little-used method. For people who want this fixed in their own Python builds, a fairly unintrusive workaround is to add '-fno-builtin-copysign' to the compiler flags, or to compile with version 4.4 of gcc until the next bugfix release of gcc 4.4 or 4.5. David: thanks for reporting this, and for all the followup. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: I would add I was building 64-bit, so adding the compiler flag -m64 on 'hawk' at least some of the time. Ah; that may be relevant. Can you tell us exactly what command line you're using to build Python, and the values of any relavent environment variables? I would have thought it was better to test this out with small bits of test code like I posted, rather than the complete Python source code. Unfortunately, the small bits of code don't really help: I get the same results as you for those, and I understand why those are failing: copysign isn't declared (as you'll see if you add -Wall to your compilation line) so the compiler assumes it returns type 'int'. This shouldn't happen with Python because its configure script defines __EXTENSIONS__, which ensures that copysign *is* declared when math.h is included. Can you still reproduce the strange copysign results with your small examples when __EXTENSIONS__ is #define'd? This conflicting behavior could be the result of what linker or assembler is being used. On SPARC, I use Sun linker and assembler. On OpenSolaris I use the Sun linker, but the GNU assembler. I have the same setup (Sun linker, GNU assembler): dicki...@eratosthenes:~/release26-maint$ gcc-4.4 -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc-4.4.4/configure --prefix=/usr/local --program-suffix=-4.4 --with-mpfr-include=/usr/include/mpfr --with-gmp-include=/usr/include/gmp --with-as=/usr/bin/gas --with-gnu-as --with-ld=/usr/bin/ld --without-gnu-ld --enable-shared --enable-multilib --enable-languages=c,c++,objc Thread model: posix gcc version 4.4.4 (GCC) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: David, I'm still missing some easy answers that would really help. Please could you answer the question about whether __EXTENSIONS__ is defined in your pyconfig.h; it would help determine what we should be investigating. There shouldn't be any need for the -std=c99 option: the Python configure script defines __EXTENSIONS__ exactly to make these c99 functions available. So either that isn't happening on your machines, in which case we should be looking for a problem with the configure script, or it *is* happening, in which case copysign is being properly declared on your machine and we have to look elsewhere (library mismatch? compiler optimization bug?) for the cause of failure. Still no joy with an -m64 build. I've attached a transcript showing the precise steps I used. [I'm tempted to close this issue as 'works for me'; I'm not seeing any test_math failure in OpenSolaris, and neither is the Solaris/SPARC buildbot.] -- Added file: http://bugs.python.org/file17774/opensolaris_python_buildlog.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: Stefan, thanks for the feedback. I don't *think* this is related to issue 7281. I thought we'd determined that that issue had nothing to do with copysign itself, and everything to do with what the signbit of the NaN returned by float(nan) happens to be. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Stefan Krah stefan-use...@bytereef.org added the comment: Mark Dickinson rep...@bugs.python.org wrote: I don't *think* this is related to issue 7281. I thought we'd determined that that issue had nothing to do with copysign itself, and everything to do with what the signbit of the NaN returned by float(nan) happens to be. Yes, that's right. Also, to avoid spreading misinformation: The copysign(1.0, float(nan)) behavior is actually the same after changing float_repr_style. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Hi, __EXTENSIONS__ is defined to 1. Give me an hour, and I'll attach a log. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Here's a build done the same way as you. This gives the same result as you here. But an attempt to run the test suite fails because of _socket. I need to patch that in order that I can run the test suite. See http://bugs.python.org/issue8852 -- Added file: http://bugs.python.org/file17775/build-with_socket-failure.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Here's the header file that gets created -- Added file: http://bugs.python.org/file17776/pyconfig.h ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: Thanks for the logs. So if you apply the issue8852 patch, and run the test suite, does test_float still fail? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Sorry, I seem to have wasted a lot of your time here. Python was built from a script which applied some patches - including that one that allows _socket to build. Without that (which is not commit to python and I'm told it might not be done this year), its impossible to run the test suite. It looks like of the patches has messed up with test_float. Unfortunately, if I just apply the patch at issue8852, then the test suite hangs at: test_posix It's used 48 minutes of CPU time on a 3.33 GHz Xeon as I write, passing most tests up to test_posix, but hanging there. Sorry to have wasted your time. BTW, are you able to run the full test suite, or does the test suite simply not run at all? Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: I see the same _socket build failure as you do; but with the issue 8852 patch, I can run the test suite. It did spend quite a while in test_posix, but the test eventually finished (and failed). I didn't get to the end of the test run, unfortunately, because I ran out of disk space. (4 virtual machines on a small laptop is pushing it a bit. :) It's possible that the test_posix failure was due to running out of space, I guess. Anyway, that's a separate issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment:
test_float
test test_float failed -- Traceback (most recent call last):
File /export/home/drkirkby/Python-2.7rc2/Lib/test/test_float.py, line 1297,
in test_roundtrip
self.identical(-x, roundtrip(-x))
File /export/home/drkirkby/Python-2.7rc2/Lib/test/test_float.py, line 907,
in identical
self.fail('%r not identical to %r' % (x, y))
AssertionError: -0.0 not identical to 0.0
test_fnmatch
test_fork1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Sorry, I missed out the comment there. This is failing for me, in boht 32 and 64-bit builds with Python-2.7rc2 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: Okay---this one I *can* reproduce. :) I'm going to call it a gcc optimization bug. Specifically, it seems to be a bug involving gcc's builtin version of the copysign function. When I build a current svn trunk checkout (r82245) with: CC='gcc-4.4 -m64' ./configure make I get the wrong result: Python 2.7rc2+ (trunk:82245, Jun 26 2010, 05:35:07) [GCC 4.4.4] on sunos5 Type help, copyright, credits or license for more information. (-0.0).hex() '0x0.0p+0' But when building with either: CC='gcc-4.4 -m64 -fno-builtin-copysign' ./configure make or CC='gcc-4.4 -m64' ./configure --with-pydebug make I get the expected results. If I have time I'll investigate further and see if I can generate the bug from smaller code. At any rate, I don't think this is something that can sensibly be fixed in Python itself, so I think this issue should be closed, and a bug filed upstream if necessary. I also can't see a good reason why this bug would be specific to OpenSolaris. Does anyone have gcc-4.4.4 available to test this on OS X, Linux or *BSD? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: I'm glad you can reproduce it! I can understand you wanting to close it in this case. I've no problem with that. To me at least, it does not seem anywhere near as serious as the other problem. I will try it on Linux though. I have access to reasonably decent (24 core) Linux box, so I'll try it on that. But it means a lot of messing around, downloading mpir, mpfr, possibly newer versions of the GNU binutils etc. Not a 5 minute job. The weather here in the UK is too nice to site behind a computer screen! Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment:
Here's some minimal failing code.
// Compile with:
// gcc-4.4 -m64 -fno-inline -g -O3 copysign_bug.c -o copysign_bug
#include math.h
#include stdio.h
int copysign_bug(double x)
{
if (x (x * 0.5 == x))
return 1;
if (copysign(1.0, x) 0.0)
return 2;
else
return 3;
}
int main(void) {
double x;
x = -0.0;
printf(copysign_bug(%.17g) = %d\n, x, copysign_bug(x));
x = 0.0;
printf(copysign_bug(%.17g) = %d\n, x, copysign_bug(x));
return 0;
}
This produces the output:
copysign_bug(-0) = 3
copysign_bug(0) = 3
I would expecting to see:
copysign_bug(-0) = 2
copysign_bug(0) = 3
I've reported this at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44683
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Stefan Krah stefan-use...@bytereef.org added the comment: Mark, gcc-4.4 on Fedora 12 is ok: [ste...@fedora-amd64 trunk]$ ./python Python 2.7rc2+ (trunk:82245M, Jun 26 2010, 13:09:14) [GCC 4.4.3 20100127 (Red Hat 4.4.3-4)] on linux2 Type help, copyright, credits or license for more information. (-0.0).hex() '-0x0.0p+0' As a general remark, from what I hear on the gmp-bugs list, the newer gcc versions often seem to have problems on Solaris. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Stefan Krah stefan-use...@bytereef.org added the comment: Fedora 12: copysign-bug varies wildly ((GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)): [ste...@fedora-amd64 trunk]$ gcc -O0 copysign_bug.c -o copysign_bug [ste...@fedora-amd64 trunk]$ ./copysign_bug copysign_bug(-0) = 2 copysign_bug(0) = 3 [ste...@fedora-amd64 trunk]$ gcc -O2 copysign_bug.c -o copysign_bug [ste...@fedora-amd64 trunk]$ ./copysign_bug copysign_bug(-0) = 3 copysign_bug(0) = 3 [ste...@fedora-amd64 trunk]$ gcc -O3 copysign_bug.c -o copysign_bug [ste...@fedora-amd64 trunk]$ ./copysign_bug copysign_bug(-0) = 2 copysign_bug(0) = 3 [ste...@fedora-amd64 trunk]$ gcc -O3 -fno-inline copysign_bug.c -o copysign_bug [ste...@fedora-amd64 trunk]$ ./copysign_bug copysign_bug(-0) = 3 copysign_bug(0) = 3 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: Thanks Stefan. The bug apparently exists in gcc-4.5 on OS X as well. I'll update the gcc bug report. newton:~ dickinsm$ gcc-mp-4.5 -fno-inline -O3 copysign_bug.c -o copysign_bug ./copysign_bug copysign_bug(-0) = 3 copysign_bug(0) = 3 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: Did you have a chance to try a debug build of Python and see if the problem persists there? I'm failing to reproduce this in OpenSolaris 2009.06, running in Parallels on a MacBook Pro (non-debug 32-bit build of Python): dicki...@eratosthenes:~/release26-maint$ uname -a SunOS eratosthenes 5.11 snv_111b i86pc i386 i86pc Solaris dicki...@eratosthenes:~/release26-maint$ cat /etc/release OpenSolaris 2009.06 snv_111b X86 Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 07 May 2009 dicki...@eratosthenes:~/release26-maint$ ./python Python 2.6.5+ (release26-maint:82213, Jun 25 2010, 00:52:22) [GCC 3.4.3 (csl-sol210-3_4-20050802)] on sunos5 Type help, copyright, credits or license for more information. float.hex(-0.0) '-0x0.0p+0' import sys; sys.maxsize 2147483647 The most noticeable difference from the machines you describe here is the compiler. (Did you build gcc 4.4.4 by hand on these machines, or is there a package I can download and install somewhere?) I'd still like to understand *how* the -c99 compiler option affects copysign; it might help inform a workaround. The library function itself can't know how you compiled Python, surely? Can you work out what's going on from the relevant header files? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: So perhaps the cause is simply that copysign isn't being declared for David's Python builds? If that were the case, I'd expect to see some gcc warnings in the Python build output, something like: warning: implicit declaration of function `copysign' David, are there any such warnings? Looking at /usr/include/math.h in my OpenSolaris VM, I see (with irrelevant bits omitted): #if defined(__EXTENSIONS__) || defined(_XOPEN_SOURCE) || \ !defined(_STRICT_STDC) !defined(_POSIX_C_SOURCE) #if defined(__EXTENSIONS__) || !defined(_XOPEN_SOURCE) extern double copysign __P((double, double)); #endif #endif Assuming that this is the cause, it would be interesting to know which of these defines differs between my OpenSolaris VM and David's machines. (e.g., the 'hawk' machine, since this seems closest in spec to what I'm working with). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: David, my pyconfig.h file contains: /* Defined on Solaris to see additional function prototypes. */ #define __EXTENSIONS__ 1 Does yours? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: Now that I've finally managed to get gcc 4.4.4 installed on OpenSolaris... .. I'm still failing to reproduce this bug. :( dicki...@eratosthenes:~/release26-maint$ uname -a SunOS eratosthenes 5.11 snv_134 i86pc i386 i86pc Solaris dicki...@eratosthenes:~/release26-maint$ cat /etc/release OpenSolaris Development snv_134 X86 Copyright 2010 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 01 March 2010 dicki...@eratosthenes:~/release26-maint$ ./python Python 2.6.4 (release26-maint:75706, Jun 25 2010, 21:44:19) [GCC 4.4.4] on sunos5 Type help, copyright, credits or license for more information. float.hex(-0.0) '-0x0.0p+0' import sys; sys.maxint 2147483647 As far as I can tell, this setup is almost identical to David's 'hawk' machine (same gcc version, same OpenSolaris build, same Python source revision). I'm not really sure where I can go from here. Stefan, you're not able to reproduce this by any chance, are you? -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Stefan Krah stefan-use...@bytereef.org added the comment: Mark Dickinson rep...@bugs.python.org wrote: Now that I've finally managed to get gcc 4.4.4 installed on OpenSolaris... .. I'm still failing to reproduce this bug. :( dicki...@eratosthenes:~/release26-maint$ uname -a SunOS eratosthenes 5.11 snv_134 i86pc i386 i86pc Solaris dicki...@eratosthenes:~/release26-maint$ cat /etc/release OpenSolaris Development snv_134 X86 Copyright 2010 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 01 March 2010 dicki...@eratosthenes:~/release26-maint$ ./python Python 2.6.4 (release26-maint:75706, Jun 25 2010, 21:44:19) [GCC 4.4.4] on sunos5 Type help, copyright, credits or license for more information. float.hex(-0.0) '-0x0.0p+0' import sys; sys.maxint 2147483647 As far as I can tell, this setup is almost identical to David's 'hawk' machine (same gcc version, same OpenSolaris build, same Python source +revision). I'm not really sure where I can go from here. Stefan, you're not able to reproduce this by any chance, are you? No, I'm getting the same results as you (OpenSolaris/qemu/32-bit/gcc). I wonder if it's somehow related to issue 7281, which was resolved by changing float_repr_style. But as I said, I cannot reproduce it with either gcc or suncc. On the other hand, who knows how the FPU is emulated in qemu. The C standard is diplomatic as usual: On implementations that represent a signed zero but do not treat negative zero consistently in arithmetic operations, the copysign functions regard the sign of zero as positive. David, one of your comments implied for me that you have managed to compile Python with -std=c99. For me, this fails instantly. What options did you use? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment:
Hi,
I had hoped to devote more time to this, but have been able to. I will do at
the weekend.
I would add I was building 64-bit, so adding the compiler flag -m64 on 'hawk'
at least some of the time. Depending on your hardware, assuming you have
installed !OpenSolaris as a Virtual machine in VirtualBox, it may be a 32 or
64-bit version of OpenSolaris. You need specific instructions from the
processor for a 64-bit version and Sony in their infinite wisdom have disabled
it on my Vaio laptop, so whilst I can install OpenSolaris as a 64-bit host
operating system, any attempt to install a 64-bit guest will fail.
If I don't chose to compile C99, then I need to add the compiler flag
-DHAVE_DECL_ISFINITE=0.
Otherwise I see:
Objects/object.c:1036: warning: implicit declaration of function 'isinf'
Undefined first referenced
symbol in file
isfinite./libpython2.6.so
ld: fatal: symbol referencing errors. No output written to python
Again, the Solaris man page says:
Mathematical Library Functions isfinite(3M)
NAME
isfinite - test for finite value
SYNOPSIS
c99 [ flag... ] file... -lm [ library... ]
#include math.h
int isfinite(real-floating x);
implying this is a C99 function.
This conflicting behavior could be the result of what linker or assembler is
being used. On SPARC, I use Sun linker and assembler. On OpenSolaris I use the
Sun linker, but the GNU assembler.
I would have thought it was better to test this out with small bits of test
code like I posted, rather than the complete Python source code.
It might be better if I just create you an account on 'hawk'. Drop me an email
at david dot kirkby {at} onetel |dot| net if you want.
I can also get you an account at the University of Washington if you want on a
Sun T5240 SPARC. I've not verified the problem on that machine, but I can do
so. Just drop me an email with a preferred user name and I'll sort it out.
The SPARC is very slow - despite it being a current model of a high end server.
It is designed for a different sort of task to developing software. The CPUs
are pretty slow (1167 MHz) and pretty dumb, but there are 128 hardware threads.
In order to get any useful performance from the T5240, the code needs to be
highly parallel or have lots of processes like on busy web servers. That is
what 't2' is designed for - a high end web server.
But 'hawk' is a pretty high spec PC which I run 24/7.
Dave
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
New submission from Mark Dickinson dicki...@gmail.com: Comment from David Kirkby in issue 8265; moved here because it looks like a separate problem. I'm seeing this failure on both Solaris 10 (SPARC processor) in 32-bit mode and OpenSolaris 06/2009 (Intel Xeon) in 64-bit mode using Python 2.6.4. So it is not just an ARM Linux issue. See http://trac.sagemath.org/sage_trac/ticket/9297 http://trac.sagemath.org/sage_trac/ticket/9299 Note, Solaris supports both a 32 and 64-bit ABI. Not sure if that is relevant, but I see ABI in the title, so perhaps it might be. -- assignee: mark.dickinson components: Extension Modules messages: 108532 nosy: drkirkby, mark.dickinson priority: normal severity: normal stage: needs patch status: open title: test_float failure on Solaris type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment:
And the text of the failure (from the first link David provides):
test test_float failed -- Traceback (most recent call last):
File
/export/home/drkirkby/sage-4.4.4.alpha1/spkg/build/python-2.6.4.p9/src/Lib/test/test_float.py,
line 765, in test_roundtrip
self.identical(-x, roundtrip(-x))
File
/export/home/drkirkby/sage-4.4.4.alpha1/spkg/build/python-2.6.4.p9/src/Lib/test/test_float.py,
line 375, in identical
self.fail('%r not identical to %r' % (x, y))
AssertionError: -0.0 not identical to 0.0
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment:
David, would it be possible for you to provide the results of:
float.hex(-0.0)
float.fromhex('-0x0.0p+0')
on those platforms, so that we can tell whether it's the float - hex
conversion or the hex - float conversion that's losing the sign of the zero?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: David, please could you also tell me whether HAVE_COPYSIGN is defined for those builds of Python? It should be in pyconfig.h in the top level of the build directory, if it is. And (just to double check), at configure time, there should be a line in the output of the configure script that looks like checking for copysign... yes Do you get 'yes' or 'no' there? If I had to guess, I'd say that it's the float - hex conversion that's going wrong (so that (-0.0).hex() produces '0x0.0p+0' instead of '-0x0.0p+0'), and that this is caused by either a buggy system copysign function, or by the system copysign function not being found and Python using a buggy workaround. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment:
Hi Mark,
Here's the info on the two systems - first the SPARC system, secondly the Intel
Xeon system.
1) SPARC
* Sun Blade 2000, with 2 x UltraSPARC III+ 1200 MHZ processors
* 8 GB RAM
* Solaris 10 update 8 10/09 release (This is the latest release of Solaris 10).
drkir...@swan:~$ cat /etc/release
Solaris 10 10/09 s10s_u8wos_08a SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 16 September 2009
drkir...@swan:~$ uname -a
SunOS swan 5.10 Generic_141444-09 sun4u sparc SUNW,Sun-Blade-1000
Python 2.6.4 (r264:75706, Jun 24 2010, 10:39:29)
[GCC 4.4.4] on sunos5
Type help, copyright, credits or license for more information.
float.hex(-0.0)
'0x0.0p+0'
float.fromhex('-0x0.0p+0')
-0.0
When configure runs, I see:
checking for copysign... yes
In pyconfig.h I have:
/* Define to 1 if you have the `copysign' function. */
#define HAVE_COPYSIGN 1
==
==
2) Intel Xeon system.
* Sun Ultra 27, quad core 3.33 GHz Intel Xeon processor
* 12 GB RAM
* OpenSolaris 06/2009, updated to build 134
* 64-bit installation.
* Note, this is the native operating system on this machine, so VirtualBox is
not used.
drkir...@hawk:~$ cat /etc/release
OpenSolaris Development snv_134 X86
Copyright 2010 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 01 March 2010
drkir...@hawk:~$ uname -a
SunOS hawk 5.11 snv_134 i86pc i386 i86pc
Python 2.6.4 (r264:75706, Jun 24 2010, 17:38:56)
[GCC 4.4.4] on sunos5
Type help, copyright, credits or license for more information.
float.hex(-0.0)
'0x0.0p+0'
float.fromhex('-0x0.0p+0')
-0.0
When configure runs, I see:
checking for copysign... yes
In pyconfig.h I have:
/* Define to 1 if you have the `copysign' function. */
#define HAVE_COPYSIGN 1
If you feel access to the SPARC system could help you debug this (or any of the
other test failures I get), I can get you access to a machine 16-core Sun T5240
which was donated by Sun.
I can't provide such easy access to the Xeon system, though you can install
OpenSolaris as a Virtual machine in VirtualBox quite easily - its a free
download.
Dave
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment:
Thanks for the details. So the relevant code (see the float_hex function in
Objects/floatobject.c) looks like this:
if (x == 0.0) {
if(copysign(1.0, x) == -1.0)
return PyString_FromString(-0x0.0p+0);
else
return PyString_FromString(0x0.0p+0);
}
This *should* produce the correct string for -0.0 (because -0.0 compares equal
to 0.0, and then copysign(1.0, x) should be -1.0); I'm reasonably confident
that the C code is correct, since the tests pass on all the other platforms
that get tested regularly.
So a buggy system copysign function looks like a possibility. Another more
likely possibility occurs to me, though: and that's that there's a buggy
compiler optimization going on: the compiler sees that we're in an 'x == 0.0'
branch, and decides that it can substitute '0.0' for 'x' everywhere in the 'if'
block. But this is just guessing.
Do you still get these failures in a debug build of Python (i.e., by passing
--with-pydebug to the configure script)?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Just to clarify something, in case you notice something does not look quite right. The link I provided to the build failure on the SPARC machine http://trac.sagemath.org/sage_trac/ticket/9297 was a Sun Blade 1000. It is *not* the same machine from which I just copied the output, which was a Sun Blade 2000. The two machines are pretty similar though - the motherboards, processors, disks, RAM are interchangeable. In fact,'uname' shows Sun-Blade-1000 in both of them. I think the only real difference between them is that the Blade 2000 looks a bit nicer, and is officially supported with faster CPUs. The link I provided to the failure on the Xeon machine http://trac.sagemath.org/sage_trac/ticket/9299 is the same machine where I just posted the output. If you need an account on a SPARC, it will be a more modern Sun T5240 with 32 GB RAM. Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: I'll take a look at this in an hour or two. I'll restrict the testing to the Xeon machine, as it is a zillion times quicker than the old SPARCs. What comes to my mind, is that perhaps 'copysign' is only defined in C99. Solaris header files are pretty strict about what gets defined and not defined depending on the mode of compilation. The compiler option -std=c99 is not being passed yet the man page for copysign on my OpenSolaris laptop (yet another system) says: drkir...@laptop:~$ man copysign Mathematical Library Functions copysign(3M) NAME copysign, copysignf, copysignl - number manipulation func- tion SYNOPSIS c99 [ flag... ] file... -lm [ library... ] #include math.h double copysign(double x, double y); float copysignf(float x, float y); long double copysignl(long double x, long double y); DESCRIPTION These functions produce a value with the magnitude of x and the sign of y. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Using the compiler option -std=c99 allows this test to pass. Perhaps adding the macro AC_PROG_CC_C99 to autoconf to add the right compiler option might be a solution. I know Solaris headers are often quite strict, and will not define something in a header file if the right things are not defined to indicate C99. I would add, there is quite a serious problem on Solaris with _socket failing to build. http://bugs.python.org/issue8852 Unless one uses that workaround, which is not committed to the python source code yet, one can not run any tests of python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
Mark Dickinson dicki...@gmail.com added the comment: Thanks for the update. So I'm confused: when -std=c99 isn't given, where is the build finding the copysign function from? That is, why isn't there a link error when building Python? (I'm attempting to install OpenSolaris in Parallels at the moment, but it may take more time than I have available at the moment...) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment:
Hi Mark,
Since 'copysign' is in the maths library, I would not expect the link phase to
fail. Solaris does not ship with different maths libraries for C99 (one just
links to libm).
However, I would not be surprised if the behavior was ill defined if the
compiler is not C99. Certainly header files behave differently on Solaris
depending on the mode of the compiler. For example, trying to use the INFINITY
macro when the compiler is not C99 seems to work on Linux, but fails on Solaris
unless you force C99 mode with gcc -std=c99.
The following bit of code gives the same results whether one uses 'gcc' or 'gcc
-std=c99' on OpenSolaris or Linux. However, if one uses 'gcc -ansi' then the
behavior is totally different.
drkir...@hawk:~$ cat cs.c
#include stdio.h
#include math.h
int main(int argc, char **argv) {
double x, y;
/* Set x and y differently if a command line arguement is given.
This will avoid the compiler optimising the values out, as they
will not be known in advance. */
if (argc==1) { /* This will stop compiler optimising 0.0 out x */
x=1.0;
y=0.0;
} else {
x=2.0;
y=-0.0;
}
printf(copysign(%lf,%lf)=%lf\n, x, y, copysign(x, y));
}
drkir...@hawk:~$ gcc -lm cs.c
drkir...@hawk:~$ ./a.out
copysign(1.00,0.00)=1.00
drkir...@hawk:~$ ./a.out z
copysign(2.00,-0.00)=-2.00
drkir...@hawk:~$ gcc -lm -std=c99 cs.c
drkir...@hawk:~$ ./a.out
copysign(1.00,0.00)=1.00
drkir...@hawk:~$ ./a.out z
copysign(2.00,-0.00)=-2.00
Note how -ansi screws it up completely
drkir...@hawk:~$ gcc -lm -ansi cs.c
drkir...@hawk:~$ ./a.out
copysign(1.00,0.00)=0.00
drkir...@hawk:~$ ./a.out z
copysign(2.00,-0.00)=0.00
I also tried it on a Sun SPARC running a recent version of Solaris (2009
release). Again the results are the same.
I then tried it on a Solaris box running the first release of Solaris 10
(03/2005). Then one gets even stranger behavior if one defines -ansi, where the
results are almost right, but with poor rounding errors.
drkir...@redstart:~$ gcc -ansi -lm cs.c
drkir...@redstart:~$ ./a.out
copysign(1.00,0.00)=1.01
drkir...@redstart:~$ ./a.out d
copysign(2.00,-0.00)=-2.02
But in C99 mode, it works fine.
drkir...@redstart:~$ gcc -std=c99 -lm cs.c
drkir...@redstart:~$ ./a.out
copysign(1.00,0.00)=1.00
drkir...@redstart:~$ ./a.out d
copysign(2.00,-0.00)=-2.00
So I draw two conclusions.
1) 'copysign' is in the maths library, so a program which tries to link to
'copysign' will succeed.
2) The behavior of 'copysign' is ill defined unless the compiler is a C99
compiler.
I don't think you should use copysign unless the compiler is C99. Trying to
come up with a test for 'copysign' working is probably an impossible task, as
it undefined. So you could try 99 different values of x and y and they all
work, but its anyone guess what will happen with the 100th set of values.
Dave
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9069
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9069] test_float failure on Solaris
David Kirkby david.kir...@onetel.net added the comment: Just to clarify the hostnames and hardware used, in case you look at the results here or the links to the Sage maths bug tracker and are not sure what is what. Note some are Solaris and some are OpenSolaris. Some have SPARC and some have Intel processors. All machines are 64-bit, but note that by default executables are created 32-bit on Solaris and OpenSolaris. * hawk = Sun Ultra 27, 3.33 GHz quad core Xeon, OpenSolaris 06/2009, but updated to the latest build of OpenSolaris. * laptop = Sony laptop, 2.0 GHz Intel CPU core2 duo, OpenSolaris 06/2009. * swan = Sun Blade 2000, 2 x 1200 MHz SPARC processors, Solaris 10 10/2009 release (Latest release of Solaris 10 at the time I'm writing this) * redstart = Sun Blade 1000, 2 x 900 MHz SPARC processors, Solaris 10 03/2005 (First Solaris 10 release) Although I've not shows the results from them, if I do show any others, likely candidates will be * sage = x86 Linux box (Ubunta I think) 24 cores. * t2 = Sun T5240, T2+ SPARC processors, 16 cores 1167 MHz, Solaris 10 05/2009 (A recent, but not the very latest release of Solaris 10) * bsd = OS X box of some sort. * hpbox = HP C3600 running HP-UX 11.11B, PA-RISC processors. * chaffinch = Virtual machine running Solaris 10 10/2009. (Runs as a guest operating system in VirtualBox) Sometimes having access to different hardware can be useful, but it can get confusing if someone sees a lot of different host names! Dave -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9069 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
