[Huaiyu Zhu]

... 1. The -lieee is indeed the most direct cure.

On the specific platform tried. The libm errno rules changed between C89 and C99, and I'm afraid there's no errno behavior Python can rely on anymore. So I expect more changes will be needed in Python, regardless of how things turn out on this specific platform.

... 2. Is there a configure option to guarantee -lieee?

If anyone can answer this question, please don't answer it here: it will just get lost. Attach it to Huaiyu's bug report instead: <http://sf.net/tracker/?func=detail&aid=525705&group_id=5470&atid=105470> Thanks.

... 3. errno 34 (or -lieee) may not be the sole reason.

On a RedHat 6.1 upgraded to 7.1 (both gcc and glibc), errno 34 is indeed raised in a C program linked without -lieee, and Python is indeed compiled without -lieee, but Python does not raise OverflowError.

I expect you're missing something. Skip posted the Python code before, and if errno gets set, Python *does* raise OverflowError: errno = 0; /* Skip forgot to post this line, and it's important */ ... ix = pow(iv, iw); ... if (errno != 0) { /* XXX could it be another type of error? */ PyErr_SetFromErrno(PyExc_OverflowError); return NULL; If you can read C, believe your eyes <wink>. What you may be missing is what an utter mess C is here. How libm behaves may depend on compiler options, linker options, global system flags, and even options set for other libraries you link with.

... 4. Is there an easier way to debug such problems?

The cause was obvious to the first person (Skip) who stepped into Python to see what the code did on a platform where it failed. It's not going to be obvious to someone who doesn't.

5. How is 1e200**2 handled?

It goes through exactly the same code.

Since both 1e-200**2 and 1e200**2 produce the same errno all the time, but Python still raises OverflowError for 1e200**2 when linked with -lieee, there must be a separate mechanism at work.

You're speculating from a false base: if platform pow(x, y) sets errno to any non-zero value, Python x**y raises OverflowError. What differs is when platform pow(x, y) does not set errno. In that case, Python synthesizes errno=ERANGE if the pow() result equals +- platform HUGE_VAL.

What is that and how can I override it?

Sorry, you can't override it.

I know this is by design, but I think the design is dumb (to put it politely). I won't get into an argument here. I'll write up my rationale against this when I have some time.

I'm afraid a rationale won't do any good. I'm in favor of supplying full 754 compatibility myself, but: A) Getting from here to there requires volunteers to design, implement, document, and test the code. Given the atrocious state of C's 754 story, and the subtlety of 754's requirements, this needs volunteers who are both 754 experts and platform C experts. That combination is rare. B) Python's floating-point users will never agree it's a good thing, so such a change requires careful backward compatibility work too. This isn't likely to get done by someone who characterizes the other side as "dumb (to put it politely)" <0.9 wink>. Note that the only significant floating-point code ever contributed to the Python core was the fpectl module, and its purpose is to *break* 754 "non-stop" exception semantics in the places Python happens to let them sneak through.

I do remember there being several discussions in the past, but I don't remember any convincing argument for the current decision. Any URL would be greatly appreciated, beside the one pointed by Tim.

Which "current decision" do you have in mind? There is no design doc for Python's numerics, if that's what you're looking for. As the text at the URL I gave you said, much of Python's fp behavior is accidental, inherited from platform C quirks.