Compiling on Windows using flang natively.

[R-Goc]

I tried compiling natively (as in not mingw or msys2) and hit a few issues.
First one was a missing module file (maybe the build graph was wrong?) but running ninja with -k0 it didn't seem to show up again(though with the amount of output I might have missed it. specialfunctions_legendre was trying to be built before specialfunctions.mod existed. As after a clean I didn't hit it again, it seems non deterministic probably due to the parallel build.
Second one is:

D:\\lib\\stdlib\\build\\src\\stdlib_math.f90:25:45: warning: acos(real(kind=10)) cannot be folded on host
        real(kind=xdp), parameter :: PI_xdp = acos(-1.0_xdp)
                                              ^^^^^^^^^^^^^^
D:\\lib\\stdlib\\build\\src\\stdlib_math.f90:25:45: error: Value of named constant 'pi_xdp' (acos(-1._10)) cannot be computed as a constant value
        real(kind=xdp), parameter :: PI_xdp = acos(-1.0_xdp)

It appears as though a lot (or all?) math functions are non-constant. atan2 log and probably others also say cannot be folded on host.
third one:

error: Semantic errors in src\CMakeFiles\fortran_stdlib.dir\stdlib_error.f90-pp.f90
D:\\lib\\stdlib\\build\\src\\stdlib_error.f90:245:14: error: Left-hand side of assignment is not definable
               ierr_out = ierr
               ^^^^^^^^
D:\\lib\\stdlib\\build\\src\\stdlib_error.f90:245:14: because: 'ierr_out' is polymorphic in a pure subprogram
               ierr_out = ierr
               ^^^^^^^^
D:\\lib\\stdlib\\build\\src\\stdlib_error.f90:239:56: Declaration of 'ierr_out'
           class(state_type), optional, intent(inout) :: ierr_out
                                                         ^^^^^^^^

[R-Goc]

There is also this:

lld-link: error: undefined symbol: __extendxftf2
>>> referenced by test-drive.lib(testdrive.F90.obj):(_QMtestdrivePcheck_float_xdp)
>>> referenced by test-drive.lib(testdrive.F90.obj):(_QMtestdrivePcheck_float_xdp)
>>> referenced by test-drive.lib(testdrive.F90.obj):(_QMtestdrivePcheck_float_xdp)
>>> referenced 7 more times

lld-link: error: undefined symbol: __trunctfxf2
>>> referenced by test-drive.lib(testdrive.F90.obj):(_QMtestdrivePcheck_float_xdp)
>>> referenced by test-drive.lib(testdrive.F90.obj):(_QMtestdrivePcheck_float_xdp)
>>> referenced by test-drive.lib(testdrive.F90.obj):(_QMtestdrivePcheck_float_xdp)
>>> referenced 4 more times

lld-link: error: undefined symbol: _FortranACAbsF128
>>> referenced by test-drive.lib(testdrive.F90.obj):(_QMtestdrivePcheck_complex_xdp)
>>> referenced by test-drive.lib(testdrive.F90.obj):(_QMtestdrivePcheck_complex_xdp)
>>> referenced by test-drive.lib(testdrive.F90.obj):(_QMtestdrivePcheck_complex_xdp)
[2/705] Building Fortran object src\CMakeFiles\fortran_stdlib.dir\stdlib_error.f90.obj

The first two I know from C++ and clang on windows. They are due to the compiler runtime from the compiler not being linked(instead it links the msvc provided one with clang). Not sure how it would work here as flang uses a different runtime, not compiler-rt afaik. The lib to link with clang to work around these is clang_rt.builtins.yourarch.lib; but I don't see a different builtins lib for flang.
Edit: on second look I see the linker have the clang runtime dir as a libpath. However these symbols are not part of the clang builtins so I assume this is not supported either.

For the last symbol, I don't see it in the fortran runtime from flang so I assume it is not supported yet. However, this error being here is a bit weird as cmake did check for real128 and fail, so I think this should not be being included?
The builds gets stuck on these errors with 700 jobs left.

[jalvesz]

Looks like flang is getting stuck with extended precision support, I have zero experience with this compiler so can't really say much about the error messages. Have you tried building without extended precision support? -DWITH_XDP=False

[R-Goc]

That's what I meant by the last part. The check for real128 failed so I thought extended precision support would be off. I'll try tomorrow.

[jalvesz]

real128 corresponds to quadruple precision (qp), the extended precision is in-between double and quadruple. Would seem like somehow in the building process it passes. I would say check indeed forcing -DWITH_XDP=False -DWITH_QP=False (to avoid extendend and quadruple precisions)

[R-Goc]

Ah. Ok so like long double potentially being there. The 80bit float type.

[R-Goc]

The amount of errors that gets thrown (mostly repeated, but they make it unreadable) makes me think that this compiler just isn't there yet. At least not on windows. Running llvm version 20.1.0.

Doing a build without the missing float types did show an interesting new error though:

D:\\lib\\stdlib\\build\\src\\stdlib_math_linspace.f90:26:28: error: Result of function 'linspace_n_1_rsp_rsp' is not compatible with the result of the corresponding interface body: function results have distinct extents (max(0_8,int(max(n,0_4),kind=8)) vs max(0_8,int(max(n,0_4),kind=8)))
        pure module function linspace_n_1_rsp_rsp(start, end, n) result(re&
                             ^^^^^^^^^^^^^^^^^^^^
D:\lib\stdlib\build\src\mod_files\stdlib_math.mod:75:22: Declaration of 'linspace_n_1_rsp_rsp'
  module pure function linspace_n_1_rsp_rsp(start,end,n) result(res)
                       ^^^^^^^^^^^^^^^^^^^^
D:\\lib\\stdlib\\build\\src\\stdlib_math_linspace.f90:55:28: error: Result of function 'linspace_n_1_rdp_rdp' is not compatible with the result of the corresponding interface body: function results have distinct extents (max(0_8,int(max(n,0_4),kind=8)) vs max(0_8,int(max(n,0_4),kind=8)))
        pure module function linspace_n_1_rdp_rdp(start, end, n) result(re&
                             ^^^^^^^^^^^^^^^^^^^^
D:\lib\stdlib\build\src\mod_files\stdlib_math.mod:84:22: Declaration of 'linspace_n_1_rdp_rdp'
  module pure function linspace_n_1_rdp_rdp(start,end,n) result(res)
                       ^^^^^^^^^^^^^^^^^^^^

I guess it's a compiler bug.

[jalvesz]

I was actually surprised of this issue being opened as, as of now, my understanding from flang's documentation is that it should not be seen as a production-ready compiler https://flang.llvm.org/docs/

LLVM Flang is under active development. While it is capable of generating executables for a number of examples, some functionality is still missing.

Is your objective using flang? or just building for windows? if so, intel compilers can be used or GNU compilers from equation.com https://www.equation.com/servlet/equation.cmd?fa=fortran can also be used on Windows. Conda also enables installing gcc/fortran.

[R-Goc]

My objective was seeing how far along flang is. I opened the issue thinking it may be something about the build config not playing nicely, but it looks like the compiler just needs more work.

[jalvesz]

I think flang developers would appreciate being alerted of these issues, maybe they could use it to check for missing features?

If that's ok, I think this issue can be closed as it doesn't seem to be an issue with stdlib but the compiler.

[R-Goc]

Indeed.