Hi Martin, conclusion: bug in the accelerate framework. Great. Since the
bug seems to be fixed in later versions of the accelerate framework, I
propose to just let it at that. It would be as easy to have a DO loop here
as opposed to a call to DCOPY. I think we'll leave the DCOPY for now.
On 8/6/13 5:16 AM, "Martin Koehler" <koehlerm@Domain.Removed> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
I tried the things today again and it seems that it caused by the
DCOPY copy implementation of the Accelerate framework. I tried the
- LAPACK 3.4.2 from scratch + Netlib BLAS - works
- LAPACK 3.4.2 from scratch and Accelerate BLAS - crashes
- all from Accelerate: crashes
Then I replace the DCOPY initialization to my manual one ( replaced
lines 374 and 375 with T16(1,1)=ZERO ... ) and compiled dlasy2.f and
dtrsyl.f on my own and place them before before BLAS and LAPACK in the
linking order. Then both crashed scenarios work fine. I tested this
using gcc-4.7.3 on MacOS X 10.7.5.
On other systems like Linux or MacOS X 10.6.8 everything works fine
with and without patching dlasy2.f. So it seems that it is a strange
error in this version of the Accelerate framework regarding DCOPY and
its behavior with an zero increment value.
Dipl.-Math. Martin K?hler
Max Planck Institute for
Dynamics of Complex Technical Systems
phone: +49 (0)391 6110 445
On 08/05/2013 06:55 PM, Langou, Julien wrote:
Thanks for the bug report and the investigation.
1) You say MacOS 10.7.5 and I assume you are using gcc as the
2) Do you compile the LAPACK and the BLAS library with gcc? Or do
you link against Apple's Accelerate Framework for the BLAS?
3) I just ran a 32-line code to test dcopy under MacOS. I thought
that might have been the problem. I have MacOS 10.8.4 here. No
problem with dcopy. It behaves as expected. Either the version in
Apple's Accelerate Framework or a version compiled from scratched
4) The line I thought might get you in trouble is line 375. The
line reads: 374: BTMP( 1 ) = ZERO
375: CALL DCOPY( 16, BTMP, 0, T16, 1 ) What this line does is
copying the "vector" BTMP of length 16 and increment 0 (so this is
really BTMP(0) repeated 16 times, so this is really ZERO repeated
16 times) into the vector T16 of length 16 and increment 1. So
essentially this line initializes the 16 entries of T16 to ZERO. So
this line is supposed to do what you are doing with your 16 lines:
T16(1,1) = ZERO T16(2,1) = ZERO T16(3,1) = ZERO T16(4,1) = ZERO
T16(1,2) = ZERO T16(2,2) = ZERO T16(3,2) = ZERO T16(4,2) = ZERO
T16(1,3) = ZERO T16(2,3) = ZERO T16(3,3) = ZERO T16(4,3) = ZERO
T16(1,4) = ZERO T16(2,4) = ZERO T16(3,4) = ZERO T16(4,4) = ZERO Can
you please check that removing those two lines (I think you can
remove line 375 and line 374 as well) and inserting your 16 lines
fixes the problem as well?
On 8/5/13 6:58 AM, "Martin Koehler" <koehlerm@Domain.Removed>
Dear Lapack Team,
I recognize a strange error inside DLASY2 (LAPACK 3.4.2) on MacOS
10.7.5. Due to completely wrong results I used valgrind to get an
idea where they come friom because they are not reproducible on any
other operating system. Valgrind said, that in dlasy2.f is an
access to an uninitialized value in lines 413,429,441,446 and 475.
All these lines access the T16 variable and compare them to a
reference value. This seems to cause a wrong evaluation inside the
"if" statement and the program flow goes the wrong way.
I tried this using gcc 4.7.3 and gcc-4.8.1 from MacPorts and even
the Intel Fortran 13 compiler. I solved the problem inserting
T16(1,1) = ZERO ... T16(4,4) = ZERO directly after the declaration
of the variables. This small modification vanished all valgrind
errors. The error also occurs when using Apple's Accelerate
I tried the same code on Linux using gcc 4.6.x and 4.7.x and on
MacOS 10.6.8 using gcc 4.8.1. and every thing works fine.
Do you have any idea about the reason of this strange problem?
regards Martin K?hler
_______________________________________________ Lapack mailing
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----