fortran intrinsics tests fail

[jschueller]

lapack 3.11 introduced intrinsics tests (#623)
these seem to fail on linux/gcc 12.2, is that a problem ?

$ gfortran lapack/INSTALL/test_zcomplexdiv.f
$ ./a.out
 !! Some (x+x*I)/(x+x*I) differ from 1
[ c3] X =  1.7976931348623157E+308 : (x+x*I)/(x+x*I) =                      NaN+0.0000000000000000E+000*I differs from +1.0000000000000000E+000
[ c4] X =  8.9884656743115795E+307 : (x+x*I)/(x+x*I) =                      NaN+0.0000000000000000E+000*I differs from +1.0000000000000000E+000
[ f3] X =  1.7976931348623157E+308 : (x+x*I)/(x-x*I) =  0.0000000000000000E+000                     NaN*I differs from +0.0000000000000000E+000+1.0000000000000000E+000*I
[ f4] X =  8.9884656743115795E+307 : (x+x*I)/(x-x*I) =  0.0000000000000000E+000                     NaN*I differs from +0.0000000000000000E+000+1.0000000000000000E+000*I
 !! Some (x+x*I)/(x-x*I) differ from I
 # Please check the failed divisions in [stderr]

also when cross-compiling (CMAKE_CROSSCOMPILING) cmake might not be able to run them

cc @weslleyspereira

[langou]

Hi Julien,

Thanks for the bug report.

This is a GCC error as far as we are concerned.

LAPACK has CLADIV / ZLADIV that implements no-unnecessary-under/overflow complex divisions (based off real divisions), but it would be nice if compilers would give this feature from the fortran complex division operator, so that we do not have to rely on our own CLADIV / ZLADIV.

I am fine with your PR which proposes to disable the compiler checks by default.

Note: I can reproduce the failure on my laptop. I also have 12.2.0.

Note: GCC passes many tests. We only report the failed tests, (so 4 in this case,) but many tests are passing.

What people think about this PR: disabling compiler checks by default?

I am fine with it. Other opinions?

Julien.

[jschueller]

Is there a bug report at gcc for this ?

[langou]

Right, that's a good question. I am not aware of a bug report at GCC for this. It would be good to let them know. I would be interested to know whether they consider this a bug or not. Maybe they are of the opinion that this is an expected behavior. I do not know. We (LAPACK) consider this a compiler bug. But happy to hear other opinions.

[weslleyspereira]

Is there a bug report at gcc for this ?

Not that I am aware of. I think is the good place to do so is https://gcc.gnu.org/bugzilla/

[jschueller]

isnt that stuff part of the ieee754 standard, or unrelated ?

[weslleyspereira]

Since the input and output are both finite, I don't think this relates to the Inf and NaN propagation discussed in the IEEE standard.

[weslleyspereira]

Just as a matter of being complete here. This is the test description: https://netlib.org/lapack/explore-html/de/db5/test__zcomplexdiv_8f_a0a9c3582674d2f2881f3fce922f84d40.html#a0a9c3582674d2f2881f3fce922f84d40

We test divisions with:

• all numbers x = 2**m, for MINEXPONENT-1 <= m < MAXEXPONENT
• the number x = OV, where OV is the overflow threshold.

The tests using GCC return NaN for the division: (OV+OV*I)/(OV+OV*I).

[jschueller]

Would you mind opening a bug report at GCC ?

[weslleyspereira]

No. I can do that!

[jschueller]

Great! thanks

[langou]

As far IEEE standard, I am not sure that the IEEE standard defines complex division as part of the standard. They define real division behavior, but the complex division is a construct on top of the real arithmetic. I think this more as to do with FORTRAN standard.

[weslleyspereira]

Done! https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107753
I am not sure whether this is already public or not.

[chewi]

I was unaware of the GCC issue but came here to deal with the cross issue. The disable-by-default fix has been sitting unmerged for a while now. Can you please either merge that or the cross fix?