Repository navigation
Fix real norm workspace arguments in CGECXX and ZGECXX - #1447
Conversation
CLANGE and ZLANGE require real WORK arrays; pass RWORK rather than the complex WORK array when computing FNRMK. Their Frobenius-norm paths do not reference the workspace, so this corrects the Fortran interface without changing the numerical algorithm. Checked all four precisions: the real callers already have the correct types. Same-unit caller/callee compilation rejects C/Z before the patch and accepts all four after it. Native query and numerical smoke checks passed 96 cases per version (before and after).
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1447 +/- ##
=======================================
Coverage 69.72% 69.72%
=======================================
Files 6204 6204
Lines 497194 497194
Branches 23430 23430
=======================================
Hits 346652 346652
Misses 150116 150116
Partials 426 426
Continue to review full report in Codecov by Harness.
|
langou
left a comment
langou
left a comment
There was a problem hiding this comment.
Thanks. Good catch!
Note that the run "openmp-windows-2025-gfortran (static)" initially failed so I had to wait for all test to complete, and once all tests completed I had to click on "re-rerun failed test" and it then worked. This is the second time I have had to do this. Last time was with @jprhyne. I am letting everyone know in case this also happens to you and you need me to click on "rereun failed jobs". This is not great to have to do this, but it is what it is. I do not know what the job fails the first time. I think it times out or something like that.
Thanks @nakatamaho !
|
Appreciated it, as always, langou-san!! |
Often that happens when the CI runner runs on different hardware AMD vs Intel based machines cause that kind of sporadic failures. |
@langou This is the failure, visible at https://github.com/Reference-LAPACK/lapack/actions/runs/40141522547/job/121014081637?pr=1447 line 489 et seq, it's not a timeout: |
|
Immediate speculation about why it's failing on OpenMP, with Windows, and intermittently: it could be similar to the problem I addressed in 43d0daa as part of #1407, with workspace calculation being suddenly much larger due to new threads being spawned. If that's so, then the calculation might be going outside its allotted work area in some threads, causing a Someone more knowledgeable than me can figure from the log above which routine is having this problem, which will narrow it down. |
|
A technique I figured out a few years ago to make Fortran77 types be consistent between caller and callee is noted in PDLPorters/pdl#369 (comment), as part of getting some bundled F77 code (in fact part of LINPACK) to be 64-bit integers. I reproduce it here: I did some extra checks for Slatec, using these techniques; first I replaced all the individual files in FFLAGS=-fPIC -std=legacy -cpp
slatec/bigun$(OBJ_EXT): slatec/bigun.f
gfortran -c $(FFLAGS) -o slatec/bigun$(OBJ_EXT) slatec/bigun.fThen iterated to find further problems and fix them using: (cd Libtmp/Slatec/;
(for x in slatec/[c-z]*.f; do echo "#line 1 \"$x\""; cat $x; done) >bigun.f; mv bigun.f slatec/;
time make test
) |&lesswhich lets the compiler see all the Fortran at once and so detect problems, while with the |
CLANGE and ZLANGE require real WORK arrays; pass RWORK rather than the complex WORK array when computing FNRMK. Their Frobenius-norm paths do not reference the workspace, so this corrects the Fortran interface without changing the numerical algorithm.
Checked all four precisions: the real callers already have the correct types. Same-unit caller/callee compilation rejects C/Z before the patch and accepts all four after it. Native query and numerical smoke checks passed 96 cases per version (before and after).
Description
Checklist