© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0f7b58d
(Get the code!)
Message-ID: <email address hidden>
Date: 07 Jun 2004 14:00:40 -0400
From: Camm Maguire <email address hidden>
To: <email address hidden> (R Clint Whaley)
Cc: <email address hidden>, <email address hidden>,
<email address hidden>
Subject: Re: [Math-atlas-devel] segfault in sparc in ATL_zupKBmm8_
(xzl3blastst, TRSM)
Greetings!
<email address hidden> (R Clint Whaley) writes:
> Camm,
>
> >Greetings! The suggested fix has gotten me past the error, and likely
> >will get me through the complete test suite, which is still in
> >progress, otherwise I'll let you know. Thanks again!
>
> I just noticed you are not signed up for the error list. I sent out a message
> about that error on the list when the error was found. You probably want to
> sign up. I send out a message for every major ATLAS error (i.e., any error
> that will produce a wrong answer or fault on a successfully installed stable)
> on that list. See:
> http://
> It's very low traffic.
>
OK, will subscribe.
> >My understanding is that the only subarch specific codes in 3.6.0 which
> >will not run (however non-optimally) on at least some machines of the
> >given general cpu architecture fall into one of the following
> >categories:
> >
> >sse1
> >sse2
> >3dnow
> >altivec
> >ultrasparc
> >alpha ev6
> >
> >Please correct me if wrong. Specifically, if one has gnu tools only
> >(no icc, etc.), is there a difference between Itan and Itan2? Is
> >either build not executable on the other cpu? I'm supposing if not,
> >the Itan2 is the better default for Debian ia64.
>
> I believe this is true. However, the Itan2 may run very slow on an Itan1.
> The difference in their kernels, as I recall, is the number of registers
> used. I was unable to get access to a Itan1, so I was never sure if the
> extra registers were due to better register handling in gcc, or due to
> architectural differences. If gcc is the culprit, Itan2 defaults should
> be great for Itan1. If the difference is not gcc, Itan2 defaults may
> cause register spills within the kernel's innermost loop, which could be
> disastrous.
>
> I suppose another approach would be to install an older gcc on an Itanium2,
> and see if the present kernel blows. From the old dev2stable page, it looks
> like gcc 3.0 was used on the last Itanium1 I had access to.
>
Thanks! Since Itan2 is the future, and since I'm not really sure how
many users in ia64 land we have, I think we should go with Itan2 as
the default for now and see if anyone complains :-). I just wanted to
make sure there would be no SIGILL on Itan1...
We've got the following builds and their 'build records' well in hand:
(To refresh your memory, I've put in a little facility for replaying a
successful build without any timing on a machine which possibly does
not support the isa extensions compiled into the lib -- these are
'build records')
i386:
base
3dnow
sse
sse2
powerpc:
base
altivec
sparc:
base
v9
alpha:
base
ev5
ia64,s390,
base
I'm down to two platforms on which completing a build is proving
difficult:
1) arm: Why would one want to do this one asks? Good question, but
in principle there may be some benefit to users of embedded devices
and pdas, where this chip is quite popular. First, there is some
instability in the cpu timer for which I need to file a bug with
the kernel or libc maintainer, but haven't yet. Am defaulting to
-DWALL right now and am getting further, but as I don't have
control of these machines and their load, I need higher reps
apparently. If you could look at
http://
and comment if you have a moment I'd be grateful.
2) m68k: This appears to merely require a longer 'inactivity'
timeout. The killer step is the final 'ar' (!)
Take care,
> Cheers,
> Clint
>
>
>
--
Camm Maguire <email address hidden>
=======
"The earth is but one country, and mankind its citizens." -- Baha'u'llah