On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs-
2.91.66, python 2.2.1c2. I build python
from source and test_struct.py dies with
a floating point exception. I believe I've
found out why:


>>> import struct
>>> s = struct.pack("d", 3.14e20)
>>> struct.unpack("d", s)
(1.69270791053e-307,)

Logged In: YES 
user_id=6656

Hmm, that looks broke.

However, I don't see this behaviour on sf's compile farm with 
221c1; I'm building 221c2 now, but I'd be amazed if it's 
different.

That machine has kernel 2.4.something and gcc 2.95.something, 
so is it possible that this is a now-fixed bug in one those 
(most likely the compiler)?

Logged In: YES 
user_id=503643

I also tried this on RH7.*/alpha/2.4.something kernel
and gcc 2.95.something and got the same error. Actually,
it started with test_struct.py core dumping. I don't
actually need to pack doubles. I was just being a good
doobie.

Logged In: YES 
user_id=503643

I also tried this on RH7.*/alpha/2.4.something kernel
and gcc 2.95.something and got the same error. Actually,
it started with test_struct.py core dumping. I don't
actually need to pack doubles. I was just being a good
doobie.

Logged In: YES 
user_id=6656

Oh.  That means it might be our fault.  Damn.

Erm, clutching at straws: what flavour of alpha is this?  I'm 
guessing this is some kind of alignment problem.

Logged In: YES 
user_id=503643

EV6 I think. Can I run a command to find out?

Logged In: YES 
user_id=31435

Can you show what's in s?  As is, it's impossible to guess 
whether the problem is in pack() or unpack().  Life would 
be simpler if you started with a simpler float too (like, 
say, 1.0).

Something random that might help:  recompile structmodule.c 
with optimization turned off.

One other:  is this Alpha configured to run in big-endian 
or little-endian mode?

Logged In: YES 
user_id=6380

- Does the same error occur in earlier versions (2.2,
2.1.2)?

- I'm relabeling this as platform-specific because it only
fails on alphas (not the world's most popular CPU
architecture).

Logged In: YES 
user_id=539787

I think it is something that might have been solved by patch
601369.  carifio, can you try downloading the latest
Modules/structmodule.c and try again?

Logged In: YES 
user_id=33168

This same problem exists in the snake farm (RedHat 6.2/alpha
egcs 2.91.66).  It turned out to be a compiler bug.  Turning
optimization off fixed the problem.  Unless I hear
otherwise, I will close this bug report.

Logged In: YES 
user_id=31435

Is our evidence that it's a compiler bug solely that turning 
optimization off made the problem go away?  If so, that's a 
good clue but not definitive.  It could be that Python's C 
code is ill-defined in such a way that optimizing or not 
changes which kind of undefined behavior obtains.  To nail 
this really requires determining exactly which piece of the 
Python code changed behavior.  This may not be easy, and 
in some cases may even require digging into the generated 
machine code.

Logged In: YES 
user_id=33168

> Is our evidence that it's a compiler bug solely that turning
> optimization off made the problem go away?

Yes.  The test is failing right now:

http://www.lysator.liu.se/xenofarm/python/files/2437_6/testlog.txt

I built the test normally and got the same failure.  I built
python with -O0 and the test passed.

Python's code may have had a problem.  On 9/3/2002, rev 2.57
to Module/structmodule.c changed to use memcpy "to avoid
alignment errors."  That was from patch 601369 which
appeared to be necessary for MIPS.

The same code does work on a different alpha, running a
different kernel, different glibc, and different compiler. 
(It works with optimization.)

http://www.lysator.liu.se/xenofarm/python/files/2479_31/testlog.txt

Suggestions?

Logged In: YES 
user_id=31435

You have to be really interested to track one of these 
down.  I started asking leading questions in April, but 
didn't get a response.  If nobody who runs on Alphas is 
interested enough to help, the heck with it.