Standard spkg requirements and SPARC future

[Volker Braun]

The new Givaro-3.7.0 has one check of its own testsuite failing on SPARC. The Sage testsuite runs without issues. Since SPARC Solaris is not a "fully supported" platform, I'll take it that this is good enough to ship in Sage? See http://trac.sagemath.org/9511

Perhaps the bigger issue is, in how far do we want to make guarantees about SPARC compatibility. For the record, the big difference to the currently "alive" processor architectures is that SPARC fails really badly on misaligned memory access. If you have a memory location that is not divisible by 8 then you get a "Bus error" signal by reading/writing a double (say) from that memory location. Most other architectures handle that transparently. Sometimes with considerable slowdown, but modern processors can often do it at the same speed. 

Given that all SPARC machines that we have access to (i.e. on skynet) aren't even supported by Solaris 11 any more, its only a matter of time until we lose the ability to test on them. And its a major hassle to try to track down bugs on them because they are glacially slow and upstream developers generally do not have access to the hardware. 

Solaris on x86, by contrast, is a reasonable system to support. Over the weekend I tried OpenIndiana (a fork of OpenSolaris), used their package manager to install a recent enough gcc (no compiling your own gcc required), and built Sage successfully. 

[Jeroen Demeyer]

On 2012-06-25 14:25, Volker Braun wrote:
> The new Givaro-3.7.0 has one check of its own testsuite failing on
> SPARC.

> The Sage testsuite runs without issues.

Does this indicate a lack of doctests in Sage, or is the failure in a
feature which isn't used by Sage?

[Volker Braun]

On Monday, June 25, 2012 1:48:33 PM UTC+1, Jeroen Demeyer wrote:

> The Sage testsuite runs without issues.
Does this indicate a lack of doctests in Sage, or is the failure in a
feature which isn't used by Sage?

I don't know. Anybody who knows exactly which parts of Givaro we use is welcome to look at the strack trace at

 http://trac.sagemath.org/9511

[Martin Albrecht]

We're definitely underusing Givaro, we're only using it for finite fields <
2^16. Incidentally, the SIGSEGV is in GFqDom which implements these finite
fields < 2^16. We don't use the stuff further up the backtrace (givarray), but
I don't know whether this is relevant.

Also, we instantiate GFqDom with int while the backtrace uses long, again, not
sure it's relevant.

Cheers,
Martin

--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
_www: http://martinralbrecht.wordpress.com/
_jab: martinr...@jabber.ccc.de

[Volker Braun]

On Monday, June 25, 2012 3:25:12 PM UTC+1, Martin Albrecht wrote:

Also, we instantiate GFqDom with int while the backtrace uses long, again, not
sure it's relevant. 

For the record, sizeof(int) == sizeof(long) on sparc 32-bit. So it should not make a difference.