Can't compile because routines declare nonstandard intrinsics

[vansnyder]

I can't compile INSTALL/dsecnd_INT_ETIME.f because it declares ETIME to be intrinsic.

I can't compile most of the z* routines in BLAS/SRC and SRC because they declare DCMPLZ, DCONJG, and DIMAG to be intrinsic.

DCONJG can be changed to CONJG, and DIMAG can be changed to AIMAG, by sed because they're generic and return a result value of the same kind as their argument.

This doesn't work for DCMPLX because CMPLX accept arguments of any numeric type but always returns a default complex kind, that is, the real and imaginary parts are the same kind as default real. It is necessary to add KIND= argument with a type parameter value for double precision kind, say KIND(0.0d0), to specify the result kind.

None of these routines were ever part of any Fortran standard and many contemporary compilers such as Intel's ifx and NAG's nagfor reject them.

Most of the z* routines use COMPLEX*16, which was never part of any Fortran standard (nor was REAL*4 or REAL*8)

I've repaired these problems (except for ETIME) — and added "implicit NONE" — so that BLAS/SRC and SRC compile at least with ifx, nagfor, and gfortran. I don't have flang. To whom should I send them?

LAPACK and BLAS are NOT Fortran 90. They're processor-dependent extensions of Fortran 77.

[martin-frbg]

How are you compiling ? I believe the CMake build should already take care of this based on the platform and compiler names. For the older Makefile system, you need to copy the appropriate make.inc from the INSTALL directory to get the relevant definitions. And there is no claim that everything is strictly F90 - most of the code base is older than that and a modern compiler could be expected to cope

[vansnyder]

On Thu, 2026-02-26 at 23:02 -0800, Martin Kroeker wrote: How are you compiling ? I believe the CMake build should already take care of this based on the platform and compiler names. For the older Makefile system, you need to copy the appropriate make.inc from the INSTALL directory to get the relevant definitions. And there is no claim that everything is strictly F90 - most of the code base is older than that and a modern compiler could be expected to cope

I use the current versions of NAG and Intel Fortran compilers. I don't have flang. I rarely use gfortran for a variety of reasons, one being that I was forbidden to use it where I worked before retiring. I have edited all of lapack-3.12.1/BLAS/SRC and lapack-3.12.1/src so that all files compile without complaints other than "Obsolescent" remarks about labeled DO loops. Do you want the edited codes? There are organizations that have standards about what compilers can be used, and what options could be used. These important codes ought to be available to them.

— Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: <Reference-LAPACK/lapack/repo- ***@***.***>

[1] view it on GitHub #1193 (comment) [2] unsubscribe https://github.com/notifications/unsubscribe-auth/AFMNQ662P7PWJMHAV4BTGWD4N7TXVAVCNFSM6AAAAACWBFK3MCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJUGMZDIMQ

[martin-frbg]

You can create a pull request if you like, but as I said - none of this should be strictly necessary, unless NAG changed something in their compiler fairly recently

[langou]

I am not against the change but PR are coming this way, first, thanks a lot to help out, second, I suggest to make a small limited PR for maybe a handful of routines, so that it is less overwhelming to review. If the changes require to do it all at once, well, so be it. But if it is a possible to first present a limited-in-scope PR this would be my preference.

[vansnyder]

On Fri, 2026-02-27 at 00:48 -0800, Martin Kroeker wrote: You can create a pull request if you like, but as I said - none of this should be strictly necessary, unless NAG changed something in their compiler fairly recently

Have you compiled z*.f with NAG? What command line options did you use to allow it to accept nonstandard intrinsic declarations?

— Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: <Reference-LAPACK/lapack/repo- ***@***.***>

[1] view it on GitHub #1193 (comment) [2] unsubscribe https://github.com/notifications/unsubscribe-auth/AFMNQ6ZAJHBXBB2TA5PIKS34OAAHFAVCNFSM6AAAAACWBFK3MCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJUGQZDIMI

[Baerenwalder]

I believe NAGFOR can use -dcfuns option for this as the documentation states:

-dcfuns
Enable recognition of non-standard double precision complex intrinsic functions. These act as specific versions of the standard generic intrinsics as follows:

Non-standard | Equivalent Standard Fortran Generic Intrinsic Function
CDABS(A) | ABS(A)
DCMPLX(X,Y) | CMPLX(X,Y,KIND=KIND(0d0))
DCONJG(Z) | CONJG(Z)
DIMAG(Z) | AIMAG(Z)
DREAL(Z) | REAL(Z) or DBLE(Z)

(https://support.nag.com/nagware/np/r72_doc/nagfor.html)

The make.inc.nagfor also lists it:
https://github.com/Reference-LAPACK/lapack/blob/master/INSTALL/make.inc.nagfor

[vansnyder]

On Fri, 2026-02-27 at 09:01 -0800, langou wrote: I am not against the change but PR are coming this way, first, thanks a lot to help out, second, I suggest to make a small limited PR for maybe a handful of routines, so that it is less overwhelming to review. If the changes require to do it all at once, well, so be it. But if it is a possible to first present a limited-in-scope PR this would be my preference.

I edited the z*.f files so this obscure command-line option isn't needed. Do you want the files?

— Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: <Reference-LAPACK/lapack/repo- ***@***.***>

[1] view it on GitHub #1193 (comment) [2] unsubscribe https://github.com/notifications/unsubscribe-auth/AFMNQ67JOIBJ3Y22546NYYD4OB2APAVCNFSM6AAAAACWBFK3MCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJUHEYTEMA

[vansnyder]

On Fri, 2026-02-27 at 10:39 -0800, Heiko Weichelt wrote: I believe NAGFOR can use -dcfuns option for this as the documentation states:

I edited the z*.f files so this obscure option isn't needed. Do you want the files?

-dcfuns Enable recognition of non-standard double precision complex intrinsic functions. These act as specific versions of the standard generic intrinsics as follows: Non-standard | Equivalent Standard Fortran Generic Intrinsic Function CDABS(A) | ABS(A) DCMPLX(X,Y) | CMPLX(X,Y,KIND=KIND(0d0)) DCONJG(Z) | CONJG(Z) DIMAG(Z) | AIMAG(Z) DREAL(Z) | REAL(Z) or DBLE(Z) (https://support.nag.com/nagware/np/r72_doc/nagfor.html) — Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you authored the thread.Message ID: <Reference-LAPACK/lapack/repo- ***@***.***>

[1] view it on GitHub #1193 (reply in thread) [2] unsubscribe https://github.com/notifications/unsubscribe-auth/AFMNQ62MGV7CSTRBWPMPTHL4OCFO3AVCNFSM6AAAAACWBFK3MCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJVGAYDKMY