Referencing an issue with LAPACK tests with GCC 11.3.0

[satishskamath]

easybuilders/easybuild-easyconfigs#16380

[martin-frbg]

Thanks for the pointer. There have been a few problems with -ftree-vectorize (which is not a default or recommended option in the OpenBLAS sources) but it is unclear to me if the recent ones are caused by errors in the code or the newer compiler, in particular gfortran. (I already disabled this option for gfortran in the "test" Makefile with #3329 to remove what looked to be spurious errors). Earlier occurences were indeed traced to bugs in optimized assembly kernels - missing clobbers and such, but I think these have all been taken care of.
BTW the OpenBLAS package already contains all of Reference-LAPACK including its testsuite, so it is not clear to me why the given reproducer needs to be this involved.

[martin-frbg]

Also worth noting that at least some of the tests in the LAPACK testsuite are very sensitive to changes in numerical accuracy as they might occur from the use of FMA instructions or simply from different computation sequences compared to the unoptimized reference implementation (#3648) and as noted in the netlib LAPACK faq not everything flagged as a test failure is necessarily serious, one needs to look at the magnitude of the deviation in the detailed log

[brada4]

The supposed build log is missing in referenced issue. That in turn has more references fhere, none yielding that or any build parameters used to reproduce the issue.

[martin-frbg]

at least some of the build options are named in the ticket, and of these the added -march=znver2 appears to be sufficient to cause the LAPACK testsuite to report errors. (And this even when I change the Makefile to apply this option only to the FFLAGS used to build the netlib lapack itself - so looks more like testsuite fragility or gfortran code generation than anything wrong in OpenBLAS)

[brada4]

reading Update4 it is not clear if openblas is involved there.

[martin-frbg]

I read it as a non-standard way of building Reference-LAPACK against OpenBLAS as the external BLAS implementation - but I am all for assuming no involvement (unless/until I hear from Ken Hoste)