Dear Vittorio,
See inlined comments. Your email shows in red.
What flags are you using for compilation? You use gfortran right? You have lots
of errors, and I am not sure I have so many. Are you using some special flags?
It seems that your execution stops at each overflow.
Are you using:
"ffpetrap=overflow"
Well if so, this is a problem.
LAPACK execution might have plenty of overflows, this is just fine and we
create +INFTY and use them as we should.
We sometimes actually use NaNs as well. So LAPACK does creates NaNs. And this
is normal. We expect IEEE arithmetic, we create NaNs, we create INFTY, and we
deal with this. Part of the game.
In other words, you should not compile LAPACK with the option
"ffpetrap=overflow". Is it what you are doing?
See your bug reports #2, #3 and #4. I think there is no problem for these three
but a compilation flag.
Maybe we should add this in our documentation.
Otherwise thanks a lot for #1, #5, #6 and #7.
I just downloaded lapack 3.6.0 trunk level 1563.
I have an x8664 hardware.
(1) During compilation I found that in zgges3.f line 404
WORK( 1 ) = DCMPLX( WKOPT )
the variable WKOPT is referenced but not declared nor initialized.
Should it be LWKOPT instead?
Correct. That was a (very bad) typo. We received a bug report from Rodney James
at 7:46am yesterday and your email pointing to the same problem came at 8:16am
yesterday. Funny.
Philippe fixed all this in revision 1564 yesterday. Thanks!
(2) Running "./xeigtsts < svd.in" I get the gfortran runtime error message
Program received signal SIGFPE: Floatingpoint exception  erroneous
arithmetic operation.
This is in sgesvj.f line 627 "TEMP1 = AMIN1( BIG, TEMP1 / AAPP )"
where BIG=3.40282347E+38 TEMP1=1.06502325E+19 AAPP=8.75567555E32
so that TEMP1/AAPP is too large for single precision arithmetic.
I "fixed" this one changing the abovementioned statement to
TEMP1 = DMIN1( dble(BIG), dble(TEMP1) / dble(AAPP) )
but I am not sure this is correct.
What is the right fix?
Given your values: dble(TEMP1) / dble(AAPP) should be +INFTY. And then MIN(
NUMBER, +INFTY) should be NUMBER. We should not have any problem.
But I think you have a flag that says that you do not want overflow. Am I
correct?
Note for LAPACKers: Since AMIN1 is archaic, we might want to use MIN( ) instead
of AMIN1()
It looks like there is some cleaning to do here. (Replace archaic intrinsic
with their corresponding modern intrinsic.)
(3) Same error message running "./xeigtsts < sgg.in"
Program received signal SIGFPE: Floatingpoint exception  erroneous
arithmetic operation.
in shgeqz.f line 762
IF ( ABS( (WR/S1)*T( ILAST, ILAST )  H( ILAST, ILAST ) )
$ .GT. ABS( (WR2/S2)*T( ILAST, ILAST )
$  H( ILAST, ILAST ) ) ) THEN
because
WR=1.11871902E+11 S1=1.17549435E36 ILAST=3 T=2.48154184E24
H=2.41910350E+23 WR2=1.11871902E+11 S2=1.17549435E36
so I get overflows computing WR/S1 and WR2/S2
I "fixed" this one by changing the statement into
IF (DABS((dble(WR)/dble(S1))*T( ILAST, ILAST )  H( ILAST, ILAST))
$ .GT.DABS( (dble(WR2)/dble(S2))*T( ILAST, ILAST )
$  H( ILAST, ILAST ) ) ) THEN
but I am not sure this is correct.
What is the right fix?
Same answer. Overflow does not necessarily mean problem.
(4) Same error message running "./xeigtsts < sbal.in" at schkbl.f line 141
VMAX = MAX( VMAX, ABS( A( I, J )AIN( I, J ) ) / TEMP )
because
I=5 J=6 VMAX=2.65845599E+38 A=4.00000000
AIN=8.00000000 TEMP=1.17549435E38
so that the result of the MAX operation is 3.4028236692093846E+038,
too large to fit in a single precision variable.
I do not know how to fix this one.
Same answer. Overflow does not necessarily mean problem.
(5) Running ./xlintstz < ztest.in zgehrd.f line 350
WORK( 1 ) = LWKOPT
LWKOPT is undefined.
Thanks! Philippe has just fixed this one with commit 1565. Thanks! Another bad
one. Thanks!
(6) In sdrgev3.f, line 900
9998 FORMAT( ' SDRGEV3: ', A, ' Eigenvectors from ', A, ' incorrectly ',
the last comma is on column 73. Same for cdrgev3.f at line 902. And
ddrgev3.f line 898. And zdrgev3.f, line 897.
Thanks! Philippe has just fixed this one with commit 1567. Thanks!
(7) The fourth formal argument of CTGSEN is a logical array SELECT.
However in the calling subroutine CGGES3
the corresponding actual argument WORK is a complex array. I believe
this is wrong and error prone.
Are you sure this is intended? Shouldn't it be BWORK, a logical array?
Thanks! Philippe has just fixed this one with commit 1567. Thanks! This was
just a worspace query, but still, better got that one right. And a compiler
won't like this indeed. Thanks!
Vittorio: Thanks a lot for all the time and all the feedback. It is great!
Cheers,
Julien and Philippe.
 next part 
An HTML attachment was scrubbed...
URL:
<http://lists.eecs.utk.edu/mailman/private/lapack/attachments/20150811/f1949877/attachment.html>
