classification
Title: math test fails on Solaris 10
Type: behavior Stage:
Components: Tests Versions: Python 3.0, Python 3.1, Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: MrJean1, loewis, mark.dickinson, skip.montanaro, terry.reedy
Priority: high Keywords: patch

Created on 2008-06-21 21:47 by MrJean1, last changed 2008-12-11 22:06 by mark.dickinson. This issue is now closed.

Files
File name Uploaded Description Edit
math_log.patch mark.dickinson, 2008-12-06 16:52 Possible fix for math.log and math.log10 failures
Python-2.6.1-32bit-Solaris10-math_patch.log MrJean1, 2008-12-09 21:03
Python-2.6.1-64bit-Solaris10-math_patch.log MrJean1, 2008-12-09 21:04
Messages (47)
msg68548 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-21 21:47
There are 2 math test failures with 32-bit Python 2.6b1 and 3.0b1 on 
Solaris 10 both built with Sun's C compiler.  The failures do *not* 
occur for the 64-bit builds.  The same compiler options are used for all 
these builds (except -xtarget=native vs -xtarget=native64).
 

======================================================================
FAIL: testLog (__main__.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_math.py", line 419, in testLog
    self.assertRaises(ValueError, math.log, NINF)
AssertionError: ValueError not raised

======================================================================
FAIL: testLog10 (__main__.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_math.py", line 441, in testLog10
    self.assertRaises(ValueError, math.log10, NINF)
AssertionError: ValueError not raised

----------------------------------------------------------------------
msg68560 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-22 08:19
I'll take a look.
msg68561 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-22 08:32
Could you tell me what

>>> import math
>>> math.log(float('-inf'))

gives instead of the expected ValueError?
msg68594 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-22 23:01
Here is that in from 32- and 64-bit Python 2.6b1:

> ./python (32-bit)
Python 2.6b1 (r26b1:64398, Jun 20 2008, 09:20:49) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.log(float('-inf'))
-inf
>>> math.log(float('inf'))
inf
>>> math.log(float('nan'))
nan

> ./python (64-bit)                  
Python 2.6b1 (r26b1:64398, Jun 19 2008, 20:27:39) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.log(float('-inf'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error
>>> math.log(float('inf'))         
inf
>>> math.log(float('nan'))
nan

Look like a Sun issue, doesn't it?
msg68624 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-23 12:30
Judging by the information at

http://docs.sun.com/app/docs/doc/802-1930-03/6i5u95u0i?
l=en&a=view&q=matherr

this behaviour is intentional.  It looks like log(-inf)
sets errno = EDOM and returns -inf.  An IEEE 754
conforming math library would return NaN instead.

I've no idea why the 64-bit build doesn't exhibit
this problem.

math_1 in Modules/mathmodule.c bases its error reporting
primarily on return values, only looking at errno in the
case when a finite value is returned.  So it doesn't
ever take any notice of the EDOM errno value.

Unfortunately, changing this would likely cause failures
on other machines.  GNU libc is all over the place when
it comes to setting errno:  I recall finding that on one
Linux machine, of the three calls atanh(1.), log(0.) and
log10(0.), one of these sets errno = EDOM, one sets errno
= ERANGE, and one doesn't set errno at all.  (All three
calls correspond to logarithmic singularities, and should
all behave the same way.)

One obvious solution is to write a matherr function
for use on Solaris, as described on the man page
above.  Do you think you could have a
go at this?
msg68627 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-23 13:39
On second thoughts, forget about matherr---looks like it's
outdated technology.
msg68637 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-23 16:25
Here is a simple test case, demonstrating the issue.

#include <errno.h>
#include <math.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
    printf("%f %d\n", log(-HUGE_VAL), errno);
    printf("%f %d\n", log( HUGE_VAL), errno);
}

result is different for 32- and 64-bit

> cc -xtarget=native log_inf.c -lm ; a.out  
-Inf 33
Inf 33

> cc -xtarget=native64 log_inf.c -lm ; a.out
-NaN 0
Inf 0

#define EDOM 33 in /usr/include/sys/errno.h
msg68699 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-24 20:17
On Mon, Jun 23, 2008 at 5:25 PM, Jean Brouwers <report@bugs.python.org>
wrote:

> result is different for 32- and 64-bit
>
> > cc -xtarget=native log_inf.c -lm ; a.out
> -Inf 33
> Inf 33
>

That 33 for the second log call may just be the propagated errno value
from the first call.  Could you try setting errno = 0 before each of the
printf
calls?  I'd expect that log(HUGE_VAL) doesn't set errno at all.

Mark
msg68706 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-24 22:37
Right on!  With errno = 0; in between both calls:

-Inf 33
Inf 0

/Jean

On Tue, Jun 24, 2008 at 1:17 PM, Mark Dickinson <report@bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm@gmail.com> added the comment:
>
> On Mon, Jun 23, 2008 at 5:25 PM, Jean Brouwers <report@bugs.python.org>
> wrote:
>
>> result is different for 32- and 64-bit
>>
>> > cc -xtarget=native log_inf.c -lm ; a.out
>> -Inf 33
>> Inf 33
>>
>
> That 33 for the second log call may just be the propagated errno value
> from the first call.  Could you try setting errno = 0 before each of the
> printf
> calls?  I'd expect that log(HUGE_VAL) doesn't set errno at all.
>
> Mark
>
> Added file: http://bugs.python.org/file10722/unnamed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue3167>
> _______________________________________
msg68707 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-24 22:46
Mark,

Take a look at the SUN forum, there is a (long) answer.

<http://forum.java.sun.com/thread.jspa?threadID=5308106&tstart=0>

/Jean

On Tue, Jun 24, 2008 at 3:37 PM, Jean Brouwers <report@bugs.python.org> wrote:
>
> Jean Brouwers <MrJean1@Gmail.com> added the comment:
>
> Right on!  With errno = 0; in between both calls:
>
> -Inf 33
> Inf 0
>
> /Jean
>
> On Tue, Jun 24, 2008 at 1:17 PM, Mark Dickinson <report@bugs.python.org> wrote:
>>
>> Mark Dickinson <dickinsm@gmail.com> added the comment:
>>
>> On Mon, Jun 23, 2008 at 5:25 PM, Jean Brouwers <report@bugs.python.org>
>> wrote:
>>
>>> result is different for 32- and 64-bit
>>>
>>> > cc -xtarget=native log_inf.c -lm ; a.out
>>> -Inf 33
>>> Inf 33
>>>
>>
>> That 33 for the second log call may just be the propagated errno value
>> from the first call.  Could you try setting errno = 0 before each of the
>> printf
>> calls?  I'd expect that log(HUGE_VAL) doesn't set errno at all.
>>
>> Mark
>>
>> Added file: http://bugs.python.org/file10722/unnamed
>>
>> _______________________________________
>> Python tracker <report@bugs.python.org>
>> <http://bugs.python.org/issue3167>
>> _______________________________________
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue3167>
> _______________________________________
>
msg68719 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-25 09:05
Nice reply from zal.  His conclusion:

> The short answer to your question is to use the cc -xlibmieee
> option (and not rely on errno in the case of log(-Inf)) if you
> would like to see results in the spirit of IEEE 754.

It sounds like using the -xlibmieee flag is the way to go.  (math_1 is 
already doing an excellent job of not relying on errno).

Could you try compiling with this flag to see whether it fixes the 
problem?  (Opening up the 'configure' file and adding the flag to 
BASECFLAGS might be the easiest way to do this; there may be easier 
ways.) If it does, I'll cook up a configure patch.
msg68762 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-25 23:33
Unless I am doing something wrong, that flag does not fix the problem.

#include <errno.h>
#include <math.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
    errno = 0;
    printf("%f %d\n", log(-HUGE_VAL), errno);
    errno = 0;
    printf("%f %d\n", log( HUGE_VAL), errno);
}

/* result is different for 32- and 64-bit

> rm a.out; cc -xtarget=native -xlibmieee log_inf.c -lm ; a.out
-NaN 33
Inf 0

> rm a.out ; cc -xtarget=native64 -xlibmieee log_inf.c -lm ; a.out
-NaN 0
Inf 0

#define EDOM 33 in /usr/include/sys/errno.h

*/
msg68763 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-25 23:55
Sorry, the flag *does* make a difference.  Ignoring errno, the results for 
32- and 64-bit do match.
msg68836 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2008-06-27 17:25
Does that mean that both do the right thing or the wrong thing?
msg68837 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-27 17:50
The 64-bit version did the right thing, all along.  The 32-bit result is 
correct only when compiled with option -xlibmieee.

But the latter sets errno value to EDOM and that should be 0, rather 
remain unmodified.
msg68849 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-27 20:19
Jean,

Could you try the attached patch and see if it fixes the problem?

And I'd welcome comments from others on the patch---I'm not much of an 
autoconf hacker.
msg68867 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-28 01:08
The patch <http://bugs.python.org/file10754/issue3167.patch> does not 
work.  The -xlibmieee flag is included in the cc command lines, like

cc -c -xtarget=native -xlibmieee -DNDEBUG -xO5  -I. ....

However, the resulting build produces to wrong result:

Python 2.6b1 (r26b1:64398, Jun 27 2008, 18:04:19) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.log(float('-inf'))
-inf
msg68870 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-28 08:51
> However, the resulting build produces to wrong result:

Darn.  That's probably because the linker needs the extra flag as well.

Here's a revised patch for you to try.  (You might need to do an "svn up"
before it applies cleanly...)
msg68878 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-28 16:39
Keep in mind also, these Python builds are compiled with the SUN 
compilers, i.e. the ./configure command line includes  --without-gcc.  
If we do change the CC- and LINKFLAGS, those changes should only apply 
in that particular case.

Using -xlibmieee in 3 places, BASECFLAGS, LDFLAGS and LDSHARED and 
without optimization produces the following for 32-bit:

Python 2.6b1 (r26b1:64398, Jun 28 2008, 10:31:27) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.

>>> import cmath
>>> cmath.log(100.0)
(4.6051701859880918+0j)
>>> cmath.log(2.0)
(0.69314718055994529+0j)
>>> cmath.log(100.0, 2.0)
(6.6438561897747253+0j)

>>> import math
>>> math.log(float('-inf'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error
msg68880 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-28 16:48
The 32-but results are the same when built with -xO5.

Python 2.6b1 (r26b1:64398, Jun 28 2008, 10:43:53) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> cmath.log(100.0)
(4.6051701859880918+0j)
>>> cmath.log(2.0)
(0.69314718055994529+0j)
>>> cmath.log(100.0, 2.0)
(6.6438561897747253+0j)

>>> import math
>>> math.log(float('-inf'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error
msg68882 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-28 17:00
> Keep in mind also, these Python builds are compiled with the SUN 
> compilers, i.e. the ./configure command line includes  --without-gcc.  
> If we do change the CC- and LINKFLAGS, those changes should only apply 
> in that particular case.

Right.  That's the purpose of the 'if's and 'case' tests in the 
configure patch.  The test "$CC"=cc should exclude these changes from 
being applied when the C compiler is gcc.

Do you happen to know which versions of Solaris support the -xlibmieee 
flag?  Is it new in Solaris 10?
msg68885 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-28 17:13
The SUN compiler versions

> cc -V
cc: Sun C 5.8 2005/10/13
usage: cc [ options] files.  Use 'cc -flags' for details
> CC -V
CC: Sun C++ 5.8 2005/10/13

Both define the following symbols:

#define __SUNPRO_C   0x580
#define __SunOS_5_10
msg68886 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-28 17:17
Okay, here's a third version of the patch.  Same as before, except
that it makes sure that LDFLAGS are included in LDSHARED.

Jean, does this patch fix the problem with math.log on 32-bit?  If so, 
I'll check it in.
msg68888 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-28 17:22
Sorry, my previous post was wrong.  The LDSHARED symbol did NOT include -
xlibmieee.  Only the BASECFLAGS and the LDFLAGS.
msg68892 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-28 18:42
I applied your patch to freshly updated configure and configure.in files 
and ran  ./configure --without-gcc on Solaris.

The resulting Makefile has empty BASECFLAGS and LDFLAGS.  Here is the 
snippet:

....
# Compiler options
OPT=            -DNDEBUG -O
BASECFLAGS=     
CFLAGS=         $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS)
# Both CPPFLAGS and LDFLAGS need to contain the shell's value for 
setup.py to
# be able to build extension modules using the directories specified in 
the
# environment variables
CPPFLAGS=       -I. -IInclude -I$(srcdir)/Include 
LDFLAGS=        
LDLAST=         
SGI_ABI=        
CCSHARED=       -Kpic
LINKFORSHARED=  
# Extra C flags added for building the interpreter object files.
CFLAGSFORSHARED=
# C flags used for building the interpreter object files
PY_CFLAGS=      $(CFLAGS) $(CPPFLAGS) $(CFLAGSFORSHARED) -DPy_BUILD_CORE
....
msg68893 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-28 19:03
Sorry---my bad.  I missed out the $ac_sys_release bit.

Patch updated again.  Jean, could you please give it one more try?
msg68903 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-28 19:53
Yep, that one works.  As before, using ./configure --without-gcc ...

....
BASECFLAGS=      -xlibmieee
CFLAGS=         $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS)
# Both CPPFLAGS and LDFLAGS need to contain the shell's value for 
setup.py to
# be able to build extension modules using the directories specified in 
the
# environment variables
CPPFLAGS=       -I. -IInclude -I$(srcdir)/Include 
LDFLAGS=         -xlibmieee
....
msg68907 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-28 20:44
Add comment to patch.
msg68911 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-28 20:56
Martin,

Do you have a moment to do a sanity check on the attached patch?  The 
aim of the patch is to add the -xlibmieee flag when compiling and 
linking on Solaris using Sun's compiler rather than gcc.  Jean Brouwers 
has confirmed that the patch fixes the test_math failure on this 
platform.

I'm not very sure of myself when it comes to messing with autoconf, so 
I'd like someone else to look this over before it gets committed.  If 
you don't have time right now, please do just assign it back to me.
msg68918 - (view) Author: Skip Montanaro (skip.montanaro) * Date: 2008-06-28 22:04
Dunno about Sun's compiler, but I get test errors on Solaris 10 using 
gcc 4.2:

======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/tuba/skipm/src/python-svn/trunk/Lib/test/test_cmath.py", 
line 338, in test_specific_values
    self.fail('OverflowError not raised in test %s' % test_str)
AssertionError: OverflowError not raised in test exp0052: 
exp(complex(710.0, 1.5))

----------------------------------------------------------------------
Ran 11 tests in 0.067s

FAILED (failures=1)
test test_cmath failed -- Traceback (most recent call last):
  File "/home/tuba/skipm/src/python-svn/trunk/Lib/test/test_cmath.py", 
line 338, in test_specific_values
    self.fail('OverflowError not raised in test %s' % test_str)
AssertionError: OverflowError not raised in test exp0052: 
exp(complex(710.0, 1.5))

======================================================================
FAIL: testLog (test.test_math.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/tuba/skipm/src/python-svn/trunk/Lib/test/test_math.py", 
line 419, in testLog
    self.assertRaises(ValueError, math.log, NINF)
AssertionError: ValueError not raised

======================================================================
FAIL: testLog10 (test.test_math.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/tuba/skipm/src/python-svn/trunk/Lib/test/test_math.py", 
line 441, in testLog10
    self.assertRaises(ValueError, math.log10, NINF)
AssertionError: ValueError not raised
msg68933 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-29 07:56
Okay---so committing this would be premature at this point.

It looks like the test_math errors are the same problem that Jean found.
Skip, does

LDFLAGS=-xlibmieee ./configure ...

do anything to alleviate the test_math errors?

The cmath problems look like a new issue.
msg68938 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-29 08:37
> LDFLAGS=-xlibmieee ./configure ...

I guess that should probably be:

LDFLAGS="-Xlinker -xlibmieee" ./configure
msg68940 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-29 08:55
Skip:  one more question.  What does

cmath.exp(710.0 + 1.5j)

give instead of the expected OverflowError?

Incidentally, the Solaris buildbot seems happy enough at the moment.  I 
wonder what the difference between Skip's machine and the buildbot is.
msg68952 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-29 15:51
For comparison, 64-bit -xO5 Python build:

Python 2.6b1 (r26b1:64398, Jun 28 2008, 12:50:06) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> cmath.exp(710.0 + 1.5j)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: math range error

>>> cmath.log(100,2)
(0.71244151439608006-2.0556716794852954j)
>>> cmath.log(complex(100,0), complex(2,0))
(0.71244151439608006-2.0556716794852954j)


64-bit -xO0 Python build:

Python 2.6b1 (r26b1:64398, Jun 28 2008, 11:02:57) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import cmath
>>> cmath.exp(710.0 + 1.5j)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: math range error

>>> cmath.log(100,2)
(6.6438561897747253+0j)
>>> cmath.log(complex(100,0), complex(2,0))
(6.6438561897747253+0j)
msg68953 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-06-29 16:14
What about this case? Should cmath not produce the same result as math:

>>> math.log(float('-inf'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error

>>> cmath.log(float('-inf'))
(inf+3.1415926535897931j)
>>> cmath.log(complex(float('-inf'), 0))
(inf+3.1415926535897931j)


This occurs in all 32- and 64-bit builds (with -xlibmieee and SUN C) on 
Solaris 10 (Opteron) and on 32-bit MacOS X 10.4.11 (Intel) built with 
gcc.
msg68954 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-06-29 16:20
> What about this case? Should cmath not produce the same result as math:

No; this is correct, I think.  Note that the cmath.log result has nonzero 
imaginary part, so can't be represented as a float.

Similarly, math.sqrt(-1) is an error, while cmath.sqrt(-1) returns a 
complex result and doesn't raise any exception.
msg68980 - (view) Author: Skip Montanaro (skip.montanaro) * Date: 2008-06-30 01:07
I tried to configure with '-Xlinker -xlibmieee' added to LDFLAGS.  Failed 
miserably.  In fact, configure complained that my compiler couldn't create 
executables, told me to look at config.log for details then logged me out 
from the machine!  It would appear gcc *really* doesn't like that 
combination:

...
configure:2676: checking for C compiler default output file name
configure:2703: gcc  -I/opt/app/nonc++/ncurses-5.6/include -
I/opt/app/nonc++/ncu
rses-5.6/include/ncurses -I/opt/app/nonc++/gdbm-1.8/include -
I/opt/app/nonc++/re
adline-4.3/include -I/opt/app/nonc++/tcl-8.4/include -
I/opt/app/nonc++/BerkleyDB
-4.3/include -L/opt/app/nonc++/ncurses-5.6/lib -R/opt/app/nonc++/ncurses-
5.6/lib
 -L/opt/app/nonc++/gdbm-1.8/lib -R/opt/app/nonc++/gdbm-1.8/lib -
L/opt/app/nonc++
/readline-4.3/lib -R/opt/app/nonc++/readline-4.3/lib -L/opt/app/nonc++/tcl-
8.4/l
ib -R/opt/app/nonc++/tcl-8.4/lib -L/opt/app/nonc++/BerkleyDB-4.3/lib -
R/opt/app/
nonc++/BerkleyDB-4.3/lib -Xlinker -xlibmieee conftest.c  >&5
/usr/ccs/bin/ld: illegal option -- x
usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] 
file(s)
        [-64]           enforce a 64-bit link-edit
        [-a]            create an absolute file
        [-b]            do not do special PIC relocations in a.out
        [-B direct | nodirect]
                        establish direct bindings, or inhibit direct binding
                        to, the object being created
...

Skip
msg69441 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-07-08 21:05
I'm pretty much out of ideas here.  Skip, if you have any time to figure 
out where the math.log call is going wrong, I'd appreciate it.  On Jean's 
machine, the problem was that the call log(-inf) to the C library's log 
function was returning -inf instead of the expected nan.

The actual function call takes place in math_1, in the line 
"r = (*func)(x)" (line 178 of Modules/mathmodule.c in the current trunk, 
r64812).  A couple of printf calls would show the inputs and outputs to 
that function.

Is /usr/bin/ccs/ld Sun's own linker?  If so, why doesn't it accept the -
xlibmieee option?  (Or maybe it does, in which case the question is why 
isn't gcc passing that option to ld properly.)
msg69443 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-07-08 21:36
Some other possibilities to try.  This page:

http://www.redhat.com/docs/wp/solaris_port/x99.html

seems to suggest that linking with -lieee, and possibly also adding the -
ffast-math gcc option, might help.
msg69450 - (view) Author: Skip Montanaro (skip.montanaro) * Date: 2008-07-09 02:02
Here's a gdb session using r64812.  gcc 4.2.2.  ldd on math.so shows:

% ldd build/lib.solaris-2.10-i86pc-2.6/math.so 
        libm.so.2 =>     /lib/libm.so.2
        libgcc_s.so.1 =>         /opt/app/nonc++/lib/libgcc_s.so.1
        libc.so.1 =>     /lib/libc.so.1

% gdb ./python 
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"
and "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.10"...
(gdb) b math_1
Function "math_1" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (math_1) pending.
(gdb) r
Starting program: /home/tuba/skipm/src/python-svn/trunk/build/python 
Python 2.6b1+ (trunk:64812M, Jul  8 2008, 20:43:40) 
[GCC 4.2.2] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> inf = float('inf')
>>> math.log(-inf)

Breakpoint 1, math_1 (arg=0x81f1fbc, func=0x805e88c <log@plt>, 
can_overflow=0)
    at /home/tuba/skipm/src/python-svn/trunk/Modules/mathmodule.c:171
171     {
(gdb) p func
$1 = (double (*)(double)) 0x805e88c <log@plt>
(gdb) n 
173             x = PyFloat_AsDouble(arg);
(gdb) n
174             if (x == -1.0 && PyErr_Occurred())
(gdb) x
0x0:    Cannot access memory at address 0x0
(gdb) p x
$2 = -inf
(gdb) n
176             errno = 0;
(gdb) n
178             r = (*func)(x);
(gdb) n
180             if (Py_IS_NAN(r)) {
(gdb) p r
$3 = -inf

Does this help?  I don't know how to tell where log@plt is resolved, but 
I suppose it probably comes from /lib/libm.so.2.  It's got a date on my 
system of Jan 22 2005.  Any idea how to tell if there's a Sun patch for 
it?

As for the /usr/ccs/bin/ld thing, it doesn't look like we are using it, 
at least not directly.  Adding the --verbose flag to the link line I get 
this output:

% gcc --verbose -L/opt/app/nonc++/ncurses-5.6/lib -
R/opt/app/nonc++/ncurses-5.6/lib -L/opt/app/nonc++/gdbm-1.8/lib -
R/opt/app/nonc++/gdbm-1.8/lib -L/opt/app/nonc++/readline-4.3/lib -
R/opt/app/nonc++/readline-4.3/lib -L/opt/app/nonc++/tcl-8.4/lib -
R/opt/app/nonc++/tcl-8.4/lib -L/opt/app/nonc++/BerkleyDB-4.3/lib -
R/opt/app/nonc++/BerkleyDB-4.3/lib  -o python                 
Modules/python.o                 libpython2.6.a -lresolv -lsocket -lnsl 
-lrt -ldl    -lm
Reading specs from /opt/app/g++lib6/gcc-4.2/lib/gcc/i386-pc-
solaris2.10/4.2.2/specs
Target: i386-pc-solaris2.10
Configured with: ../configure --prefix=/opt/app/g++lib6/gcc-4.2 --
enable-languages=c,c++,fortran,objc --disable-nls --with-included-
gettext --with-gnu-as --with-as=/usr/sfw/bin/gas --with-target-
tools=/usr/sfw/bin/ --with-gmp=/opt/app/nonc++/gmp-4.2 --with-
mpfr=/opt/app/nonc++/mpfr-2.3
Thread model: posix
gcc version 4.2.2
 /opt/app/g++lib6/gcc-4.2/libexec/gcc/i386-pc-solaris2.10/4.2.2/collect2 
-V -R/opt/app/nonc++/lib -R/opt/app/g++lib6/lib -
R/opt/app/nonc++/ncurses-5.6/lib -R/opt/app/nonc++/gdbm-1.8/lib -
R/opt/app/nonc++/readline-4.3/lib -R/opt/app/nonc++/tcl-8.4/lib -
R/opt/app/nonc++/BerkleyDB-4.3/lib -Y P,/usr/ccs/lib:/usr/lib -Qy -o 
python /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/values-Xa.o 
/opt/app/g++lib6/gcc-4.2/lib/gcc/i386-pc-solaris2.10/4.2.2/crtbegin.o -
L/opt/app/nonc++/ncurses-5.6/lib -L/opt/app/nonc++/gdbm-1.8/lib -
L/opt/app/nonc++/readline-4.3/lib -L/opt/app/nonc++/tcl-8.4/lib -
L/opt/app/nonc++/BerkleyDB-4.3/lib -L/opt/app/g++lib6/gcc-
4.2/lib/gcc/i386-pc-solaris2.10/4.2.2 -L/opt/app/g++lib6/gcc-
4.2/lib/gcc/i386-pc-solaris2.10/4.2.2/../../.. Modules/python.o 
libpython2.6.a -lresolv -lsocket -lnsl -lrt -ldl -lm -lgcc -lgcc_eh -lc 
-lgcc -lgcc_eh /opt/app/g++lib6/gcc-4.2/lib/gcc/i386-pc-
solaris2.10/4.2.2/crtend.o /usr/lib/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.482

I don't see /usr/ccs/bin/ld mentioned.

Skip
msg69452 - (view) Author: Skip Montanaro (skip.montanaro) * Date: 2008-07-09 02:45
Regarding -lieee, I don't see an ieee library on my system.

Regarding -ffast-math, while it changes the log function which is linked 
to, it doesn't appear to modify the result of math.log:

% ldd build/lib.solaris-2.10-i86pc-2.6/math.so 
        libm.so.2 =>     /lib/libm.so.2
        libgcc_s.so.1 =>         /opt/app/nonc++/lib/libgcc_s.so.1
        libc.so.1 =>     /lib/libc.so.1
% gdb ./python
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"
and "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.10"...
(gdb) b math_1
Function "math_1" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (math_1) pending.
(gdb) r
Starting program: /home/tuba/skipm/src/python-svn/trunk/build/python 
Python 2.6b1+ (trunk:64812M, Jul  8 2008, 21:40:26) 
[GCC 4.2.2] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
im>>> import math
>>> inf = float('inf')
>>> math.log(-inf)

Breakpoint 1, math_1 (arg=0x81f19bc, func=0xfee2d6a0 <log>, 
can_overflow=0)
    at /home/tuba/skipm/src/python-svn/trunk/Modules/mathmodule.c:171
171     {
(gdb) func
Undefined command: "func".  Try "help".
(gdb) p func
$1 = (double (*)(double)) 0xfee2d6a0 <log>
(gdb) n
173             x = PyFloat_AsDouble(arg);
(gdb) n
174             if (x == -1.0 && PyErr_Occurred())
(gdb) p x
$2 = -inf
(gdb) n
176             errno = 0;
(gdb) n
178             r = (*func)(x);
(gdb) n
186             else if (Py_IS_INFINITY(r)) {
(gdb) p r
$3 = -inf
msg69455 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-07-09 03:12
The /lib/libm.so.* files on my Solaris 10 (Opteron) box are equally old:

> ll /lib/libm.so*
lrwxrwxrwx 1 root  root      9 Sep  7  2006 /lib/libm.so -> libm.so.2*
-rwxr-xr-x 1 root  bin   13536 Jan 22  2005 /lib/libm.so.1
-rwxr-xr-x 1 root  bin  337804 Jan 22  2005 /lib/libm.so.2


Also, this looks like a more recent patch for the Math libraries, under 3.2:

  <http://developers.sun.com/sunstudio/downloads/express_readme.html>


Then thare are the Studio patches SUN recommended the other day:

  <http://developers.sun.com/sunstudio/downloads/patches/ss11_patches.html>

If things change after I install those, I will certainly let you know.


/Jean Brouwers
msg77147 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-12-06 16:52
Skip, Jean:

Could you try the attached patch to see if it fixes the math.log and 
math.log10 test failures.  (The patch is generated against the trunk, but 
should apply cleanly to py3k or either of the 2.6 or 3.0 maintenance 
branches.
msg77152 - (view) Author: Skip Montanaro (skip.montanaro) * Date: 2008-12-06 17:21
Mark> Could you try the attached patch to see if it fixes the math.log
    Mark> and math.log10 test failures.  (The patch is generated against the
    Mark> trunk, but should apply cleanly to py3k or either of the 2.6 or
    Mark> 3.0 maintenance branches.

Seems to work on Sol10 for me:

    % ./python Lib/test/regrtest.py -v test_math 
    test_math
    testAcos (test.test_math.MathTests) ... ok
    testAcosh (test.test_math.MathTests) ... ok
    testAsin (test.test_math.MathTests) ... ok
    testAsinh (test.test_math.MathTests) ... ok
    testAtan (test.test_math.MathTests) ... ok
    testAtan2 (test.test_math.MathTests) ... ok
    testAtanh (test.test_math.MathTests) ... ok
    testCeil (test.test_math.MathTests) ... ok
    testConstants (test.test_math.MathTests) ... ok
    testCopysign (test.test_math.MathTests) ... ok
    testCos (test.test_math.MathTests) ... ok
    testCosh (test.test_math.MathTests) ... ok
    testDegrees (test.test_math.MathTests) ... ok
    testExp (test.test_math.MathTests) ... ok
    testFabs (test.test_math.MathTests) ... ok
    testFactorial (test.test_math.MathTests) ... ok
    testFloor (test.test_math.MathTests) ... ok
    testFmod (test.test_math.MathTests) ... ok
    testFrexp (test.test_math.MathTests) ... ok
    testFsum (test.test_math.MathTests) ... ok
    testHypot (test.test_math.MathTests) ... ok
    testIsinf (test.test_math.MathTests) ... ok
    testIsnan (test.test_math.MathTests) ... ok
    testLdexp (test.test_math.MathTests) ... ok
    testLog (test.test_math.MathTests) ... ok
    testLog10 (test.test_math.MathTests) ... ok
    testLog1p (test.test_math.MathTests) ... ok
    testModf (test.test_math.MathTests) ... ok
    testPow (test.test_math.MathTests) ... ok
    testRadians (test.test_math.MathTests) ... ok
    testSin (test.test_math.MathTests) ... ok
    testSinh (test.test_math.MathTests) ... ok
    testSqrt (test.test_math.MathTests) ... ok
    testTan (test.test_math.MathTests) ... ok
    testTanh (test.test_math.MathTests) ... ok
    test_exceptions (test.test_math.MathTests) ... ok
    test_testfile (test.test_math.MathTests) ... ok
    test_trunc (test.test_math.MathTests) ... ok
    Doctest: ieee754.txt ... ok

    ----------------------------------------------------------------------
    Ran 39 tests in 0.237s

    OK
    1 test OK.

Skip
msg77452 - (view) Author: Jean Brouwers (MrJean1) Date: 2008-12-09 21:03
It looks like the patch did fix the problems.  Attached are the results 
for 32- and 64-bit Python 2.6.1 with and without the patch, all built with 
SUN's compilers on Solaris 10 (Opteron).

The math log tests failed with the 32-bit build before and passed after 
applying the patch.  The 64-bit build passed before and still passes after 
the patch.
msg77627 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-12-11 19:32
Thanks, both!

Fixed in the trunk in r67707.  I'll wait to be sure that the buildbots are 
happy, then merge to 2.6, 3.0, 3.1.
msg77634 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-12-11 22:06
Buildbots seem content.  Merged to 2.6, 3.0, 3.1.
History
Date User Action Args
2008-12-11 22:06:17mark.dickinsonsetstatus: open -> closed
resolution: fixed
messages: + msg77634
2008-12-11 19:32:15mark.dickinsonsetmessages: + msg77627
versions: + Python 3.0, Python 3.1
2008-12-11 19:14:03mark.dickinsonsetfiles: - issue3167.patch
2008-12-09 21:04:10MrJean1setfiles: + Python-2.6.1-64bit-Solaris10-math_patch.log
2008-12-09 21:03:45MrJean1setfiles: + Python-2.6.1-32bit-Solaris10-math_patch.log
messages: + msg77452
2008-12-06 17:21:06skip.montanarosetmessages: + msg77152
2008-12-06 16:52:48mark.dickinsonsetfiles: + math_log.patch
messages: + msg77147
2008-07-09 03:12:48MrJean1setmessages: + msg69455
2008-07-09 02:45:59skip.montanarosetmessages: + msg69452
2008-07-09 02:02:08skip.montanarosetmessages: + msg69450
2008-07-08 21:36:45mark.dickinsonsetmessages: + msg69443
2008-07-08 21:05:31mark.dickinsonsetmessages: + msg69441
2008-06-30 01:07:01skip.montanarosetmessages: + msg68980
2008-06-29 16:20:21mark.dickinsonsetmessages: + msg68954
2008-06-29 16:14:11MrJean1setmessages: + msg68953
2008-06-29 15:51:33MrJean1setmessages: + msg68952
2008-06-29 08:55:32mark.dickinsonsetmessages: + msg68940
2008-06-29 08:37:24mark.dickinsonsetmessages: + msg68938
2008-06-29 07:56:30mark.dickinsonsetassignee: loewis -> mark.dickinson
messages: + msg68933
2008-06-28 22:04:50skip.montanarosetnosy: + skip.montanaro
messages: + msg68918
2008-06-28 20:56:08mark.dickinsonsetassignee: mark.dickinson -> loewis
messages: + msg68911
nosy: + loewis
2008-06-28 20:44:22mark.dickinsonsetfiles: - issue3167.patch
2008-06-28 20:44:14mark.dickinsonsetfiles: + issue3167.patch
messages: + msg68907
2008-06-28 19:53:36MrJean1setmessages: + msg68903
2008-06-28 19:04:02mark.dickinsonsetfiles: - issue3167.patch
2008-06-28 19:03:51mark.dickinsonsetfiles: + issue3167.patch
messages: + msg68893
2008-06-28 18:42:03MrJean1setmessages: + msg68892
2008-06-28 17:22:39MrJean1setmessages: + msg68888
2008-06-28 17:17:13mark.dickinsonsetfiles: - issue3167.patch
2008-06-28 17:17:05mark.dickinsonsetfiles: + issue3167.patch
messages: + msg68886
2008-06-28 17:13:24MrJean1setmessages: + msg68885
2008-06-28 17:00:49mark.dickinsonsetmessages: + msg68882
2008-06-28 16:48:09MrJean1setmessages: + msg68880
2008-06-28 16:39:38MrJean1setmessages: + msg68878
2008-06-28 08:52:01mark.dickinsonsetfiles: - issue3167.patch
2008-06-28 08:51:53mark.dickinsonsetfiles: + issue3167.patch
messages: + msg68870
2008-06-28 01:08:28MrJean1setmessages: + msg68867
2008-06-27 20:19:11mark.dickinsonsetfiles: + issue3167.patch
keywords: + patch
messages: + msg68849
2008-06-27 17:50:31MrJean1setmessages: + msg68837
2008-06-27 17:25:17terry.reedysetnosy: + terry.reedy
messages: + msg68836
2008-06-25 23:55:38MrJean1setmessages: + msg68763
2008-06-25 23:33:15MrJean1setmessages: + msg68762
2008-06-25 09:05:52mark.dickinsonsetmessages: + msg68719
2008-06-24 22:46:46MrJean1setmessages: + msg68707
2008-06-24 22:37:04MrJean1setmessages: + msg68706
2008-06-24 20:18:06mark.dickinsonsetfiles: - unnamed
2008-06-24 20:17:23mark.dickinsonsetfiles: + unnamed
messages: + msg68699
2008-06-23 16:25:15MrJean1setmessages: + msg68637
2008-06-23 13:39:05mark.dickinsonsetmessages: + msg68627
2008-06-23 12:30:30mark.dickinsonsetpriority: high
messages: + msg68624
2008-06-22 23:01:26MrJean1setmessages: + msg68594
2008-06-22 08:32:56mark.dickinsonsetmessages: + msg68561
2008-06-22 08:19:53mark.dickinsonsetassignee: mark.dickinson
messages: + msg68560
nosy: + mark.dickinson
2008-06-21 21:47:19MrJean1create