Description of problem:

The lapack subroutines xGELSD (I tested single and double real, actually)
apparently calculate required real workspace incorrectly. The attached f90
program compiled with Fedora blas & lapack crashes with both ifort and gfortran,
but works when used with Intel's MKL lapack library. 

Version-Release number of selected component (if applicable):
 3.0-37.fc4 

How reproducible:
Attachment + Fortran 95 compilers (Intel ifort or gcc gfortran)

Steps to Reproduce:
1. unpack attachment
2 [details]. gfortran svd.f90 lapfail.f90 -lblas -llapack
3. ./a.out
  
Actual results:
           2         140          40           5
*** glibc detected *** ./a.out: double free or corruption (out): 0x09875fc8 ***
======= Backtrace: =========
/lib/libc.so.6[0x199124]
/lib/libc.so.6(__libc_free+0x77)[0x19965f]
/usr/lib/libgfortran.so.0(_gfortran_internal_free+0x42)[0xcf6aaf]
/usr/lib/libgfortran.so.0(_gfortran_deallocate+0x2c)[0xcf6be6]
./a.out[0x8049566]
./a.out[0x8049d22]
./a.out[0x8049e2b]
/lib/libc.so.6(__libc_start_main+0xdf)[0x14ad5f]
./a.out[0x8048a51]
======= Memory map: ========
00111000-00134000 r-xp 00000000 fd:00 7668788    /lib/libm-2.3.5.so
00134000-00135000 r-xp 00022000 fd:00 7668788    /lib/libm-2.3.5.so
00135000-00136000 rwxp 00023000 fd:00 7668788    /lib/libm-2.3.5.so
00136000-00259000 r-xp 00000000 fd:00 7668784    /lib/libc-2.3.5.so
00259000-0025b000 r-xp 00123000 fd:00 7668784    /lib/libc-2.3.5.so
0025b000-0025d000 rwxp 00125000 fd:00 7668784    /lib/libc-2.3.5.so
0025d000-0025f000 rwxp 0025d000 00:00 0
0051c000-00536000 r-xp 00000000 fd:00 7667762    /lib/ld-2.3.5.so
00536000-00537000 r-xp 00019000 fd:00 7667762    /lib/ld-2.3.5.so
00537000-00538000 rwxp 0001a000 fd:00 7667762    /lib/ld-2.3.5.so
00602000-009b3000 r-xp 00000000 fd:00 6432627    /usr/lib/liblapack.so.3.0.3
009b3000-009b6000 rwxp 003b1000 fd:00 6432627    /usr/lib/liblapack.so.3.0.3
009b6000-00aba000 rwxp 009b6000 00:00 0
00bf2000-00c49000 r-xp 00000000 fd:00 6425580    /usr/lib/libblas.so.3.0.3
00c49000-00c4a000 rwxp 00056000 fd:00 6425580    /usr/lib/libblas.so.3.0.3
00cee000-00d48000 r-xp 00000000 fd:00 6432729    /usr/lib/libgfortran.so.0.0.0
00d48000-00d49000 rwxp 00059000 fd:00 6432729    /usr/lib/libgfortran.so.0.0.0
00d49000-00d4d000 rwxp 00d49000 00:00 0
00db7000-00dc0000 r-xp 00000000 fd:00 7668789    /lib/libgcc_s-4.0.2-20051126.so.1
00dc0000-00dc1000 rwxp 00009000 fd:00 7668789    /lib/libgcc_s-4.0.2-20051126.so.1
00ea4000-00ea5000 r-xp 00ea4000 00:00 0          [vdso]
08048000-0804a000 r-xp 00000000 fd:00 4588980    /home/hajek/scratch/a.out
0804a000-0804b000 rw-p 00002000 fd:00 4588980    /home/hajek/scratch/a.out
09868000-09889000 rw-p 09868000 00:00 0          [heap]
b7e00000-b7e21000 rw-p b7e00000 00:00 0
b7e21000-b7f00000 ---p b7e21000 00:00 0
b7f9d000-b7f9f000 rw-p b7f9d000 00:00 0
b7fad000-b7fae000 rw-p b7fad000 00:00 0
bfa99000-bfaae000 rw-p bfa99000 00:00 0          [stack]
Aborted


Expected results:
           2         140          40           5

Additional info:
This bug seems to be closely related with #169399, however, that one 
is reported fixed and the author complained that he didn't succeed with
calculating the workspace size according to the subroutine description, whereas
I used the recommended and safer LWORK = -1 query to let the subroutine
calculate the workspace. The bug occurs often, but not for arbitrary matrices;
therefore, I attached a data file also, but I always succeded even with
initializing the matrices randomly.