Tim> None of those were reliable across platforms before, and I'm afraid Tim> there's strong reason to suspect one or more still won't work right Tim> under Mandrake Linux when Python is compiled with -O (this based on Tim> the output of a C program someone posted to c.l.py yesterday). But Tim> it's a world better than it used to be. After executing cvs update -d . ./configure make clean make OPT=-O3 I get the following output from regrtest.py regarding test_math: % ./python Lib/test/regrtest.py test_math test_math 1 test OK. This is on a Mandrake 7.1 system. Here are the bits I think are relevant to identify my environment: % cat /etc/issue.net Linux Mandrake release 7.1 (helium) Kernel 2.2.16-9mdk on an i686 % gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs gcc version 2.95.3 19991030 (prerelease) % rpm -q -a | egrep glibc glibc-devel-2.1.3-15mdk compat-glibc-5.3-2.0.7.6mdk glibc-2.1.3-15mdk If you have a C test program you'd like me to try, shoot it over. I'll be glad to run it and shoot back the results. Skip

Skip Montanaro writes:

This is on a Mandrake 7.1 system. Here are the bits I think are relevant to identify my environment:

% gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs gcc version 2.95.3 19991030 (prerelease)

AFAIK, this version of GCC was never "blessed" by the GCC maintainers and should not be being used for any production work. I think Mandrake did a bad thing by shipping this version. Not quite as bad as what RedHat did by shipping the completely not-for-general-use gcc-2.96, but nonetheless still a bad thing. When will distribution builders learn that having a higher version number is not necessarily a good thing? Why do they keep second-guessing the good advice of the GCC Steering Committee? Sigh... In any case, I don't think we should put effort into chasing down bugs that are caused by bogus C compilers. Any reports coming in from RedHat 7.0 users or Mandrake 7.1 need to be evaluated in this light.

The original source of my concern was this c.l.py post from David Cooke: http://www.deja.com/getdoc.xp?AN=680840594 He ran a little C program that Huaiyu Zhu had posted earlier in the thread. According to David's results, under "Linux-Mandrake 7.1 (glibc 2.1.3) ... without -lieee, but compiled with -O ... gcc 2.95.2.", platform exp and sqrt *never* set errno, regardless of input. In which case what Python does with the platform NaN result from math.sqrt(-1.) is an accident (and probably ends up setting errno to ERANGE itself by mistake), and an overflowing exp would let the platform +Inf result pass thru silently. So, if David's report is correct, and best I understand it you were all using 7.1 too with at least some level of optimization, it's A Mystery why CVS test_math.py succeeds on that system (its new math.sqrt(-1) test would probably fail; its new math.exp(+huge) test would almost certainly fail). I'm anal enough about this stuff that I'd try to figure out why if I had a Mandrake system, but in the cosmic scheme of things I doubt it's important enough for anyone else to burn time on.