LAPACK Archives

[Lapack] Error using DTRSYL / DLASY2 on MacOS 10.7.5

Hi Martin, 

Thanks for the bug report and the investigation.

1) You say MacOS 10.7.5 and I assume you are using gcc as the compiler.

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 with BLAS.

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> wrote:

Hash: SHA1

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 Framework.

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?

Martin K?hler

- -- 
Dipl.-Math. Martin K?hler
Max Planck Institute for
Dynamics of Complex Technical Systems
Sandtorstr. 1
39106 Magdeburg

phone: +49 (0)391 6110 445
email: koehlerm@Domain.Removed
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -

Lapack mailing list

<Prev in Thread] Current Thread [Next in Thread>

For additional information you may use the LAPACK/ScaLAPACK Forum.
Or one of the mailing lists, or