[flang] MSVC runtime library selection

[bradking]

For targets such as x86_64-pc-windows-msvc, LLVM/Flang generates
object files for the MSVC ABI and uses MSVC-compatible tooling.

Compilers that target the MSVC ABI need to select one of the MSVC
runtime libraries. They should define preprocessor macros identifying
the selected runtime library, and add #pragma comment-style annotations
to object files to pass /defaultlib:... flags to the linker without
build system intervention. With LLVM/Flang the latter is needed even
for a trivial empty Fortran program:

>type foo.f90
program foo
end program
>flang-new foo.f90
LINK : error LNK2001: unresolved external symbol mainCRTStartup
>flang-new foo.f90 -Xlinker -defaultlib:msvcrt
(works)

MSVC toolsets provide the following runtime library variants:

• libcmt: Multi-threaded, optimized, linked statically.
  Defines -D_MT, links /defaultlib:libcmt.
  MSVC flag: cl -MT.

• msvcrt: Multi-threaded, optimized, linked shared.
  Defines -D_MT -D_DLL, links /defaultlib:msvcrt.
  MSVC flag: cl -MD.

• libcmtd: Multi-threaded, debug, linked statically.
  Defines -D_MT -D_DEBUG, links /defaultlib:libcmtd.
  MSVC flag: cl -MTd.

• msvcrtd: Multi-threaded, debug, linked shared.
  Defines -D_MT -D_DEBUG -D_DLL, links /defaultlib:msvcrtd.
  MSVC flag: cl -MDd.

LLVM/Flang should be updated as follows:

• Add command-line flags to select a MSVC runtime library variant.
• Provide predefined macros indicating the selected MSVC runtime library
  for the preprocessor.
• Generate /defaultlib:... flags in object files referencing the
  selected MSVC runtime library for the linker.

For reference, LLVM/Clang does all of these when targeting the MSVC ABI.

Additionally, LLVM/Flang's own runtime libraries (Fortran*.lib)
could be provided as variants corresponding to each MSVC runtime
library variant. Currently the Fortran*.lib libraries included in
the LLVM/Flang distribution only use the msvcrt runtime library.
LLVM/Flang should then write /defaultlib:... references in object
files, to link its own Fortran*.lib runtime libraries, matching the
selected MSVC runtime library variant.

Cc: @DavidTruby

[bradking]

#67675 is related in that it asks for MSVC-like predefined macros (identifying the ABI and target architecture).

[bradking]

For reference, this came up in discussion of CMake Issue 24840, requesting support for targeting the MSVC ABI with flang-new.

[llvmbot]

@llvm/issue-subscribers-flang-driver

For targets such as `x86_64-pc-windows-msvc`, LLVM/Flang generates object files for the MSVC ABI and uses MSVC-compatible tooling.

Compilers that target the MSVC ABI need to select one of the MSVC
runtime libraries. They should define preprocessor macros identifying
the selected runtime library, and add #pragma comment-style annotations
to object files to pass /defaultlib:... flags to the linker without
build system intervention. With LLVM/Flang the latter is needed even
for a trivial empty Fortran program:

>type foo.f90
program foo
end program
>flang-new foo.f90
LINK : error LNK2001: unresolved external symbol mainCRTStartup
>flang-new foo.f90 -Xlinker -defaultlib:msvcrt
(works)

MSVC toolsets provide the following runtime library variants:

• libcmt: Multi-threaded, optimized, linked statically.
  Defines -D_MT, links /defaultlib:libcmt.
  MSVC flag: cl -MT.

• msvcrt: Multi-threaded, optimized, linked shared.
  Defines -D_MT -D_DLL, links /defaultlib:msvcrt.
  MSVC flag: cl -MD.

• libcmtd: Multi-threaded, debug, linked statically.
  Defines -D_MT -D_DEBUG, links /defaultlib:libcmtd.
  MSVC flag: cl -MTd.

• msvcrtd: Multi-threaded, debug, linked shared.
  Defines -D_MT -D_DEBUG -D_DLL, links /defaultlib:msvcrtd.
  MSVC flag: cl -MDd.

LLVM/Flang should be updated as follows:

• Add command-line flags to select a MSVC runtime library variant.
• Provide predefined macros indicating the selected MSVC runtime library
  for the preprocessor.
• Generate /defaultlib:... flags in object files referencing the
  selected MSVC runtime library for the linker.

For reference, LLVM/Clang does all of these when targeting the MSVC ABI.

Additionally, LLVM/Flang's own runtime libraries (Fortran*.lib)
could be provided as variants corresponding to each MSVC runtime
library variant. Currently the Fortran*.lib libraries included in
the LLVM/Flang distribution only use the msvcrt runtime library.
LLVM/Flang should then write /defaultlib:... references in object
files, to link its own Fortran*.lib runtime libraries, matching the
selected MSVC runtime library variant.

Cc: @DavidTruby

[DavidTruby]

There’s an ongoing refactor of the flang runtime library happening at the moment but once that has landed I will take a look at this

[DavidTruby]

The flang runtime library build refactor is talking a while so I'm going to pick this up and try and fix it separately to that

[Meinersbur]

Additionally, LLVM/Flang's own runtime libraries (Fortran*.lib) could be provided as variants corresponding to each MSVC runtime library variant.

AFAIK none of the other runtime-libraries (compiler-rt, libcxx, libomp) currently have this. Should this be done as a coordinated effort?

[DavidTruby]

I was just checking and agree with @Meinersbur; at the moment every runtime uses just the static version. I think that doesn't preclude the end user linking to the dynamic one for their own program though, since no C++ classes cross the ABI boundary in the runtime? So a first step to get flang on the same level as everything else should be just to:

• Always build the runtime as MT static
• Give a flag for the end user selecting the dynamic or static runtime for their own code

Probably in the long run we want to be able to have both options for all of the runtimes. That will need to be done as a co-ordinated effort with all of the other runtimes since we depend on those in flang too. This part might have to wait until the flang runtime refactor though, after which the flang runtime will be built in the same way as the rest of the runtimes as I understand it.

[DavidTruby]

On third thought; we don't have any dependency on the CRT outside the Fortran runtime, so I think we should just always link Fortran programs against the static runtime (libcmt) for now as I think it makes no difference other than introducing a dll dependency that isn't actually used to the generated binaries. What do you two think? I will admit to not being that familiar with how all this works on Windows

[bradking]

If the Fortran runtime library has dependencies on the CRT, then the specific .obj files in the Fortran runtime library that have such dependence should have a /defaultlib:libcmt reference. That should cause the CRT to be linked only when the Fortran program relies on a Fortran runtime symbol whose implementation needs the CRT.

If the Fortran compiler itself never generates references to the CRT, then the only reason to have flags controlling which CRT to use would be if corresponding variants of the Fortran runtime library were available. Such flags would then control which Fortran runtime variant to name in /defaultlib:Fortran... references generated in the .obj files. Until multiple CRT variants of the Fortran runtime library are available, no such flags are needed.

However, even without multiple CRT variants of the Fortran runtime library, flang-new should still do the following:

• The preprocessor should define the MSVC macro(s) associated with libcmt since that is the CRT that will ultimately be linked.
• The compiler should emit /defaultlib:Fortran... references in the .obj files for any of the Fortran runtime libraries on which they depend. With that, the flang-new driver doesn't actually have to pass the .lib files to the linker.
• The Fortran runtime libraries' individual object files should have /defaultlib:libcmt references if they rely on CRT symbols.

[DavidTruby]

Ok yes then my understanding was correct (at least on the third try!) and I'll implement it that way with the changes you suggest. I do have one question/comment about it though, which is; I think the reason we pass the runtimes to the linker directly rather than relying on defaultlib is so that we can look up where they are e.g. in the LLVM build directory or install directory relative to the linker. I suppose we can pass -L or whatever the link.exe equivalent is instead, if we use defaultlib for the flang runtimes as well? Would this have better behaviour than what we do currently (just passing them manually) in some way I don't understand?