[flang] Problems building flang 16.0.x following standalone build instructions

I'm trying to build Flang for conda-forge, but running into several issues of differing severity:

[x] https://flang.llvm.org/docs/ has no build instructions, this should be added; for now I'm following the standalone build instructions from the README.
[ ] The dependency target "Bye" of target "check-flang-*" does not exist.
- worked around by -DFLANG_INCLUDE_TESTS=OFF
[x] compilation hangs on Linux/Windows
- seems to OOM not exactly powerful public CI agents, worked around by passing -j1
[ ] correct cmake module path not automatically set up (esp. on windows)
- worked around by passing -DCMAKE_MODULE_PATH, could be done automatically like (e.g.) for lld
[ ] -DFLANG_ENABLE_WERROR=ON not suitable for windows
- worked around by simple removal; remove from build instructions?
[ ] building with msvc needs linkage to compiler-rt, incompatible with how HandleCompilerRT.cmake is currently written, see also #25679
- [ ] missing linkage of FortranParser to FortranCommon?
[ ] compilation error for linux-ppc64le
[x] ~missing Scrt1.o / crti.o when running flang-new on linux~ solved by pointing to correct sysroot
[ ] segfault when running flang-new on osx

The dependency target "Bye" of target "check-flang-*" does not exist.

```console CMake Error at [...]/lib/cmake/llvm/AddLLVM.cmake:1915 (add_dependencies): The dependency target "Bye" of target "check-flang" does not exist. The dependency target "Bye" of target "check-flang-cmakefiles" does not exist. The dependency target "Bye" of target "check-flang-nongtestunit" does not exist. The dependency target "Bye" of target "check-flang-unit" does not exist. The dependency target "Bye" of target "check-flang-lib" does not exist. The dependency target "Bye" of target "check-flang-lib-analysis" does not exist. The dependency target "Bye" of target "check-flang-lib-analysis-aliasanalysis" does not exist. The dependency target "Bye" of target "check-flang-lib-analysis-aliasanalysis-cmakefiles" does not exist. The dependency target "Bye" of target "check-flang-lib-analysis-cmakefiles" does not exist. The dependency target "Bye" of target "check-flang-lib-cmakefiles" does not exist. ```

cmake module path

```console CMake Error at CMakeLists.txt:51 (find_compiler_rt_library): Unknown CMake command "find_compiler_rt_library". ```

missing linkage of FortranCommon to FortranParser

```console [107/323] Linking CXX shared library bin\FortranParser.dll FAILED: bin/FortranParser.dll lib/FortranParser.lib cmd.exe /C "cd . && %BUILD_PREFIX%\Library\bin\cmake.exe -E vs_link_dll --intdir=lib\Parser\CMakeFiles\FortranParser.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests -- C:\PROGRA~1\LLVM\bin\lld-link.exe /nologo lib\Parser\CMakeFiles\obj.FortranParser.dir\Fortran-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\char-buffer.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\char-block.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\char-set.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\characters.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\debug-parser.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\executable-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\expr-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\instrumented-parser.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\io-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\message.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\openacc-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\openmp-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\parse-tree.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\parsing.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\preprocessor.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\prescan.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\program-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\provenance.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\source.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\token-sequence.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\tools.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\unparse.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\user-state.cpp.obj /out:bin\FortranParser.dll /implib:lib\FortranParser.lib /pdb:bin\FortranParser.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO -LIBPATH:%PREFIX%\Library\lib %PREFIX%\Library\lib\clang\16.0.1\lib\windows\clang_rt.builtins-x86_64.lib lib\FortranCommon.lib %PREFIX%\Library\lib\LLVMSupport.lib %PREFIX%\Library\lib\LLVMFrontendOpenACC.lib %PREFIX%\Library\lib\clang\16.0.1\lib\windows\clang_rt.builtins-x86_64.lib %PREFIX%\Library\lib\LLVMSupport.lib psapi.lib shell32.lib ole32.lib uuid.lib advapi32.lib %PREFIX%\Library\lib\z.lib %PREFIX%\Library\lib\zstd.lib delayimp.lib -delayload:shell32.dll -delayload:ole32.dll %PREFIX%\Library\lib\LLVMDemangle.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ." LINK: command "C:\PROGRA~1\LLVM\bin\lld-link.exe /nologo lib\Parser\CMakeFiles\obj.FortranParser.dir\Fortran-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\char-buffer.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\char-block.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\char-set.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\characters.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\debug-parser.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\executable-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\expr-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\instrumented-parser.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\io-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\message.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\openacc-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\openmp-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\parse-tree.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\parsing.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\preprocessor.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\prescan.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\program-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\provenance.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\source.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\token-sequence.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\tools.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\unparse.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\user-state.cpp.obj /out:bin\FortranParser.dll /implib:lib\FortranParser.lib /pdb:bin\FortranParser.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO -LIBPATH:%PREFIX%\Library\lib %PREFIX%\Library\lib\clang\16.0.1\lib\windows\clang_rt.builtins-x86_64.lib lib\FortranCommon.lib %PREFIX%\Library\lib\LLVMSupport.lib %PREFIX%\Library\lib\LLVMFrontendOpenACC.lib %PREFIX%\Library\lib\clang\16.0.1\lib\windows\clang_rt.builtins-x86_64.lib %PREFIX%\Library\lib\LLVMSupport.lib psapi.lib shell32.lib ole32.lib uuid.lib advapi32.lib %PREFIX%\Library\lib\z.lib %PREFIX%\Library\lib\zstd.lib delayimp.lib -delayload:shell32.dll -delayload:ole32.dll %PREFIX%\Library\lib\LLVMDemangle.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:bin\FortranParser.dll.manifest" failed (exit code 1) with the following output: lld-link: error: undefined symbol: void __cdecl Fortran::common::die(char const *, ...) >>> referenced by lib\Parser\CMakeFiles\obj.FortranParser.dir\Fortran-parsers.cpp.obj:(public: class std::optional __cdecl Fortran::parser::AlternativesParser, class Fortran::parser::FollowParser>, class Fortran::parser::ApplyConstructor>>>, class Fortran::parser::ApplyConstructor>>, class Fortran::parser::ApplyConstructor>, class Fortran::parser::ApplyConstructor, struct Fortran::parser::Parser>>>>>, class Fortran::parser::TokenStringMatch<0, 0>>>>, class Fortran::parser::NonstandardParser<14, class Fortran::parser::ApplyConstructor, class Fortran::parser::FollowParser>>>>>::Parse(class Fortran::parser::ParseState &) const) >>> referenced by lib\Parser\CMakeFiles\obj.FortranParser.dir\Fortran-parsers.cpp.obj:(public: class std::optional __cdecl Fortran::parser::ApplyConstructor, class Fortran::parser::TokenStringMatch<0, 0>>, class Fortran::parser::AlternativesParser, class Fortran::parser::PureParser>, class Fortran::parser::SequenceParser, class Fortran::parser::PureParser>>, class Fortran::parser::SequenceParser, class Fortran::parser::WithMessageParser, class Fortran::parser::TokenStringMatch<0, 0>>>>>::Parse(class Fortran::parser::ParseState &) const) >>> referenced by lib\Parser\CMakeFiles\obj.FortranParser.dir\Fortran-parsers.cpp.obj:(public: class std::optional __cdecl Fortran::parser::ApplyConstructor, class Fortran::parser::MaybeParser, class Fortran::parser::ApplyConstructor>>>, class Fortran::parser::ApplyConstructor>>, class Fortran::parser::ApplyConstructor>, class Fortran::parser::ApplyConstructor, struct Fortran::parser::Parser>>>>>>>::Parse(class Fortran::parser::ParseState &) const) >>> referenced 1508 more times ```

compilation error for linux-ppc64le

```console [305/322] Building CXX object runtime/CMakeFiles/obj.FortranRuntime.dir/sum.cpp.o FAILED: runtime/CMakeFiles/obj.FortranRuntime.dir/sum.cpp.o $BUILD_PREFIX/bin/powerpc64le-conda-linux-gnu-c++ -DFLANG_LITTLE_ENDIAN=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I$SRC_DIR/flang/include -I$SRC_DIR/build/include -I$SRC_DIR/build/runtime -fvisibility-inlines-hidden -fmessage-length=0 -mcpu=power8 -mtune=power8 -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O3 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/flang-split-16.0.0.rc3 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -Werror -Wno-deprecated-copy -Wno-ctad-maybe-unsupported -fno-strict-aliasing -fno-semantic-interposition -fno-lto -O3 -DNDEBUG -fno-semantic-interposition -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++17 -fno-exceptions -MD -MT runtime/CMakeFiles/obj.FortranRuntime.dir/sum.cpp.o -MF runtime/CMakeFiles/obj.FortranRuntime.dir/sum.cpp.o.d -o runtime/CMakeFiles/obj.FortranRuntime.dir/sum.cpp.o -c $SRC_DIR/flang/runtime/sum.cpp $SRC_DIR/flang/runtime/sum.cpp: In instantiation of 'bool Fortran::runtime::RealSumAccumulator::Accumulate(A) [with A = __ieee128; INTERMEDIATE = long double]': $SRC_DIR/flang/runtime/sum.cpp:58:22: required from 'bool Fortran::runtime::RealSumAccumulator::AccumulateAt(const Fortran::runtime::SubscriptValue*) [with A = __ieee128; INTERMEDIATE = long double; Fortran::runtime::SubscriptValue = long int]' $SRC_DIR/flang/runtime/reduction-templates.h:60:55: required from 'void Fortran::runtime::DoTotalReduction(const Descriptor&, int, const Descriptor*, ACCUMULATOR&, const char*, Terminator&) [with TYPE = __ieee128; ACCUMULATOR = RealSumAccumulator]' $SRC_DIR/flang/runtime/reduction-templates.h:85:28: required from 'Fortran::runtime::CppTypeFor Fortran::runtime::GetTotalReduction(const Descriptor&, const char*, int, int, const Descriptor*, ACCUMULATOR&&, const char*) [with Fortran::common::TypeCategory CAT = Fortran::common::TypeCategory::Real; int KIND = 16; ACCUMULATOR = RealSumAccumulator; CppTypeFor = __ieee128]' $SRC_DIR/flang/runtime/sum.cpp:143:51: required from here $SRC_DIR/flang/runtime/sum.cpp:51:17: error: Invalid mixing of IEEE 128-bit and IBM 128-bit floating point types 51 | auto next{x + correction_}; | ~~^~~~~~~~~~~~~ ninja: build stopped: subcommand failed. ```

segfault when running flang-new on osx

```console + flang-new -flang-experimental-exec hello_world.f90 PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /Users/runner/miniforge3/conda-bld/flang-split_1681164433960/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/bin/flang-new -fc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -mrelocation-model pic -pic-level 2 -target-cpu core2 -o /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/hello_world-b0b304.o -x f95-cpp-input hello_world.f90 Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 libLLVM-16.dylib 0x000000010ff9e568 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56 1 libLLVM-16.dylib 0x000000010ff9d3d8 llvm::sys::RunSignalHandlers() + 248 2 libLLVM-16.dylib 0x000000010ff9ec73 SignalHandler(int) + 355 3 libsystem_platform.dylib 0x00007fff205dcd7d _sigtramp + 29 4 libsystem_platform.dylib 0x000000010fdac380 _sigtramp + 18446603344534107680 5 libFIRSupport.16.dylib 0x000000011d09afce mlir::StringAttr::get(mlir::MLIRContext*, llvm::Twine const&) + 478 6 libFIRSupport.16.dylib 0x000000011d1683bf mlir::OperationName::Impl::Impl(llvm::StringRef, mlir::Dialect*, mlir::TypeID, mlir::detail::InterfaceMap) + 79 7 libFIRCodeGen.16.dylib 0x000000010ef18b03 mlir::RegisteredOperationName::Model::Model(mlir::Dialect*) + 259 8 libFIRCodeGen.16.dylib 0x000000010eee2f64 void mlir::Dialect::addOperations() + 52 9 libFIRCodeGen.16.dylib 0x000000010eee2cb3 mlir::AffineDialect::initialize() + 35 10 libFIRCodeGen.16.dylib 0x000000010eee2e4f mlir::AffineDialect::AffineDialect(mlir::MLIRContext*) + 143 11 libflangFrontend.16.dylib 0x00000001081ca9b8 std::__1::unique_ptr> llvm::function_ref> ()>::callback_fn()::'lambda'()>(long) + 40 12 libHLFIRDialect.16.dylib 0x000000010fa367b5 mlir::MLIRContext::getOrLoadDialect(llvm::StringRef, mlir::TypeID, llvm::function_ref> ()>) + 245 13 libflangFrontend.16.dylib 0x00000001081c4bfb Fortran::frontend::CodeGenAction::beginSourceFileAction() + 763 14 libflangFrontend.16.dylib 0x00000001081c356b Fortran::frontend::FrontendAction::beginSourceFile(Fortran::frontend::CompilerInstance&, Fortran::frontend::FrontendInputFile const&) + 315 15 libflangFrontend.16.dylib 0x00000001081b5d3f Fortran::frontend::CompilerInstance::executeAction(Fortran::frontend::FrontendAction&) + 207 16 libflangFrontendTool.16.dylib 0x0000000107f5ce01 Fortran::frontend::executeCompilerInvocation(Fortran::frontend::CompilerInstance*) + 3057 17 flang-new 0x0000000107f4f463 fc1_main(llvm::ArrayRef, char const*) + 627 18 flang-new 0x0000000107f4c7a4 main + 820 19 libdyld.dylib 0x00007fff205b2f3d start + 1 flang-new: error: unable to execute command: Segmentation fault: 11 flang-new: error: flang frontend command failed due to signal (use -v to see invocation) flang-new version 16.0.1 Target: x86_64-apple-darwin20.6.0 Thread model: posix InstalledDir: /Users/runner/miniforge3/conda-bld/flang-split_1681164433960/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/bin flang-new: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: flang-new: note: diagnostic msg: /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/hello_world-035f57 flang-new: note: diagnostic msg: /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/hello_world-035f57.sh flang-new: note: diagnostic msg: Crash backtrace is located in flang-new: note: diagnostic msg: /Users/runner/Library/Logs/DiagnosticReports/flang-new__.crash flang-new: note: diagnostic msg: (choose the .crash file that corresponds to your crash) flang-new: note: diagnostic msg: ******************** ```

@llvm/issue-subscribers-flang-build

Thanks for reporting and sorry that you are hitting this :(

Have you checked flang-aarch64-out-of-tree? IIRC, that Buildbot runs two stages:

Build the dependencies of Flang
Build standalone (aka out-of-tree) Flang.

Here's the CMake invocation for the 2nd stage.

HTH, -Andrzej

https://flang.llvm.org/docs/ has no build instructions, this should be added; for now I'm following the standalone build instructions from the README.

You are welcome to add the instructions in https://flang.llvm.org/docs. The website is mostly populated from the docs folder, so adding build instructions as a file in llvm-project/flang/docs will probably be enough.

[33/323] Building CXX object lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/characteristics.cpp.o [34/323] Building CXX object lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/constant.cpp.o [hangs until killed]

Some files in this directory might take some time to build. Could you leave it for a while more and see whether it passes this stage to rule out a hang/infinite loop?

Here's the CMake invocation for the 2nd stage.

Thanks, but I don't see the CMake invocation under that link, just the logs from that (in step 4)

Some files in this directory might take some time to build. Could you leave it for a while more and see whether it passes this stage to rule out a hang/infinite loop?

I meant it when I said it hangs until killed. :)

I'll retry with GCC 12 (our default on linux currently is still 11) in the meantime.

Same problem (hang on linux at the same point) with GCC 12

Thanks for the update!

Here's the CMake invocation for the 2nd stage.

Thanks, but I don't see the CMake invocation under that link, just the logs from that (in step 4)

The UI can be a bit clunky, but the information is there: Screenshot 2023-02-15 at 07 51 10

To save you "clicking", here's stage 1 invocation:

cmake ../llvm-project/llvm -DLLVM_TARGETS_TO_BUILD=AArch64 -DCMAKE_CXX_STANDARD=17 -DLLVM_ENABLE_WERROR=OFF -DLLVM_ENABLE_ASSERTIONS=ON -DCMAKE_BUILD_TYPE=Release '-DLLVM_ENABLE_PROJECTS=llvm;clang;mlir' '-DLLVM_LIT_ARGS=-v -vv' -GNinja

And here's stage 2 invocation:

cmake ../llvm-project/flang -DFLANG_ENABLE_WERROR=ON -DCMAKE_BUILD_TYPE=Release -GNinja -DLLVM_DIR:PATH=../../build_llvm/lib/cmake/llvm -DMLIR_DIR:PATH=../../build_llvm/lib/cmake/mlir -DCLANG_DIR:PATH=../../build_llvm/lib/cmake/clang

I meant it when I said it hangs until killed. :)

Perhaps OOM?

Let's take a step back.

Can you share your CMake invocations?
Do you hit this error only for standalone builds?

-Andrzej

Let's take a step back.

Can you share your CMake invocations?

Of course. This represents the state of the PR I linked. These are following quite closely the instructions I found, slightly adapted for our infrastructure. And the exact same cmake invocation works on osx (windows has a separate script).

Do you hit this error only for standalone builds?

Do to the limitations of public CI (weak agents and a 6h timeout), we cannot build anything else but separately, i.e. standalone (though there are other interests as well, it's really not a choice; even just the library part of llvm takes 4-6h to build).

Here's your CMake invocation:

cmake -G Ninja \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_CXX_STANDARD=17 \
    -DCMAKE_EXPORT_COMPILE_COMMANDS=ON \
    -DCMAKE_INSTALL_PREFIX=$PREFIX \
    -DCMAKE_PREFIX_PATH=$PREFIX \
    -DFLANG_ENABLE_WERROR=ON \
    -DLLVM_BUILD_MAIN_SRC_DIR=.. \
    -DLLVM_EXTERNAL_LIT=$PREFIX/bin/lit \
    -DLLVM_LIT_ARGS=-v \
    -DLLVM_CMAKE_DIR=$PREFIX/lib/cmake/llvm \
    -DCLANG_DIR=$PREFIX/lib/cmake/clang \
    -DFLANG_INCLUDE_TESTS=OFF \
    -DMLIR_DIR=$PREFIX/lib/cmake/mlir \
    ../flang

Note that LLVM_BUILD_MAIN_SRC_DIR is no longer used (README requires updating, CC @psteinfeld who updated it most recently):

$ grep "LLVM_BUILD_MAIN_SRC_DIR" flang/
flang/README.md
190:  -DLLVM_BUILD_MAIN_SRC_DIR=$ROOTDIR/build/lib/cmake/llvm \

This is the buildbot invocaiton:

cmake ../llvm-project/flang \
  -DFLANG_ENABLE_WERROR=ON \
  -DCMAKE_BUILD_TYPE=Release \
  -GNinja -DLLVM_DIR:PATH=../../build_llvm/lib/cmake/llvm \
  -DMLIR_DIR:PATH=../../build_llvm/lib/cmake/mlir \
  -DCLANG_DIR:PATH=../../build_llvm/lib/cmake/clang

Looking at my personal notes (which I have not used in the last 12 months, so no guarantees) I also see that I set

LLVM_DIR,
MLIR_DIR, and
CLANG_DIR. This are basically the key CMake variables here.

Also:

6h timeout

This might be the actual issue here - LLVM Flang is very demanding when it comes to resources. Could you replace:

cmake --build .
cmake --install .

with e.g.:

cmake --build --target bbc

bbc is one of many drivers in LLVM Flang. If this builds fine then we will know that your set-up is correct and that your CI machine might be too constrained for LLVM Flang.

-Andrzej

So before I tried to reduce the targets, I though I'd try to reduce parallelism, and indeed, cmake --build . -j1 progresses further than the default invocation cmake --build .. Will see if it actually runs to completion like that (or if we are able to use -j2 at least, etc.).

But even if that's fully resolved now, it still leaves the question of the test targets (resp. their dependencies) not being found, and the windows issues.

Aside from the other issues (test deps & windows & cross-compilation), I managed to build flang on linux-64 & osx-64, but invocation seems to run into problems:

+ flang-new -flang-experimental-exec hello_world.f90
/home/conda/feedstock_root/build_artifacts/flang-split_1677889664762/_test_env_.../bin/ld: cannot find Scrt1.o: No such file or directory
/home/conda/feedstock_root/build_artifacts/flang-split_1677889664762/_test_env_.../bin/ld: cannot find crti.o: No such file or directory
flang-new: error: linker command failed with exit code 1 (use -v to see invocation)

This seems to be coming from (or related to) the clang driver?

Regarding windows: The issue mentioned in the OP could be solved by specifying CMAKE_MODULE_PATH, though I note that other subprojects ensure this themselves in their CMakeLists.txt, e.g. lld:

  find_package(LLVM REQUIRED HINTS "${LLVM_CMAKE_DIR}")
  list(APPEND CMAKE_MODULE_PATH "${LLVM_DIR}")

Regarding windows: The issue mentioned in the OP could be solved by specifying CMAKE_MODULE_PATH

Which leads to the next error:

[36/323] Building CXX object lib\Evaluate\CMakeFiles\obj.FortranEvaluate.dir\fold-integer.cpp.obj
FAILED: lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.cpp.obj 
%PREFIX%\Library\bin\clang-cl.exe  /nologo -TP -DFLANG_LITTLE_ENDIAN=1 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I%SRC_DIR%\flang\include -I%SRC_DIR%\build\include -imsvc%PREFIX%\Library\include /DWIN32 /D_WINDOWS   /Zc:inline /Zc:__cplusplus /Oi /Brepro /bigobj /permissive- /W4  -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported /Gw /WX -Wno-deprecated-copy -Wno-string-conversion -Wno-ctad-maybe-unsupported /MD /O2 /Ob2 /DNDEBUG   -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -DUNICODE -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS  /EHs-c- /GR -std:c++17 /showIncludes /Folib\Evaluate\CMakeFiles\obj.FortranEvaluate.dir\fold-integer.cpp.obj /Fdlib\Evaluate\CMakeFiles\obj.FortranEvaluate.dir\ -c -- %SRC_DIR%\flang\lib\Evaluate\fold-integer.cpp
%SRC_DIR%\flang\lib\Evaluate\fold-integer.cpp(628,35): error: lambda capture 'FromInt64' is not used [-Werror,-Wunused-lambda-capture]
            [&funcRef, &context, &FromInt64](const auto &str) -> Expr<T> {

Setting -DFLANG_ENABLE_WERROR=ON is from the README, but I'm honestly not surprised that this fails on windows; removing it...

So, after removing -DFLANG_ENABLE_WERROR=ON on windows, the build now stumbles over:

[56/323] Linking CXX shared library bin\FortranDecimal.dll
FAILED: bin/FortranDecimal.dll lib/FortranDecimal.lib 
cmd.exe /C "cd . && %BUILD_PREFIX%\Library\bin\cmake.exe -E vs_link_dll --intdir=lib\Decimal\CMakeFiles\FortranDecimal.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\LLVM\bin\lld-link.exe /nologo lib\Decimal\CMakeFiles\obj.FortranDecimal.dir\binary-to-decimal.cpp.obj lib\Decimal\CMakeFiles\obj.FortranDecimal.dir\decimal-to-binary.cpp.obj  /out:bin\FortranDecimal.dll /implib:lib\FortranDecimal.lib /pdb:bin\FortranDecimal.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO -LIBPATH:%PREFIX%\Library\lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib  && cd ."
LINK: command "C:\PROGRA~1\LLVM\bin\lld-link.exe /nologo lib\Decimal\CMakeFiles\obj.FortranDecimal.dir\binary-to-decimal.cpp.obj lib\Decimal\CMakeFiles\obj.FortranDecimal.dir\decimal-to-binary.cpp.obj /out:bin\FortranDecimal.dll /implib:lib\FortranDecimal.lib /pdb:bin\FortranDecimal.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO -LIBPATH:%PREFIX%\Library\lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:bin\FortranDecimal.dll.manifest" failed (exit code 1) with the following output:
lld-link: error: undefined symbol: __udivti3
>>> referenced by lib\Decimal\CMakeFiles\obj.FortranDecimal.dir\binary-to-decimal.cpp.obj:(public: __cdecl Fortran::decimal::BigRadixFloatingPointNumber<64, 16>::BigRadixFloatingPointNumber<64, 16>(class Fortran::decimal::BinaryFloatingPointNumber<64>, enum Fortran::decimal::FortranRounding))

>>> referenced by lib\Decimal\CMakeFiles\obj.FortranDecimal.dir\binary-to-decimal.cpp.obj:(public: __cdecl Fortran::decimal::BigRadixFloatingPointNumber<113, 16>::BigRadixFloatingPointNumber<113, 16>(class Fortran::decimal::BinaryFloatingPointNumber<113>, enum Fortran::decimal::FortranRounding))

It looks like FortranDecimal isn't being linked to the compiler-rt builtins like flang is?

@banach-space @kiranchandramohan Any inputs about Scrt1.o / crti.o on linux resp. linking FortranDecimal with builtins?

I've also noticed that (cross-)compilation fails on linux-ppc64le:

[305/322] Building CXX object runtime/CMakeFiles/obj.FortranRuntime.dir/sum.cpp.o
FAILED: runtime/CMakeFiles/obj.FortranRuntime.dir/sum.cpp.o 
$BUILD_PREFIX/bin/powerpc64le-conda-linux-gnu-c++ -DFLANG_LITTLE_ENDIAN=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I$SRC_DIR/flang/include -I$SRC_DIR/build/include -I$SRC_DIR/build/runtime -fvisibility-inlines-hidden -fmessage-length=0 -mcpu=power8 -mtune=power8 -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O3 -pipe -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/flang-split-16.0.0.rc3 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-pessimizing-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wno-misleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -Werror -Wno-deprecated-copy -Wno-ctad-maybe-unsupported -fno-strict-aliasing -fno-semantic-interposition -fno-lto -O3 -DNDEBUG -fno-semantic-interposition   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -std=c++17  -fno-exceptions -MD -MT runtime/CMakeFiles/obj.FortranRuntime.dir/sum.cpp.o -MF runtime/CMakeFiles/obj.FortranRuntime.dir/sum.cpp.o.d -o runtime/CMakeFiles/obj.FortranRuntime.dir/sum.cpp.o -c $SRC_DIR/flang/runtime/sum.cpp
$SRC_DIR/flang/runtime/sum.cpp: In instantiation of 'bool Fortran::runtime::RealSumAccumulator<INTERMEDIATE>::Accumulate(A) [with A = __ieee128; INTERMEDIATE = long double]':
$SRC_DIR/flang/runtime/sum.cpp:58:22:   required from 'bool Fortran::runtime::RealSumAccumulator<INTERMEDIATE>::AccumulateAt(const Fortran::runtime::SubscriptValue*) [with A = __ieee128; INTERMEDIATE = long double; Fortran::runtime::SubscriptValue = long int]'
$SRC_DIR/flang/runtime/reduction-templates.h:60:55:   required from 'void Fortran::runtime::DoTotalReduction(const Descriptor&, int, const Descriptor*, ACCUMULATOR&, const char*, Terminator&) [with TYPE = __ieee128; ACCUMULATOR = RealSumAccumulator<long double>]'
$SRC_DIR/flang/runtime/reduction-templates.h:85:28:   required from 'Fortran::runtime::CppTypeFor<CAT, KIND> Fortran::runtime::GetTotalReduction(const Descriptor&, const char*, int, int, const Descriptor*, ACCUMULATOR&&, const char*) [with Fortran::common::TypeCategory CAT = Fortran::common::TypeCategory::Real; int KIND = 16; ACCUMULATOR = RealSumAccumulator<long double>; CppTypeFor<CAT, KIND> = __ieee128]'
$SRC_DIR/flang/runtime/sum.cpp:143:51:   required from here
$SRC_DIR/flang/runtime/sum.cpp:51:17: error: Invalid mixing of IEEE 128-bit and IBM 128-bit floating point types
   51 |     auto next{x + correction_};
      |               ~~^~~~~~~~~~~~~
ninja: build stopped: subcommand failed.

And there's a segfault on osx-64 when calling flang-new:

+ flang-new -flang-experimental-exec hello_world.f90
flang-new: error: unable to execute command: Segmentation fault: 11
flang-new: error: flang frontend command failed due to signal (use -v to see invocation)
flang-new version 16.0.0
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Users/runner/miniforge3/conda-bld/flang-split_1677915266036/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/bin
flang-new: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
flang-new: note: diagnostic msg: /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/hello_world-29b064
flang-new: note: diagnostic msg: /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/hello_world-29b064.sh
flang-new: note: diagnostic msg: Crash backtrace is located in
flang-new: note: diagnostic msg: /Users/runner/Library/Logs/DiagnosticReports/flang-new_<YYYY-MM-DD-HHMMSS>_<hostname>.crash
flang-new: note: diagnostic msg: (choose the .crash file that corresponds to your crash)
flang-new: note: diagnostic msg: 

********************

This is running in CI, but if helpful I can try to recover the respective logs

I turned the OP into a list of all the issues I've run into so far.

I turned the OP into a list of all the issues I've run into so far.

Thanks - that helps a lot!

In fact, I was planning to suggest creating separate tickets. This way it should be much easier to draw the attention of people with relevant expertise.

Also, I don't work on Flang anymore and don't know much about Windows. So may not be as helpful as I wish I was (that's also why I'm not so active here).

Regarding windows: The issue mentioned in the OP could be solved by specifying CMAKE_MODULE_PATH

Which leads to the next error:

[36/323] Building CXX object lib\Evaluate\CMakeFiles\obj.FortranEvaluate.dir\fold-integer.cpp.obj
FAILED: lib/Evaluate/CMakeFiles/obj.FortranEvaluate.dir/fold-integer.cpp.obj 
%PREFIX%\Library\bin\clang-cl.exe  /nologo -TP -DFLANG_LITTLE_ENDIAN=1 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I%SRC_DIR%\flang\include -I%SRC_DIR%\build\include -imsvc%PREFIX%\Library\include /DWIN32 /D_WINDOWS   /Zc:inline /Zc:__cplusplus /Oi /Brepro /bigobj /permissive- /W4  -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported /Gw /WX -Wno-deprecated-copy -Wno-string-conversion -Wno-ctad-maybe-unsupported /MD /O2 /Ob2 /DNDEBUG   -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -DUNICODE -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS  /EHs-c- /GR -std:c++17 /showIncludes /Folib\Evaluate\CMakeFiles\obj.FortranEvaluate.dir\fold-integer.cpp.obj /Fdlib\Evaluate\CMakeFiles\obj.FortranEvaluate.dir\ -c -- %SRC_DIR%\flang\lib\Evaluate\fold-integer.cpp
%SRC_DIR%\flang\lib\Evaluate\fold-integer.cpp(628,35): error: lambda capture 'FromInt64' is not used [-Werror,-Wunused-lambda-capture]
            [&funcRef, &context, &FromInt64](const auto &str) -> Expr<T> {

Setting -DFLANG_ENABLE_WERROR=ON is from the README, but I'm honestly not surprised that this fails on windows; removing it...

Also not that surprised. However, note that flang-x86_64-windows seems fine.

Any inputs about Scrt1.o / crti.o on linux resp. linking FortranDecimal with builtins?

That's also happening on Windows, right? I think that it would be good to make that clear in the summary above. And I recommend pinging @Meinersbur who is a Windows expert and who worked on making Flang build and run on that platform.

And there's a segfault on osx-64 when calling flang-new

Extra logs would be nice. Before that, @kiranchandramohan - any chance you've tried flang-new on Mac OS lately? Also, @h-vetinari we don't have access to linux-ppc64le or osx-64 (might be a bit tricky to help there).

Thanks for all the digging and the intel so far! -Andrzej

Any inputs about Scrt1.o / crti.o on linux resp. linking FortranDecimal with builtins?

That's also happening on Windows, right?

Windows builds fail earlier because they cannot seem to locate a pre-installed compiler-rt (at least that's what I think is causing it). I had to patch a bit to get past an error if not using clang to compile flang (our main compiler on windows is msvc), and then the config passes, but at compilation time I run into:

[55/323] Building CXX object lib\Decimal\CMakeFiles\obj.FortranDecimal.dir\decimal-to-binary.cpp.obj
[56/323] Linking CXX shared library bin\FortranDecimal.dll
FAILED: bin/FortranDecimal.dll lib/FortranDecimal.lib 
cmd.exe /C "cd . && %BUILD_PREFIX%\Library\bin\cmake.exe -E vs_link_dll --intdir=lib\Decimal\CMakeFiles\FortranDecimal.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\LLVM\bin\lld-link.exe /nologo lib\Decimal\CMakeFiles\obj.FortranDecimal.dir\binary-to-decimal.cpp.obj lib\Decimal\CMakeFiles\obj.FortranDecimal.dir\decimal-to-binary.cpp.obj  /out:bin\FortranDecimal.dll /implib:lib\FortranDecimal.lib /pdb:bin\FortranDecimal.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO -LIBPATH:%PREFIX%\Library\lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib  && cd ."
LINK: command "C:\PROGRA~1\LLVM\bin\lld-link.exe /nologo lib\Decimal\CMakeFiles\obj.FortranDecimal.dir\binary-to-decimal.cpp.obj lib\Decimal\CMakeFiles\obj.FortranDecimal.dir\decimal-to-binary.cpp.obj /out:bin\FortranDecimal.dll /implib:lib\FortranDecimal.lib /pdb:bin\FortranDecimal.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO -LIBPATH:%PREFIX%\Library\lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:bin\FortranDecimal.dll.manifest" failed (exit code 1) with the following output:
lld-link: error: undefined symbol: __udivti3
>>> referenced by lib\Decimal\CMakeFiles\obj.FortranDecimal.dir\binary-to-decimal.cpp.obj:(public: __cdecl Fortran::decimal::BigRadixFloatingPointNumber<64, 16>::BigRadixFloatingPointNumber<64, 16>(class Fortran::decimal::BinaryFloatingPointNumber<64>, enum Fortran::decimal::FortranRounding))

>>> referenced by lib\Decimal\CMakeFiles\obj.FortranDecimal.dir\binary-to-decimal.cpp.obj:(public: __cdecl Fortran::decimal::BigRadixFloatingPointNumber<113, 16>::BigRadixFloatingPointNumber<113, 16>(class Fortran::decimal::BinaryFloatingPointNumber<113>, enum Fortran::decimal::FortranRounding))

And there's a segfault on osx-64 when calling flang-new

Extra logs would be nice

As of 16.0.1, the segfault on osx has some extra information now:

+ flang-new -flang-experimental-exec hello_world.f90
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.  Program arguments: /Users/runner/miniforge3/conda-bld/flang-split_1681164433960/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/bin/flang-new -fc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -mrelocation-model pic -pic-level 2 -target-cpu core2 -o /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/hello_world-b0b304.o -x f95-cpp-input hello_world.f90
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  libLLVM-16.dylib              0x000000010ff9e568 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1  libLLVM-16.dylib              0x000000010ff9d3d8 llvm::sys::RunSignalHandlers() + 248
2  libLLVM-16.dylib              0x000000010ff9ec73 SignalHandler(int) + 355
3  libsystem_platform.dylib      0x00007fff205dcd7d _sigtramp + 29
4  libsystem_platform.dylib      0x000000010fdac380 _sigtramp + 18446603344534107680
5  libFIRSupport.16.dylib        0x000000011d09afce mlir::StringAttr::get(mlir::MLIRContext*, llvm::Twine const&) + 478
6  libFIRSupport.16.dylib        0x000000011d1683bf mlir::OperationName::Impl::Impl(llvm::StringRef, mlir::Dialect*, mlir::TypeID, mlir::detail::InterfaceMap) + 79
7  libFIRCodeGen.16.dylib        0x000000010ef18b03 mlir::RegisteredOperationName::Model<mlir::AffineDmaStartOp>::Model(mlir::Dialect*) + 259
8  libFIRCodeGen.16.dylib        0x000000010eee2f64 void mlir::Dialect::addOperations<mlir::AffineDmaStartOp, mlir::AffineDmaWaitOp, mlir::AffineApplyOp, mlir::AffineDelinearizeIndexOp, mlir::AffineForOp, mlir::AffineIfOp, mlir::AffineLoadOp, mlir::AffineMaxOp, mlir::AffineMinOp, mlir::AffineParallelOp, mlir::AffinePrefetchOp, mlir::AffineStoreOp, mlir::AffineVectorLoadOp, mlir::AffineVectorStoreOp, mlir::AffineYieldOp>() + 52
9  libFIRCodeGen.16.dylib        0x000000010eee2cb3 mlir::AffineDialect::initialize() + 35
10 libFIRCodeGen.16.dylib        0x000000010eee2e4f mlir::AffineDialect::AffineDialect(mlir::MLIRContext*) + 143
11 libflangFrontend.16.dylib     0x00000001081ca9b8 std::__1::unique_ptr<mlir::Dialect, std::__1::default_delete<mlir::Dialect>> llvm::function_ref<std::__1::unique_ptr<mlir::Dialect, std::__1::default_delete<mlir::Dialect>> ()>::callback_fn<mlir::AffineDialect* mlir::MLIRContext::getOrLoadDialect<mlir::AffineDialect>()::'lambda'()>(long) + 40
12 libHLFIRDialect.16.dylib      0x000000010fa367b5 mlir::MLIRContext::getOrLoadDialect(llvm::StringRef, mlir::TypeID, llvm::function_ref<std::__1::unique_ptr<mlir::Dialect, std::__1::default_delete<mlir::Dialect>> ()>) + 245
13 libflangFrontend.16.dylib     0x00000001081c4bfb Fortran::frontend::CodeGenAction::beginSourceFileAction() + 763
14 libflangFrontend.16.dylib     0x00000001081c356b Fortran::frontend::FrontendAction::beginSourceFile(Fortran::frontend::CompilerInstance&, Fortran::frontend::FrontendInputFile const&) + 315
15 libflangFrontend.16.dylib     0x00000001081b5d3f Fortran::frontend::CompilerInstance::executeAction(Fortran::frontend::FrontendAction&) + 207
16 libflangFrontendTool.16.dylib 0x0000000107f5ce01 Fortran::frontend::executeCompilerInvocation(Fortran::frontend::CompilerInstance*) + 3057
17 flang-new                     0x0000000107f4f463 fc1_main(llvm::ArrayRef<char const*>, char const*) + 627
18 flang-new                     0x0000000107f4c7a4 main + 820
19 libdyld.dylib                 0x00007fff205b2f3d start + 1
flang-new: error: unable to execute command: Segmentation fault: 11
flang-new: error: flang frontend command failed due to signal (use -v to see invocation)
flang-new version 16.0.1
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Users/runner/miniforge3/conda-bld/flang-split_1681164433960/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pl/bin
flang-new: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
flang-new: note: diagnostic msg: /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/hello_world-035f57
flang-new: note: diagnostic msg: /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/hello_world-035f57.sh
flang-new: note: diagnostic msg: Crash backtrace is located in
flang-new: note: diagnostic msg: /Users/runner/Library/Logs/DiagnosticReports/flang-new_<YYYY-MM-DD-HHMMSS>_<hostname>.crash
flang-new: note: diagnostic msg: (choose the .crash file that corresponds to your crash)
flang-new: note: diagnostic msg: 

********************

Windows builds fail earlier because they cannot seem to locate a pre-installed compiler-rt (at least that's what I think is causing it).

On Windows, when compiling with msvc, compiler-rt is not needed. The flang-x86_64-windows builds without it. Msvc does not generate calls to compiler-rt, only to Microsoft's own libraries.

If you compile with Clang, the same requirements as with compiling anything with Clang should apply. If you use clang-cl, you encountered an open bug: https://github.com/llvm/llvm-project/issues/25679. IMHO, clang-cl is meant to be msvc-compatible, it should not insert calls to libraries that cl.exe would not also emit, or existing build systems will not work (or you need to add compiler-rt.lib manually to the link flags). It's also what find_compiler_rt_library that you patched assumed. See also https://github.com/llvm/llvm-project/issues/26142.

@h-vetinari: missing Scrt1.o / crti.o when running flang-new on linux

OK, this one was partly on me, because we have our sysroot in a non-standard location. I've resolved that point in the OP.

@Meinersbur: or you need to add compiler-rt.lib manually to the link flags

OK, I did that (turns out it was also necessary on osx-arm64?), and got one step further:

[107/323] Linking CXX shared library bin\FortranParser.dll
FAILED: bin/FortranParser.dll lib/FortranParser.lib 
cmd.exe /C "cd . && %BUILD_PREFIX%\Library\bin\cmake.exe -E vs_link_dll --intdir=lib\Parser\CMakeFiles\FortranParser.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\LLVM\bin\lld-link.exe /nologo lib\Parser\CMakeFiles\obj.FortranParser.dir\Fortran-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\char-buffer.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\char-block.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\char-set.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\characters.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\debug-parser.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\executable-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\expr-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\instrumented-parser.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\io-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\message.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\openacc-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\openmp-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\parse-tree.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\parsing.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\preprocessor.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\prescan.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\program-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\provenance.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\source.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\token-sequence.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\tools.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\unparse.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\user-state.cpp.obj  /out:bin\FortranParser.dll /implib:lib\FortranParser.lib /pdb:bin\FortranParser.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO -LIBPATH:%PREFIX%\Library\lib %PREFIX%\Library\lib\clang\16.0.1\lib\windows\clang_rt.builtins-x86_64.lib  lib\FortranCommon.lib  %PREFIX%\Library\lib\LLVMSupport.lib  %PREFIX%\Library\lib\LLVMFrontendOpenACC.lib  %PREFIX%\Library\lib\clang\16.0.1\lib\windows\clang_rt.builtins-x86_64.lib  %PREFIX%\Library\lib\LLVMSupport.lib  psapi.lib  shell32.lib  ole32.lib  uuid.lib  advapi32.lib  %PREFIX%\Library\lib\z.lib  %PREFIX%\Library\lib\zstd.lib  delayimp.lib  -delayload:shell32.dll  -delayload:ole32.dll  %PREFIX%\Library\lib\LLVMDemangle.lib  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib  && cd ."
LINK: command "C:\PROGRA~1\LLVM\bin\lld-link.exe /nologo lib\Parser\CMakeFiles\obj.FortranParser.dir\Fortran-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\char-buffer.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\char-block.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\char-set.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\characters.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\debug-parser.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\executable-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\expr-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\instrumented-parser.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\io-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\message.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\openacc-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\openmp-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\parse-tree.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\parsing.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\preprocessor.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\prescan.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\program-parsers.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\provenance.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\source.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\token-sequence.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\tools.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\unparse.cpp.obj lib\Parser\CMakeFiles\obj.FortranParser.dir\user-state.cpp.obj /out:bin\FortranParser.dll /implib:lib\FortranParser.lib /pdb:bin\FortranParser.pdb /dll /version:0.0 /machine:x64 /INCREMENTAL:NO -LIBPATH:%PREFIX%\Library\lib %PREFIX%\Library\lib\clang\16.0.1\lib\windows\clang_rt.builtins-x86_64.lib lib\FortranCommon.lib %PREFIX%\Library\lib\LLVMSupport.lib %PREFIX%\Library\lib\LLVMFrontendOpenACC.lib %PREFIX%\Library\lib\clang\16.0.1\lib\windows\clang_rt.builtins-x86_64.lib %PREFIX%\Library\lib\LLVMSupport.lib psapi.lib shell32.lib ole32.lib uuid.lib advapi32.lib %PREFIX%\Library\lib\z.lib %PREFIX%\Library\lib\zstd.lib delayimp.lib -delayload:shell32.dll -delayload:ole32.dll %PREFIX%\Library\lib\LLVMDemangle.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:bin\FortranParser.dll.manifest" failed (exit code 1) with the following output:
lld-link: error: undefined symbol: void __cdecl Fortran::common::die(char const *, ...)
>>> referenced by lib\Parser\CMakeFiles\obj.FortranParser.dir\Fortran-parsers.cpp.obj:(public: class std::optional<struct Fortran::parser::KindSelector> __cdecl Fortran::parser::AlternativesParser<class Fortran::parser::ApplyConstructor<struct Fortran::parser::KindSelector, class Fortran::parser::SequenceParser<class Fortran::parser::TokenStringMatch<0, 0>, class Fortran::parser::FollowParser<class Fortran::parser::SequenceParser<class Fortran::parser::MaybeParser<class Fortran::parser::TokenStringMatch<0, 0>>, class Fortran::parser::ApplyConstructor<struct Fortran::parser::Scalar<struct Fortran::parser::Integer<struct Fortran::parser::Constant<class Fortran::common::Indirection<struct Fortran::parser::Expr, 0>>>>, class Fortran::parser::ApplyConstructor<struct Fortran::parser::Integer<struct Fortran::parser::Constant<class Fortran::common::Indirection<struct Fortran::parser::Expr, 0>>>, class Fortran::parser::ApplyConstructor<struct Fortran::parser::Constant<class Fortran::common::Indirection<struct Fortran::parser::Expr, 0>>, class Fortran::parser::ApplyConstructor<class Fortran::common::Indirection<struct Fortran::parser::Expr, 0>, struct Fortran::parser::Parser<struct Fortran::parser::Expr>>>>>>, class Fortran::parser::TokenStringMatch<0, 0>>>>, class Fortran::parser::NonstandardParser<14, class Fortran::parser::ApplyConstructor<struct Fortran::parser::KindSelector, class Fortran::parser::ApplyConstructor<struct Fortran::parser::KindSelector::StarSize, class Fortran::parser::SequenceParser<class Fortran::parser::TokenStringMatch<0, 0>, class Fortran::parser::FollowParser<struct Fortran::parser::DigitString64, struct Fortran::parser::SpaceCheck>>>>>>::Parse(class Fortran::parser::ParseState &) const)
>>> referenced by lib\Parser\CMakeFiles\obj.FortranParser.dir\Fortran-parsers.cpp.obj:(public: class std::optional<struct Fortran::parser::TypeParamDefStmt> __cdecl Fortran::parser::ApplyConstructor<struct Fortran::parser::TypeParamDefStmt, class Fortran::parser::FollowParser<struct Fortran::parser::Parser<struct Fortran::parser::IntegerTypeSpec>, class Fortran::parser::TokenStringMatch<0, 0>>, class Fortran::parser::AlternativesParser<class Fortran::parser::SequenceParser<class Fortran::parser::TokenStringMatch<0, 0>, class Fortran::parser::PureParser<enum Fortran::common::TypeParamAttr>>, class Fortran::parser::SequenceParser<class Fortran::parser::TokenStringMatch<0, 0>, class Fortran::parser::PureParser<enum Fortran::common::TypeParamAttr>>>, class Fortran::parser::SequenceParser<class Fortran::parser::TokenStringMatch<0, 0>, class Fortran::parser::WithMessageParser<class Fortran::parser::NonemptySeparated<struct Fortran::parser::Parser<struct Fortran::parser::TypeParamDecl>, class Fortran::parser::TokenStringMatch<0, 0>>>>>::Parse(class Fortran::parser::ParseState &) const)
>>> referenced by lib\Parser\CMakeFiles\obj.FortranParser.dir\Fortran-parsers.cpp.obj:(public: class std::optional<struct Fortran::parser::TypeParamDecl> __cdecl Fortran::parser::ApplyConstructor<struct Fortran::parser::TypeParamDecl, struct Fortran::parser::Parser<struct Fortran::parser::Name>, class Fortran::parser::MaybeParser<class Fortran::parser::SequenceParser<class Fortran::parser::TokenStringMatch<0, 0>, class Fortran::parser::ApplyConstructor<struct Fortran::parser::Scalar<struct Fortran::parser::Integer<struct Fortran::parser::Constant<class Fortran::common::Indirection<struct Fortran::parser::Expr, 0>>>>, class Fortran::parser::ApplyConstructor<struct Fortran::parser::Integer<struct Fortran::parser::Constant<class Fortran::common::Indirection<struct Fortran::parser::Expr, 0>>>, class Fortran::parser::ApplyConstructor<struct Fortran::parser::Constant<class Fortran::common::Indirection<struct Fortran::parser::Expr, 0>>, class Fortran::parser::ApplyConstructor<class Fortran::common::Indirection<struct Fortran::parser::Expr, 0>, struct Fortran::parser::Parser<struct Fortran::parser::Expr>>>>>>>>::Parse(class Fortran::parser::ParseState &) const)
>>> referenced 1508 more times

Looks like FortranParser needs to link to FortranCommon (IIUC where this comes from)?

Edit: I see now that the linkage is already specified, but then I don't understand yet why the symbol isn't found...

@kiranchandramohan @banach-space @Meinersbur Any help with what's happening with FortranParser vs FortranCommon on windows?

OK, another update: our default in conda-forge is shared builds, which is what I started out with. Switching osx & windows to static builds, the segfaults on osx are gone, and windows builds successfully 🥳

The only last problem on windows I now have is (again) how to link compiler-rt correctly, because I'm running into:

FortranDecimal.lib(binary-to-decimal.cpp.obj) : error LNK2019: unresolved external symbol __udivti3 referenced in function "public: __cdecl Fortran::decimal::BigRadixFloatingPointNumber<64,16>::BigRadixFloatingPointNumber<64,16>(class Fortran::decimal::BinaryFloatingPointNumber<64>,enum Fortran::decimal::FortranRounding)" (??0?$BigRadixFloatingPointNumber@$0EA@$0BA@@decimal@Fortran@@QEAA@V?$BinaryFloatingPointNumber@$0EA@@12@W4FortranRounding@12@@Z)

from a simple call to

flang-new -flang-experimental-exec hello_world.f90

I've tried to look at the driver documentation but I'm not sure how I would provide a -Lsomelib linker argument? There's also a small chance that this has something to do with having to patch out find_compiler_rt_library, which doesn't work correctly in our case (I've replaced it directly with the path to the libs, because I know where they are in our respective file hierarchy).

Hi @h-vetinari , great news! 🥳

Sorry for not replying earlier. I am very hands off with respect to Flang these days and also have only a very basic understanding of what makes Windows special in these cases (and have no Windows machine to experiment).

I'm not sure how I would provide a -Lsomelib linker argument?

Same as Clang. Or, are you asking for ways to add it permanently? For the latter you could check the original patch that adds support for generating executables: https://reviews.llvm.org/D122008. In particular, gnutools::Linker::ConstructJob. I have not looked at how Linker invocation is generated on Windows, so not able to help, sorry :( You could try by looking at visualstudio::Linker::ConstructJob.

I've tried to look at the driver documentation

BTW, markdown renders much nicer document: https://github.com/llvm/llvm-project/blob/main/flang/docs/FlangDriver.md

HTH, Andrzej

I'm not sure how I would provide a -Lsomelib linker argument?

Same as Clang. Or, are you asking for ways to add it permanently?

For now just on the command line (though long-term it might be useful to add the built-ins by default on windows, if they're always necessary anyway). However, there's a dizzying array of interfaces that are non-trivial for me to make sense of.

flang-new vs. flang-new -fc1
clang vs clang-cl
does it need forward slashes for clang or backslashes for windows
who talks to the windows linker and how
does the MSVC runtime get linked statically (/MT) or dynamically (/MD)

I tried:

> flang-new -flang-experimental-exec hello_world.f90
FortranDecimal.lib(binary-to-decimal.cpp.obj) : error LNK2019: unresolved external symbol __udivti3 # as above
> 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

After some googling, this looks like it's related to trying to link the runtime statically (apparently the default?).

There are some mentions of how to pass arguments to the linker for clang-cl (i.e. /link ... resp. /LIBPATH), but not for the native clang interface, and I presume flang just uses that.

So using a cursed mix of conventions, I tried

> 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

Calling the last command again with -v, I get [linebreaks added for clarity]:

> flang-new -flang-experimental-exec hello_world.f90 -l path\to\clang_rt.builtins-x86_64.lib -v
flang-new version 16.0.5
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Users\[...]\.conda\envs\llvm\Library\bin
 "C:\Users\[...]\.conda\envs\llvm\Library\bin\flang-new" -fc1
   -triple x86_64-pc-windows-msvc19.35.32215 -emit-obj -fcolor-diagnostics -mrelocation-model pic -pic-level 2
   -target-cpu x86-64 -o "C:\Users\[...]\AppData\Local\Temp\hello_world-f6cc2c.o" -x f95-cpp-input hello_world.f90
 "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.35.32215\bin\Hostx64\x64\link.exe"
   -out:a.exe "-libpath:C:\Users\[...]\.conda\envs\llvm\Library\lib" Fortran_main.lib FortranRuntime.lib FortranDecimal.lib
   /subsystem:console -nologo "C:\Users\[...]\AppData\Local\Temp\hello_world-f6cc2c.o"
   "C:\Users\[...]\.conda\envs\llvm\Library\lib\clang\16.0.5\lib\windows\clang_rt.builtins-x86_64.lib" /NODEFAULTLIB:library

so the argument actually gets passed to the linker, but still doesn't work (unsurprisingly, given the SO answer).

AFAICT, I need to pass something through to flang-new -fc1 to tell it to link the temporary objectfile it's generating either with /MT or /MD, but I have no idea how I'd need to do that, or if the frontend driver is even capable of understanding this difference.

However, there's a dizzying array of interfaces that are non-trivial for me to make sense of.

It is quite confusing TBH. Let me try to explain.

* `flang-new` vs. `flang-new -fc1`

This is similar to clang vs clang -cc1. First, the theory:

flang-new -fc1 The frontend driver can "drive" everything that's inside the Flang sub-project. Primarily a developer's interface into the frontend. Unable to call external tools, e.g. a linker.

flang-new The compiler driver connects flang-new -fc1, the backend (e.g. the assembler/machine code generator from LLVM), the linker (and runtimes) as well as other tools that could take part in compilation.

In practice, however, flang-new -fc1 can do a bit more than just "driving" Flang - it will also "drive" MLIR and LLVM. As the latter implements various backends, it means that flang-new -fc1 can generate object files (but not executables, that would require calling a linker). The following slide from my EuroLLVM 2022 presentation tries to convey that:

You can also look at:

Flang driver documentation,
Driving Compilers blog by Fabien Sanglard (very recent, probably the best resource on "how compiler driver works" that's available ATM).

* `clang` vs `clang-cl`

Both drive Clang and both are built in terms of the clangDriver library from Clang. The former provides a "GNU compatible" interface (i.e. a gcc equivalent) and the latter provides an "MSVC compatible" interface (see cl.exe here: https://learn.microsoft.com/en-us/cpp/build/reference/compiler-options?view=msvc-170). The latter could be viewed as a wrapper for "Clang" that allows it be a drop-in replacement for cl.exe

As for your more specific questions on flang-new on Windows, I need to defer to experts. CC @Meinersbur :)

Thanks for the references and the kind explanations! As my code examples show, I already worked out most of that (if only by gutfeeling/hoping), but it still seems to me that using flang on windows will need some way to communicate windows-specific thing down to the chain.

I think that a "MSVC compatible" interface for flang is very likely overkill, but being able to pass through /MD vs. /MT somehow is a must AFAICT (unless flang will only require LLVM's compiler-rt, and nothing from MSFT's C runtime library; I think this is probably #25679 / #26142 again?). Also, it feels weird to mix GNU's -Wl, with windows-specific options, but I guess as long as it doesn't break, that's something one could get used to.

Came across the following comments by accident, which now finally makes me understand why a hello-world example might need that symbol - it's likely from std::to_char (or something equivalent), in combination with 128bit support:

@zmodem: Sharing in case anyone else runs into the same problem: This caused Chromium builds to fail on Windows due to not linking against compiler-rt's builtins library. It turns out this patch caused us to compile some code doing 128-bit arithmetic and calling the __udivti3 runtime function. We worked around it by defining _LIBCPP_HAS_NO_INT128 until we can make the builtins library part of all our builds.

@Mordante: Interesting that this caused it. I expect the real cause is std::to_char for 128-bit values, there divisions are used. Does that mean the flag in __config is not set correctly? It was recently updated in D134912.

The sticking point here is that flang doesn't use libcxx, so I'm not sure where else that 128bit config creeps in, and how I could suppress it?

@Meinersbur? @banach-space? @kiranchandramohan?

so I'm not sure where else that 128bit config creeps in, and how I could suppress it?

After some searching I found AVOID_NATIVE_UINT128_T, but having built flang with that still, it still runs into missing __udivti3 when trying to build a hello-world example. There's also __SIZEOF_INT128__ in several places, but this doesn't look like a user-influenceable option.

OTOH, looking at the linker error, I'm not that sure anymore this has something to do with 128bits?

FortranDecimal.lib(binary-to-decimal.cpp.obj) : error LNK2019:
    unresolved external symbol __udivti3 referenced in function "public: __cdecl
        Fortran::decimal::BigRadixFloatingPointNumber<64,16>::BigRadixFloatingPointNumber<64,16>(class
            Fortran::decimal::BinaryFloatingPointNumber<64>,enum Fortran::decimal::FortranRounding)"
(??0?$BigRadixFloatingPointNumber@$0EA@$0BA@@decimal@Fortran@@QEAA@V?$BinaryFloatingPointNumber@$0EA@@12@W4FortranRounding@12@@Z)

In any case, is building flang without native 128-bit types considered supported? And if so, should I raise a separate issue for this?

CC @klausler who introduced AVOID_NATIVE_UINT128_T 3-4 years ago, and @vzakhari who recently touched this in https://github.com/llvm/llvm-project/commit/21bff9ca42e4735a52aa1e981b1ccd0d3b274b34 (which I backported, but it didn't make a difference).

Assuming it's impossible to switch off the need for __udivti3, I also looked at the /MD vs /MT situation some more. The clang driver has ProcessVSRuntimeLibrary plus an option to pass --dependent-lib=... to the frontend driver.

Based on what's encoded in ProcessVSRuntimeLibrary (and matching information I found elsewhere), the equivalent of /MD would then be

-D_MT -D_DLL -Xflang --dependent-lib=msvcrt

However, flang-new -fc1 doesn't have a similar option to --dependent-lib AFAICT.

Trying to somehow monkey-patch things through the current interface, I see that it still wants to use the wrong (static) VS Runtime lib.

>flang-new -flang-experimental-exec hello_world.f90 -l path\to\clang_rt.builtins-x86_64.lib -D_MT -D_DLL -Wl,/DEFAULTLIB:msvcrt.lib
LINK : warning LNK4098: defaultlib 'libcmt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library

In any case, is building flang without native 128-bit types considered supported? And if so, should I raise a separate issue for this?

Hi @h-vetinari, I do not think building with AVOID_NATIVE_UINT128_T is being tested or/and is fully functional. I remember trying to experimentally enable it would fail the runtime compilation because of the missing type conversion operators. The most reliable way to make sure that AVOID_NATIVE_UINT128_T works is to have at least one buildbot that uses it for Flang build and also runs some end-to-end testing. It seems to worth a separate issue.

So we managed to get something going based on flang 17. It's still in the debugging phase and I might eventually come back and open follow-up tickets for the still-open points, but for the purposes of this issue, I think it's fine to close.

Thanks for the help everyone!

Great effort, thank you so much for all the amazing work that you have put into this, that's greatly appreciated! 🙏🏻

Same problem (hang on linux at the same point) with GCC 12

flang-17 hangs badly towards the very end of the build on macOS too (using clang). 17.0.5 got worse, I cannot make it through the end. It is at 100%, but freezes every time I try to restart.

Have you tried building with -j1? That's what solved things for me. Presumably the linking phase at the end needs a bunch of memory, and doing too many in parallel could lead to your system starting to swap out memory to disk (for example)

@h-vetinari Thank you, that indeed helped.

llvm / llvm-project

[flang] Problems building flang 16.0.x following standalone build instructions #60730