[Clang][Interpreter] Don't pass -fPIC on MSVC - #210507
Conversation
MSCV does not support the -fPIC option. When it is passed, Clang falls back to PIC level 2 on x86_64 and to a static binary on AArch64. Without -fPIC, however, PIC is already enabled by default on both targets. As a result, the PCH (built with the default PIC level by toolchain hint) and the clang-repl instance (using the fallback PIC level) end up with different PIC settings, consuming a mismatch. Avoid passing -fPIC when targeting MSVC on Windows. This preserve the existing semantics, since PIC is already enabled by default, while ensuring that both the PCH and clang-repl use the same PIC level.
|
@llvm/pr-subscribers-clang Author: aokblast ChangesMSCV does not support the -fPIC option. When it is passed, Clang falls back to PIC level 2 on x86_64 and to a static binary on AArch64. Without -fPIC, however, PIC is already enabled by default on both targets. As a result, the PCH (built with the default PIC level by toolchain hint) and the clang-repl instance (using the fallback PIC level) end up with different PIC settings, consuming a mismatch. Avoid passing -fPIC when targeting MSVC on Windows. This preserve the existing semantics, since PIC is already enabled by default, while ensuring that both the PCH and clang-repl use the same PIC level. Full diff: https://github.com/llvm/llvm-project/pull/210507.diff 1 Files Affected:
diff --git a/clang/lib/Interpreter/Interpreter.cpp b/clang/lib/Interpreter/Interpreter.cpp
index 933a68b50db41..0536fdcd548a2 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -53,6 +53,7 @@
#include "llvm/Support/VirtualFileSystem.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/TargetParser/Host.h"
+#include "llvm/TargetParser/Triple.h"
#include "llvm/Transforms/Utils/Cloning.h" // for CloneModule
#define DEBUG_TYPE "clang-repl"
@@ -228,8 +229,13 @@ IncrementalCompilerBuilder::create(std::string TT,
// host symbol may be out of range when the JIT memory is mapped more than
// 2GB away (as on FreeBSD), breaking tests such as
// Interpreter/simple-exception.cpp. Insert before user arguments so it can
- // still be overridden.
- ClangArgv.insert(ClangArgv.begin() + 1, "-fPIC");
+ // still be overridden. On Windows (excluding Cygwin/MinGW) an explicit
+ // -fPIC is an unsupported driver option that would drop non-x86_64 targets
+ // to PIC level 0; PIC is already the forced default there where relevant,
+ // so don't inject it.
+ llvm::Triple TargetTriple(TT);
+ if (!TargetTriple.isOSWindows() || TargetTriple.isOSCygMing())
+ ClangArgv.insert(ClangArgv.begin() + 1, "-fPIC");
// Prepending -c to force the driver to do something if no action was
// specified. By prepending we allow users to override the default
|
|
@dyung I am wondering if we can run on the breaking machine as MSVC in aarch64 is not in PR hook. |
I ran your changes on the failing bot and they seemed to work: https://lab.llvm.org/buildbot/#/builders/161/builds/12358 |
|
Thanks! |
|
/cherry-pick 617e4f5 |
|
/pull-request #210642 |
(cherry picked from commit 617e4f5)
MSCV does not support the -fPIC option. When it is passed, Clang falls back to PIC level 2 on x86_64 and to a static binary on AArch64. Without -fPIC, however, PIC is already enabled by default on both targets.
As a result, the PCH (built with the default PIC level by toolchain hint) and the clang-repl instance (using the fallback PIC level) end up with different PIC settings, consuming a mismatch.
Avoid passing -fPIC when targeting MSVC on Windows. This preserve the existing semantics, since PIC is already enabled by default, while ensuring that both the PCH and clang-repl use the same PIC level.