atlas3: FTBFS on more than one architecture

Bug #6778 reported by Debian Bug Importer
4
Affects Status Importance Assigned to Milestone
atlas3 (Debian)
Fix Released
Unknown
atlas3 (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

Automatically imported from Debian bug report #243447
http://bugs.debian.org/243447

Revision history for this message
In , Camm Maguire (camm) wrote : Re: Bug#243447: atlas3: FTBFS on more than one architecture

Greetings! Just a quick inquiry -- you are not directly
build-depending on atlas3, are you? You can build-depend on either
refblas3-dev/lapack3-dev or libblas-3.so/liblapack-3.so and still get
the automatic benefit of atlas speedups where available and defaulting
to the reference versions elsewhere. Getting atlas to compile is a
lot of work, all of which I will not have any time soon, alas. Would
be happy to help interested porters accomplish same.

Take care,

Matthias Klose <email address hidden> writes:

> Package: atlas3
> Version: 3.6.0-4
> Severity: serious
>
> Fails on hppa, sparc, m68k, s390, arm, powerpc, ia64, succeeded on
> mips, mipsel, alpha.
>
>
>
>
>

--
Camm Maguire <email address hidden>
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

Revision history for this message
In , Camm Maguire (camm) wrote : Re: [Math-atlas-devel] segfault in sparc in ATL_zupKBmm8_8_1_bX.c:467 (xzl3blastst, TRSM)
Download full text (3.8 KiB)

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://math-atlas.sourceforge.net/faq.html#lists
> 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,mips,mipsel,amd64,hppa:
        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 ha...

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Automatically imported from Debian bug report #243447
http://bugs.debian.org/243447

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Tue, 13 Apr 2004 06:58:55 +0200
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: atlas3: FTBFS on more than one architecture

Package: atlas3
Version: 3.6.0-4
Severity: serious

Fails on hppa, sparc, m68k, s390, arm, powerpc, ia64, succeeded on
mips, mipsel, alpha.

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: 14 Apr 2004 15:48:44 -0400
From: Camm Maguire <email address hidden>
To: Matthias Klose <email address hidden>
Cc: <email address hidden>, <email address hidden>,
 <email address hidden>, <email address hidden>,
 <email address hidden>, <email address hidden>,
 <email address hidden>, <email address hidden>
Subject: Re: Bug#243447: atlas3: FTBFS on more than one architecture

Greetings! Just a quick inquiry -- you are not directly
build-depending on atlas3, are you? You can build-depend on either
refblas3-dev/lapack3-dev or libblas-3.so/liblapack-3.so and still get
the automatic benefit of atlas speedups where available and defaulting
to the reference versions elsewhere. Getting atlas to compile is a
lot of work, all of which I will not have any time soon, alas. Would
be happy to help interested porters accomplish same.

Take care,

Matthias Klose <email address hidden> writes:

> Package: atlas3
> Version: 3.6.0-4
> Severity: serious
>
> Fails on hppa, sparc, m68k, s390, arm, powerpc, ia64, succeeded on
> mips, mipsel, alpha.
>
>
>
>
>

--
Camm Maguire <email address hidden>
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (4.2 KiB)

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_8_1_bX.c:467
 (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://math-atlas.sourceforge.net/faq.html#lists
> 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,mips,mipsel,amd64,hppa:
        base

I'm down to two platforms on...

Read more...

Revision history for this message
Matt Zimmerman (mdz) wrote :

Remove myself from all these CCs now that we have the warty-bugs mailing list

Revision history for this message
Matt Zimmerman (mdz) wrote :

atlas3 has been removed from Warty, hence this bug is NOTWARTY

Revision history for this message
In , Steve Langasek (vorlon) wrote :

severity 243447 important
thanks

As the most recent version of atlas3 has been autobuild on all
architectures for which it has previously built (save alpha, which
currently has autobuilder problems), I don't see any reason to justify an
RC severity for this bug.

Thanks,
--
Steve Langasek
postmodern programmer

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sat, 10 Jul 2004 23:42:17 -0500
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: Re: atlas3: FTBFS on more than one architecture

severity 243447 important
thanks

As the most recent version of atlas3 has been autobuild on all
architectures for which it has previously built (save alpha, which
currently has autobuilder problems), I don't see any reason to justify an
RC severity for this bug.

Thanks,
--
Steve Langasek
postmodern programmer

Revision history for this message
In , Frank Lichtenheld (djpig) wrote : severity of 272665 is important, merging 272665 243447

# Automatically generated email from bts, devscripts version 2.8.4
 # never build before on these arches
severity 272665 important
merge 272665 243447

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Wed, 22 Sep 2004 01:42:24 +0200
From: Frank Lichtenheld <email address hidden>
To: <email address hidden>
Subject: severity of 272665 is important, merging 272665 243447

# Automatically generated email from bts, devscripts version 2.8.4
 # never build before on these arches
severity 272665 important
merge 272665 243447

Revision history for this message
In , Nelson A. de Oliveira (naoliv) wrote : Only FTBFS on arm

retitle 243447 FTBFS on arm
thanks

atlas3 version 3.6.0-20.2 has only failed on arm [1]. All other archs
seem to build atlas3 successfully [2]

[1]http://buildd.debian.org/fetch.cgi?&pkg=atlas3&ver=3.6.0-20.2&arch=arm&stamp=1164057762&file=log
[2]http://people.debian.org/~igloo/status.php?packages=atlas3

Best regards,
Nelson

Revision history for this message
In , Marco Rodrigues (gothicx-sapo) wrote : atlas3 has been removed from Debian, closing #243447

Version: 3.6.0-20.6

The atlas3 package has been removed from Debian testing, unstable and
experimental, so I am now closing the bugs that were still opened
against it.

For more information about this package's removal, read
http://bugs.debian.org/473440 . That bug might give the reasons why
this package was removed, and suggestions of possible replacements.

Don't hesitate to reply to this mail if you have any question.

Thank you for your contribution to Debian.

--
Marco Rodrigues

http://Marco.Tondela.org

Revision history for this message
In , Marco Rodrigues (gothicx-sapo) wrote : reopening 243447

# Automatically generated email from bts, devscripts version 2.10.11ubuntu5
reopen 243447

Revision history for this message
In , Marco Rodrigues (gothicx-sapo) wrote : notfixed 243447 in 3.6.0-20.6

# Automatically generated email from bts, devscripts version 2.10.11ubuntu5
notfixed 243447 3.6.0-20.6

Revision history for this message
In , Marco Rodrigues (gothicx-sapo) wrote : reassign 243447 to atlas

# Automatically generated email from bts, devscripts version 2.10.11ubuntu5
reassign 243447 atlas

Revision history for this message
In , Marco Rodrigues (gothicx-sapo) wrote : notfixed 272665 in 3.6.0-20.6

# Automatically generated email from bts, devscripts version 2.10.11ubuntu5
notfixed 272665 3.6.0-20.6

Revision history for this message
In , Marco Rodrigues (gothicx-sapo) wrote : reassign 272665 to atlas

# Automatically generated email from bts, devscripts version 2.10.11ubuntu5
reassign 272665 atlas

Changed in atlas3 (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.