Python 2.1 on SGI

[Tim Peters]

[RajGopal Srinivasan]
> 	Curiously, one can compile with optimization and not have a
> SIGBUS if the CONVERT_TO_DOUBLE macro is slightly modified as
> follows:
> [snip]

[Pete Forman]
> This does not surprise me.  IRIX, or rather the MIPS CPU, has some of
> the strictest alignment requirements.  Doubles have to be stored on 8
> byte boundaries.  Other CPUs such as x86 (Linux, Win32) or POWER (AIX)
> have no restrictions on how doubles are aligned.  SPARC (Solaris) can
> be aligned to 1, 2, 4 or 8 byte boundaries depending on compiler and
> linker options.
>
> Programs which do their own structure management have to be aware of
> these issues.  A typical example is allocating an array of char and
> then storing a double somewhere in it.

If Python ever does something like that, we would consider it a bug in
Python.  The Python implementation never tries to outguess native platform
alignment rules (all doubles are declared as doubles, all longs as longs,
pointers to one type aren't cast to pointers of another type that *could*
require stricter alignment, etc).

It's possible we screwed up somewhere, but there's no real evidence of that.
If you find any, please point it out.

The first response to every SGI bug report has always been "try it with
optimization off", and that's almost invariably made the SGI problem du jour
go away.  If it were in fact random, I'd expect that sometimes compiling the
whole thing with optimmzation off would trigger *new* SIGBUS (or other)
problems; but in practice, it never has.  What seems to be the case instead
is that SGI does unusually aggressive optimization, and doesn't always do it
right.