[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
bradking wrote: @DavidTruby please see my above retraction of the suggestion to rename `.dynamic.lib` to `.dll.lib`. https://github.com/llvm/llvm-project/pull/70833 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [flang] Add runtimes using --dependent-lib on MSVC targets (PR #72519)
bradking wrote: I tried this locally, but it doesn't quite work: ``` >flang-new foo.f90 ... fatal error LNK1276: invalid directive 'clang_rt.builtins-x86_64.lib' found; does not start with '/' ``` The directives appear in the object file with an extra space: ``` >flang-new -c foo.f90 >grep -ai defaultlib foo.o /DEFAULTLIB: clang_rt.builtins-x86_64.lib /DEFAULTLIB: libcmt /DEFAULTLIB: Fortran_main.static.lib /DEFAULTLIB: FortranRuntime.static.lib /DEFAULTLIB: FortranDecimal.static.lib.text ``` There should not be a space after `/DEFAULTLIB:` before the library name. https://github.com/llvm/llvm-project/pull/72519 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [flang] Add runtimes using --dependent-lib on MSVC targets (PR #72519)
bradking wrote:
@DavidTruby that fixed it, thanks. Nice work. I've locally updated CMake to
use `flang-new`'s MSVC runtime library selection flags
(`-fms-runtime-lib={static,static_dbg,dll,dll_dbg}`). It passes CMake's test
suite, including the `MSVCRuntimeLibrary.Fortran` test that covers all four
variants' preprocessor definitions and linking behavior. Once this is merged
I'll update CMake to use this feature for LLVMFlang 18.0 and above.
The only remaining issue I see after this is that the default
`FortranRuntime.lib` library (and friends) are still installed even though they
are only needed inside the llvm-project/flang build tree for testing. Only the
Fortran*.{static,static_dbg,dynamic,dynamic_dbg}.lib
variants should be installed. That could be considered out-of-scope for this
PR though and done in a follow-up instead.
Therefore I think this PR/commit can be marked as `Fixes: #68017`.
https://github.com/llvm/llvm-project/pull/72519
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
https://github.com/bradking requested changes to this pull request. https://github.com/llvm/llvm-project/pull/70833 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
https://github.com/bradking edited https://github.com/llvm/llvm-project/pull/70833 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
@@ -976,12 +976,46 @@ bool tools::addOpenMPRuntime(ArgStringList &CmdArgs,
const ToolChain &TC,
return true;
}
-void tools::addFortranRuntimeLibs(const ToolChain &TC,
+void tools::addFortranRuntimeLibs(const ToolChain &TC, const ArgList &Args,
llvm::opt::ArgStringList &CmdArgs) {
if (TC.getTriple().isKnownWindowsMSVCEnvironment()) {
-CmdArgs.push_back("Fortran_main.lib");
-CmdArgs.push_back("FortranRuntime.lib");
-CmdArgs.push_back("FortranDecimal.lib");
+CmdArgs.push_back(Args.MakeArgString(
+"/DEFAULTLIB:" + TC.getCompilerRTBasename(Args, "builtins")));
+unsigned RTOptionID = options::OPT__SLASH_MT;
+if (auto *rtl = Args.getLastArg(options::OPT_fms_runtime_lib_EQ)) {
+ RTOptionID = llvm::StringSwitch(rtl->getValue())
+ .Case("static", options::OPT__SLASH_MT)
+ .Case("static_dbg", options::OPT__SLASH_MTd)
+ .Case("dll", options::OPT__SLASH_MD)
+ .Case("dll_dbg", options::OPT__SLASH_MDd)
+ .Default(options::OPT__SLASH_MT);
+}
+switch (RTOptionID) {
+case options::OPT__SLASH_MT:
+ CmdArgs.push_back("/DEFAULTLIB:libcmt");
+ CmdArgs.push_back("Fortran_main.static.lib");
+ CmdArgs.push_back("FortranRuntime.static.lib");
+ CmdArgs.push_back("FortranDecimal.static.lib");
+ break;
+case options::OPT__SLASH_MTd:
+ CmdArgs.push_back("/DEFAULTLIB:libcmtd");
+ CmdArgs.push_back("Fortran_main.static_debug.lib");
+ CmdArgs.push_back("FortranRuntime.static_debug.lib");
+ CmdArgs.push_back("FortranDecimal.static_debug.lib");
+ break;
+case options::OPT__SLASH_MD:
+ CmdArgs.push_back("/DEFAULTLIB:msvcrt");
+ CmdArgs.push_back("Fortran_main.dynamic.lib");
+ CmdArgs.push_back("FortranRuntime.dynamic.lib");
+ CmdArgs.push_back("FortranDecimal.dynamic.lib");
+ break;
bradking wrote:
>From https://github.com/llvm/llvm-project/pull/70833#issuecomment-1787651022:
> I think you're probably right in the linked issue that it'd be better to add
> defaultlib directives to the object files, but that appears to be quite
> difficult as we'd need to track the attributes all the way through our MLIR
> lowering, so as a (hopefully temporary) shortcut I have just passed the
> libraries on the link line.
This temporary approach will actually make things harder for CMake to support
`flang-new`. In order to support mixed-language (e.g., Fortran and C++)
binaries we detect the implicit link directories and libraries that each
compiler driver passes to the linker when used to drive linking. Then if we
have to link using a different language's tooling, we can add them explicitly.
We don't typically do that for the MSVC ABI though because the set of runtime
libraries varies with the CRT choice and the defaultlib directives in object
files handle it automatically anyway. Currently CMake is working around the
lack of defaultlib directives for `flang-new` by using the
implicit-lib-detection approach. Once the implicitly linked runtime libraries
vary with the CRT, we would need a lot of dedicated non-trivial infrastructure
to handle all the `MSVC_RUNTIME_LIBRARY` variants, and I'm not sure it's
possible in all cases.
Can you instead add these four CRT-specific libraries as defaultlib directives
in all object files, and add the more detailed conditions to remove unnecessary
libraries later? Since they are all static `.lib` files, unused directives may
not hurt.
https://github.com/llvm/llvm-project/pull/70833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
@@ -53,3 +53,26 @@ add_flang_library(FortranDecimal INSTALL_WITH_TOOLCHAIN
binary-to-decimal.cpp
decimal-to-binary.cpp
)
+
+if (DEFINED MSVC)
+ set(CMAKE_MSVC_RUNTIME_LIBRARY MultiThreaded)
bradking wrote:
`add_flang_library` eventually ends up in `llvm/cmake/modules/AddLLVM.cmake`'s
`llvm_add_library` which calls `add_library(${name} STATIC ...)`. All
`CMAKE_MSVC_RUNTIME_LIBRARY` does is initialize the `MSVC_RUNTIME_LIBRARY`
property on that target when it is created.
You should be able to do
```cmake
add_flang_library(FortranDecimal.static ...)
set_property(TARGET FortranDecimal.static PROPERTY MSVC_RUNTIME_LIBRARY
MultiThreaded)
```
https://github.com/llvm/llvm-project/pull/70833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
@@ -976,12 +976,46 @@ bool tools::addOpenMPRuntime(ArgStringList &CmdArgs,
const ToolChain &TC,
return true;
}
-void tools::addFortranRuntimeLibs(const ToolChain &TC,
+void tools::addFortranRuntimeLibs(const ToolChain &TC, const ArgList &Args,
llvm::opt::ArgStringList &CmdArgs) {
if (TC.getTriple().isKnownWindowsMSVCEnvironment()) {
-CmdArgs.push_back("Fortran_main.lib");
-CmdArgs.push_back("FortranRuntime.lib");
-CmdArgs.push_back("FortranDecimal.lib");
+CmdArgs.push_back(Args.MakeArgString(
+"/DEFAULTLIB:" + TC.getCompilerRTBasename(Args, "builtins")));
+unsigned RTOptionID = options::OPT__SLASH_MT;
bradking wrote:
As of LLVM 17.0's distribution, the Fortran runtime libraries are built with
`msvcrt`, so I think the current default is actually `/MD`. Since this wasn't
really modeled before, and CMake will be taught to pass one of the four flags
explicitly anyway, changing the default may not matter, but it's something to
be aware of.
https://github.com/llvm/llvm-project/pull/70833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
@@ -976,12 +976,46 @@ bool tools::addOpenMPRuntime(ArgStringList &CmdArgs,
const ToolChain &TC,
return true;
}
-void tools::addFortranRuntimeLibs(const ToolChain &TC,
+void tools::addFortranRuntimeLibs(const ToolChain &TC, const ArgList &Args,
llvm::opt::ArgStringList &CmdArgs) {
if (TC.getTriple().isKnownWindowsMSVCEnvironment()) {
-CmdArgs.push_back("Fortran_main.lib");
-CmdArgs.push_back("FortranRuntime.lib");
-CmdArgs.push_back("FortranDecimal.lib");
+CmdArgs.push_back(Args.MakeArgString(
+"/DEFAULTLIB:" + TC.getCompilerRTBasename(Args, "builtins")));
+unsigned RTOptionID = options::OPT__SLASH_MT;
bradking wrote:
Yes, changing the default to match Clang makes sense.
https://github.com/llvm/llvm-project/pull/70833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
@@ -976,12 +976,46 @@ bool tools::addOpenMPRuntime(ArgStringList &CmdArgs,
const ToolChain &TC,
return true;
}
-void tools::addFortranRuntimeLibs(const ToolChain &TC,
+void tools::addFortranRuntimeLibs(const ToolChain &TC, const ArgList &Args,
llvm::opt::ArgStringList &CmdArgs) {
if (TC.getTriple().isKnownWindowsMSVCEnvironment()) {
-CmdArgs.push_back("Fortran_main.lib");
-CmdArgs.push_back("FortranRuntime.lib");
-CmdArgs.push_back("FortranDecimal.lib");
+CmdArgs.push_back(Args.MakeArgString(
+"/DEFAULTLIB:" + TC.getCompilerRTBasename(Args, "builtins")));
+unsigned RTOptionID = options::OPT__SLASH_MT;
+if (auto *rtl = Args.getLastArg(options::OPT_fms_runtime_lib_EQ)) {
+ RTOptionID = llvm::StringSwitch(rtl->getValue())
+ .Case("static", options::OPT__SLASH_MT)
+ .Case("static_dbg", options::OPT__SLASH_MTd)
+ .Case("dll", options::OPT__SLASH_MD)
+ .Case("dll_dbg", options::OPT__SLASH_MDd)
+ .Default(options::OPT__SLASH_MT);
+}
+switch (RTOptionID) {
+case options::OPT__SLASH_MT:
+ CmdArgs.push_back("/DEFAULTLIB:libcmt");
+ CmdArgs.push_back("Fortran_main.static.lib");
+ CmdArgs.push_back("FortranRuntime.static.lib");
+ CmdArgs.push_back("FortranDecimal.static.lib");
+ break;
+case options::OPT__SLASH_MTd:
+ CmdArgs.push_back("/DEFAULTLIB:libcmtd");
+ CmdArgs.push_back("Fortran_main.static_debug.lib");
+ CmdArgs.push_back("FortranRuntime.static_debug.lib");
+ CmdArgs.push_back("FortranDecimal.static_debug.lib");
+ break;
+case options::OPT__SLASH_MD:
+ CmdArgs.push_back("/DEFAULTLIB:msvcrt");
+ CmdArgs.push_back("Fortran_main.dynamic.lib");
+ CmdArgs.push_back("FortranRuntime.dynamic.lib");
+ CmdArgs.push_back("FortranDecimal.dynamic.lib");
+ break;
bradking wrote:
I'm not aware of any easy way to add defaultlib directives after-the-fact.
I think it's okay to merge this PR's approach as a temporary solution. It does
fix the empty-`program` example in #68017 work, and provide the Fortran runtime
library variants. However, I'm not sure how well CMake will be able to support
this until the defaultlib part is added.
BTW, the `Fixes #68017` note in the PR description is no longer accurate. It's
not fully fixed yet.
https://github.com/llvm/llvm-project/pull/70833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
@@ -976,12 +976,46 @@ bool tools::addOpenMPRuntime(ArgStringList &CmdArgs,
const ToolChain &TC,
return true;
}
-void tools::addFortranRuntimeLibs(const ToolChain &TC,
+void tools::addFortranRuntimeLibs(const ToolChain &TC, const ArgList &Args,
llvm::opt::ArgStringList &CmdArgs) {
if (TC.getTriple().isKnownWindowsMSVCEnvironment()) {
-CmdArgs.push_back("Fortran_main.lib");
-CmdArgs.push_back("FortranRuntime.lib");
-CmdArgs.push_back("FortranDecimal.lib");
+CmdArgs.push_back(Args.MakeArgString(
+"/DEFAULTLIB:" + TC.getCompilerRTBasename(Args, "builtins")));
+unsigned RTOptionID = options::OPT__SLASH_MT;
bradking wrote:
In local testing, `flang-new -fms-runtime-lib=static foo.f90 -v`, where
`foo.f90` is an empty `program` statement, fails with a bunch of unresolved CRT
symbols.
https://github.com/llvm/llvm-project/pull/70833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
@@ -281,3 +281,26 @@ add_flang_library(FortranRuntime
INSTALL_WITH_TOOLCHAIN
)
+
+if (DEFINED MSVC)
+ add_flang_library(FortranRuntime.static ${sources}
+LINK_LIBS
+FortranDecimal.static
+INSTALL_WITH_TOOLCHAIN)
+ set_property(TARGET FortranRuntime.static PROPERTY MSVC_RUNTIME_LIBRARY
MultiThreaded)
bradking wrote:
After local testing, it seems my earlier advice to set the
`MSVC_RUNTIME_LIBRARY` property directly instead of using
`CMAKE_MSVC_RUNTIME_LIBRARY` was incorrect. LLVM's CMake infrastructure has
options for using object libraries, in which case the compilation might not
actually happen in the targets we name here. Please switch back to the
`set(CMAKE_MSVC_RUNTIME_LIBRARY ...)` pattern.
https://github.com/llvm/llvm-project/pull/70833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
@@ -976,12 +976,46 @@ bool tools::addOpenMPRuntime(ArgStringList &CmdArgs,
const ToolChain &TC,
return true;
}
-void tools::addFortranRuntimeLibs(const ToolChain &TC,
+void tools::addFortranRuntimeLibs(const ToolChain &TC, const ArgList &Args,
llvm::opt::ArgStringList &CmdArgs) {
if (TC.getTriple().isKnownWindowsMSVCEnvironment()) {
-CmdArgs.push_back("Fortran_main.lib");
-CmdArgs.push_back("FortranRuntime.lib");
-CmdArgs.push_back("FortranDecimal.lib");
+CmdArgs.push_back(Args.MakeArgString(
+"/DEFAULTLIB:" + TC.getCompilerRTBasename(Args, "builtins")));
+unsigned RTOptionID = options::OPT__SLASH_MT;
+if (auto *rtl = Args.getLastArg(options::OPT_fms_runtime_lib_EQ)) {
+ RTOptionID = llvm::StringSwitch(rtl->getValue())
+ .Case("static", options::OPT__SLASH_MT)
+ .Case("static_dbg", options::OPT__SLASH_MTd)
+ .Case("dll", options::OPT__SLASH_MD)
+ .Case("dll_dbg", options::OPT__SLASH_MDd)
+ .Default(options::OPT__SLASH_MT);
bradking wrote:
The switch accepts names `static,static_dbg,dll,dbg_dll`. Should we use
matching names for the `FortranRuntime.*.lib` variants?
https://github.com/llvm/llvm-project/pull/70833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
@@ -1,3 +1,21 @@ add_flang_library(Fortran_main STATIC INSTALL_WITH_TOOLCHAIN Fortran_main.c ) +if (DEFINED MSVC) +add_flang_library(Fortran_main.static STATIC INSTALL_WITH_TOOLCHAIN +Fortran_main.c +) bradking wrote: The style elsewhere seems to use 2 spaces for indentation. https://github.com/llvm/llvm-project/pull/70833 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
@@ -976,12 +976,46 @@ bool tools::addOpenMPRuntime(ArgStringList &CmdArgs,
const ToolChain &TC,
return true;
}
-void tools::addFortranRuntimeLibs(const ToolChain &TC,
+void tools::addFortranRuntimeLibs(const ToolChain &TC, const ArgList &Args,
llvm::opt::ArgStringList &CmdArgs) {
if (TC.getTriple().isKnownWindowsMSVCEnvironment()) {
-CmdArgs.push_back("Fortran_main.lib");
-CmdArgs.push_back("FortranRuntime.lib");
-CmdArgs.push_back("FortranDecimal.lib");
+CmdArgs.push_back(Args.MakeArgString(
+"/DEFAULTLIB:" + TC.getCompilerRTBasename(Args, "builtins")));
+unsigned RTOptionID = options::OPT__SLASH_MT;
+if (auto *rtl = Args.getLastArg(options::OPT_fms_runtime_lib_EQ)) {
+ RTOptionID = llvm::StringSwitch(rtl->getValue())
+ .Case("static", options::OPT__SLASH_MT)
+ .Case("static_dbg", options::OPT__SLASH_MTd)
+ .Case("dll", options::OPT__SLASH_MD)
+ .Case("dll_dbg", options::OPT__SLASH_MDd)
+ .Default(options::OPT__SLASH_MT);
bradking wrote:
Hmm. Now that I see those names on disk after building from your update, file
names like `FortranRuntime.dll.lib` might be confusing since they do not
actually have a corresponding `FortranRuntime.dll`. Maybe `.dynamic` was
better.
https://github.com/llvm/llvm-project/pull/70833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
https://github.com/bradking edited https://github.com/llvm/llvm-project/pull/70833 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
@@ -976,12 +976,46 @@ bool tools::addOpenMPRuntime(ArgStringList &CmdArgs,
const ToolChain &TC,
return true;
}
-void tools::addFortranRuntimeLibs(const ToolChain &TC,
+void tools::addFortranRuntimeLibs(const ToolChain &TC, const ArgList &Args,
llvm::opt::ArgStringList &CmdArgs) {
if (TC.getTriple().isKnownWindowsMSVCEnvironment()) {
-CmdArgs.push_back("Fortran_main.lib");
-CmdArgs.push_back("FortranRuntime.lib");
-CmdArgs.push_back("FortranDecimal.lib");
+CmdArgs.push_back(Args.MakeArgString(
+"/DEFAULTLIB:" + TC.getCompilerRTBasename(Args, "builtins")));
+unsigned RTOptionID = options::OPT__SLASH_MT;
bradking wrote:
The errors were due to
https://github.com/llvm/llvm-project/pull/70833#pullrequestreview-1710341215
because the runtime library variants not being built with the correct CRT
themselves. After switching back to the `CMAKE_MSVC_RUNTIME_LIBRARY` the
problem is resolved.
https://github.com/llvm/llvm-project/pull/70833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang][windows] Add option to link against specific MSVC CRT (PR #70833)
@@ -281,3 +281,26 @@ add_flang_library(FortranRuntime
INSTALL_WITH_TOOLCHAIN
)
+
+if (DEFINED MSVC)
+ set(CMAKE_MSVC_RUNTIME_LIBRARY MultiThreaded)
+ add_flang_library(FortranRuntime.static ${sources}
bradking wrote:
When targeting the MSVC ABI, the plain `FortranRuntime` library added above
should be excluded. Only the per-CRT variants should exist, because choosing a
CRT variant is not optional.
https://github.com/llvm/llvm-project/pull/70833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [flang] Add MSC_VER and target arch defines when targeting the MSVC ABI (PR #73250)
bradking wrote: This file has CRLF newlines. Is that expected? https://github.com/llvm/llvm-project/pull/73250 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [flang] Add MSC_VER and target arch defines when targeting the MSVC ABI (PR #73250)
@@ -204,6 +204,29 @@ void Flang::AddAArch64TargetArgs(const ArgList &Args,
}
}
+static void addVSDefines(const ToolChain &TC, const ArgList &Args,
+ ArgStringList &CmdArgs) {
+
+ unsigned ver = 0;
+ const VersionTuple vt = TC.computeMSVCVersion(nullptr, Args);
+ ver = vt.getMajor() * 1000 + vt.getMinor().value_or(0) * 10 +
+vt.getSubminor().value_or(0);
+ CmdArgs.push_back(Args.MakeArgString("-D_MSC_VER=" + Twine(ver / 10)));
+ CmdArgs.push_back(Args.MakeArgString("-D_MSC_FULL_VER=" + Twine(ver)));
+
+ llvm::Triple triple = TC.getTriple();
+ if (triple.isAArch64()) {
+CmdArgs.push_back("-D_M_ARM64=1");
bradking wrote:
Does LLVM/Flang support the `_M_ARM64EC` ABI?
https://github.com/llvm/llvm-project/pull/73250
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang] Add MSC_VER and target arch defines when targeting the MSVC ABI (PR #73250)
@@ -322,6 +345,7 @@ void Flang::addTargetOptions(const ArgList &Args,
if (Triple.isKnownWindowsMSVCEnvironment()) {
processVSRuntimeLibrary(TC, Args, CmdArgs);
+addVSDefines(TC, Args, CmdArgs);
}
// TODO: Add target specific flags, ABI, mtune option etc.
bradking wrote:
Please also add `-D_WIN32` to indicate that this is targeting a Windows
platform.
https://github.com/llvm/llvm-project/pull/73250
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [flang] [flang] Add MSC_VER and target arch defines when targeting the MSVC ABI (PR #73250)
@@ -322,6 +345,7 @@ void Flang::addTargetOptions(const ArgList &Args,
if (Triple.isKnownWindowsMSVCEnvironment()) {
processVSRuntimeLibrary(TC, Args, CmdArgs);
+addVSDefines(TC, Args, CmdArgs);
}
// TODO: Add target specific flags, ABI, mtune option etc.
bradking wrote:
OTOH this could be considered out of scope for this PR.
https://github.com/llvm/llvm-project/pull/73250
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[flang] [clang] [flang] Add MSC_VER and target arch defines when targeting the MSVC ABI (PR #73250)
bradking wrote: @DavidTruby thanks. This LGTM now. I've locally updated CMake to use the preprocessor definitions in place of the workaround we had before, and it seems to work with this PR. https://github.com/llvm/llvm-project/pull/73250 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r250577 - [modules] Allow the error when explicitly loading an incompatible module file
On 10/20/2015 04:38 AM, Manuel Klimek wrote: > On Tue, Oct 20, 2015 at 5:52 AM Sean Silva wrote: >> get cmake to generate clang module map files and add explicit module build >> steps? > > I have some experience hacking on cmake, and from my experience I think > this shouldn't be too hard to get working (mainly work ;) I agree this shouldn't be too hard on the CMake side. Manuel, please come over to the cmake dev list to raise the design discussion. Then we can guide your implementation work. The main design challenges I foresee are: 1. Deciding how this behavior should be activated for a project by its code and/or by the user. 2. Selection of the proper set of headers if it is not exactly the set listed in the target for some reason. Might this ever by more granular than a whole library target? 3. Finding the right place during the CMake generation process to add the rules for this. We already detect the Clang compiler version so deciding if it is new enough to support the feature should not be hard. Thanks, -Brad ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D23455: [Tooling] Parse compilation database command lines properly on Windows
brad.king added a comment. > the feasibility of emitting 'arguments' instead of 'command' into the JSON > compilation database. CMake constructs the command lines internally using string replacement on templates. We never actually know the exact arguments. Therefore providing arguments instead of the whole command would require parsing to be done on the CMake side instead. This is theoretically possible because we do know the shell for which we are generating (Windows `cmd` versus MSYS `sh`). However, it may also require a bunch of logic we don't have yet but that LLVM does. Alternatively, the JSON could have an additional `command_shell="..."` field that indicates the shell for which the command line is encoded. https://reviews.llvm.org/D23455 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D19881: clang-cl: Print a blank line at the start of /showIncludes (PR27226)
brad.king added a comment. I do not think MSVC starts off with an empty line with -showIncludes specifically. It is just that MSVC unconditionally prints the name of the source file first. This means that any showIncludes output is naturally preceded by a newline because at least one other line was printed first. If clang-cl is to have compatible output with MS cl then it should print the source file name first too. However, that would be a broader decision that should stand on its own. IMO the motivating use case is simply a bug in CMake and clang-cl should not have to adapt to it. There is already a workaround available for existing clang-cl/CMake release combinations. CMake nightly binaries will be available starting tonight with the fix, and the CMake 3.6 release will have the fix too. http://reviews.llvm.org/D19881 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
