dlahrd.f: consistent line reflow for DTRMV calls

[wdconinc]

Description
Under gcc-12.3.0 (locally confirmed with gcc-14.2.0 as well), we are noticing spurious type mismatch errors due to different line reflow in dlahrd.f, see e.g. https://gitlab.spack.io/spack/spack/-/jobs/14595649#L1131. Notice that the types of different arguments are compared in that error message.

This PR makes the line reflow for two DTRMV calls identical, which resolves the spurious report. This does not appear to be necessary for the other ?lahrd.f files (they reflow the relevant lines differently).

Checklist

• The documentation has been updated.
  • No documentation updates needed
• If the PR solves a specific issue, it is set to be closed on merge.
  • No specific issue reported, but see netlib-lapack: add v3.12.1 spack/spack#48318 (comment).

[wdconinc]

cc @alalazo

[langou]

Thanks @wdconinc !

[thierry-FreeBSD]

After applying this patch on FreeBSD, with clang-19 and gfortran-13.3, the build fails with this error:

[ 81%] Building Fortran object TESTING/LIN/CMakeFiles/xlintstd.dir/dchkeq.f.o
cd /usr/ports/math/lapack/work/.build/TESTING/LIN && /usr/local/bin/gfortran13   -O -Wl,-rpath=/usr/local/lib/gcc13 -O2 -frecursive -c /usr/ports/math/lapack/work/lapack-3.12.1/TESTING/LIN/dchkeq.f -o CMakeFiles/xlintstd.dir/dchkeq.f.o
--- TESTING/LIN/CMakeFiles/xlintstds.dir/all ---
/usr/local/bin/ld: ../../lib/liblapack.so.3.12.0: undefined reference to `taa_'
/usr/local/bin/ld: ../../lib/liblapack.so.3.12.0: undefined reference to `ldawork_'
collect2: error: ld returned 1 exit status
/usr/local/bin/gfortran13  -Wl,-rpath=/usr/local/lib/gcc13  -L/usr/local/lib/gcc13 -fstack-protector-strong -Wl,--dependency-file=CMakeFiles/xlintstds.dir/link.d -O -Wl,-rpath=/usr/local/lib/gcc13 -O2 CMakeFiles/xlintstds.dir/dchkab.f.o CMakeFiles/xlintstds.dir/ddrvab.f.o CMakeFiles/xlintstds.dir/ddrvac.f.o CMakeFiles/xlintstds.dir/derrab.f.o CMakeFiles/xlintstds.dir/derrac.f.o CMakeFiles/xlintstds.dir/dget08.f.o CMakeFiles/xlintstds.dir/alaerh.f.o CMakeFiles/xlintstds.dir/alahd.f.o CMakeFiles/xlintstds.dir/aladhd.f.o CMakeFiles/xlintstds.dir/alareq.f.o CMakeFiles/xlintstds.dir/chkxer.f.o CMakeFiles/xlintstds.dir/dlarhs.f.o CMakeFiles/xlintstds.dir/dlatb4.f.o CMakeFiles/xlintstds.dir/xerbla.f.o CMakeFiles/xlintstds.dir/dget02.f.o CMakeFiles/xlintstds.dir/dpot06.f.o -o ../../bin/xlintstds  -Wl,-rpath,/usr/ports/math/lapack/work/.build/lib:/usr/local/lib ../../lib/libtmglib.so.3.12.0 ../../lib/liblapack.so.3.12.0 /usr/local/lib/libblas.so
*** [bin/xlintstds] Error code 1

[martin-frbg]

does not appear to be related to this PR, do you get any earlier warnings or errors regarding these two symbols ?

[thierry-FreeBSD]

I don't see any related warning.
Full log is available at https://gist.githubusercontent.com/thierry-FreeBSD/a55bccdd952a10fc2a2e38f3cd8ac035/raw/455c75296c92ba8f4144f98849eca7fb60746457/lapack.log

[martin-frbg]

I got a clean compile of the current master branch on FreeBSD15 with clang19/gfortran14 , will see if I can retry with gfortran13 later

[thierry-FreeBSD]

Exactly the same error has been reported on Arch Linux for nomacs when linking with lapack-3.12.1: see https://aur.archlinux.org/packages/nomacs#comment-1006320
and also for /rpcs3: see https://aur.archlinux.org/packages/rpcs3-git#comment-1006321

[martin-frbg]

must be a similar issue with the fortran default line length somewhere, as "ldawork" does not make sense (i.e. a comma behind lda went unseen), but I wonder why different environments would come up with a different default for gfortran's line lengths option... Or does the BSD package build script impose something like std=legacy that would imply the traditional column 72 limit of punched cards ?

[thierry-FreeBSD]

I'm not aware of such a limitation, we compile a lot of various Fortran code without errors.
Moreover, it compiles without errors, this is just missing elements during linkage.
Strangely, lapack builds on Arch Linux, and this error appears when they try to link other programs with this library...

[martin-frbg]

there should be no LDAWORK symbol as far as I (and the github search function) am aware. I'm currently doing test builds in the GCC Compile Farm, but as it is a complimentary shared resource I cannot be too greedy with cpu time.
Unfortunately using wc -L as a quick tool to check source line length doesn't really help as most files seem to have the comments at the top extend far beyond column 72.

[angsch]

/usr/local/bin/ld: ../../lib/liblapack.so.3.12.0: undefined reference to `taa_'

My guess is that this is a cropped version of tau.

A candidate is

lapack/SRC/DEPRECATED/sgeqpf.f

Lines 221 to 222 in ba83427

	CALL SORM2R( 'Left', 'Transpose', M, N-MA, MA, A, LDA, TAU,
	$ A( 1, MA+1 ), LDA, WORK, INFO )

with current line length at 71.

[martin-frbg]

(Hmm. Actually trying to build with -ffixed-form fails in BLAS/SRC/snrm2.f90 already as that file is clearly free-form with code starting before column 7. The documented -ffixed-line-length-72 elicits a warning from the f951 step, suggesting it may not be supported anymore. Grepping for LDA,[[:space:]]$ does not find any likely candidate (some occurences in ?trf_aa_2stage.f but the line break is well before column 60)

[martin-frbg]

there are more candidates without spaces behind the comma, so I need some more time to check, but no obvious offender so far

[thierry-FreeBSD]

find . -name "*.f" | xargs awk '/LDA,/{if(length($0)>72) print FILENAME ":" FNR}' reports too many lines!

[thierry-FreeBSD]

/usr/local/bin/ld: ../../lib/liblapack.so.3.12.0: undefined reference to `taa_'

My guess is that this is a cropped version of tau.

A candidate is

lapack/SRC/DEPRECATED/sgeqpf.f

Lines 221 to 222 in ba83427

	CALL SORM2R( 'Left', 'Transpose', M, N-MA, MA, A, LDA, TAU,
	$ A( 1, MA+1 ), LDA, WORK, INFO )

with current line length at 71.

I tried this patch:

--- SRC/DEPRECATED/sgeqpf.f.orig        2024-12-03 12:39:11.000000000 +0100
+++ SRC/DEPRECATED/sgeqpf.f     2025-01-18 21:14:48.246623000 +0100
@@ -218,8 +218,8 @@
          MA = MIN( ITEMP, M )
          CALL SGEQR2( M, MA, A, LDA, TAU, WORK, INFO )
          IF( MA.LT.N ) THEN
-            CALL SORM2R( 'Left', 'Transpose', M, N-MA, MA, A, LDA, TAU,
-     $                   A( 1, MA+1 ), LDA, WORK, INFO )
+            CALL SORM2R( 'Left', 'Transpose', M, N-MA, MA, A, LDA,
+     $                    TAU, A( 1, MA+1 ), LDA, WORK, INFO )
          END IF
       END IF
 *

and it produces the same error.

[martin-frbg]

my best candidate for "LDA...WORK (in TESTING/LIN) has the comma after LDA in column 72 so should be safe too - though a script-added _64 suffix on the function name would probably change that (as it would in angsch's example).
I still wonder why I cannot reproduce the problem in my tests - what patches (if any) does your build script add over the base "git checkout" of lapack ?

[thierry-FreeBSD]

I don't use git checkout but the tarball https://github.com/Reference-LAPACK/lapack/archive/refs/tags/v3.12.1.tar.gz and I added the patches from 3aa8775 and f5103fc .
May be this is the root of the problem: I'll check the master branch (tomorrow).

[thierry-FreeBSD]

Done (from master at ba83427): exactly the same error.

[martin-frbg]

are you building directly with cmake, or via some package build script that sets some options ?

[thierry-FreeBSD]

I'm using the FreeBSD ports framework: it doesn't anything special, except passing the required variables.
Firstly for configure it runs:
cd /usr/ports/math/lapack/work/.build; /usr/bin/env -i HOME=/usr/ports/math/lapack/work MACHINE_ARCH=amd64 PWD="${PWD}" GIT_CEILING_DIRECTORIES=/usr/ports/math/lapack/work __MAKE_CONF=/nonexistent OSVERSION=1500029 PATH=/usr/ports/math/lapack/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/thierry/bin:/home/thierry/bin TERM=xterm-256color F77="gfortran13" F90="gfortran13" FC="gfortran13" FFLAGS="-O -Wl,-rpath=/usr/local/lib/gcc13" F90FLAGS="-O -Wl,-rpath=/usr/local/lib/gcc13" FCFLAGS="-Wl,-rpath=/usr/local/lib/gcc13" XDG_DATA_HOME=/usr/ports/math/lapack/work XDG_CONFIG_HOME=/usr/ports/math/lapack/work XDG_CACHE_HOME=/usr/ports/math/lapack/work/.cache HOME=/usr/ports/math/lapack/work PATH=/usr/ports/math/lapack/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/thierry/bin:/home/thierry/bin PKG_CONFIG_LIBDIR=/usr/ports/math/lapack/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig SHELL=/bin/sh CONFIG_SHELL=/bin/sh /usr/local/bin/cmake -DBLAS_LIBRARIES="/usr/local/lib/libblas.so" -DCMAKE_C_COMPILER:STRING="cc" -DCMAKE_CXX_COMPILER:STRING="c++" -DCMAKE_C_FLAGS:STRING="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing " -DCMAKE_C_FLAGS_DEBUG:STRING="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing " -DCMAKE_C_FLAGS_RELEASE:STRING="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DNDEBUG" -DCMAKE_CXX_FLAGS:STRING="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing " -DCMAKE_CXX_FLAGS_DEBUG:STRING="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing " -DCMAKE_CXX_FLAGS_RELEASE:STRING="-O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DNDEBUG" -DCMAKE_EXE_LINKER_FLAGS:STRING=" -Wl,-rpath=/usr/local/lib/gcc13 -L/usr/local/lib/gcc13 -fstack-protector-strong " -DCMAKE_MODULE_LINKER_FLAGS:STRING=" -Wl,-rpath=/usr/local/lib/gcc13 -L/usr/local/lib/gcc13 -fstack-protector-strong " -DCMAKE_SHARED_LINKER_FLAGS:STRING=" -Wl,-rpath=/usr/local/lib/gcc13 -L/usr/local/lib/gcc13 -fstack-protector-strong " -DCMAKE_INSTALL_PREFIX:PATH="/usr/local" -DCMAKE_AUTOGEN_PARALLEL:STRING="8" -DCMAKE_BUILD_TYPE:STRING="Release" -DTHREADS_HAVE_PTHREAD_ARG:BOOL=YES -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=YES -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DFETCHCONTENT_FULLY_DISCONNECTED:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_DEPRECATED:BOOL=ON -DUSE_OPTIMIZED_BLAS:BOOL=ON -DBUILD_TESTING:BOOL=ON -DCMAKE_COLOR_MAKEFILE:BOOL=OFF /usr/ports/math/lapack/work/lapack-3.12.1
And then to build:

/usr/local/bin/cmake -S/usr/ports/math/lapack/work/lapack-3.12.1 -B/usr/ports/math/lapack/work/.build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/local/bin/cmake -E cmake_progress_start /usr/ports/math/lapack/work/.build/CMakeFiles /usr/ports/math/lapack/work/.build//CMakeFiles/progress.marks

[martin-frbg]

Got it - the spurious LDAWORK appears in the 64-bit version of cgelsx.f.o (SRC/DEPRECATED/cgelsx.f has a call the CUNM2R that has the comma after the LDA in column 70 - which looks totally safe until CUNM2R gets expanded to CUNM2R_64

[martin-frbg]

One TAA is the TAU in a call to DORM2R from SRC/DEPRECATED/dgeqpf.f, where the trailing comma is initially in column 71
and the continuation line starts with an "A" array . Another is sgeqpf.f (obviously the latter is the one @angsch already identified)

[martin-frbg]

Created a PR to fix the three identified sources. As far as I can tell by running nm on the generated library, there are currently no other suspicious symbols. But I can't help feeling that the code base has become a bit fragile, given that there are probably many perfectly legal lines ending close to the column limit that has been surreptitiously moved a few characters further in than a Fortran programmer would expect.

[langou]

Please try #1099 from @martin-frbg
Thanks @martin-frbg
I agree with the comment of "the code base has become a bit fragile", I think that'll stabilize soon.

[thierry-FreeBSD]

Great! I don't know about Arch Linux, but I can confirm that with commit 447fd4e lapack builds fine on FreeBSD -CURRENT, with clang-19 and gfortran-13.

And all the tests pass:

…
87/94 Test #52: LAPACK-xeigtstc_svd_in ...........   Passed    9.60 sec
88/94 Test #47: LAPACK-xlintstc_ctest_in .........   Passed   14.93 sec
89/94 Test #94: LAPACK-xlintstzc_zctest_in .......   Passed    1.63 sec
90/94 Test #76: LAPACK-xeigtstz_zec_in ...........   Passed    9.56 sec
91/94 Test #75: LAPACK-xeigtstz_svd_in ...........   Passed   10.47 sec
92/94 Test #69: LAPACK-xdmdeigtstc_cdmd_in .......   Passed   14.78 sec
93/94 Test #92: LAPACK-xdmdeigtstz_zdmd_in .......   Passed   14.66 sec
94/94 Test #70: LAPACK-xlintstz_ztest_in .........   Passed   21.50 sec

100% tests passed, 0 tests failed out of 94