
Hi,
Since r5443 the Sparc buildbots show a "Bus error" in the test phase:
http://buildbot.scipy.org/builders/Linux_SPARC_64_Debian/ builds/102/steps/shell_2/logs/stdio
while the one on FreeBSD-64 passes.

On Thu, Jul 17, 2008 at 03:19, Pauli Virtanen pav@iki.fi wrote:
Hi,
Since r5443 the Sparc buildbots show a "Bus error" in the test phase:
http://buildbot.scipy.org/builders/Linux_SPARC_64_Debian/
builds/102/steps/shell_2/logs/stdio
while the one on FreeBSD-64 passes.
In the test that's failing (test_filled_w_flexible_dtype), a structured array with a dtype of [('i',int), ('s','|S3'), ('f',float)] is created. I'm guessing that the final C double in that record is not getting aligned properly. On that architecture, I'm willing to bet that doubles need to be aligned on a 4-byte or 8-byte boundary. Can someone on that architecture try this for me?
In [4]: from numpy import dtype
In [5]: dtype([('i',int), ('s','|S3'), ('f',float)]).fields.items() Out[5]: [('i', (dtype('int32'), 0)), ('s', (dtype('|S3'), 4)), ('f', (dtype('float64'), 7))]

On Thu, Jul 17, 2008 at 03:51, Robert Kern robert.kern@gmail.com wrote:
On Thu, Jul 17, 2008 at 03:19, Pauli Virtanen pav@iki.fi wrote:
Hi,
Since r5443 the Sparc buildbots show a "Bus error" in the test phase:
http://buildbot.scipy.org/builders/Linux_SPARC_64_Debian/
builds/102/steps/shell_2/logs/stdio
while the one on FreeBSD-64 passes.
In the test that's failing (test_filled_w_flexible_dtype), a structured array with a dtype of [('i',int), ('s','|S3'), ('f',float)] is created. I'm guessing that the final C double in that record is not getting aligned properly. On that architecture, I'm willing to bet that doubles need to be aligned on a 4-byte or 8-byte boundary.
I think this is the case. Changing the dtype to use |S8 fixes that test. I get another bus error where the same dtype is used. I've changed these over in r5445 and r5446. We'll see if the buildbots pass, but I suspect they will. I'm not sure where the real bug is, though. We'll need real access to such a machine to fix the problem, I suspect. Volunteers?

On Thu, Jul 17, 2008 at 10:51 AM, Robert Kern robert.kern@gmail.com wrote:
On Thu, Jul 17, 2008 at 03:19, Pauli Virtanen pav@iki.fi wrote:
Hi,
Since r5443 the Sparc buildbots show a "Bus error" in the test phase:
http://buildbot.scipy.org/builders/Linux_SPARC_64_Debian/
builds/102/steps/shell_2/logs/stdio
while the one on FreeBSD-64 passes.
In the test that's failing (test_filled_w_flexible_dtype), a structured array with a dtype of [('i',int), ('s','|S3'), ('f',float)] is created. I'm guessing that the final C double in that record is not getting aligned properly. On that architecture, I'm willing to bet that doubles need to be aligned on a 4-byte or 8-byte boundary.
The Sparc ABI requires that doubles be aligned on a 4-byte boundary. However, gcc uses instructions which require 8-byte alignment of doubles on SPARC by default - there are a couple of flags which can be used to force 4-byte alignment, but that imposes a (usually significant) speed penalty. AFAIK, the Solaris compilers also require 8-byte alignment for doubles.
In [4]: from numpy import dtype
In [5]: dtype([('i',int), ('s','|S3'), ('f',float)]).fields.items() Out[5]: [('i', (dtype('int32'), 0)), ('s', (dtype('|S3'), 4)), ('f', (dtype('float64'), 7))]
os.uname()[4]
'sparc64'
from numpy import dtype dtype([('i',int), ('s','|S3'), ('f',float)]).fields.items()
[('i', (dtype('int32'), 0)), ('s', (dtype('|S3'), 4)), ('f', (dtype('float64'), 7))]

On Thu, Jul 17, 2008 at 3:51 AM, Neil Muller <drnlmuller+scipy@gmail.comdrnlmuller%2Bscipy@gmail.com> wrote:
On Thu, Jul 17, 2008 at 10:51 AM, Robert Kern robert.kern@gmail.com wrote:
On Thu, Jul 17, 2008 at 03:19, Pauli Virtanen pav@iki.fi wrote:
Hi,
Since r5443 the Sparc buildbots show a "Bus error" in the test phase:
http://buildbot.scipy.org/builders/Linux_SPARC_64_Debian/
builds/102/steps/shell_2/logs/stdio
while the one on FreeBSD-64 passes.
In the test that's failing (test_filled_w_flexible_dtype), a structured array with a dtype of [('i',int), ('s','|S3'), ('f',float)] is created. I'm guessing that the final C double in that record is not getting aligned properly. On that architecture, I'm willing to bet that doubles need to be aligned on a 4-byte or 8-byte boundary.
The Sparc ABI requires that doubles be aligned on a 4-byte boundary. However, gcc uses instructions which require 8-byte alignment of doubles on SPARC by default - there are a couple of flags which can be used to force 4-byte alignment, but that imposes a (usually significant) speed penalty. AFAIK, the Solaris compilers also require 8-byte alignment for doubles.
In [4]: from numpy import dtype
In [5]: dtype([('i',int), ('s','|S3'), ('f',float)]).fields.items() Out[5]: [('i', (dtype('int32'), 0)), ('s', (dtype('|S3'), 4)), ('f', (dtype('float64'), 7))]
os.uname()[4]
'sparc64'
from numpy import dtype dtype([('i',int), ('s','|S3'), ('f',float)]).fields.items()
[('i', (dtype('int32'), 0)), ('s', (dtype('|S3'), 4)), ('f', (dtype('float64'), 7))]
I wonder what descr->alignment is for doubles on SPARC.
Chuck
participants (4)
-
Charles R Harris
-
Neil Muller
-
Pauli Virtanen
-
Robert Kern