Openblas: Fortran API.

[ChinouneMehdi]

In modern Fortran we use modules which include explicit interface to functions and subroutines.
Could you please make interface to OpenBLAS for modern Fortran.
other Remark: you claim that the project is written in Fortran but it is not.

[martin-frbg]

I suspect this may be better addressed at the netlib LAPACK/BLAS level, as the Fortran parts of OpenBLAS are copies taken from that project. ("Patches welcome" at both projects I guess, and from my limited understanding of the topic the mod file you requested could probably be created simply from
concatenating the declarations extracted from the beginning of the individual source files.)

[brada4]

You can use netlib lapack source in place of MOD files in archaic compilers. Having full source renders mod files unneeded.

[martin-frbg]

Did (or could) you check that netlib/lapack95 is sufficient for your needs, or would at least serve as a good starting point ? My impression was that work on it stopped sometime in 2000 while netlib LAPACK itself is still in active development and receiving new functions with every major release.

[brada4]

You can unzip that lapack95, it is just primitive wrappers around BLAS. It will not give you MOD files for latest IFORT.EXE

[brada4]

@ChinouneMehdi thank you for explanation. Maybe continue on with telling what fortran is.
I really dont understand what takes you 2 days to generate MOD files from NetLib LAPACK sources. They will be 100% valid for OpenBLAS which provides exactly same API.
If you want 17 years unmaintained lapack95 - go ahead, 8 lapack functions are deprecated since, it will not compile right away.

[brada4]

I just see one problem - one cannot create MOD file from OpenBLAS where all BLAS is rewritten in C. Nowadays that pertains just one single compiler.

[martin-frbg]

As stated above, most of the LAPACK parts are copied from https://github.com/Reference-LAPACK/lapack (which is still written in Fortran) so if anything the "project languages" entry would have to be Fortran+C+asm. My guess is that github supported only a single language option earlier and/or Fortran
was picked as the most unusual (i.e. not usually present in default installations of the supported operating systems).
As the API is still compatible with the netlib reference libraries, I am _guessing_ that a MOD file created for these would still be usable in an OpenBLAS (or ATLAS,...) context. (Hence my earlier suggestion that this issue probably belongs in the hands of the reference-lapack maintainers)

[martin-frbg]

FWIW the "Fortran" language tag on the project appears to be auto-generated by the github linguist tool (seems plausible to me that Fortran makes up the majority of files due to inclusion of netlib reference implementations of both LAPACK and (unused) BLAS), there does not seem to be an easy way to change this (short of adding otherwise useless .git property files everywhere) and no way at all to achieve the "C + Asm" tag you suggested.

[loveshack]

OpenBLAS doubtless isn't the place to define a modern (f2003?) interface which really should exist. However, it would be good not to have ignorant noise about Fortran in response to the request.

[brada4]

You can generate MOD file from netlib lapack sources. That is all the interface you need (though there is no need whatsoever to extract prototypes having them in .f source files)

[brada4]

normally $FC -c *.f
(you can try to get asterisk from exported symbols in libopenblas.so too)

[brada4]

got you :)
You need to extract prototypes from *f files, then wrap them off with end subroutine
. module blas contains subroutine DAXPY(....) (just definitions of attributes) end subroutine daxpy subroutine ... ... end module

[brada4]

Approx:
extract prototype lines from *.f found between lines
* =====================================================================
Strip comments
add END after each subroutine
concatenate into f90 file, wrap into module... interface ... end .. end ?

[loveshack]

Approx:
extract prototype lines from *.f found between lines

Fortran doesn't have prototypes.

* =====================================================================
Strip comments
add END after each subroutine
concatenate into f90 file, wrap into module... interface ... end .. end ?

Well, we have tools to derive trivial F77-style interfaces. That's not
"modern Fortran", which has polymorphism, and properties like INTENT,
KIND, OPTIONAL, and even PURE.

[martin-frbg]

May I respectfully suggest (again) that this issue should be addressed to the netlib LAPACK developers at https://github.com/Reference-LAPACK/lapack ? (And please refrain from continuing that spat about what is or is not modern (about) FORTRAN)

[mattcbro]

Openblas is definitely not the place to ask for "nonstandard" Fortran interfaces. One problem is that so called modern Fortran is too restrictive in their definition of pure functions, so that there is no real way to wrap any BLAS or Lapack function in a pure function wrapper.

Gfortran requires that any subfunction or subroutine that is called have no side effects. So even if you make it so that such side effects do not effect the input variables, or even if BLAS is multi-thread safe, it still will not allow it. The reason why we need pure functions in Fortran is an additional restriction on the languages parallel do idioms, such as concurrent do. They restrict all calls in the function body to be pure.

It's actually a Fortran standards problem I think, and a limitation in what the compiler can do. It would be nice if we could downgrade some of the restrictions to warnings at least so that some of the intrinsic parallelization could be more easily integrated with our standard dense linear algebra functions.

[brada4]

OpenBLAS is written in C and assembly. Upstream LAPACK is written in F77.

[martin-frbg]

netlib issue created, hopefully discussion and/or eventual implementation can continue there.

[loveshack]

Openblas is definitely not the place to ask for "nonstandard" Fortran
interfaces. One problem is that so called modern Fortran is too
restrictive in their definition of pure functions, so that there is no
real way to wrap any BLAS or Lapack function in a pure function
wrapper.

This issue should surely be closed, but I'm puzzled how the proprietary
Intel MKL blas95/lapack95 wrappers aren't standard-conforming, and what
the problem is with gfortran, which they support.