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

I'll take a look.

Could you tell me what

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

gives instead of the expected ValueError?

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?

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?

On second thoughts, forget about matherr---looks like it's
outdated technology.

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

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

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\>

---

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>
> _______________________________________
>

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.

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

*/

Sorry, the flag *does* make a difference. Ignoring errno, the results for
32- and 64-bit do match.

Does that mean that both do the right thing or the wrong thing?

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.

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.

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

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...)

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

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

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?

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

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.

Sorry, my previous post was wrong. The LDSHARED symbol did NOT include -
xlibmieee. Only the BASECFLAGS and the LDFLAGS.

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
....

Sorry---my bad. I missed out the $ac_sys_release bit.

Patch updated again. Jean, could you please give it one more try?

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
....

Add comment to patch.

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.

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

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.

LDFLAGS=-xlibmieee ./configure ...

I guess that should probably be:

LDFLAGS="-Xlinker -xlibmieee" ./configure

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.

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)

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.

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.

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

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.)

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.

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

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

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

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.

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](https://github.com/python/cpython/blob/main/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

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.

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.

Buildbots seem content. Merged to 2.6, 3.0, 3.1.