WIP: LLVM flang 16.0.x

[h-vetinari]

Trying #25 + update to 16.0

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[h-vetinari]

@isuruf, aside from windows not working yet, I'd be glad to have your input on how a future libflang output should look in an LLVM world. Instead of libflang.so, we now have:

[...]
-- Installing: $PREFIX/include/flang/Version.inc
-- Installing: $PREFIX/lib/libFortranCommon.so.16
-- Installing: $PREFIX/lib/libFortranCommon.so
-- Installing: $PREFIX/lib/libFortranEvaluate.so.16
-- Installing: $PREFIX/lib/libFortranEvaluate.so
-- Installing: $PREFIX/lib/libFortranDecimal.so.16
-- Installing: $PREFIX/lib/libFortranDecimal.so
-- Installing: $PREFIX/lib/libFortranLower.so.16
-- Installing: $PREFIX/lib/libFortranLower.so
-- Installing: $PREFIX/lib/libFortranParser.so.16
-- Installing: $PREFIX/lib/libFortranParser.so
-- Installing: $PREFIX/lib/libFortranSemantics.so.16
-- Installing: $PREFIX/lib/libFortranSemantics.so
-- Installing: $PREFIX/lib/libflangFrontend.so.16
-- Installing: $PREFIX/lib/libflangFrontend.so
-- Installing: $PREFIX/lib/libflangFrontendTool.so.16
-- Installing: $PREFIX/lib/libflangFrontendTool.so
-- Installing: $PREFIX/lib/libFIRBuilder.so.16
-- Installing: $PREFIX/lib/libFIRBuilder.so
-- Installing: $PREFIX/lib/libFIRCodeGen.so.16
-- Installing: $PREFIX/lib/libFIRCodeGen.so
-- Installing: $PREFIX/lib/libFIRDialect.so.16
-- Installing: $PREFIX/lib/libFIRDialect.so
-- Installing: $PREFIX/lib/libHLFIRDialect.so.16
-- Installing: $PREFIX/lib/libHLFIRDialect.so
-- Installing: $PREFIX/lib/libHLFIRTransforms.so.16
-- Installing: $PREFIX/lib/libHLFIRTransforms.so
-- Installing: $PREFIX/lib/libFIRSupport.so.16
-- Installing: $PREFIX/lib/libFIRSupport.so
-- Installing: $PREFIX/lib/libFIRTransforms.so.16
-- Installing: $PREFIX/lib/libFIRTransforms.so
-- Installing: $PREFIX/lib/libFIRAnalysis.so.16
-- Installing: $PREFIX/lib/libFIRAnalysis.so
-- Installing: $PREFIX/lib/cmake/flang/FlangTargets.cmake
[...]

I'm guessing libflang would then be the totality of those shared libs? Or do we want to drop that output?

[isuruf]

None of those. Those are for the compiler and not runtime libraries for compiled projects.

[h-vetinari]

None of those. Those are for the compiler and not runtime libraries for compiled projects.

Thanks. I didn't know what was in the old libflang. I guess that role's then being filled by compiler-rt, and we don't need the libflang output anymore?

[isuruf]

No, it's replaced by libFortranRuntime.so

[h-vetinari]

No, it's replaced by libFortranRuntime

OK, sounds good. It might also be necessary to add libFortran_main.a to that? (being installed together as below looks like an indicator that they're from the same target)

[...]
-- Installing: $PREFIX/bin/fir-opt
-- Installing: $PREFIX/lib/libFortranRuntime.16.dylib
-- Installing: $PREFIX/lib/libFortranRuntime.dylib
-- Installing: $PREFIX/lib/libFortran_main.a

Resource usage statistics from building flang-split:

[isuruf]

It might also be necessary to add libFortran_main.a to that

No. It shouldn't be needed at runtime. Maybe as a libfortran-main_{{ target_platform }} output to allow cross compilation.

[h-vetinari]

@isuruf, I'm getting closer here (though the turn-arounds are glacial...): no more segfaults on osx and windows builds 🥳

Both problems were "solved" by switching to static builds. I can eventually raise issues for that upstream, but for now passing-on-static is way better than being blocked on shared libs (especially for a compiler package), because we're on a pretty tight schedule here for building scipy on windows for CPython 3.12 in a post-distutils world (without a suitable Fortran compiler, we won't be able to build scipy for 3.12 on windows otherwise), and I'd like to push on this a bit further (meson, scipy, etc., raising flang bugs upstream) before then.

Where I'd really need your help is in deciding the overall direction:

• do we want to call this flang or llvm-flang? Upstream decided they'll aim for separate names in distributions for a while yet until it's ready to fully supplant classic flang. I don't think we're really affected by this and could just go with flang.
  • By extension this will probably determine whether we need/want a new feedstock or change this one
• Compiler activation: Do we want/need a separate feedstock for that? I couldn't get the sysroot to be found without the setup that {{ compiler('cxx') }} is doing (but failed to emulate it here myself), so as a hack I'm currently including that in the test environment
• How to deal with libfortran-main - you mentioned this as a "maybe" to allow cross-compilation. I've tried to add it here but don't really understand what needs to be done here.

Of course the commit history needs a clean-up and there's some rough corners still here and there - I'm not asking for a detailed review, but mostly for direction.

[h-vetinari]

OK, that last commit is mis-diagnosed, it's not actually a merge of build & host, but for some reason, flang's very vanilla host-deps

      host:
        - clangdev =={{ version }}
        - compiler-rt =={{ version }}
        - llvm-openmp =={{ version }}
        - llvmdev =={{ version }}
        - mlir =={{ version }}
        # for required run-exports
        - llvm =={{ version }}
        - libclang-cpp =={{ version }}
        - {{ pin_subpackage('libflang', exact=True) }}
        - {{ pin_subpackage('libfortran-main', exact=True) }}

cause gcc to be installed, which pulls in libgomp. I cannot determine where a run-time dependence on gcc would be coming from?! It also looks inconsistent to me that _openmp_mutex allows the presence of both libgomp and llvm-openmp in the same environment.

The following NEW packages will be INSTALLED [filtered]:

    _openmp_mutex:           4.5-2_gnu                 conda-forge
    gcc_impl_linux-64:       13.1.0-hc4be1a9_0         conda-forge
    libflang:                16.0.5-h59595ed_0         local      
    libfortran-main:         16.0.5-ha770c72_0         local      
    libgomp:                 13.1.0-he5830b7_0         conda-forge
    llvm-openmp:             16.0.5-h4dfa4b3_0         conda-forge

[h-vetinari]

As an update: the last hurdle here is how to link the compiler-rt libs on windows by default. I've asked in the issue upstream, and it seems (AFAICT) that there's something about /MT vs. /MD slipping in somewhere.

> flang-new -flang-experimental-exec hello_world.f90
FortranDecimal.lib(binary-to-decimal.cpp.obj) : error LNK2019: unresolved external symbol __udivti3 [snip]
> flang-new -flang-experimental-exec hello_world.f90 -l path\to\clang_rt.builtins-x86_64.lib
LINK : warning LNK4098: defaultlib 'libcmt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
> flang-new -flang-experimental-exec hello_world.f90 -l path\to\clang_rt.builtins-x86_64.lib -Wl,/NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib 'libcmt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library

More details

[h-vetinari]

Some notes from a 1:1 sync with Isuru (please let me know if I got something wrong):

• Currently {{ compiler('cxx') }} in the test environment is necessary to properly find the sysroot on linux because of this; however the GCC-activation will set CONDA_BUILD_SYSROOT, which is then picked up through our patched clang.
• libgfortran_main needs to depend on libgfortran_main_{{ cross_platform }} (not the other way around), and we need to put it on a path that's distinct per target triple to support e.g. having both x64 & aarch64 in the same environment (this will likely need patching of flang)
• for windows, we'll probably need to do something like the clang-win activation does to set +/- the equivalent of /MD, which will also likely have to go into a separate feedstock
• we're going to drop osx builds for now, as one compiler per language & platform is enough (and in contrast to clang, which can target the gcc runtime, flang cannot target gfortran). We're still keeping linux because it's easier to debug for general problems, but will have to make it conflict with libgfortran-ng.

Independently, I came across some indications in discussions upstream that the missing __udivti3 symbol on windows is very likely related to default 128-bit support; I hope it may be possible to switch that off completely, which would probably save us from having to deal with compiler-rt at runtime.

[h-vetinari]

It looks like the runtime libs will get shuffled around quite a bit, see https://reviews.llvm.org/D154869. I'm not sure if this will land before the branch at the end of the month; I've asked in the discourse thread.

[h-vetinari]

Superseded by #28