Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#71 blas-atlas-3.6.0 compile failure on ppc

Stable
closed-works-for-me
5
2007-10-14
2006-01-29
Markus Dittrich
No

Dear ATLAS team,

During a stabilization attempt of blas-atlas-3.6.0 on the
PPC architecture, the Gentoo Linux team has experienced
problems compiling the code.

It seems that xemit_mm creates "bad" code.
Here's one of the error messages

------------------- SNIP --------------------------------------
/usr/bin/gcc -DL2SIZE=4194304
-I/var/tmp/portage/blas-atlas-3.6.0-r1/work/ATLAS/include
-I/var/tmp/portage/blas-atlas-3.6.0-r1/work/ATLAS/include/Linux_UNKNOWNAltiVec
-I/var/tmp/portage/blas-atlas-3.6.0-r1/work/ATLAS/include/contrib
-DAdd__ -DStringSunStyle -DATL_OS_Linux -DATL_AltiVec
-DATL_AVgcc -DATL_GAS_LINUX_PPC -DATL_UCLEANM
-DATL_UCLEANN -DATL_UCLEANK -c -fomit-frame-pointer
-O -maltivec -mabi=altivec ATL_dupKBmm_b0.c -fPIC
-DPIC -o .libs/ATL_dupKBmm_b0.o
ATL_dupKBmm_b0.c: In function `ATL_dpKBmm_b0':
ATL_dupKBmm_b0.c:26: error: parse error before "else"
make[8]: *** [ATL_dupKBmm_b0.o] Error 1

------------------------ SNIP ---------------------------------

The relevant piece of code ATL_dupKBmm_b0.c looks
like this

------------------------ SNIP ----------------------------------
void ATL_dpKBmm_b0
(const int M, const int N, const int K, const double alpha,
const double *A, const int lda, const double *B, const
int ldb,
const double beta, double *C, const int ldc)
{

else
{
ATL_dupKBmm1_1_1_b0(M, N, K, alpha, A, lda, B, ldb,
beta, C, ldc);
}
else if (K == (((((K) >> 1)) << 1)))
{
ATL_dupKBmm0_2_0_b0(M, N, K, alpha, A, lda, B, ldb,
beta, C, ldc);
}
}
-------------------------------------------------------------------

which is obviously incorrect.

Additional details can be found in Gentoo's bugzilla

https://bugs.gentoo.org/show_bug.cgi?id=114587

It would be great if you could help us debug this issue.

Thanks in advance,
Markus

Discussion

  • Error log for blas-atlas-3.6.0 on PPC

     
    • labels: 360151 -->
    • milestone: 148062 -->
    • assigned_to: nobody --> rwhaley
    • status: open --> open-accepted
     
  • Logged In: YES
    user_id=182470

    Markus,

    First, let me confirm that this is a known bug in the ATLAS
    framework. I think it's still in the newest dev release as
    well. I've known about it for about 5 years :)

    OK, so why isn't it fixed? The reason is that it only
    rarely happens, and never when the search has found a really
    good solution (i.e. the only times I observed it, the search
    had gone awry and was timing non-optimal cases). For
    machines where it happened, I intervened by providing
    architectural defaults that provided better performance, as
    well as not producing illegal code :-}

    I'm not saying I'm never going to fix, it just has never
    risen high enough in the unending queue of things I'm
    supposed to do. This is particularly the case, because it
    is not easy to debug, as it relies on some non-determistic
    criteria to occur.

    The unending queue of things now includes getting a stable
    release out that runs on modern machines. Until I obtain
    some funding (because I'm a professor who will be fired if
    he spends his time on unsupported work), I don't have the
    time to do the stuff needed (I am working on grants to try
    to get funding for ATLAS, so far without success).

    In the meantime, I really urge people to use the developer
    release, and would like to encourage you to do the same.
    The PowerPC support is much better there, as is the entire
    family of x86 machines. You will get significant speedup
    across a wide range of machines. The real difference is
    just testing, and since you repackagers do that yourselves,
    this should not be a problem. There used to be a big
    difference in the level of support I offered, but in these
    lean times, developer is probably more supported. I will
    not fix bugs in the stable, though I might help others to do
    so. The first ATLAS task I will undertake if I find the
    time to do significant work (other than the weekend tunings
    that occasionally produce new dev releases) will be to turn
    the developer into a new stable . . .

    Let me know,
    Clint

     
  • Logged In: YES
    user_id=1438734

    Dear Clint,

    First of all I would like to thank you for your detailed comments
    and, of course, for your great work with blas-atlas. I really hope
    you'll be able to come up with some funding to continue the
    good work. Being in academia myself, I only know too well how
    hard this can be.

    Your remarks "nicely" explain with this bug has only hit our
    ppc testing team but seems to work for other ppc users.
    Knowing this, we'll be able to deal with this appropriately.

    With regard to your recommendation of using the latest
    developer release:
    Gentoo has two package branches per architecture, one
    containing stable releases (i.e. blas-atlas-3.6.0) and a
    "unstable" (development) one (i.e., latest blas atlas).
    Hence the most recent blas-atlas is available to Gentoo
    users if they opt for it. I certainly do:)

    Thanks again for your time and I wish you all the best
    for your future blas-atlas development efforts.

    Regards,
    Markus

     
    • milestone: --> Stable
    • labels: --> Install problem
    • status: open-accepted --> closed-works-for-me
     
  • Logged In: YES
    user_id=182470
    Originator: NO

    Markus,

    I believe this problem should now not occur on PowerPC, due to some bug fixes in the search. I think the error is still there in the code emitter, but that it won't go to this solution anymore with 3.8.0. Reopen if you experience with 3.8.0.

    Thanks,
    Clint