Re: r338749 - Work around more GCC miscompiles exposed by r338464.
Hans, I think this commit should be merged to the 7.0 release branch; the first half of the GCC workaround made it in before the branch happened, but there was another identical case missing. // Martin On Thu, 2 Aug 2018, Martin Storsjo via cfe-commits wrote: Author: mstorsjo Date: Thu Aug 2 11:12:08 2018 New Revision: 338749 URL: http://llvm.org/viewvc/llvm-project?rev=338749&view=rev Log: Work around more GCC miscompiles exposed by r338464. This is the same fix as in r338478, for another occurrance of the same pattern from r338464. See gcc.gnu.org/PR86769 for details of the bug. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D49922: [P0936R0] add [[clang::lifetimebound]] attribute
On Thu, 2 Aug 2018, Richard Smith via cfe-commits wrote: On Thu, 2 Aug 2018, 06:10 Martin Storsjö via Phabricator via cfe-commits, wrote: mstorsjo added a comment. This change made clang to start trigger failed asserts for me (although they seem to not be reproducible with all compilers building clang), see https://bugs.llvm.org/show_bug.cgi?id=38421 for full description. Are you still seeing problems after r338478? This change is miscompiled by GCC; that revision contains a workaround. Sorry, didn't see this mail until now. Yes, I saw problems even after r338478; I applied the same fix in a different spot as well, in r338749. // Martin ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r333978 - Reimplement the bittest intrinsic family as builtins with inline asm
On Tue, 5 Jun 2018, Reid Kleckner via cfe-commits wrote:
Author: rnk
Date: Mon Jun 4 18:33:40 2018
New Revision: 333978
URL: http://llvm.org/viewvc/llvm-project?rev=333978&view=rev
Log:
Reimplement the bittest intrinsic family as builtins with inline asm
We need to implement _interlockedbittestandset as a builtin for
windows.h, so we might as well do the whole family. It reduces code
duplication anyway.
Fixes PR33188, a long standing bug in our bittest implementation
encountered by Chakra.
Added:
cfe/trunk/test/CodeGen/bittest-intrin.c
Modified:
cfe/trunk/include/clang/Basic/Builtins.def
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/Headers/intrin.h
cfe/trunk/test/CodeGen/ms-intrinsics-other.c
cfe/trunk/test/CodeGen/ms-intrinsics.c
Modified: cfe/trunk/include/clang/Basic/Builtins.def
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.def?rev=333978&r1=333977&r2=333978&view=diff
==
--- cfe/trunk/include/clang/Basic/Builtins.def (original)
+++ cfe/trunk/include/clang/Basic/Builtins.def Mon Jun 4 18:33:40 2018
@@ -744,6 +744,14 @@ BUILTIN(__builtin_rindex, "c*cC*i", "Fn"
LANGBUILTIN(_alloca, "v*z", "n", ALL_MS_LANGUAGES)
LANGBUILTIN(__annotation, "wC*.","n", ALL_MS_LANGUAGES)
LANGBUILTIN(__assume, "vb", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_bittest,"UcNiC*Ni", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_bittestandcomplement, "UcNi*Ni", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_bittestandreset,"UcNi*Ni", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_bittestandset, "UcNi*Ni", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_bittest64, "UcWiC*Wi", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_bittestandcomplement64, "UcWi*Wi", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_bittestandreset64, "UcWi*Wi", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_bittestandset64,"UcWi*Wi", "n", ALL_MS_LANGUAGES)
LIBBUILTIN(_byteswap_ushort, "UsUs", "fnc", "stdlib.h", ALL_MS_LANGUAGES)
LIBBUILTIN(_byteswap_ulong, "UNiUNi", "fnc", "stdlib.h", ALL_MS_LANGUAGES)
LIBBUILTIN(_byteswap_uint64, "ULLiULLi", "fnc", "stdlib.h", ALL_MS_LANGUAGES)
@@ -783,7 +791,10 @@ LANGBUILTIN(_InterlockedOr, "NiNiD*Ni"
LANGBUILTIN(_InterlockedXor8, "ccD*c", "n", ALL_MS_LANGUAGES)
LANGBUILTIN(_InterlockedXor16, "ssD*s", "n", ALL_MS_LANGUAGES)
LANGBUILTIN(_InterlockedXor, "NiNiD*Ni","n", ALL_MS_LANGUAGES)
-LANGBUILTIN(_interlockedbittestandset, "UcNiD*Ni", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_interlockedbittestandreset, "UcNiD*Ni", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_interlockedbittestandreset64, "UcWiD*Wi", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_interlockedbittestandset, "UcNiD*Ni", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_interlockedbittestandset64, "UcWiD*Wi", "n", ALL_MS_LANGUAGES)
LANGBUILTIN(__noop, "i.", "n", ALL_MS_LANGUAGES)
LANGBUILTIN(__popcnt16, "UsUs", "nc", ALL_MS_LANGUAGES)
LANGBUILTIN(__popcnt, "UiUi", "nc", ALL_MS_LANGUAGES)
Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=333978&r1=333977&r2=333978&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Mon Jun 4 18:33:40 2018
@@ -484,6 +484,37 @@ CodeGenFunction::emitBuiltinObjectSize(c
return Builder.CreateCall(F, {Ptr, Min, NullIsUnknown});
}
+static RValue EmitBitTestIntrinsic(CodeGenFunction &CGF, const CallExpr *E,
+ char TestAnd, char Size,
+ bool Locked = false) {
+ Value *BitBase = CGF.EmitScalarExpr(E->getArg(0));
+ Value *BitPos = CGF.EmitScalarExpr(E->getArg(1));
+
+ // Build the assembly.
+ SmallString<64> Asm;
+ raw_svector_ostream AsmOS(Asm);
+ if (Locked)
+AsmOS << "lock ";
+ AsmOS << "bt";
+ if (TestAnd)
+AsmOS << TestAnd;
+ AsmOS << Size << " $2, ($1)\n\tsetc ${0:b}";
+
+ // Build the constraints. FIXME: We should support immediates when possible.
+ std::string Constraints = "=r,r,r,~{cc},~{flags},~{memory},~{fpsr}";
+ llvm::IntegerType *IntType = llvm::IntegerType::get(
+ CGF.getLLVMContext(),
+ CGF.getContext().getTypeSize(E->getArg(1)->getType()));
+ llvm::Type *IntPtrType = IntType->getPointerTo();
+ llvm::FunctionType *FTy =
+ llvm::FunctionType::get(CGF.Int8Ty, {IntPtrType, IntType}, false);
+
+ llvm::InlineAsm *IA =
+ llvm::InlineAsm::get(FTy, Asm, Constraints, /*SideEffects=*/true);
+ CallSite CS = CGF.Builder.CreateCall(IA, {BitBase, BitPos});
+ return RValue::get(CS.getInstruction());
+}
+
// Many of MSVC builtins are on both x64 and ARM; to avoid repeating code, we
// handle them here.
This doesn't seem thought through wrt non-x86 architectures. I'm not sure
if there's any similar suitable instruction to use on ARM/AArch64, but we
should
Re: r334208 - [X86] Add back builtins for _mm_slli_si128/_mm_srli_si128 and similar intrinsics.
On Thu, 7 Jun 2018, Craig Topper via cfe-commits wrote: Author: ctopper Date: Thu Jun 7 10:28:03 2018 New Revision: 334208 URL: http://llvm.org/viewvc/llvm-project?rev=334208&view=rev Log: [X86] Add back builtins for _mm_slli_si128/_mm_srli_si128 and similar intrinsics. We still lower them to native shuffle IR, but we do it in CGBuiltin.cpp now. This allows us to check the target feature and ensure the immediate fits in 8 bits. FWIW, this change broke building libaom: https://bugs.chromium.org/p/aomedia/issues/detail?id=1945 In libaom, there's a macro construct like this: #define v256_shr_n_byte(a, n) \ ((n) < 16 \ ? _mm256_alignr_epi8( \ _mm256_permute2x128_si256(a, a, _MM_SHUFFLE(2, 0, 0, 1)), a, n) \ : ((n) > 16\ ? _mm256_srli_si256(\ _mm256_permute2x128_si256(a, a, _MM_SHUFFLE(2, 0, 0, 1)), \ (n)-16) \ : _mm256_permute2x128_si256(a, a, _MM_SHUFFLE(2, 0, 0, 1 Since this commit, the compilation errors out due to the _mm256_srli_si256 with invalid range, even though the toplevel ternary operator won't actually pick them to be used. Not sure if there's anything to do from the clang point of view here, I guess it's a tradeoff between having stricter parameter checks for the intrinsics, vs the convenience of piling them up in a macro like this in libaom. // Martin ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D56850: [ASTMatchers][NFC] Add tests for assorted `CXXMemberCallExpr` matchers.
It broke on the first commit and is broken even after all of them.
// Martin
On Fri, 15 Feb 2019, Yitzhak Mandelbaum wrote:
Was it the complete diff or one of the intermediate commits? I accidentally
committed the diff as a series of commits rather than one (squashed)
commit.
On Fri, Feb 15, 2019 at 4:51 PM Martin Storsjö via Phabricator
wrote:
mstorsjo added a comment.
This broke compilation with GCC 5.4 on Ubuntu 16.04:
../tools/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:474:243:
warning: missing terminating " character
../tools/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:474:3:
error: missing terminating " character
EXPECT_TRUE(matches(
^
../tools/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:480:7:
error: stray ‘\’ in program
void z(X x) { x.m(); }
^
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56850/new/
https://reviews.llvm.org/D56850
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D56850: [ASTMatchers][NFC] Add tests for assorted `CXXMemberCallExpr` matchers.
FWIW, this was fixed by SVN r354201. Thanks David!
// Martin
On Sat, 16 Feb 2019, Martin Storsjö via cfe-commits wrote:
It broke on the first commit and is broken even after all
of them.
// Martin
On Fri, 15 Feb 2019, Yitzhak Mandelbaum wrote:
Was it the complete diff or one of the intermediate
commits? I accidentally
committed the diff as a series of commits rather than
one (squashed)
commit.
On Fri, Feb 15, 2019 at 4:51 PM Martin Storsjö via
Phabricator
wrote:
mstorsjo added a comment.
This broke compilation with GCC 5.4 on Ubuntu
16.04:
../tools/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:474:243:
warning: missing terminating " character
../tools/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:474:3:
error: missing terminating " character
EXPECT_TRUE(matches(
^
../tools/clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:480:7:
error: stray ‘\’ in program
void z(X x) { x.m(); }
^
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56850/new/
https://reviews.llvm.org/D56850
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r362551 - Convert MemberExpr creation and serialization to work the same way as
This broke building of Qt when using PCH. Selfcontained repro is a bit
hard to make though...
// Martin
On Tue, 4 Jun 2019, Richard Smith via cfe-commits wrote:
Author: rsmith
Date: Tue Jun 4 14:29:28 2019
New Revision: 362551
URL: http://llvm.org/viewvc/llvm-project?rev=362551&view=rev
Log:
Convert MemberExpr creation and serialization to work the same way as
most / all other Expr subclasses.
Modified:
cfe/trunk/include/clang/AST/Expr.h
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/lib/AST/DeclBase.cpp
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/lib/Frontend/Rewrite/RewriteModernObjC.cpp
cfe/trunk/lib/Frontend/Rewrite/RewriteObjC.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Serialization/ASTReaderStmt.cpp
cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
Modified: cfe/trunk/include/clang/AST/Expr.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Expr.h?rev=362551&r1=362550&r2=362551&view=diff
==
--- cfe/trunk/include/clang/AST/Expr.h (original)
+++ cfe/trunk/include/clang/AST/Expr.h Tue Jun 4 14:29:28 2019
@@ -2735,6 +2735,7 @@ class MemberExpr final
ASTTemplateKWAndArgsInfo,
TemplateArgumentLoc> {
friend class ASTReader;
+ friend class ASTStmtReader;
friend class ASTStmtWriter;
friend TrailingObjects;
@@ -2769,49 +2770,38 @@ class MemberExpr final
return MemberExprBits.HasTemplateKWAndArgsInfo;
}
-public:
- MemberExpr(Expr *base, bool isarrow, SourceLocation operatorloc,
- ValueDecl *memberdecl, const DeclarationNameInfo &NameInfo,
- QualType ty, ExprValueKind VK, ExprObjectKind OK)
- : Expr(MemberExprClass, ty, VK, OK, base->isTypeDependent(),
- base->isValueDependent(), base->isInstantiationDependent(),
- base->containsUnexpandedParameterPack()),
-Base(base), MemberDecl(memberdecl), MemberDNLoc(NameInfo.getInfo()),
-MemberLoc(NameInfo.getLoc()) {
-assert(memberdecl->getDeclName() == NameInfo.getName());
-MemberExprBits.IsArrow = isarrow;
-MemberExprBits.HasQualifierOrFoundDecl = false;
-MemberExprBits.HasTemplateKWAndArgsInfo = false;
-MemberExprBits.HadMultipleCandidates = false;
-MemberExprBits.OperatorLoc = operatorloc;
- }
-
- // NOTE: this constructor should be used only when it is known that
- // the member name can not provide additional syntactic info
- // (i.e., source locations for C++ operator names or type source info
- // for constructors, destructors and conversion operators).
- MemberExpr(Expr *base, bool isarrow, SourceLocation operatorloc,
- ValueDecl *memberdecl, SourceLocation l, QualType ty,
- ExprValueKind VK, ExprObjectKind OK)
- : Expr(MemberExprClass, ty, VK, OK, base->isTypeDependent(),
- base->isValueDependent(), base->isInstantiationDependent(),
- base->containsUnexpandedParameterPack()),
-Base(base), MemberDecl(memberdecl), MemberDNLoc(), MemberLoc(l) {
-MemberExprBits.IsArrow = isarrow;
-MemberExprBits.HasQualifierOrFoundDecl = false;
-MemberExprBits.HasTemplateKWAndArgsInfo = false;
-MemberExprBits.HadMultipleCandidates = false;
-MemberExprBits.OperatorLoc = operatorloc;
- }
+ MemberExpr(Expr *Base, bool IsArrow, SourceLocation OperatorLoc,
+ ValueDecl *MemberDecl, const DeclarationNameInfo &NameInfo,
+ QualType T, ExprValueKind VK, ExprObjectKind OK);
+ MemberExpr(EmptyShell Empty)
+ : Expr(MemberExprClass, Empty), Base(), MemberDecl() {}
- static MemberExpr *Create(const ASTContext &C, Expr *base, bool isarrow,
+public:
+ static MemberExpr *Create(const ASTContext &C, Expr *Base, bool IsArrow,
SourceLocation OperatorLoc,
NestedNameSpecifierLoc QualifierLoc,
-SourceLocation TemplateKWLoc, ValueDecl
*memberdecl,
-DeclAccessPair founddecl,
+SourceLocation TemplateKWLoc, ValueDecl
*MemberDecl,
+DeclAccessPair FoundDecl,
DeclarationNameInfo MemberNameInfo,
-const TemplateArgumentListInfo *targs, QualType ty,
-ExprValueKind VK, ExprObjectKind OK);
+const TemplateArgumentListInfo *TemplateArgs,
+QualType T, ExprValueKind VK, ExprObjectKind OK);
+
+ /// Create an implicit MemberExpr, with no location, qualifier, template
+ /// arguments, and so on.
+ static MemberExpr *CreateImplicit(const ASTContext &C, Expr *Base,
+bool IsArrow, ValueDecl *MemberDecl,
+QualType T, ExprValueKind VK,
+ExprObjectKind OK) {
+return Create(C, Base, IsArro
Re: r368348 - Fix up fd limit diagnosis code
This change broke compiling Qt.
A repro case looks like this:
mkdir -p fake-qtincl/5.13.1/QtCore/private
touch fake-qtincl/5.13.1/QtCore/private/qglobal_p.h
touch fake-qtincl/QtCore
echo "#include " > qtincl.cpp
bin/clang++ -c qtincl.cpp -Ifake-qtincl -Ifake-qtincl/5.13.1
Previously this ignored the non-directory QtCore, but now clang bails out
on it. (And this is code that all other major compilers tolerate, afaik.)
// Martin
On Thu, 8 Aug 2019, Reid Kleckner via cfe-commits wrote:
Author: rnk
Date: Thu Aug 8 14:35:03 2019
New Revision: 368348
URL: http://llvm.org/viewvc/llvm-project?rev=368348&view=rev
Log:
Fix up fd limit diagnosis code
Apparently Windows returns the "invalid argument" error code when the
path contains invalid characters such as '<'. The
test/Preprocessor/include-likely-typo.c test does this, so it was
failing after r368322.
Also, the diagnostic requires two arguments, so add the filename.
Modified:
cfe/trunk/lib/Lex/HeaderSearch.cpp
Modified: cfe/trunk/lib/Lex/HeaderSearch.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/HeaderSearch.cpp?rev=368348&r1=368347&r2=368348&view=diff
==
--- cfe/trunk/lib/Lex/HeaderSearch.cpp (original)
+++ cfe/trunk/lib/Lex/HeaderSearch.cpp Thu Aug 8 14:35:03 2019
@@ -316,8 +316,9 @@ const FileEntry *HeaderSearch::getFileAn
// message.
std::error_code EC = File.getError();
if (EC != std::errc::no_such_file_or_directory &&
-EC != std::errc::is_a_directory) {
- Diags.Report(IncludeLoc, diag::err_cannot_open_file) << EC.message();
+EC != std::errc::invalid_argument && EC != std::errc::is_a_directory) {
+ Diags.Report(IncludeLoc, diag::err_cannot_open_file)
+ << FileName << EC.message();
}
return nullptr;
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r368348 - Fix up fd limit diagnosis code
Thanks for the fix, Qt does seem to build correctly now again.
// Martin
On Fri, 9 Aug 2019, Reid Kleckner wrote:
Let me know if the problem persists after r368475. Someone else filed
https://bugs.llvm.org/show_bug.cgi?id=42948 as well.
On Thu, Aug 8, 2019 at 11:34 PM Martin Storsjö wrote:
This change broke compiling Qt.
A repro case looks like this:
mkdir -p fake-qtincl/5.13.1/QtCore/private
touch fake-qtincl/5.13.1/QtCore/private/qglobal_p.h
touch fake-qtincl/QtCore
echo "#include " > qtincl.cpp
bin/clang++ -c qtincl.cpp -Ifake-qtincl -Ifake-qtincl/5.13.1
Previously this ignored the non-directory QtCore, but now clang
bails out
on it. (And this is code that all other major compilers
tolerate, afaik.)
// Martin
On Thu, 8 Aug 2019, Reid Kleckner via cfe-commits wrote:
> Author: rnk
> Date: Thu Aug 8 14:35:03 2019
> New Revision: 368348
>
> URL: http://llvm.org/viewvc/llvm-project?rev=368348&view=rev
> Log:
> Fix up fd limit diagnosis code
>
> Apparently Windows returns the "invalid argument" error code
when the
> path contains invalid characters such as '<'. The
> test/Preprocessor/include-likely-typo.c test does this, so it
was
> failing after r368322.
>
> Also, the diagnostic requires two arguments, so add the
filename.
>
> Modified:
> cfe/trunk/lib/Lex/HeaderSearch.cpp
>
> Modified: cfe/trunk/lib/Lex/HeaderSearch.cpp
>
URL:http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/HeaderSearch.cpp?rev=
368348&r1=368347&r2=368348&view=diff
>===
===
> --- cfe/trunk/lib/Lex/HeaderSearch.cpp (original)
> +++ cfe/trunk/lib/Lex/HeaderSearch.cpp Thu Aug 8 14:35:03
2019
> @@ -316,8 +316,9 @@ const FileEntry *HeaderSearch::getFileAn
> // message.
> std::error_code EC = File.getError();
> if (EC != std::errc::no_such_file_or_directory &&
> - EC != std::errc::is_a_directory) {
> - Diags.Report(IncludeLoc, diag::err_cannot_open_file) <<
EC.message();
> + EC != std::errc::invalid_argument && EC !=
std::errc::is_a_directory) {
> + Diags.Report(IncludeLoc, diag::err_cannot_open_file)
> + << FileName << EC.message();
> }
> return nullptr;
> }
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RE: r330244 - [MinGW] Look for a cross sysroot relative to the clang binary
Hi Douglas,
Yes, I saw it - trying to look into it right now.
// Martin
On Wed, 18 Apr 2018, douglas.y...@sony.com wrote:
Hi Martin,
Your commit is causing a few test failures on the PS4 Windows bot, can you take
a look?
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/16544
Failing Tests (13):
Clang :: CodeGenCXX/mingw-w64-exceptions.c
Clang :: Driver/clang-translation.c
Clang :: Driver/cxa-atexit.cpp
Clang :: Driver/default-image-name.c
Clang :: Driver/fsjlj-exceptions.c
Clang :: Driver/incremental-linker-compatible.c
Clang :: Driver/mingw-libgcc.c
Clang :: Driver/mingw-msvcrt.c
Clang :: Driver/no-integrated-as-win.c
Clang :: Driver/pic.c
Clang :: Driver/windows-pic.cpp
Clang :: Index/index-attrs.c
Clang :: Index/index-attrs.cpp
Douglas Yung
-Original Message-
From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
Martin Storsjo via cfe-commits
Sent: Wednesday, April 18, 2018 1:47
To: cfe-commits@lists.llvm.org
Subject: r330244 - [MinGW] Look for a cross sysroot relative to the clang
binary
Author: mstorsjo
Date: Wed Apr 18 01:47:26 2018
New Revision: 330244
URL: http://llvm.org/viewvc/llvm-project?rev=330244&view=rev
Log:
[MinGW] Look for a cross sysroot relative to the clang binary
If found, prefer this over looking for a similar gcc later in the
system path.
Differential Revision: https://reviews.llvm.org/D45504
Modified:
cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
cfe/trunk/lib/Driver/ToolChains/MinGW.h
Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
URL: http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/Driver/ToolChains/MinGW.cpp?rev=330244&r1=330243&r2=3302
44&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/MinGW.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/MinGW.cpp Wed Apr 18 01:47:26 2018
@@ -275,7 +275,8 @@ void toolchains::MinGW::findGccLibDir()
Archs.emplace_back(getTriple().getArchName());
Archs[0] += "-w64-mingw32";
Archs.emplace_back("mingw32");
- Arch = Archs[0].str();
+ if (Arch.empty())
+Arch = Archs[0].str();
// lib: Arch Linux, Ubuntu, Windows
// lib64: openSUSE Linux
for (StringRef CandidateLib : {"lib", "lib64"}) {
@@ -302,6 +303,24 @@ llvm::ErrorOr toolchains::M
return make_error_code(std::errc::no_such_file_or_directory);
}
+llvm::ErrorOr toolchains::MinGW::findClangRelativeSysroot() {
+ llvm::SmallVector, 2> Subdirs;
+ Subdirs.emplace_back(getTriple().str());
+ Subdirs.emplace_back(getTriple().getArchName());
+ Subdirs[1] += "-w64-mingw32";
+ Twine ClangRoot =
+ llvm::sys::path::parent_path(getDriver().getInstalledDir()) +
+ llvm::sys::path::get_separator();
+ for (StringRef CandidateSubdir : Subdirs) {
+Twine Subdir = ClangRoot + CandidateSubdir;
+if (llvm::sys::fs::is_directory(Subdir)) {
+ Arch = CandidateSubdir;
+ return Subdir.str();
+}
+ }
+ return make_error_code(std::errc::no_such_file_or_directory);
+}
+
toolchains::MinGW::MinGW(const Driver &D, const llvm::Triple &Triple,
const ArgList &Args)
: ToolChain(D, Triple, Args), CudaInstallation(D, Triple, Args) {
@@ -309,6 +328,10 @@ toolchains::MinGW::MinGW(const Driver &D
if (getDriver().SysRoot.size())
Base = getDriver().SysRoot;
+ // Look for /../; if found, use /.. as the
+ // base as it could still be a base for a gcc setup with libgcc.
+ else if (llvm::ErrorOr TargetSubdir =
findClangRelativeSysroot())
+Base = llvm::sys::path::parent_path(TargetSubdir.get());
else if (llvm::ErrorOr GPPName = findGcc())
Base = llvm::sys::path::parent_path(
llvm::sys::path::parent_path(GPPName.get()));
Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.h
URL: http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/Driver/ToolChains/MinGW.h?rev=330244&r1=330243&r2=330244
&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/MinGW.h (original)
+++ cfe/trunk/lib/Driver/ToolChains/MinGW.h Wed Apr 18 01:47:26 2018
@@ -96,6 +96,7 @@ private:
mutable std::unique_ptr Compiler;
void findGccLibDir();
llvm::ErrorOr findGcc();
+ llvm::ErrorOr findClangRelativeSysroot();
};
} // end namespace toolchains
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RE: r330244 - [MinGW] Look for a cross sysroot relative to the clang binary
Hi Douglas,
I wasn't able to reproducd the issue myself, but I think I know what the
issue was, and I committed a fix attempt.
// Martin
On Wed, 18 Apr 2018, Martin Storsjö via cfe-commits wrote:
Hi Douglas,
Yes, I saw it - trying to look into it right now.
// Martin
On Wed, 18 Apr 2018, douglas.y...@sony.com wrote:
Hi Martin,
Your commit is causing a few test failures on the PS4 Windows bot,
can you take a look?
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/16544
Failing Tests (13):
Clang :: CodeGenCXX/mingw-w64-exceptions.c
Clang :: Driver/clang-translation.c
Clang :: Driver/cxa-atexit.cpp
Clang :: Driver/default-image-name.c
Clang :: Driver/fsjlj-exceptions.c
Clang :: Driver/incremental-linker-compatible.c
Clang :: Driver/mingw-libgcc.c
Clang :: Driver/mingw-msvcrt.c
Clang :: Driver/no-integrated-as-win.c
Clang :: Driver/pic.c
Clang :: Driver/windows-pic.cpp
Clang :: Index/index-attrs.c
Clang :: Index/index-attrs.cpp
Douglas Yung
-Original Message-
From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On
Behalf Of
Martin Storsjo via cfe-commits
Sent: Wednesday, April 18, 2018 1:47
To: cfe-commits@lists.llvm.org
Subject: r330244 - [MinGW] Look for a cross sysroot relative to
the clang
binary
Author: mstorsjo
Date: Wed Apr 18 01:47:26 2018
New Revision: 330244
URL: http://llvm.org/viewvc/llvm-project?rev=330244&view=rev
Log:
[MinGW] Look for a cross sysroot relative to the clang binary
If found, prefer this over looking for a similar gcc later in the
system path.
Differential Revision: https://reviews.llvm.org/D45504
Modified:
cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
cfe/trunk/lib/Driver/ToolChains/MinGW.h
Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
URL: http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/Driver/ToolChains/MinGW.cpp?rev=330244&r1=330243&r2=3302
44&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/MinGW.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/MinGW.cpp Wed Apr 18 01:47:26
2018
@@ -275,7 +275,8 @@ void toolchains::MinGW::findGccLibDir()
Archs.emplace_back(getTriple().getArchName());
Archs[0] += "-w64-mingw32";
Archs.emplace_back("mingw32");
- Arch = Archs[0].str();
+ if (Arch.empty())
+Arch = Archs[0].str();
// lib: Arch Linux, Ubuntu, Windows
// lib64: openSUSE Linux
for (StringRef CandidateLib : {"lib", "lib64"}) {
@@ -302,6 +303,24 @@ llvm::ErrorOr toolchains::M
return make_error_code(std::errc::no_such_file_or_directory);
}
+llvm::ErrorOr
toolchains::MinGW::findClangRelativeSysroot() {
+ llvm::SmallVector, 2> Subdirs;
+ Subdirs.emplace_back(getTriple().str());
+ Subdirs.emplace_back(getTriple().getArchName());
+ Subdirs[1] += "-w64-mingw32";
+ Twine ClangRoot =
+ llvm::sys::path::parent_path(getDriver().getInstalledDir())
+
+ llvm::sys::path::get_separator();
+ for (StringRef CandidateSubdir : Subdirs) {
+Twine Subdir = ClangRoot + CandidateSubdir;
+if (llvm::sys::fs::is_directory(Subdir)) {
+ Arch = CandidateSubdir;
+ return Subdir.str();
+}
+ }
+ return make_error_code(std::errc::no_such_file_or_directory);
+}
+
toolchains::MinGW::MinGW(const Driver &D, const llvm::Triple
&Triple,
const ArgList &Args)
: ToolChain(D, Triple, Args), CudaInstallation(D, Triple,
Args) {
@@ -309,6 +328,10 @@ toolchains::MinGW::MinGW(const Driver &D
if (getDriver().SysRoot.size())
Base = getDriver().SysRoot;
+ // Look for /../; if found, use
/.. as the
+ // base as it could still be a base for a gcc setup with
libgcc.
+ else if (llvm::ErrorOr TargetSubdir =
findClangRelativeSysroot())
+Base = llvm::sys::path::parent_path(TargetSubdir.get());
else if (llvm::ErrorOr GPPName = findGcc())
Base = llvm::sys::path::parent_path(
llvm::sys::path::parent_path(GPPName.get()));
Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.h
URL: http://llvm.org/viewvc/llvm-
project/cfe/trunk/lib/Driver/ToolChains/MinGW.h?rev=330244&r1=330243&r2=330244
&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/MinGW.h (original)
+++ cfe/trunk/lib/Driver/ToolChains/MinGW.h Wed Apr 18 01:47:26
2018
@@ -96,6 +96,7 @@ private:
mutable std::unique_ptr Compiler;
void findGccLibDir();
llvm::ErrorOr findGcc();
+ llvm::ErrorOr findClangRelativeSysroot();
};
} // end namespace toolchains
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llv
Re: Fix __attribute__((force_align_arg_pointer)) misalignment bug
Hej Henrik, On Thu, 19 Apr 2018, Henrik Gramner via cfe-commits wrote: The force_align_arg_pointer attribute was using a hardcoded 16-byte alignment value which in combination with -mstack-alignment=32 (or larger) would produce a misaligned stack which could result in crashes when accessing stack buffers using aligned AVX load/store instructions. The attached patch fixes the issue by using the "stackrealign" function attribute instead of using a hardcoded 16-byte alignment. Tested on 64-bit Linux and it works as far as I can see, unable to test on anything else though. You need to update the corresponding tests as well, run "ninja check-clang" to see that this change alters the output from test/CodeGen/function-attributes.c, breaking that test. You at least need to update it with how this patch changes the behaviour of the existing tests, but ideally also add a new test case (either in this file or as a completely new file) for the specific usecase that you had in mind (32 byte alignment). For better visibility, I'd also recommend uploading the patch at https://reviews.llvm.org (even though the official guidelines say this is optional). I don't know off-hand who would be best to add as reviewer for it though (I'm not authoritative in this area)... // Martin ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 0073c29 - [clang] Avoid linking libdl unless needed
Author: Tobias Hieta
Date: 2020-05-28T21:08:00+03:00
New Revision: 0073c293a401774ac96b4b3d27f05e13f379f98e
URL:
https://github.com/llvm/llvm-project/commit/0073c293a401774ac96b4b3d27f05e13f379f98e
DIFF:
https://github.com/llvm/llvm-project/commit/0073c293a401774ac96b4b3d27f05e13f379f98e.diff
LOG: [clang] Avoid linking libdl unless needed
Differential Revision: https://reviews.llvm.org/D80492
Added:
Modified:
clang/tools/libclang/CMakeLists.txt
Removed:
diff --git a/clang/tools/libclang/CMakeLists.txt
b/clang/tools/libclang/CMakeLists.txt
index ba286b672772..9b34682cc49b 100644
--- a/clang/tools/libclang/CMakeLists.txt
+++ b/clang/tools/libclang/CMakeLists.txt
@@ -66,9 +66,8 @@ if (LIBCLANG_INCLUDE_CLANG_TOOLS_EXTRA)
endif ()
endif ()
-find_library(DL_LIBRARY_PATH dl)
-if (DL_LIBRARY_PATH)
- list(APPEND LIBS dl)
+if (HAVE_LIBDL)
+ list(APPEND LIBS ${CMAKE_DL_LIBS})
endif()
option(LIBCLANG_BUILD_STATIC
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] ac1f7ab - [clang] [Darwin] Add reverse mappings for aarch64/aarch64_32 to darwin arch names
Author: Martin Storsjö
Date: 2020-05-29T15:23:14+03:00
New Revision: ac1f7ab007e347dc4a542aa3415e6378289480f4
URL:
https://github.com/llvm/llvm-project/commit/ac1f7ab007e347dc4a542aa3415e6378289480f4
DIFF:
https://github.com/llvm/llvm-project/commit/ac1f7ab007e347dc4a542aa3415e6378289480f4.diff
LOG: [clang] [Darwin] Add reverse mappings for aarch64/aarch64_32 to darwin
arch names
These are mapped in MachO::getMachOArchName already, but were missing
in ToolChain::getDefaultUniversalArchName.
Having these reverse mapped here fixes weird inconsistencies like
-dumpmachine showing a target triple like "aarch64-apple-darwin",
while "clang -target aarch64-apple-darwin" didn't use to work (ended
up mapped as unknown-apple-ios).
Differential Revision: https://reviews.llvm.org/D79117
Added:
clang/test/Driver/darwin-arm64-target.c
Modified:
clang/lib/Driver/ToolChain.cpp
Removed:
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index ad66e8e6b5d3..cf04fd07e2a0 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -230,9 +230,12 @@ ToolChain::getTargetAndModeFromProgramName(StringRef PN) {
StringRef ToolChain::getDefaultUniversalArchName() const {
// In universal driver terms, the arch name accepted by -arch isn't exactly
// the same as the ones that appear in the triple. Roughly speaking, this is
- // an inverse of the darwin::getArchTypeForDarwinArchName() function, but the
- // only interesting special case is powerpc.
+ // an inverse of the darwin::getArchTypeForDarwinArchName() function.
switch (Triple.getArch()) {
+ case llvm::Triple::aarch64:
+return "arm64";
+ case llvm::Triple::aarch64_32:
+return "arm64_32";
case llvm::Triple::ppc:
return "ppc";
case llvm::Triple::ppc64:
diff --git a/clang/test/Driver/darwin-arm64-target.c
b/clang/test/Driver/darwin-arm64-target.c
new file mode 100644
index ..397afa288360
--- /dev/null
+++ b/clang/test/Driver/darwin-arm64-target.c
@@ -0,0 +1,3 @@
+// RUN: %clang -target aarch64-apple-darwin %s -miphoneos-version-min=8.0 -###
2>&1 | FileCheck %s
+
+// CHECK: "-cc1"{{.*}} "-triple" "arm64-apple-ios8.0.0"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] ab4d02c - [clang] [MinGW] Fix libunwind extension
Author: Mateusz Mikuła
Date: 2020-05-29T15:23:14+03:00
New Revision: ab4d02cf265982d4c03123d2f52b9d5ee8df575d
URL:
https://github.com/llvm/llvm-project/commit/ab4d02cf265982d4c03123d2f52b9d5ee8df575d
DIFF:
https://github.com/llvm/llvm-project/commit/ab4d02cf265982d4c03123d2f52b9d5ee8df575d.diff
LOG: [clang] [MinGW] Fix libunwind extension
Differential Revision: https://reviews.llvm.org/D79995
Added:
Modified:
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/test/Driver/compiler-rt-unwind.c
Removed:
diff --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 33c43222b5f9..b2c984912154 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1235,7 +1235,14 @@ static void AddUnwindLibrary(const ToolChain &TC, const
Driver &D,
case ToolChain::UNW_CompilerRT:
if (LGT == LibGccType::StaticLibGcc)
CmdArgs.push_back("-l:libunwind.a");
-else
+else if (TC.getTriple().isOSCygMing()) {
+ if (LGT == LibGccType::SharedLibGcc)
+CmdArgs.push_back("-l:libunwind.dll.a");
+ else
+// Let the linker choose between libunwind.dll.a and libunwind.a
+// depending on what's available, and depending on the -static flag
+CmdArgs.push_back("-lunwind");
+} else
CmdArgs.push_back("-l:libunwind.so");
break;
}
diff --git a/clang/test/Driver/compiler-rt-unwind.c
b/clang/test/Driver/compiler-rt-unwind.c
index 652a48c6ad78..e21916d41f93 100644
--- a/clang/test/Driver/compiler-rt-unwind.c
+++ b/clang/test/Driver/compiler-rt-unwind.c
@@ -48,3 +48,26 @@
// RUN: --gcc-toolchain="" \
// RUN: FileCheck --input-file=%t.err
--check-prefix=RTLIB-GCC-UNWINDLIB-COMPILER_RT %s
// RTLIB-GCC-UNWINDLIB-COMPILER_RT: "{{[.|\\\n]*}}--rtlib=libgcc requires
--unwindlib=libgcc"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt
--unwindlib=libunwind \
+// RUN: -shared-libgcc \
+// RUN: --gcc-toolchain="" \
+// RUN: | FileCheck
--check-prefix=MINGW-RTLIB-COMPILER-RT-SHARED-UNWINDLIB-COMPILER-RT %s
+// MINGW-RTLIB-COMPILER-RT-SHARED-UNWINDLIB-COMPILER-RT:
"{{.*}}libclang_rt.builtins-x86_64.a"
+// MINGW-RTLIB-COMPILER-RT-SHARED-UNWINDLIB-COMPILER-RT:
"{{.*}}l:libunwind.dll.a"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt
--unwindlib=libunwind \
+// RUN: -static-libgcc \
+// RUN: --gcc-toolchain="" \
+// RUN: | FileCheck
--check-prefix=MINGW-RTLIB-COMPILER-RT-STATIC-UNWINDLIB-COMPILER-RT %s
+// MINGW-RTLIB-COMPILER-RT-STATIC-UNWINDLIB-COMPILER-RT:
"{{.*}}libclang_rt.builtins-x86_64.a"
+// MINGW-RTLIB-COMPILER-RT-STATIC-UNWINDLIB-COMPILER-RT: "{{.*}}l:libunwind.a"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt
--unwindlib=libunwind \
+// RUN: --gcc-toolchain="" \
+// RUN: | FileCheck
--check-prefix=MINGW-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT %s
+// MINGW-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT:
"{{.*}}libclang_rt.builtins-x86_64.a"
+// MINGW-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT: "{{.*}}lunwind"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] a41af6e - [clang] Fix libdl linking for libclang in standalone mode
Author: Tobias Hieta
Date: 2020-07-24T00:10:22+03:00
New Revision: a41af6e41e6fcf3e7030feaf24057cbe8291b748
URL:
https://github.com/llvm/llvm-project/commit/a41af6e41e6fcf3e7030feaf24057cbe8291b748
DIFF:
https://github.com/llvm/llvm-project/commit/a41af6e41e6fcf3e7030feaf24057cbe8291b748.diff
LOG: [clang] Fix libdl linking for libclang in standalone mode
Differential Revision: https://reviews.llvm.org/D81385
Added:
Modified:
clang/tools/libclang/CMakeLists.txt
Removed:
diff --git a/clang/tools/libclang/CMakeLists.txt
b/clang/tools/libclang/CMakeLists.txt
index 9b34682cc49b..a4077140acee 100644
--- a/clang/tools/libclang/CMakeLists.txt
+++ b/clang/tools/libclang/CMakeLists.txt
@@ -68,7 +68,12 @@ endif ()
if (HAVE_LIBDL)
list(APPEND LIBS ${CMAKE_DL_LIBS})
-endif()
+elseif (CLANG_BUILT_STANDALONE)
+ find_library(DL_LIBRARY_PATH dl)
+ if (DL_LIBRARY_PATH)
+list(APPEND LIBS dl)
+ endif ()
+endif ()
option(LIBCLANG_BUILD_STATIC
"Build libclang as a static library (in addition to a shared one)" OFF)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] e3fd9dc - [clang] Enable -mms-bitfields by default for mingw targets
Author: Martin Storsjö
Date: 2020-06-17T09:37:07+03:00
New Revision: e3fd9dc9734c5775dc6824d0a839702e8d43e7f6
URL:
https://github.com/llvm/llvm-project/commit/e3fd9dc9734c5775dc6824d0a839702e8d43e7f6
DIFF:
https://github.com/llvm/llvm-project/commit/e3fd9dc9734c5775dc6824d0a839702e8d43e7f6.diff
LOG: [clang] Enable -mms-bitfields by default for mingw targets
This matches GCC, which enabled -mms-bitfields by default for
mingw targets in 4.7 [1].
[1] https://www.gnu.org/software/gcc/gcc-4.7/changes.html
Differential Revision: https://reviews.llvm.org/D81795
Added:
Modified:
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/ms-bitfields.c
Removed:
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp
b/clang/lib/Driver/ToolChains/Clang.cpp
index 23ffc212056a..0ff8d1250242 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4679,7 +4679,7 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
CmdArgs.push_back("-fforbid-guard-variables");
if (Args.hasFlag(options::OPT_mms_bitfields, options::OPT_mno_ms_bitfields,
- false)) {
+ Triple.isWindowsGNUEnvironment())) {
CmdArgs.push_back("-mms-bitfields");
}
diff --git a/clang/test/Driver/ms-bitfields.c
b/clang/test/Driver/ms-bitfields.c
index 7bf9aaad2c96..51faa05f5855 100644
--- a/clang/test/Driver/ms-bitfields.c
+++ b/clang/test/Driver/ms-bitfields.c
@@ -1,4 +1,5 @@
-// RUN: %clang -### %s 2>&1 | FileCheck %s -check-prefix=NO-MSBITFIELDS
+// RUN: %clang -### -target x86_64-linux-gnu %s 2>&1 | FileCheck %s
-check-prefix=NO-MSBITFIELDS
+// RUN: %clang -### -target x86_64-windows-gnu %s 2>&1 | FileCheck %s
-check-prefix=MSBITFIELDS
// RUN: %clang -### -mno-ms-bitfields -mms-bitfields %s 2>&1 | FileCheck %s
-check-prefix=MSBITFIELDS
// RUN: %clang -### -mms-bitfields -mno-ms-bitfields %s 2>&1 | FileCheck %s
-check-prefix=NO-MSBITFIELDS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] beeed36 - [clang] [MinGW] Link kernel32 once after the last instance of msvcrt
Author: Martin Storsjö
Date: 2020-06-17T09:37:07+03:00
New Revision: beeed368b60252178f66ab117d8a96ecdc35f60e
URL:
https://github.com/llvm/llvm-project/commit/beeed368b60252178f66ab117d8a96ecdc35f60e
DIFF:
https://github.com/llvm/llvm-project/commit/beeed368b60252178f66ab117d8a96ecdc35f60e.diff
LOG: [clang] [MinGW] Link kernel32 once after the last instance of msvcrt
The msvcrt library isn't a pure import library; it does contain
regular object files with wrappers/fallbacks, and these can require
linking against kernel32.
This only makes a difference when linking with ld.bfd, as lld
always searches all static libraries.
This matches a similar change made recently in gcc in
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=850533ab160ef40eccfd039e1e3b138cf26e76b8,
although clang adds --start-group --end-group around these libraries
if -static is specified, which gcc doesn't. But try to match gcc's
linking order in any case, for consistency.
Differential Revision: https://reviews.llvm.org/D80880
Added:
Modified:
clang/lib/Driver/ToolChains/MinGW.cpp
clang/test/Driver/mingw-msvcrt.c
Removed:
diff --git a/clang/lib/Driver/ToolChains/MinGW.cpp
b/clang/lib/Driver/ToolChains/MinGW.cpp
index ce01c8816263..3c2ba40323d9 100644
--- a/clang/lib/Driver/ToolChains/MinGW.cpp
+++ b/clang/lib/Driver/ToolChains/MinGW.cpp
@@ -304,10 +304,13 @@ void tools::MinGW::Linker::ConstructJob(Compilation &C,
const JobAction &JA,
CmdArgs.push_back("-lkernel32");
}
- if (Args.hasArg(options::OPT_static))
+ if (Args.hasArg(options::OPT_static)) {
CmdArgs.push_back("--end-group");
- else
+ } else {
AddLibGCC(Args, CmdArgs);
+if (!HasWindowsApp)
+ CmdArgs.push_back("-lkernel32");
+ }
}
if (!Args.hasArg(options::OPT_nostartfiles)) {
diff --git a/clang/test/Driver/mingw-msvcrt.c
b/clang/test/Driver/mingw-msvcrt.c
index 89a8d2a94c28..bb4813ca33a5 100644
--- a/clang/test/Driver/mingw-msvcrt.c
+++ b/clang/test/Driver/mingw-msvcrt.c
@@ -4,6 +4,7 @@
// RUN: %clang -v -target i686-pc-windows-gnu -lucrt -### %s 2>&1 | FileCheck
-check-prefix=CHECK_UCRT %s
// CHECK_DEFAULT: "-lmingwex" "-lmsvcrt" "-ladvapi32"
+// CHECK_DEFAULT-SAME: "-lmsvcrt" "-lkernel32" "{{.*}}crtend.o"
// CHECK_MSVCR120: "-lmsvcr120"
// CHECK_MSVCR120-SAME: "-lmingwex" "-ladvapi32"
// CHECK_UCRTBASE: "-lucrtbase"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 7b3fe96 - [clang] Don't emit warn_cxx_ms_struct when MSBitfields is enabled globally
Author: Martin Storsjö
Date: 2020-06-17T09:37:07+03:00
New Revision: 7b3fe969927731c69ba4d8a428442e1e191f49b5
URL:
https://github.com/llvm/llvm-project/commit/7b3fe969927731c69ba4d8a428442e1e191f49b5
DIFF:
https://github.com/llvm/llvm-project/commit/7b3fe969927731c69ba4d8a428442e1e191f49b5.diff
LOG: [clang] Don't emit warn_cxx_ms_struct when MSBitfields is enabled globally
This diagnostic (which defaults to an error, added in
95833f33bda6c92e746e0b0007b69c2c30bfc693) was intended to clearly
point out cases where the C++ ABI won't match the Microsoft C++ ABI,
for cases when this is enabled via a pragma over a region of code.
The MSVC compatible struct layout feature can also be enabled via a
compiler option (-mms-bitfields). If enabled that way, one essentially
can't compile any C++ code unless also building with
-Wno-incompatible-ms-struct (which GCC doesn't support, and projects
developed with GCC aren't setting).
For the MinGW target, it's expected that the C++ ABI won't match
the MSVC one, if this option is used for getting the struct
layout to match MSVC.
Differential Revision: https://reviews.llvm.org/D81794
Added:
Modified:
clang/lib/Sema/SemaDeclCXX.cpp
clang/test/SemaCXX/ms_struct.cpp
Removed:
diff --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index f1ade752e2fe..a2b669c99125 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -6773,7 +6773,11 @@ void Sema::CheckCompletedCXXClass(Scope *S,
CXXRecordDecl *Record) {
// headers, sweeping up a bunch of types that the project doesn't
// really rely on MSVC-compatible layout for. We must therefore
// support "ms_struct except for C++ stuff" as a secondary ABI.
- if (Record->isMsStruct(Context) &&
+ // Don't emit this diagnostic if the feature was enabled as a
+ // language option (as opposed to via a pragma or attribute), as
+ // the option -mms-bitfields otherwise essentially makes it impossible
+ // to build C++ code, unless this diagnostic is turned off.
+ if (Record->isMsStruct(Context) && !Context.getLangOpts().MSBitfields &&
(Record->isPolymorphic() || Record->getNumBases())) {
Diag(Record->getLocation(), diag::warn_cxx_ms_struct);
}
diff --git a/clang/test/SemaCXX/ms_struct.cpp
b/clang/test/SemaCXX/ms_struct.cpp
index 414b56b491c6..122819c3eead 100644
--- a/clang/test/SemaCXX/ms_struct.cpp
+++ b/clang/test/SemaCXX/ms_struct.cpp
@@ -1,8 +1,11 @@
-// RUN: %clang_cc1 -fsyntax-only -Wno-error=incompatible-ms-struct -verify
-triple i686-apple-darwin9 -std=c++11 %s
-// RUN: %clang_cc1 -fsyntax-only -Wno-error=incompatible-ms-struct -verify
-triple armv7-apple-darwin9 -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -DTEST_FOR_WARNING
-Wno-error=incompatible-ms-struct -verify -triple i686-apple-darwin9 -std=c++11
%s
+// RUN: %clang_cc1 -fsyntax-only -DTEST_FOR_WARNING
-Wno-error=incompatible-ms-struct -verify -triple armv7-apple-darwin9
-std=c++11 %s
// RUN: %clang_cc1 -fsyntax-only -DTEST_FOR_ERROR -verify -triple
armv7-apple-darwin9 -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -DNO_PRAGMA -mms-bitfields -verify -triple
armv7-apple-darwin9 -std=c++11 %s
+#ifndef NO_PRAGMA
#pragma ms_struct on
+#endif
struct A {
unsigned long a:4;
@@ -12,7 +15,7 @@ struct A {
struct B : public A {
#ifdef TEST_FOR_ERROR
// expected-error@-2 {{ms_struct may not produce Microsoft-compatible
layouts for classes with base classes or virtual functions}}
-#else
+#elif defined(TEST_FOR_WARNING)
// expected-warning@-4 {{ms_struct may not produce Microsoft-compatible
layouts for classes with base classes or virtual functions}}
#endif
unsigned long c:16;
@@ -27,7 +30,7 @@ static_assert(__builtin_offsetof(B, d) == 12,
struct C {
#ifdef TEST_FOR_ERROR
// expected-error@-2 {{ms_struct may not produce Microsoft-compatible
layouts for classes with base classes or virtual functions}}
-#else
+#elif defined(TEST_FOR_WARNING)
// expected-warning@-4 {{ms_struct may not produce Microsoft-compatible
layouts for classes with base classes or virtual functions}}
#endif
virtual void foo();
@@ -36,3 +39,6 @@ struct C {
static_assert(__builtin_offsetof(C, n) == 8,
"long long field in ms_struct should be 8-byte aligned");
+#if !defined(TEST_FOR_ERROR) && !defined(TEST_FOR_WARNING)
+// expected-no-diagnostics
+#endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 6fb80d9 - libclang: Add static build support for Windows
Author: Cristian Adam
Date: 2020-04-25T20:19:17+03:00
New Revision: 6fb80d9383e415c35204b62569972f70ae7dcb0a
URL:
https://github.com/llvm/llvm-project/commit/6fb80d9383e415c35204b62569972f70ae7dcb0a
DIFF:
https://github.com/llvm/llvm-project/commit/6fb80d9383e415c35204b62569972f70ae7dcb0a.diff
LOG: libclang: Add static build support for Windows
Differential Revision: https://reviews.llvm.org/D75068
Added:
Modified:
clang/include/clang-c/Platform.h
clang/tools/libclang/CMakeLists.txt
Removed:
diff --git a/clang/include/clang-c/Platform.h
b/clang/include/clang-c/Platform.h
index 3bb66bb0df48..67c1fff8ff78 100644
--- a/clang/include/clang-c/Platform.h
+++ b/clang/include/clang-c/Platform.h
@@ -18,14 +18,23 @@
LLVM_CLANG_C_EXTERN_C_BEGIN
-/* MSVC DLL import/export. */
-#ifdef _MSC_VER
- #ifdef _CINDEX_LIB_
-#define CINDEX_LINKAGE __declspec(dllexport)
- #else
-#define CINDEX_LINKAGE __declspec(dllimport)
+/* Windows DLL import/export. */
+#ifndef CINDEX_NO_EXPORTS
+ #define CINDEX_EXPORTS
+#endif
+#ifdef _WIN32
+ #ifdef CINDEX_EXPORTS
+#ifdef _CINDEX_LIB_
+ #define CINDEX_LINKAGE __declspec(dllexport)
+#else
+ #define CINDEX_LINKAGE __declspec(dllimport)
+#endif
#endif
-#else
+#elif defined(CINDEX_EXPORTS) && defined(__GNUC__)
+ #define CINDEX_LINKAGE __attribute__((visibility("default")))
+#endif
+
+#ifndef CINDEX_LINKAGE
#define CINDEX_LINKAGE
#endif
diff --git a/clang/tools/libclang/CMakeLists.txt
b/clang/tools/libclang/CMakeLists.txt
index bd0c945a5e12..bb2b14cc8e27 100644
--- a/clang/tools/libclang/CMakeLists.txt
+++ b/clang/tools/libclang/CMakeLists.txt
@@ -77,14 +77,18 @@ if(MSVC)
set(LLVM_EXPORTED_SYMBOL_FILE)
endif()
-if(LLVM_ENABLE_PIC OR WIN32)
+if(LLVM_ENABLE_PIC OR NOT LIBCLANG_BUILD_STATIC)
set(ENABLE_SHARED SHARED)
endif()
-if((NOT LLVM_ENABLE_PIC OR LIBCLANG_BUILD_STATIC) AND NOT WIN32)
+if(NOT LLVM_ENABLE_PIC OR LIBCLANG_BUILD_STATIC)
set(ENABLE_STATIC STATIC)
endif()
+if (WIN32 AND ENABLE_SHARED AND ENABLE_STATIC)
+ unset(ENABLE_STATIC)
+endif()
+
if(WIN32)
set(output_name "libclang")
else()
@@ -113,6 +117,14 @@ add_clang_library(libclang ${ENABLE_SHARED}
${ENABLE_STATIC} INSTALL_WITH_TOOLCH
Support
)
+if(ENABLE_STATIC)
+ foreach(name libclang obj.libclang libclang_static)
+if (TARGET ${name})
+ target_compile_definitions(${name} PUBLIC CINDEX_NO_EXPORTS)
+endif()
+ endforeach()
+endif()
+
if(ENABLE_SHARED)
if(WIN32)
set_target_properties(libclang
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] a0e53de - [clang] [MinGW] Add the compiler rt libdirs to the search path
Author: Martin Storsjö
Date: 2020-04-29T20:35:50+03:00
New Revision: a0e53de472c5b9538884f23eb8f47c3bc734b345
URL:
https://github.com/llvm/llvm-project/commit/a0e53de472c5b9538884f23eb8f47c3bc734b345
DIFF:
https://github.com/llvm/llvm-project/commit/a0e53de472c5b9538884f23eb8f47c3bc734b345.diff
LOG: [clang] [MinGW] Add the compiler rt libdirs to the search path
This matches what is done for MSVC in
b8000c0ce84541c5b5535419234fb65ce77d6756. Since that commit, compiler
rt sanitizer libraries aren't linked to with absolute path on windows,
but using their basenames, requiring the libdirs to be passed to
the linker.
This fixes undefined behaviour sanitizer on MinGW after
b8000c0ce84541c5b5535419234fb65ce77d6756.
Differential Revision: https://reviews.llvm.org/D79076
Added:
Modified:
clang/lib/Driver/ToolChains/MinGW.cpp
Removed:
diff --git a/clang/lib/Driver/ToolChains/MinGW.cpp
b/clang/lib/Driver/ToolChains/MinGW.cpp
index 6139764e4601..ce01c8816263 100644
--- a/clang/lib/Driver/ToolChains/MinGW.cpp
+++ b/clang/lib/Driver/ToolChains/MinGW.cpp
@@ -18,6 +18,7 @@
#include "llvm/Option/ArgList.h"
#include "llvm/Support/FileSystem.h"
#include "llvm/Support/Path.h"
+#include "llvm/Support/VirtualFileSystem.h"
#include
using namespace clang::diag;
@@ -198,6 +199,17 @@ void tools::MinGW::Linker::ConstructJob(Compilation &C,
const JobAction &JA,
Args.AddAllArgs(CmdArgs, options::OPT_L);
TC.AddFilePathLibArgs(Args, CmdArgs);
+
+ // Add the compiler-rt library directories if they exist to help
+ // the linker find the various sanitizer, builtin, and profiling runtimes.
+ for (const auto &LibPath : TC.getLibraryPaths()) {
+if (TC.getVFS().exists(LibPath))
+ CmdArgs.push_back(Args.MakeArgString("-L" + LibPath));
+ }
+ auto CRTPath = TC.getCompilerRTPath();
+ if (TC.getVFS().exists(CRTPath))
+CmdArgs.push_back(Args.MakeArgString("-L" + CRTPath));
+
AddLinkerInputs(TC, Inputs, Args, CmdArgs, JA);
// TODO: Add profile stuff here
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [clang] 6170072 - Improve modeling of variable template specializations with dependent
On Sun, 9 Aug 2020, Richard Smith via cfe-commits wrote:
Author: Richard Smith
Date: 2020-08-09T23:22:26-07:00
New Revision: 617007240cbfb97c8ccf6d61b0c4ca0bb62d43c9
URL:
https://github.com/llvm/llvm-project/commit/617007240cbfb97c8ccf6d61b0c4ca0bb62d43c9
DIFF:
https://github.com/llvm/llvm-project/commit/617007240cbfb97c8ccf6d61b0c4ca0bb62d43c9.diff
LOG: Improve modeling of variable template specializations with dependent
arguments.
Don't build a variable template specialization declaration until its
scope and template arguments are non-dependent.
No functionality change intended, but the AST representation is now more
consistent with how we model other templates.
This did turn out to make a functional change, breaking building the dev
branch of Qt. A halfway reduced example below:
template
struct integral_constant
{
static constexpr const _Tp value = __v;
typedef _Tp value_type;
typedef integral_constant type;
__attribute__ ((__exclude_from_explicit_instantiation__))
constexpr operator value_type() const noexcept {return value;}
__attribute__ ((__exclude_from_explicit_instantiation__))
constexpr value_type operator ()() const noexcept {return value;}
};
template
struct is_nothrow_assignable
: public integral_constant
{};
template
inline constexpr bool is_nothrow_assignable_v
= is_nothrow_assignable<_Tp, _Arg>::value;
template
class QCache
{
struct Value {
T *t = nullptr;
};
struct Node {
Value value;
void replace(const Value &t) noexcept(is_nothrow_assignable_v) {
value = t;
}
};
};
// Martin
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [clang] 6170072 - Improve modeling of variable template specializations with dependent
On Tue, 11 Aug 2020, Richard Smith wrote:
On Tue, 11 Aug 2020 at 00:29, Martin Storsjö wrote:
On Sun, 9 Aug 2020, Richard Smith via cfe-commits wrote:
>
> Author: Richard Smith
> Date: 2020-08-09T23:22:26-07:00
> New Revision: 617007240cbfb97c8ccf6d61b0c4ca0bb62d43c9
>
>
URL:https://github.com/llvm/llvm-project/commit/617007240cbfb97c8ccf6d61b0c4ca0
bb62d43c9
>
DIFF:https://github.com/llvm/llvm-project/commit/617007240cbfb97c8ccf6d61b0c4ca0
bb62d43c9.diff
>
> LOG: Improve modeling of variable template specializations
with dependent
> arguments.
>
> Don't build a variable template specialization declaration
until its
> scope and template arguments are non-dependent.
>
> No functionality change intended, but the AST representation
is now more
> consistent with how we model other templates.
This did turn out to make a functional change, breaking building
the dev
branch of Qt. A halfway reduced example below:
Thanks for reporting this! Reduced a bit more:
template
inline constexpr bool is_nothrow_assignable_v = true;
template class QCache {
void replace() noexcept(is_nothrow_assignable_v);
};
We used to allow this and now reject. This code is ill-formed (no diagnostic
required) by [temp.res]/8, because it has no valid instantiations, because
the second template argument of is_nothrow_assignable_v is missing.
So, assuming the case from which this was reduced was similarly ill-formed
(which it looks like itis:
https://github.com/qt/qtbase/blob/48c8322a613f58d19ad9e0262bbac437ce259
8f8/src/corelib/tools/qcache.h#L114), I think that's a (minor) quality of
implementation improvement -- we now diagnose a bug that we used to miss.
ICC also rejects this, although GCC does not, and all three compilers reject
the corresponding case using a class template instead of a variable
template.
Thanks! I sent an attempt at a fix upstream at
https://codereview.qt-project.org/c/qt/qtbase/+/309878.
// Martin
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 609ef94 - [CMake] Fix building with -DBUILD_SHARED_LIBS=ON on mingw
Author: Martin Storsjö
Date: 2020-05-11T23:51:14+03:00
New Revision: 609ef948387ba40e3693c2bd693d82ca34dcdc02
URL:
https://github.com/llvm/llvm-project/commit/609ef948387ba40e3693c2bd693d82ca34dcdc02
DIFF:
https://github.com/llvm/llvm-project/commit/609ef948387ba40e3693c2bd693d82ca34dcdc02.diff
LOG: [CMake] Fix building with -DBUILD_SHARED_LIBS=ON on mingw
Set the right target name in clang/examples/Attribute.
Add a missing dependency in the TableGen GlobalISel sublibrary.
Skip building the Bye pass plugin example on windows; plugins
that should have undefined symbols that are found in the host
process aren't supported on windows - this matches what was done
for a unit test in bc8e44218810c0db6328b9809c959ceb7d43e3f5.
Added:
Modified:
clang/examples/Attribute/CMakeLists.txt
llvm/examples/Bye/CMakeLists.txt
llvm/utils/TableGen/GlobalISel/CMakeLists.txt
Removed:
diff --git a/clang/examples/Attribute/CMakeLists.txt
b/clang/examples/Attribute/CMakeLists.txt
index 19323bb0962b..ed02f5e5992f 100644
--- a/clang/examples/Attribute/CMakeLists.txt
+++ b/clang/examples/Attribute/CMakeLists.txt
@@ -1,7 +1,7 @@
add_llvm_library(Attribute MODULE Attribute.cpp PLUGIN_TOOL clang)
if(LLVM_ENABLE_PLUGINS AND (WIN32 OR CYGWIN))
- target_link_libraries(AnnotateFunctions ${cmake_2_8_12_PRIVATE}
+ target_link_libraries(Attribute ${cmake_2_8_12_PRIVATE}
clangAST
clangBasic
clangFrontend
diff --git a/llvm/examples/Bye/CMakeLists.txt
b/llvm/examples/Bye/CMakeLists.txt
index 3206f90d0916..362086eb1b32 100644
--- a/llvm/examples/Bye/CMakeLists.txt
+++ b/llvm/examples/Bye/CMakeLists.txt
@@ -2,12 +2,18 @@ if(LLVM_BYE_LINK_INTO_TOOLS)
message(WARNING "Setting LLVM_BYE_LINK_INTO_TOOLS=ON only makes sense for
testing purpose")
endif()
-add_llvm_pass_plugin(Bye
- Bye.cpp
- DEPENDS
- intrinsics_gen
- BUILDTREE_ONLY
- )
+# The plugin expects to not link against the Support and Core libraries,
+# but expects them to exist in the process loading the plugin. This doesn't
+# work with DLLs on Windows (where a shared library can't have undefined
+# references), so just skip this testcase on Windows.
+if (NOT WIN32)
+ add_llvm_pass_plugin(Bye
+Bye.cpp
+DEPENDS
+intrinsics_gen
+BUILDTREE_ONLY
+ )
-install(TARGETS ${name} RUNTIME DESTINATION examples)
-set_target_properties(${name} PROPERTIES FOLDER "Examples")
+ install(TARGETS ${name} RUNTIME DESTINATION examples)
+ set_target_properties(${name} PROPERTIES FOLDER "Examples")
+endif()
diff --git a/llvm/utils/TableGen/GlobalISel/CMakeLists.txt
b/llvm/utils/TableGen/GlobalISel/CMakeLists.txt
index 292a1bd639fb..25fff72d3dcf 100644
--- a/llvm/utils/TableGen/GlobalISel/CMakeLists.txt
+++ b/llvm/utils/TableGen/GlobalISel/CMakeLists.txt
@@ -1,5 +1,6 @@
set(LLVM_LINK_COMPONENTS
Support
+ TableGen
)
llvm_add_library(LLVMTableGenGlobalISel STATIC DISABLE_LLVM_LINK_LLVM_DYLIB
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D24609: [ARM] Add missing Interlocked intrinsics
mstorsjo added inline comments.
Comment at: lib/Headers/intrin.h:504
@@ +503,3 @@
+_interlockedbittestandset_acq(long volatile *_BitBase, long _BitPos) {
+ long _PrevVal = __atomic_fetch_or(_BitBase, 1l << _BitPos, __ATOMIC_ACQUIRE);
+ return (_PrevVal >> _BitPos) & 1;
compnerd wrote:
> mstorsjo wrote:
> > compnerd wrote:
> > > Perhaps we should add static asserts that _BitPos is within limits for
> > > the signed shift.
> > Sure, although I guess that also goes for the existing inline functions as
> > well?
> >
> > Which kind of assert would be suitable for that here? As far as I see,
> > static_assert is C++ only, while this header also can be used from C.
> >
> > If I try to add _Static_assert, which is usable in C, I get the following
> > error when compiling:
> >
> > intrin.h:499:18: error:
> > static_assert expression is not an integral constant expression
> > _Static_assert(_BitPos < 32, "_BitPos out of range");
> >
> > This even when I don't actually use the inline function anywhere, just
> > including intrin.h.
> Yeah, we would have to use `_Static_assert`, but that requires C11. It is
> possible to emulate it, but probably not worth the effort. I am worried
> though that we could introduce undefined behavior with an incorrect parameter.
Sure, there's probably such a risk. But this issue already exists - an almost
identical _interlockedbittestandset function already exists in the header - I'm
just adding new copies of it with different atomic semantics (__ATOMIC_ACQUIRE
etc).
So I'd ask if we can deal with that issue separately from this patch.
https://reviews.llvm.org/D24609
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D24609: [ARM] Add missing Interlocked intrinsics
mstorsjo added a comment. Thanks! Can you/someone commit it? https://reviews.llvm.org/D24609 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D24609: [ARM] Add missing Interlocked intrinsics
mstorsjo updated the summary for this revision.
mstorsjo updated this revision to Diff 72025.
mstorsjo added a comment.
Rebased on top of the latest master
https://reviews.llvm.org/D24609
Files:
lib/Headers/intrin.h
Index: lib/Headers/intrin.h
===
--- lib/Headers/intrin.h
+++ lib/Headers/intrin.h
@@ -490,6 +490,23 @@
long _PrevVal = __atomic_fetch_or(_BitBase, 1l << _BitPos, __ATOMIC_SEQ_CST);
return (_PrevVal >> _BitPos) & 1;
}
+#if defined(__arm__) || defined(__aarch64__)
+static __inline__ unsigned char __DEFAULT_FN_ATTRS
+_interlockedbittestandset_acq(long volatile *_BitBase, long _BitPos) {
+ long _PrevVal = __atomic_fetch_or(_BitBase, 1l << _BitPos, __ATOMIC_ACQUIRE);
+ return (_PrevVal >> _BitPos) & 1;
+}
+static __inline__ unsigned char __DEFAULT_FN_ATTRS
+_interlockedbittestandset_nf(long volatile *_BitBase, long _BitPos) {
+ long _PrevVal = __atomic_fetch_or(_BitBase, 1l << _BitPos, __ATOMIC_RELAXED);
+ return (_PrevVal >> _BitPos) & 1;
+}
+static __inline__ unsigned char __DEFAULT_FN_ATTRS
+_interlockedbittestandset_rel(long volatile *_BitBase, long _BitPos) {
+ long _PrevVal = __atomic_fetch_or(_BitBase, 1l << _BitPos, __ATOMIC_RELEASE);
+ return (_PrevVal >> _BitPos) & 1;
+}
+#endif
#ifdef __x86_64__
static __inline__ unsigned char __DEFAULT_FN_ATTRS
_BitScanForward64(unsigned long *_Index, unsigned __int64 _Mask) {
@@ -533,64 +550,521 @@
__atomic_fetch_or(_BitBase, 1ll << _BitPos, __ATOMIC_SEQ_CST);
return (_PrevVal >> _BitPos) & 1;
}
+#endif
/**\
|* Interlocked Exchange Add
\**/
+#if defined(__arm__) || defined(__aarch64__)
+static __inline__ char __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd8_acq(char volatile *_Addend, char _Value) {
+ return __atomic_fetch_add(_Addend, _Value, __ATOMIC_ACQUIRE);
+}
+static __inline__ char __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd8_nf(char volatile *_Addend, char _Value) {
+ return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELAXED);
+}
+static __inline__ char __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd8_rel(char volatile *_Addend, char _Value) {
+ return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELAXED);
+}
+static __inline__ short __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd16_acq(short volatile *_Addend, short _Value) {
+ return __atomic_fetch_add(_Addend, _Value, __ATOMIC_ACQUIRE);
+}
+static __inline__ short __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd16_nf(short volatile *_Addend, short _Value) {
+ return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELAXED);
+}
+static __inline__ short __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd16_rel(short volatile *_Addend, short _Value) {
+ return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELEASE);
+}
+static __inline__ long __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd_acq(long volatile *_Addend, long _Value) {
+ return __atomic_fetch_add(_Addend, _Value, __ATOMIC_ACQUIRE);
+}
+static __inline__ long __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd_nf(long volatile *_Addend, long _Value) {
+ return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELAXED);
+}
+static __inline__ long __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd_rel(long volatile *_Addend, long _Value) {
+ return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELEASE);
+}
+#endif
+#if defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)
static __inline__ __int64 __DEFAULT_FN_ATTRS
_InterlockedExchangeAdd64(__int64 volatile *_Addend, __int64 _Value) {
return __atomic_fetch_add(_Addend, _Value, __ATOMIC_SEQ_CST);
}
+#endif
+#if defined(__arm__) || defined(__aarch64__)
+static __inline__ __int64 __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd64_acq(__int64 volatile *_Addend, __int64 _Value) {
+ return __atomic_fetch_add(_Addend, _Value, __ATOMIC_ACQUIRE);
+}
+static __inline__ __int64 __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd64_nf(__int64 volatile *_Addend, __int64 _Value) {
+ return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELAXED);
+}
+static __inline__ __int64 __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd64_rel(__int64 volatile *_Addend, __int64 _Value) {
+ return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELEASE);
+}
+#endif
/**\
|* Interlocked Exchange Sub
\**/
+#if defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)
static __inline__ __int64 __DEFAULT_FN_ATTRS
_InterlockedExchangeSub64(__int64 volatile *_Subend, __int64 _Value) {
return __atomic_fetch_sub(_Subend, _Value, __ATOMIC_SEQ_CST);
}
+#endif
/**\
|* Interlocked Increment
\**/
+#if defined(__ar
Re: [PATCH] D24609: [ARM] Add missing Interlocked intrinsics
mstorsjo added a comment. Can someone commit this patch now after it has been rebased? https://reviews.llvm.org/D24609 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D24609: [ARM] Add missing Interlocked intrinsics
mstorsjo added a comment. Ping, can someone commit this one now? https://reviews.llvm.org/D24609 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D24986: Headers: Add iso_volatile load/store intrinsics
mstorsjo created this revision.
mstorsjo added a reviewer: majnemer.
mstorsjo added a subscriber: cfe-commits.
Herald added a subscriber: aemerson.
This implements what is missing for PR30394, making it possible to compile C++
for ARM in MSVC mode with MSVC headers.
https://reviews.llvm.org/D24986
Files:
lib/Headers/intrin.h
Index: lib/Headers/intrin.h
===
--- lib/Headers/intrin.h
+++ lib/Headers/intrin.h
@@ -1248,6 +1248,42 @@
}
#endif
+#if defined(__arm__) || defined(__aarch64__)
+static __inline__ char __DEFAULT_FN_ATTRS
+__iso_volatile_load8(const char volatile *_Src) {
+ return *_Src;
+}
+static __inline__ short __DEFAULT_FN_ATTRS
+__iso_volatile_load16(const short volatile *_Src) {
+ return *_Src;
+}
+static __inline__ int __DEFAULT_FN_ATTRS
+__iso_volatile_load32(const int volatile *_Src) {
+ return *_Src;
+}
+static __inline__ __int64 __DEFAULT_FN_ATTRS
+__iso_volatile_load64(const __int64 volatile *_Src) {
+ return *_Src;
+}
+
+static __inline__ void __DEFAULT_FN_ATTRS
+__iso_volatile_store8(char volatile *_Dest, char _Value) {
+ *_Dest = _Value;
+}
+static __inline__ void __DEFAULT_FN_ATTRS
+__iso_volatile_store16(short volatile *_Dest, short _Value) {
+ *_Dest = _Value;
+}
+static __inline__ void __DEFAULT_FN_ATTRS
+__iso_volatile_store32(int volatile *_Dest, int _Value) {
+ *_Dest = _Value;
+}
+static __inline__ void __DEFAULT_FN_ATTRS
+__iso_volatile_store64(__int64 volatile *_Dest, __int64 _Value) {
+ *_Dest = _Value;
+}
+#endif
+
#ifdef __cplusplus
}
#endif
Index: lib/Headers/intrin.h
===
--- lib/Headers/intrin.h
+++ lib/Headers/intrin.h
@@ -1248,6 +1248,42 @@
}
#endif
+#if defined(__arm__) || defined(__aarch64__)
+static __inline__ char __DEFAULT_FN_ATTRS
+__iso_volatile_load8(const char volatile *_Src) {
+ return *_Src;
+}
+static __inline__ short __DEFAULT_FN_ATTRS
+__iso_volatile_load16(const short volatile *_Src) {
+ return *_Src;
+}
+static __inline__ int __DEFAULT_FN_ATTRS
+__iso_volatile_load32(const int volatile *_Src) {
+ return *_Src;
+}
+static __inline__ __int64 __DEFAULT_FN_ATTRS
+__iso_volatile_load64(const __int64 volatile *_Src) {
+ return *_Src;
+}
+
+static __inline__ void __DEFAULT_FN_ATTRS
+__iso_volatile_store8(char volatile *_Dest, char _Value) {
+ *_Dest = _Value;
+}
+static __inline__ void __DEFAULT_FN_ATTRS
+__iso_volatile_store16(short volatile *_Dest, short _Value) {
+ *_Dest = _Value;
+}
+static __inline__ void __DEFAULT_FN_ATTRS
+__iso_volatile_store32(int volatile *_Dest, int _Value) {
+ *_Dest = _Value;
+}
+static __inline__ void __DEFAULT_FN_ATTRS
+__iso_volatile_store64(__int64 volatile *_Dest, __int64 _Value) {
+ *_Dest = _Value;
+}
+#endif
+
#ifdef __cplusplus
}
#endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D24986: [MS] Implement __iso_volatile loads/stores as builtins
mstorsjo retitled this revision from "Headers: Add iso_volatile load/store
intrinsics" to "[MS] Implement __iso_volatile loads/stores as builtins".
mstorsjo updated the summary for this revision.
mstorsjo updated this revision to Diff 72782.
mstorsjo added a comment.
Changed to implement it as builtins, as requested. I had to put this at the
bottom in EmitBuiltinExpr (which returns RValues) instead of in
EmitARMBuiltinExpr (which returns Value*), since the returned Value* for stores
is nullptr. A nullptr return value from EmitTargetBuiltinExpr indicates that it
wasn't handled, this triggered errors about the store builtins being
unsupported.
https://reviews.llvm.org/D24986
Files:
include/clang/Basic/BuiltinsARM.def
lib/CodeGen/CGBuiltin.cpp
test/CodeGen/ms-volatile-arm.c
Index: test/CodeGen/ms-volatile-arm.c
===
--- /dev/null
+++ test/CodeGen/ms-volatile-arm.c
@@ -0,0 +1,13 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -triple thumbv7-win32 -emit-llvm -fms-extensions -fms-volatile -o - < %s | FileCheck %s
+
+void test1(int volatile *p, int v) {
+ __iso_volatile_store32(p, v);
+ // CHECK-LABEL: @test1
+ // CHECK: store volatile {{.*}}, {{.*}}
+}
+int test2(const int volatile *p) {
+ return __iso_volatile_load32(p);
+ // CHECK-LABEL: @test2
+ // CHECK: load volatile {{.*}}
+}
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -134,6 +134,36 @@
return CGF.EmitLoadOfScalar(LV, E->getExprLoc());
}
+static Value *EmitVolatileStore(CodeGenFunction &CGF, const CallExpr *E) {
+ Value *Address = CGF.EmitScalarExpr(E->getArg(0));
+ Value *Val = CGF.EmitScalarExpr(E->getArg(1));
+
+ LValue LV = CGF.MakeNaturalAlignAddrLValue(Address, E->getArg(1)->getType());
+ // Call the full version of EmitStoreOfScalar directly, to override the volatile
+ // flag without actually setting volatile in the type. This avoids
+ // LValueIsSuitableForInlineAtomic picking it up and transforming it into an
+ // atomic store.
+ CGF.EmitStoreOfScalar(Val, LV.getAddress(), true, LV.getType(),
+LV.getAlignmentSource(), LV.getTBAAInfo(), false,
+LV.getTBAABaseType(), LV.getTBAAOffset(),
+LV.isNontemporal());
+ return nullptr;
+}
+
+static Value *EmitVolatileLoad(CodeGenFunction &CGF, const CallExpr *E) {
+ Value *Address = CGF.EmitScalarExpr(E->getArg(0));
+
+ LValue LV = CGF.MakeNaturalAlignAddrLValue(Address, E->getType());
+ // Call the full version of EmitLoadOfScalar directly, to override the volatile
+ // flag without actually setting volatile in the type. This avoids
+ // LValueIsSuitableForInlineAtomic picking it up and transforming it into an
+ // atomic load.
+ return CGF.EmitLoadOfScalar(LV.getAddress(), true, LV.getType(),
+ E->getExprLoc(), LV.getAlignmentSource(),
+ LV.getTBAAInfo(), LV.getTBAABaseType(),
+ LV.getTBAAOffset(), LV.isNontemporal());
+}
+
static RValue EmitBinaryAtomic(CodeGenFunction &CGF,
llvm::AtomicRMWInst::BinOp Kind,
const CallExpr *E) {
@@ -2558,6 +2588,33 @@
return RValue::get(V);
}
+ switch (getTarget().getTriple().getArch()) {
+ case llvm::Triple::arm:
+ case llvm::Triple::armeb:
+ case llvm::Triple::thumb:
+ case llvm::Triple::thumbeb:
+switch (BuiltinID) {
+case ARM::BI__iso_volatile_load8:
+case ARM::BI__iso_volatile_load16:
+case ARM::BI__iso_volatile_load32:
+case ARM::BI__iso_volatile_load64:
+ return RValue::get(EmitVolatileLoad(*this, E));
+case ARM::BI__iso_volatile_store8:
+case ARM::BI__iso_volatile_store16:
+case ARM::BI__iso_volatile_store32:
+case ARM::BI__iso_volatile_store64:
+ // EmitVolatileStore returns nullptr, but we want to
+ // return that RValue here. If handled via EmitTargetBuiltinExpr
+ // below, the returned Value *V will be nullptr, and we will
+ // continue on to declaring the builtin unsupported below, even
+ // though it was handled correctly.
+ return RValue::get(EmitVolatileStore(*this, E));
+}
+break;
+ default:
+break;
+ }
+
// See if we have a target specific builtin that needs to be lowered.
if (Value *V = EmitTargetBuiltinExpr(BuiltinID, E))
return RValue::get(V);
Index: include/clang/Basic/BuiltinsARM.def
===
--- include/clang/Basic/BuiltinsARM.def
+++ include/clang/Basic/BuiltinsARM.def
@@ -115,6 +115,14 @@
LANGBUILTIN(__dmb, "vUi", "nc", ALL_MS_LANGUAGES)
LANGBUILTIN(__dsb, "vUi", "nc", ALL_MS_LANGUAGES)
LANGBUILTIN(__isb, "vUi", "nc", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_load8, "ccCD*", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__
[PATCH] [Updated, 56 lines] D24986: [MS] Implement __iso_volatile loads/stores as builtins
mstorsjo updated this revision to Diff 72988.
mstorsjo added a comment.
Implemented using `CreateAlignedStore` and `CreateAlignedLoad` instead.
I'm less confident in what this actually does though - e.g. is the
`CreateBitCast` part necessary at all? I just based this on code I found in the
same file calling `CreateAlignedStore`. (If I comment out the `CreateBitCast`
line, it still works just as fine, at least for the unit test - but what about
actual use?)
Compared to the previous patch, the generated IR now lacks a `!tbaa !3` marker
at the end - is that an issue?
https://reviews.llvm.org/D24986
Files:
include/clang/Basic/BuiltinsARM.def
lib/CodeGen/CGBuiltin.cpp
test/CodeGen/ms-volatile-arm.c
Index: test/CodeGen/ms-volatile-arm.c
===
--- /dev/null
+++ test/CodeGen/ms-volatile-arm.c
@@ -0,0 +1,13 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -triple thumbv7-win32 -emit-llvm -fms-extensions
-fms-volatile -o - < %s | FileCheck %s
+
+void test1(int volatile *p, int v) {
+ __iso_volatile_store32(p, v);
+ // CHECK-LABEL: @test1
+ // CHECK: store volatile {{.*}}, {{.*}}
+}
+int test2(const int volatile *p) {
+ return __iso_volatile_load32(p);
+ // CHECK-LABEL: @test2
+ // CHECK: load volatile {{.*}}
+}
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -4279,6 +4279,41 @@
return Builder.CreateCall(F, {StoreVal, StoreAddr}, "strex");
}
+ switch (BuiltinID) {
+ case ARM::BI__iso_volatile_load8:
+ case ARM::BI__iso_volatile_load16:
+ case ARM::BI__iso_volatile_load32:
+ case ARM::BI__iso_volatile_load64: {
+Value *Ptr = EmitScalarExpr(E->getArg(0));
+QualType ElTy = E->getArg(0)->getType()->getPointeeType();
+CharUnits LoadSize = getContext().getTypeSizeInChars(ElTy);
+llvm::Type *ITy = llvm::IntegerType::get(getLLVMContext(),
+ LoadSize.getQuantity() * 8);
+Ptr = Builder.CreateBitCast(Ptr, ITy->getPointerTo());
+llvm::LoadInst *Load =
+ Builder.CreateAlignedLoad(Ptr, LoadSize);
+Load->setVolatile(true);
+return Load;
+ }
+ case ARM::BI__iso_volatile_store8:
+ case ARM::BI__iso_volatile_store16:
+ case ARM::BI__iso_volatile_store32:
+ case ARM::BI__iso_volatile_store64: {
+Value *Ptr = EmitScalarExpr(E->getArg(0));
+Value *Value = EmitScalarExpr(E->getArg(1));
+QualType ElTy = E->getArg(0)->getType()->getPointeeType();
+CharUnits StoreSize = getContext().getTypeSizeInChars(ElTy);
+llvm::Type *ITy = llvm::IntegerType::get(getLLVMContext(),
+ StoreSize.getQuantity() * 8);
+Ptr = Builder.CreateBitCast(Ptr, ITy->getPointerTo());
+llvm::StoreInst *Store =
+ Builder.CreateAlignedStore(Value, Ptr,
+ StoreSize);
+Store->setVolatile(true);
+return Store;
+ }
+ }
+
if (BuiltinID == ARM::BI__builtin_arm_clrex) {
Function *F = CGM.getIntrinsic(Intrinsic::arm_clrex);
return Builder.CreateCall(F);
Index: include/clang/Basic/BuiltinsARM.def
===
--- include/clang/Basic/BuiltinsARM.def
+++ include/clang/Basic/BuiltinsARM.def
@@ -115,6 +115,14 @@
LANGBUILTIN(__dmb, "vUi", "nc", ALL_MS_LANGUAGES)
LANGBUILTIN(__dsb, "vUi", "nc", ALL_MS_LANGUAGES)
LANGBUILTIN(__isb, "vUi", "nc", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_load8, "ccCD*", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_load16, "ssCD*", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_load32, "iiCD*", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_load64, "LLiLLiCD*", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_store8, "vcD*c", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_store16, "vsD*s", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_store32, "viD*i", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_store64, "vLLiD*LLi", "n", ALL_MS_LANGUAGES)
LANGBUILTIN(__ldrexd, "WiWiCD*", "", ALL_MS_LANGUAGES)
LANGBUILTIN(_MoveFromCoprocessor, "UiIUiIUiIUiIUiIUi", "", ALL_MS_LANGUAGES)
LANGBUILTIN(_MoveFromCoprocessor2, "UiIUiIUiIUiIUiIUi", "", ALL_MS_LANGUAGES)
Index: test/CodeGen/ms-volatile-arm.c
===
--- /dev/null
+++ test/CodeGen/ms-volatile-arm.c
@@ -0,0 +1,13 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -triple thumbv7-win32 -emit-llvm -fms-extensions -fms-volatile -o - < %s | FileCheck %s
+
+void test1(int volatile *p, int v) {
+ __iso_volatile_store32(p, v);
+ // CHECK-LABEL: @test1
+ // CHECK: store volatile {{.*}}, {{.*}}
+}
+int test2(const int volatile *p) {
+ return __iso_volatile_load32(p);
+ // CHECK-LABEL: @test2
+ // CHECK: load volatile {{.*}}
+}
Index: lib/CodeGen/CGBuiltin.cpp
=
[PATCH] D24986: [MS] Implement __iso_volatile loads/stores as builtins
mstorsjo added inline comments. > majnemer wrote in ms-volatile-arm.c:2 > You don't need -fms-volatile. Well, originally, the point was to clarify that these volatile stores end up without atomic semantics, regardless of whether -volatile:ms has been specified. The original version of this patch (with an inline implementation in intrin.h, just using a normal volatile pointer) wouldn't pass this test, but would pass if I remove this option. But if you prefer, I can leave it out. https://reviews.llvm.org/D24986 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D24986: [MS] Implement __iso_volatile loads/stores as builtins
This revision was automatically updated to reflect the committed changes.
Closed by commit rL282900: [MS] Implement __iso_volatile loads/stores as
builtins (authored by mstorsjo).
Changed prior to commit:
https://reviews.llvm.org/D24986?vs=72988&id=73113#toc
Repository:
rL LLVM
https://reviews.llvm.org/D24986
Files:
cfe/trunk/include/clang/Basic/BuiltinsARM.def
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/ms-volatile-arm.c
Index: cfe/trunk/include/clang/Basic/BuiltinsARM.def
===
--- cfe/trunk/include/clang/Basic/BuiltinsARM.def
+++ cfe/trunk/include/clang/Basic/BuiltinsARM.def
@@ -115,6 +115,14 @@
LANGBUILTIN(__dmb, "vUi", "nc", ALL_MS_LANGUAGES)
LANGBUILTIN(__dsb, "vUi", "nc", ALL_MS_LANGUAGES)
LANGBUILTIN(__isb, "vUi", "nc", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_load8, "ccCD*", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_load16, "ssCD*", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_load32, "iiCD*", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_load64, "LLiLLiCD*", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_store8, "vcD*c", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_store16, "vsD*s", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_store32, "viD*i", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_store64, "vLLiD*LLi", "n", ALL_MS_LANGUAGES)
LANGBUILTIN(__ldrexd, "WiWiCD*", "", ALL_MS_LANGUAGES)
LANGBUILTIN(_MoveFromCoprocessor, "UiIUiIUiIUiIUiIUi", "", ALL_MS_LANGUAGES)
LANGBUILTIN(_MoveFromCoprocessor2, "UiIUiIUiIUiIUiIUi", "", ALL_MS_LANGUAGES)
Index: cfe/trunk/test/CodeGen/ms-volatile-arm.c
===
--- cfe/trunk/test/CodeGen/ms-volatile-arm.c
+++ cfe/trunk/test/CodeGen/ms-volatile-arm.c
@@ -0,0 +1,13 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang_cc1 -triple thumbv7-win32 -emit-llvm -fms-extensions
-fms-volatile -o - < %s | FileCheck %s
+
+void test1(int volatile *p, int v) {
+ __iso_volatile_store32(p, v);
+ // CHECK-LABEL: @test1
+ // CHECK: store volatile {{.*}}, {{.*}}
+}
+int test2(const int volatile *p) {
+ return __iso_volatile_load32(p);
+ // CHECK-LABEL: @test2
+ // CHECK: load volatile {{.*}}
+}
Index: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
===
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp
@@ -4279,6 +4279,41 @@
return Builder.CreateCall(F, {StoreVal, StoreAddr}, "strex");
}
+ switch (BuiltinID) {
+ case ARM::BI__iso_volatile_load8:
+ case ARM::BI__iso_volatile_load16:
+ case ARM::BI__iso_volatile_load32:
+ case ARM::BI__iso_volatile_load64: {
+Value *Ptr = EmitScalarExpr(E->getArg(0));
+QualType ElTy = E->getArg(0)->getType()->getPointeeType();
+CharUnits LoadSize = getContext().getTypeSizeInChars(ElTy);
+llvm::Type *ITy = llvm::IntegerType::get(getLLVMContext(),
+ LoadSize.getQuantity() * 8);
+Ptr = Builder.CreateBitCast(Ptr, ITy->getPointerTo());
+llvm::LoadInst *Load =
+ Builder.CreateAlignedLoad(Ptr, LoadSize);
+Load->setVolatile(true);
+return Load;
+ }
+ case ARM::BI__iso_volatile_store8:
+ case ARM::BI__iso_volatile_store16:
+ case ARM::BI__iso_volatile_store32:
+ case ARM::BI__iso_volatile_store64: {
+Value *Ptr = EmitScalarExpr(E->getArg(0));
+Value *Value = EmitScalarExpr(E->getArg(1));
+QualType ElTy = E->getArg(0)->getType()->getPointeeType();
+CharUnits StoreSize = getContext().getTypeSizeInChars(ElTy);
+llvm::Type *ITy = llvm::IntegerType::get(getLLVMContext(),
+ StoreSize.getQuantity() * 8);
+Ptr = Builder.CreateBitCast(Ptr, ITy->getPointerTo());
+llvm::StoreInst *Store =
+ Builder.CreateAlignedStore(Value, Ptr,
+ StoreSize);
+Store->setVolatile(true);
+return Store;
+ }
+ }
+
if (BuiltinID == ARM::BI__builtin_arm_clrex) {
Function *F = CGM.getIntrinsic(Intrinsic::arm_clrex);
return Builder.CreateCall(F);
Index: cfe/trunk/include/clang/Basic/BuiltinsARM.def
===
--- cfe/trunk/include/clang/Basic/BuiltinsARM.def
+++ cfe/trunk/include/clang/Basic/BuiltinsARM.def
@@ -115,6 +115,14 @@
LANGBUILTIN(__dmb, "vUi", "nc", ALL_MS_LANGUAGES)
LANGBUILTIN(__dsb, "vUi", "nc", ALL_MS_LANGUAGES)
LANGBUILTIN(__isb, "vUi", "nc", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_load8, "ccCD*", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_load16, "ssCD*", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_load32, "iiCD*", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_load64, "LLiLLiCD*", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_store8, "vcD*c", "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(__iso_volatile_store16, "vsD*s", "n",
[PATCH] D25576: Add 64-bit MS _Interlocked functions as builtins again
mstorsjo added a comment. > (should they be also on AArch64? I had problems with testing it for AArch64, > so I left it) Technically, I think they should be on AArch64 as well. But clang/LLVM probably doesn't support AArch64/Windows yet (I guess?), so testing it probably is impossible. When/if support later gets added for that, it's easy to complete these. AArch64/Windows in general isn't available yet; the Windows 10 SDK contains some arm64 tools, and the Windows 10 SDK and MSVC 2015 headers have got ifdefs using _M_ARM64, but other than that, there's no public version of Visual Studio even having a compiler for it. So until then, and when someone tries to get clang/LLVM to support it, it's probably ok to just ignore it. https://reviews.llvm.org/D25576 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r319297 - Toolchain: Normalize dwarf, sjlj and seh eh
On Wed, 29 Nov 2017, Martell Malone via cfe-commits wrote: Thanks for letting me know Reid. I’ll in work and won’t be able to access the repo until lunch time. (~3 hours) Feel free to revert if it is not trivial. The easy fix might be to change to == x86_64 from != x86 For is Windows in the default toolchain. That should restore the old behavior. My suggestion would be to just return None for all architectures for the default windows (msvc) case. We didn't use to set any defines to indicate EH mode there before anyway, so setting it to None should make things behave just as before, right? // Martin___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r319297 - Toolchain: Normalize dwarf, sjlj and seh eh
On Wed, 29 Nov 2017, Reid Kleckner wrote: On Wed, Nov 29, 2017 at 12:21 PM, Martin Storsjö wrote: On Wed, 29 Nov 2017, Martell Malone via cfe-commits wrote: Thanks for letting me know Reid. I’ll in work and won’t be able to access the repo until lunch time. (~3 hours) Feel free to revert if it is not trivial. The easy fix might be to change to == x86_64 from != x86 For is Windows in the default toolchain. That should restore the old behavior. My suggestion would be to just return None for all architectures for the default windows (msvc) case. We didn't use to set any defines to indicate EH mode there before anyway, so setting it to None should make things behave just as before, right? I did this slightly differently in r319363, but maybe that's silly. My reasoning was that `clang -cc1 -fseh-exceptions -fexceptions` in the MSVC environment should still use __CxxFrameHandler3. -fseh-exceptions indicates what format of unwind information we should use, and we're still using the normal SEH .xdata opcodes. No, I think this change makes sense - I was just about to write a comment pointing out this spot in the code but was waiting for a compile to finish before posting. Alternatively, you could view -fseh-exceptions, -fdwarf-exceptions, and -fsjlj-exceptions as choices of EH personality function, No, I don't think that'd make sense in which case, my change is wrong, and we should do what you guys were suggesting and stop passing this from the driver. Hard to say. My point was that for the MSVC mode, this worked fine before since this was the default behaviour - avoiding passing any option (i.e. having that function return None) should be a safe way to keep things working as it did before. But then it would break again if -fseh-exceptions were passed, which I would expect to be a no-op in such a configuration. My remaining concern is mostly about why we still need the workaround for x86 in the function getting the default (returning None instead of WinEH for that case). But as long as this works and the rest of this change can settle, we can look at that later if any further change is warranted at all. // Martin___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r319297 - Toolchain: Normalize dwarf, sjlj and seh eh
On Wed, 29 Nov 2017, Martin Storsjö via cfe-commits wrote: On Wed, 29 Nov 2017, Reid Kleckner wrote: On Wed, Nov 29, 2017 at 12:21 PM, Martin Storsjö wrote: On Wed, 29 Nov 2017, Martell Malone via cfe-commits wrote: Thanks for letting me know Reid. I’ll in work and won’t be able to access the repo until lunch time. (~3 hours) Feel free to revert if it is not trivial. The easy fix might be to change to == x86_64 from != x86 For is Windows in the default toolchain. That should restore the old behavior. My suggestion would be to just return None for all architectures for the default windows (msvc) case. We didn't use to set any defines to indicate EH mode there before anyway, so setting it to None should make things behave just as before, right? I did this slightly differently in r319363, but maybe that's silly. My reasoning was that `clang -cc1 -fseh-exceptions -fexceptions` in the MSVC environment should still use __CxxFrameHandler3. -fseh-exceptions indicates what format of unwind information we should use, and we're still using the normal SEH .xdata opcodes. No, I think this change makes sense - I was just about to write a comment pointing out this spot in the code but was waiting for a compile to finish before posting. Alternatively, you could view -fseh-exceptions, -fdwarf-exceptions, and -fsjlj-exceptions as choices of EH personality function, No, I don't think that'd make sense FWIW, another reason I don't think that makes sense, is that making a GNU_CPlusPlus_SEH + MSVC combination probably would require quite a bit more changes as well. When I tested the same in a build with assertions enabled, I didn't get the references to _Unwind_Resume as you did, but the compilation failed on some internal assertion. So making GNU_CPlusPlus_SEH usable with the microsoft C++ ABI would probably require a significant amount of more work, for very little value. // Martin___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 00d648b - [clang] Make guard(nocf) attribute available only for Windows
Author: Alvin Wong
Date: 2022-08-29T11:30:44+03:00
New Revision: 00d648bdb5a8b71785269b4851b651c883de2cd9
URL:
https://github.com/llvm/llvm-project/commit/00d648bdb5a8b71785269b4851b651c883de2cd9
DIFF:
https://github.com/llvm/llvm-project/commit/00d648bdb5a8b71785269b4851b651c883de2cd9.diff
LOG: [clang] Make guard(nocf) attribute available only for Windows
Control Flow Guard is only supported on Windows target, therefore there
is no point to make it an accepted attribute for other targets.
Reviewed By: rnk, aaron.ballman
Differential Revision: https://reviews.llvm.org/D132661
Added:
Modified:
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/Attr.td
clang/test/Sema/attr-guard_nocf.c
Removed:
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index b19a81e848387..cdcb6007ab836 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -146,7 +146,8 @@ Attribute Changes in Clang
``[[clang::guard(nocf)]]``, which is equivalent to
``__declspec(guard(nocf))``
when using the MSVC environment. This is to support enabling Windows Control
Flow Guard checks with the ability to disable them for specific functions
when
- using the MinGW environment.
+ using the MinGW environment. This attribute is only available for Windows
+ targets.
Windows Support
---
diff --git a/clang/include/clang/Basic/Attr.td
b/clang/include/clang/Basic/Attr.td
index f962f84f3b7a7..3b0e3e2971803 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -399,6 +399,9 @@ def TargetRISCV : TargetArch<["riscv32", "riscv64"]>;
def TargetX86 : TargetArch<["x86"]>;
def TargetAnyX86 : TargetArch<["x86", "x86_64"]>;
def TargetWebAssembly : TargetArch<["wasm32", "wasm64"]>;
+def TargetWindows : TargetSpec {
+ let OSes = ["Win32"];
+}
def TargetHasDLLImportExport : TargetSpec {
let CustomCode = [{ Target.getTriple().hasDLLImportExport() }];
}
@@ -3494,7 +3497,7 @@ def MSAllocator : InheritableAttr {
let Documentation = [MSAllocatorDocs];
}
-def CFGuard : InheritableAttr {
+def CFGuard : InheritableAttr, TargetSpecificAttr {
// Currently only the __declspec(guard(nocf)) modifier is supported. In
future
// we might also want to support __declspec(guard(suppress)).
let Spellings = [Declspec<"guard">, Clang<"guard">];
diff --git a/clang/test/Sema/attr-guard_nocf.c
b/clang/test/Sema/attr-guard_nocf.c
index 7d7708e766473..c40884f45b7b7 100644
--- a/clang/test/Sema/attr-guard_nocf.c
+++ b/clang/test/Sema/attr-guard_nocf.c
@@ -2,10 +2,14 @@
// RUN: %clang_cc1 -triple %ms_abi_triple -fms-extensions -verify -std=c++11
-fsyntax-only -x c++ %s
// RUN: %clang_cc1 -triple x86_64-w64-windows-gnu -verify -fsyntax-only %s
// RUN: %clang_cc1 -triple x86_64-w64-windows-gnu -verify -std=c++11
-fsyntax-only -x c++ %s
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -verify -fsyntax-only %s
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -verify -std=c++11
-fsyntax-only -x c++ %s
// The x86_64-w64-windows-gnu version tests mingw target, which relies on
// __declspec(...) being defined as __attribute__((...)) by compiler built-in.
+#if defined(_WIN32)
+
// Function definition.
__declspec(guard(nocf)) void testGuardNoCF(void) { // no warning
}
@@ -35,3 +39,9 @@ __declspec(guard(nocf, nocf)) void
testGuardNoCFTooManyParams(void) { // expecte
// 'guard' Attribute argument must be a supported identifier.
__declspec(guard(cf)) void testGuardNoCFInvalidParam(void) { //
expected-warning {{'guard' attribute argument not supported: 'cf'}}
}
+
+#else
+
+__attribute((guard(nocf))) void testGNUStyleGuardNoCF(void) {} //
expected-warning {{unknown attribute 'guard' ignored}}
+
+#endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] efc76a1 - [analyzer] Silence GCC warnings about unused variables. NFC.
Author: Martin Storsjö
Date: 2022-08-29T13:26:13+03:00
New Revision: efc76a1ac5f910776091a48947ca1e90e9068845
URL:
https://github.com/llvm/llvm-project/commit/efc76a1ac5f910776091a48947ca1e90e9068845
DIFF:
https://github.com/llvm/llvm-project/commit/efc76a1ac5f910776091a48947ca1e90e9068845.diff
LOG: [analyzer] Silence GCC warnings about unused variables. NFC.
Use `isa()` instead of `Type *Var = dyn_cast()`
when the result of the cast isn't used.
Added:
Modified:
clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
Removed:
diff --git a/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
b/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
index 586e89ef2a174..656a7c1fe590a 100644
--- a/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ b/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -1217,7 +1217,7 @@ void ExprEngine::ProcessAutomaticObjDtor(const
CFGAutomaticObjDtor Dtor,
}
unsigned Idx = 0;
- if (const auto *AT = dyn_cast(varType)) {
+ if (isa(varType)) {
SVal ElementCount;
std::tie(state, Idx) = prepareStateForArrayDestruction(
state, Region, varType, LCtx, &ElementCount);
@@ -1368,7 +1368,7 @@ void ExprEngine::ProcessMemberDtor(const CFGMemberDtor D,
SVal FieldVal = State->getLValue(Member, ThisLoc);
unsigned Idx = 0;
- if (const auto *AT = dyn_cast(T)) {
+ if (isa(T)) {
SVal ElementCount;
std::tie(State, Idx) = prepareStateForArrayDestruction(
State, FieldVal.getAsRegion(), T, LCtx, &ElementCount);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] ce4c7a9 - [clang] Silence a false positive GCC -Wunused-but-set-parameter warning with constexpr
Author: Martin Storsjö
Date: 2022-08-31T14:55:44+03:00
New Revision: ce4c7a987fa3f255fa49570da4be1b9739815369
URL:
https://github.com/llvm/llvm-project/commit/ce4c7a987fa3f255fa49570da4be1b9739815369
DIFF:
https://github.com/llvm/llvm-project/commit/ce4c7a987fa3f255fa49570da4be1b9739815369.diff
LOG: [clang] Silence a false positive GCC -Wunused-but-set-parameter warning
with constexpr
This fixes the following warning:
In file included from
../tools/clang/lib/Tooling/Transformer/Transformer.cpp:9:
../tools/clang/include/clang/Tooling/Transformer/Transformer.h: In
instantiation of ‘llvm::Error clang::tooling::detail::populateMetadata(const
clang::transformer::RewriteRuleWith&, size_t, const
clang::ast_matchers::MatchFinder::MatchResult&,
clang::tooling::TransformerResult&) [with T = void; size_t = long unsigned
int]’:
../tools/clang/include/clang/Tooling/Transformer/Transformer.h:179:34:
required from ‘void
clang::tooling::detail::WithMetadataImpl::onMatchImpl(const
clang::ast_matchers::MatchFinder::MatchResult&) [with T = void]’
../tools/clang/include/clang/Tooling/Transformer/Transformer.h:156:8:
required from here
../tools/clang/include/clang/Tooling/Transformer/Transformer.h:120:25:
warning: parameter ‘SelectedCase’ set but not used [-Wunused-but-set-parameter]
120 | size_t SelectedCase,
| ~~~^~~~
The issue is fixed in GCC 10 and later, but this silences the noisy
warning in older versions. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827
for more details about the bug.
Differential Revision: https://reviews.llvm.org/D132920
Added:
Modified:
clang/include/clang/Tooling/Transformer/Transformer.h
Removed:
diff --git a/clang/include/clang/Tooling/Transformer/Transformer.h
b/clang/include/clang/Tooling/Transformer/Transformer.h
index 23683bfb8603..71b1fe81b951 100644
--- a/clang/include/clang/Tooling/Transformer/Transformer.h
+++ b/clang/include/clang/Tooling/Transformer/Transformer.h
@@ -120,6 +120,11 @@ populateMetadata(const transformer::RewriteRuleWith
&Rule,
size_t SelectedCase,
const ast_matchers::MatchFinder::MatchResult &Match,
TransformerResult &Result) {
+ // Silence a false positive GCC -Wunused-but-set-parameter warning in
constexpr
+ // cases, by marking SelectedCase as used. See
+ // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827 for details. The issue
is
+ // fixed in GCC 10.
+ (void)SelectedCase;
if constexpr (!std::is_void_v) {
auto Metadata = Rule.Metadata[SelectedCase]->eval(Match);
if (!Metadata)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] a3a8bd0 - [clang][MinGW] Add `-mguard=cf` and `-mguard=cf-nochecks`
Author: Alvin Wong
Date: 2022-09-09T09:55:40+03:00
New Revision: a3a8bd00c8f1e094967a80e56485c421e312dd2e
URL:
https://github.com/llvm/llvm-project/commit/a3a8bd00c8f1e094967a80e56485c421e312dd2e
DIFF:
https://github.com/llvm/llvm-project/commit/a3a8bd00c8f1e094967a80e56485c421e312dd2e.diff
LOG: [clang][MinGW] Add `-mguard=cf` and `-mguard=cf-nochecks`
This option can be used to enable Control Flow Guard checks and
generation of address-taken function table. They are equivalent to
`/guard:cf` and `/guard:cf,nochecks` in clang-cl. Passing this flag to
the Clang driver will also pass `--guard-cf` to the MinGW linker.
This feature is disabled by default. The option `-mguard=none` is also
available to explicitly disable this feature.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D132810
Added:
clang/test/Driver/mingw-cfguard.c
Modified:
clang/docs/ReleaseNotes.rst
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/MinGW.cpp
clang/lib/Driver/ToolChains/MinGW.h
Removed:
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 5bd812aca97f4..155eababa81e6 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -178,6 +178,10 @@ Attribute Changes in Clang
Windows Support
---
+- For the MinGW driver, added the options ``-mguard=none``, ``-mguard=cf`` and
+ ``-mguard=cf-nochecks`` (equivalent to ``/guard:cf-``, ``/guard:cf`` and
+ ``/guard:cf,nochecks`` in clang-cl) for enabling Control Flow Guard checks
+ and generation of address-taken function table.
AIX Support
---
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index 3b8c2a99178fb..b9be33396fdfe 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3367,6 +3367,9 @@ def mwindows : Joined<["-"], "mwindows">, Group,
Flags<[NoXarchOption]>
def mdll : Joined<["-"], "mdll">, Group, Flags<[NoXarchOption]>;
def municode : Joined<["-"], "municode">, Group,
Flags<[NoXarchOption]>;
def mthreads : Joined<["-"], "mthreads">, Group,
Flags<[NoXarchOption]>;
+def mguard_EQ : Joined<["-"], "mguard=">, Group,
Flags<[NoXarchOption]>,
+ HelpText<"Enable or disable Control Flow Guard checks and guard tables
emission">,
+ Values<"none,cf,cf-nochecks">;
def mcpu_EQ : Joined<["-"], "mcpu=">, Group;
def mmcu_EQ : Joined<["-"], "mmcu=">, Group;
def msim : Flag<["-"], "msim">, Group;
diff --git a/clang/lib/Driver/ToolChains/MinGW.cpp
b/clang/lib/Driver/ToolChains/MinGW.cpp
index ae7c4c56bf9e7..e7710bf12c080 100644
--- a/clang/lib/Driver/ToolChains/MinGW.cpp
+++ b/clang/lib/Driver/ToolChains/MinGW.cpp
@@ -169,6 +169,17 @@ void tools::MinGW::Linker::ConstructJob(Compilation &C,
const JobAction &JA,
if (Args.hasArg(options::OPT_Z_Xlinker__no_demangle))
CmdArgs.push_back("--no-demangle");
+ if (Arg *A = Args.getLastArg(options::OPT_mguard_EQ)) {
+StringRef GuardArgs = A->getValue();
+if (GuardArgs == "none")
+ CmdArgs.push_back("--no-guard-cf");
+else if (GuardArgs == "cf" || GuardArgs == "cf-nochecks")
+ CmdArgs.push_back("--guard-cf");
+else
+ D.Diag(diag::err_drv_unsupported_option_argument)
+ << A->getSpelling() << GuardArgs;
+ }
+
CmdArgs.push_back("-o");
const char *OutputFile = Output.getFilename();
// GCC implicitly adds an .exe extension if it is given an output file name
@@ -607,6 +618,26 @@ void toolchains::MinGW::AddClangSystemIncludeArgs(const
ArgList &DriverArgs,
addSystemInclude(DriverArgs, CC1Args, Base + "include");
}
+void toolchains::MinGW::addClangTargetOptions(
+const llvm::opt::ArgList &DriverArgs, llvm::opt::ArgStringList &CC1Args,
+Action::OffloadKind DeviceOffloadKind) const {
+ if (Arg *A = DriverArgs.getLastArg(options::OPT_mguard_EQ)) {
+StringRef GuardArgs = A->getValue();
+if (GuardArgs == "none") {
+ // Do nothing.
+} else if (GuardArgs == "cf") {
+ // Emit CFG instrumentation and the table of address-taken functions.
+ CC1Args.push_back("-cfguard");
+} else if (GuardArgs == "cf-nochecks") {
+ // Emit only the table of address-taken functions.
+ CC1Args.push_back("-cfguard-no-checks");
+} else {
+ getDriver().Diag(diag::err_drv_unsupported_option_argument)
+ << A->getSpelling() << GuardArgs;
+}
+ }
+}
+
void toolchains::MinGW::AddClangCXXStdlibIncludeArgs(
const ArgList &DriverArgs, ArgStringList &CC1Args) const {
if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
diff --git a/clang/lib/Driver/ToolChains/MinGW.h
b/clang/lib/Driver/ToolChains/MinGW.h
index f15f99dc8a8c0..531b2b9eabf3a 100644
--- a/clang/lib/Driver/ToolChains/MinGW.h
+++ b/clang/lib/Driver/ToolChains/MinGW.h
@@ -79,6 +79,10 @@ class LLVM_LIBRARY_VISIBILITY MinGW : public ToolChain {
void
AddClangSystemInclu
[clang] fbfe1db - [clang] Explicitly set the EmulatedTLS codegen option. NFC.
Author: Martin Storsjö
Date: 2022-09-13T10:40:54+03:00
New Revision: fbfe1db4a95a73ed6a0767db0ab7d449fc03405e
URL:
https://github.com/llvm/llvm-project/commit/fbfe1db4a95a73ed6a0767db0ab7d449fc03405e
DIFF:
https://github.com/llvm/llvm-project/commit/fbfe1db4a95a73ed6a0767db0ab7d449fc03405e.diff
LOG: [clang] Explicitly set the EmulatedTLS codegen option. NFC.
Set the EmulatedTLS option based on `Triple::hasDefaultEmulatedTLS()`
if the user didn't specify it; set `ExplicitEmulatedTLS` to true
in `llvm::TargetOptions` and set `EmulatedTLS` to Clang's
opinion of what the default or preference is.
This avoids any risk of deviance between the two.
This affects one check of `getCodeGenOpts().EmulatedTLS` in
`shouldAssumeDSOLocal` in CodeGenModule, but as that check only
is done for `TT.isWindowsGNUEnvironment()`, and
`hasDefaultEmulatedTLS()` returns false for such environments
it doesn't make any current testable difference - thus NFC.
Some mingw distributions carry a downstream patch, that enables
emulated TLS by default for mingw targets in `hasDefaultEmulatedTLS()`
- and for such cases, this patch does make a difference and fixes the
detection of emulated TLS, if it is implicitly enabled.
Differential Revision: https://reviews.llvm.org/D132916
Added:
Modified:
clang/include/clang/Basic/CodeGenOptions.def
clang/lib/CodeGen/BackendUtil.cpp
clang/lib/Frontend/CompilerInvocation.cpp
Removed:
diff --git a/clang/include/clang/Basic/CodeGenOptions.def
b/clang/include/clang/Basic/CodeGenOptions.def
index ca2aa0d09aaf9..9c1a23cb17261 100644
--- a/clang/include/clang/Basic/CodeGenOptions.def
+++ b/clang/include/clang/Basic/CodeGenOptions.def
@@ -88,7 +88,6 @@ CODEGENOPT(EmitGcovArcs , 1, 0) ///< Emit coverage data
files, aka. GCDA.
CODEGENOPT(EmitGcovNotes , 1, 0) ///< Emit coverage "notes" files, aka
GCNO.
CODEGENOPT(EmitOpenCLArgMetadata , 1, 0) ///< Emit OpenCL kernel arg metadata.
CODEGENOPT(EmulatedTLS , 1, 0) ///< Set by default or
-f[no-]emulated-tls.
-CODEGENOPT(ExplicitEmulatedTLS , 1, 0) ///< Set if -f[no-]emulated-tls is used.
/// Embed Bitcode mode (off/all/bitcode/marker).
ENUM_CODEGENOPT(EmbedBitcode, EmbedBitcodeKind, 2, Embed_Off)
/// Inline asm dialect, -masm=(att|intel)
diff --git a/clang/lib/CodeGen/BackendUtil.cpp
b/clang/lib/CodeGen/BackendUtil.cpp
index f4a4f1cd22ab9..aff277f59c054 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -440,7 +440,7 @@ static bool initTargetOptions(DiagnosticsEngine &Diags,
CodeGenOpts.UniqueBasicBlockSectionNames;
Options.TLSSize = CodeGenOpts.TLSSize;
Options.EmulatedTLS = CodeGenOpts.EmulatedTLS;
- Options.ExplicitEmulatedTLS = CodeGenOpts.ExplicitEmulatedTLS;
+ Options.ExplicitEmulatedTLS = true;
Options.DebuggerTuning = CodeGenOpts.getDebuggerTuning();
Options.EmitStackSizeSection = CodeGenOpts.StackSizeSection;
Options.StackUsageOutput = CodeGenOpts.StackUsageOutput;
diff --git a/clang/lib/Frontend/CompilerInvocation.cpp
b/clang/lib/Frontend/CompilerInvocation.cpp
index 9ac522adfd9a9..201b9965bb0eb 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -1492,13 +1492,8 @@ void CompilerInvocation::GenerateCodeGenArgs(
F.Filename, SA);
}
- // TODO: Consider removing marshalling annotations from f[no_]emulated_tls.
- // That would make it easy to generate the option only **once** if it was
- // explicitly set to non-default value.
- if (Opts.ExplicitEmulatedTLS) {
-GenerateArg(
-Args, Opts.EmulatedTLS ? OPT_femulated_tls : OPT_fno_emulated_tls, SA);
- }
+ GenerateArg(
+ Args, Opts.EmulatedTLS ? OPT_femulated_tls : OPT_fno_emulated_tls, SA);
if (Opts.FPDenormalMode != llvm::DenormalMode::getIEEE())
GenerateArg(Args, OPT_fdenormal_fp_math_EQ, Opts.FPDenormalMode.str(), SA);
@@ -1862,9 +1857,9 @@ bool CompilerInvocation::ParseCodeGenArgs(CodeGenOptions
&Opts, ArgList &Args,
Opts.LinkBitcodeFiles.push_back(F);
}
- if (Args.getLastArg(OPT_femulated_tls) ||
- Args.getLastArg(OPT_fno_emulated_tls)) {
-Opts.ExplicitEmulatedTLS = true;
+ if (!Args.getLastArg(OPT_femulated_tls) &&
+ !Args.getLastArg(OPT_fno_emulated_tls)) {
+Opts.EmulatedTLS = T.hasDefaultEmulatedTLS();
}
if (Arg *A = Args.getLastArg(OPT_ftlsmodel_EQ)) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Fix BUILD_SHARED_LIBS symbols from libclangInterpreter on MinGW (PR #71393)
https://github.com/mstorsjo created https://github.com/llvm/llvm-project/pull/71393 A few symbols within libclangInterpreter have got explicit dllexport attributes, in order to make them exported (and thus visible at runtime) in any build, not only when they are part of e.g. a DLL libclang-cpp, but also when they are part of a plain .exe. Due to the explicit dllexports, these symbols would sidestep the regular MinGW logic of exporting all symbols if there are no dllexports. Therefore, for libclang-cpp, a separate fix was made in 592e935e115ffb451eb9b782376711dab6558fe0, to pass --export-all-symbols to the build of libclang-cpp. If building with BUILD_SHARED_LIBS enabled, then the same issue appears in libclangInterpreter; pass the same flag --export-all-symbols there as well, to make sure all symbols are visible, not only the ones that are explicitly marked as dllexport. From 9de9617b46bd3c2ff4abd9446afc72c6e91f2493 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Martin=20Storsj=C3=B6?= Date: Mon, 6 Nov 2023 15:42:42 +0200 Subject: [PATCH] [clang-repl] Fix BUILD_SHARED_LIBS symbols from libclangInterpreter on MinGW A few symbols within libclangInterpreter have got explicit dllexport attributes, in order to make them exported (and thus visible at runtime) in any build, not only when they are part of e.g. a DLL libclang-cpp, but also when they are part of a plain .exe. Due to the explicit dllexports, these symbols would sidestep the regular MinGW logic of exporting all symbols if there are no dllexports. Therefore, for libclang-cpp, a separate fix was made in 592e935e115ffb451eb9b782376711dab6558fe0, to pass --export-all-symbols to the build of libclang-cpp. If building with BUILD_SHARED_LIBS enabled, then the same issue appears in libclangInterpreter; pass the same flag --export-all-symbols there as well, to make sure all symbols are visible, not only the ones that are explicitly marked as dllexport. --- clang/lib/Interpreter/CMakeLists.txt | 11 +++ 1 file changed, 11 insertions(+) diff --git a/clang/lib/Interpreter/CMakeLists.txt b/clang/lib/Interpreter/CMakeLists.txt index 84f6ca5271d2ab0..9065f998f73c473 100644 --- a/clang/lib/Interpreter/CMakeLists.txt +++ b/clang/lib/Interpreter/CMakeLists.txt @@ -38,3 +38,14 @@ add_clang_library(clangInterpreter clangSema clangSerialization ) + +if ((MINGW OR CYGWIN) AND BUILD_SHARED_LIBS) + # The DLLs are supposed to export all symbols (except for ones that are + # explicitly hidden). Normally, this is what happens anyway, but if there + # are symbols that are marked explicitly as dllexport, we'd only export them + # and nothing else. The Interpreter contains a few cases of such dllexports + # (for symbols that need to be exported even from standalone exe files); + # therefore, add --export-all-symbols to make sure we export all symbols + # despite potential dllexports. + target_link_options(clangInterpreter PRIVATE LINKER:--export-all-symbols) +endif() ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Fix BUILD_SHARED_LIBS symbols from libclangInterpreter on MinGW (PR #71393)
mstorsjo wrote: CC @brechtsanders, this is an alternative to #66881. https://github.com/llvm/llvm-project/pull/71393 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Fix build dllexport/dllimport issues when doing a shared build for Windows using GCC (PR #66881)
mstorsjo wrote: Thanks, I wasn't aware of this issue (I don't routinely try building with `-DBUILD_SHARED_LIBS=ON`, which I presume is what you've done to trigger this). See 592e935e115ffb451eb9b782376711dab6558fe0 for earlier context on this issue; therefore I'd prefer to fix this as I do in #71393; can you confirm if that change works for you as well? https://github.com/llvm/llvm-project/pull/66881 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] Reapply #2 [clang-repl] [test] Make an XFAIL more precise (PR #71168)
https://github.com/mstorsjo edited https://github.com/llvm/llvm-project/pull/71168 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] Reapply #2 [clang-repl] [test] Make an XFAIL more precise (PR #71168)
https://github.com/mstorsjo edited https://github.com/llvm/llvm-project/pull/71168 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] Reapply #2 [clang-repl] [test] Make an XFAIL more precise (PR #71168)
https://github.com/mstorsjo closed https://github.com/llvm/llvm-project/pull/71168 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] Fix BUILD_SHARED_LIBS symbols from libclangInterpreter on MinGW (PR #71393)
https://github.com/mstorsjo closed https://github.com/llvm/llvm-project/pull/71393 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Fix build dllexport/dllimport issues when doing a shared build for Windows using GCC (PR #66881)
mstorsjo wrote: This is superseded by #71393 which was merged now. https://github.com/llvm/llvm-project/pull/66881 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [X86][AVX10] Permit AVX512 options/features used together with AVX10 (PR #71318)
mstorsjo wrote: > Hi Phoebe, starting seeing this error on rather old codes after this patch > landed . is there a particular flag you recommend i should compile with to > get previous behavior ? > > error: always_inline function '_mm_setzero_pd' requires target feature > 'evex512', but would be inlined into function '_mm_getexp_pd' that is > compiled without support for 'evex512' I also ran into something similar, when compiling Qt; I filed https://github.com/llvm/llvm-project/issues/72106 with a different reproducer. https://github.com/llvm/llvm-project/pull/71318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[lldb] [clang] [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (PR #74580)
mstorsjo wrote: Could we please land this now? https://github.com/llvm/llvm-project/pull/74580 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Stub out gcc_struct attribute (PR #71148)
mstorsjo wrote: > Right, I'd just like to make sure that we're not deepening a divergence here. > It would be good to get agreement from the GCC devs that they think > `ms_struct` probably ought to do something on e.g. ARM MinGW targets and that > they consider this a bug (in a feature that they may not really support, > which is fine). But if they think _we're_ wrong and that this really should > only have effect on x86, I would like to know that. I'm not a GCC developer, but I would not think that GCC would consider this an x86-only feature. It just so happens that (upstream) GCC only supports Windows on x86. But MSVC does their own funky bitfield packing on all architectures - so it seems reasonable to want to be able to match it on all architectures. https://github.com/llvm/llvm-project/pull/71148 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [MinGW] MinGW dynamicbase (PR #74979)
https://github.com/mstorsjo requested changes to this pull request. This is not necessary. Since 514b4e191d5f46de8e142fe216e677a35fa9c4bb in binutils (https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=514b4e191d5f46de8e142fe216e677a35fa9c4bb), dynamicbase is enabled by default. Also since e72403f96de7f1c681acd5968f72aa986412dfce in llvm-project, LLD also does the same. https://github.com/llvm/llvm-project/pull/74979 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [MinGW] MinGW pthread (PR #74981)
mstorsjo wrote: This breaks bootstrapping llvm-mingw. Not all mingw environments use or require pthreads; llvm-mingw is one such environment, and the clang64 environment in msys2 is another one. While llvm-mingw does contain winpthreads, it is built later in the build process, and if this patch is applied, the setup procedure is broken; one would need to reorder how these libraries are linked, or create a dummy empty `libpthread.a` to make sure that linking works until the read winpthreads library is built. Note that within msys2, they do apply a patch that does exactly what this patch does, for the mingw64 environment, where the system libstdc++ and similar does require winpthreads. The fact that this is patched for the GCC environments isn't ideal, but any attempt to modify this needs to first acknowledge the current state of things and not just blindly barge ahead with a breaking change like this. Also do note that the upcoming GCC 14 will have the win32 thread model supporting C++11, so it is quite possible for GCC based environments to stop relying so much on winpthreads, which would reduce the need for this patch. CC @mati865 @lazka @jeremyd2019 https://github.com/llvm/llvm-project/pull/74981 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Cygwin] Cygwin driver (PR #74933)
mstorsjo wrote: @carlo-bramini has spent some effort on using Clang in Cygwin environments before, so as far as I know, it does work in general from before. So this change, which adds an entirely new driver for Cygwin environments, would need to be explained why it does that (I don't disagree, it's probably the right thing to do in general), how things worked before and how this changes things. And I would like to have @carlo-bramini's eye on this (and all the related Cygwin patches from @xu-chiheng). And changes like this need some general tests, have a look at `clang/test/Driver` for how other drivers are tested. https://github.com/llvm/llvm-project/pull/74933 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [MinGW] Fix the regression caused by commit 592e935e115ffb451eb9b782376711dab6558fe0, that, in MinGW, Clang can't be built by system Clang 15.0.4. (PR #74982)
mstorsjo wrote: I don't know what issue/regression you're referring to. Please explain, in detail, what the issue is and all the relevant aspects of your configuration. Also explain what the suggested fix does, and how it handles the various cases (I just tested building latest llvm-project main with Clang 15 and LLD, for a mingw target, and it worked just fine, both as a regular non-dylib build, and with `LLVM_LINK_LLVM_DYLIB` enabled.) I also believe that the suggested patch would break actual use of clang-repl; if `LLVM_BUILD_LLVM_DYLIB` or `LLVM_BUILD_SHARED_LIBS` aren't defined, then those symbols wouldn't be dllexported at all. This causes them to not be found at runtime when the JIT runtime tries to locate them. https://github.com/llvm/llvm-project/pull/74982 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [libunwind] Fix an inconsistent indentation (NFC) (PR #72314)
https://github.com/mstorsjo approved this pull request. LGTM, thanks! (I have no idea how I botched that previous fix commit...) https://github.com/llvm/llvm-project/pull/72314 ___ 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) mstorsjo wrote: Instead of redefining `CMAKE_MSVC_RUNTIME_LIBRARY` repeatedly, if you really want to set it specifically for one library, it's better to set the `MSVC_RUNTIME_LIBRARY` target property instead - see https://cmake.org/cmake/help/latest/prop_tgt/MSVC_RUNTIME_LIBRARY.html. 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] [clang-repl] [test] Make an XFAIL more precise (PR #70991)
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/70991
The const.cpp testcase fails when running in MSVC mode, while it does succeed
in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as the
printout looks like this:
A(1), this = 02559793
A(1), this = 02559793
f: this = 02559793, val = 1
A(1), this = 02559793
f: this = 02559793, val = 1
~A, this = 02559793, val = 1
~A, this = 02559793, val = 1
~A, this = 02559793, val = 1
While the expected printout looks like this:
A(1), this = 02C903E1
f: this = 02C903E1, val = 1
f: this = 02C903E1, val = 1
~A, this = 02C903E1, val = 1
From 83554507ba60e8d8d0864176f2f0629c3bb7e75a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Wed, 1 Nov 2023 23:35:43 +0200
Subject: [PATCH] [clang-repl] [test] Make an XFAIL more precise
The const.cpp testcase fails when running in MSVC mode, while they
do succeed in MinGW mode.
In MSVC mode, there are more constructor invocations than expected,
as the printout looks like this:
A(1), this = 02559793
A(1), this = 02559793
f: this = 02559793, val = 1
A(1), this = 02559793
f: this = 02559793, val = 1
~A, this = 02559793, val = 1
~A, this = 02559793, val = 1
~A, this = 02559793, val = 1
While the expected printout looks like this:
A(1), this = 02C903E1
f: this = 02C903E1, val = 1
f: this = 02C903E1, val = 1
~A, this = 02C903E1, val = 1
---
clang/test/Interpreter/const.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clang/test/Interpreter/const.cpp b/clang/test/Interpreter/const.cpp
index 4b6ce65e3643e64..1412a1d85d6f58f 100644
--- a/clang/test/Interpreter/const.cpp
+++ b/clang/test/Interpreter/const.cpp
@@ -1,6 +1,6 @@
// UNSUPPORTED: system-aix
// see https://github.com/llvm/llvm-project/issues/68092
-// XFAIL: system-windows
+// XFAIL: target={{.*}}-windows-msvc
// RUN: cat %s | clang-repl | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -O2 | FileCheck %s
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] [test] Make an XFAIL more precise (PR #70991)
mstorsjo wrote: > Very interesting... See also #68092, now I understand even less what the > problem is... No idea actually, but I tested passing `-Xcc --target=x86_64-w64-mingw32` to an MSVC-built clang-repl, and then it outputs the expected things. Not sure at what level some JIT deduplication should be happening, but anyway, the MSVC C++ ABI is distinctly different from the Itanium C++ ABI, in most aspects. https://github.com/llvm/llvm-project/pull/70991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] [test] Make an XFAIL more precise (PR #70991)
https://github.com/mstorsjo closed https://github.com/llvm/llvm-project/pull/70991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] [test] Make an XFAIL more precise (PR #70991)
mstorsjo wrote:
This broke on PS5 bots, like
https://lab.llvm.org/buildbot/#/builders/216/builds/29677; those are configured
with a triple like `x86_64-sie-ps5`, which seems to use an MSVC like C++ ABI
behaviour, so I pushed a revert.
Not sure whom to CC to pull in Sony people to discuss this matter, so trying
@pogo59. Can we use something like `XFAIL: target={{.*}}-windows-msvc,
target={{.*}-ps4, target={{.*}-ps5` to specifically point towards the Sony PS
triples that also use the MSVC C++ ABI here? The ideal would be something like
`XFAIL: default-target-is-msvc-cxx-abi`, but I don't think we have that. I see
triples `x86_64-scei-ps4` and `x86_64-sie-ps5` being mentioned elsewhere in
Clang tests as examples of PS4/PS5 triples.
https://github.com/llvm/llvm-project/pull/70991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] b73d739 - Revert "[clang-repl] [test] Make an XFAIL more precise (#70991)"
Author: Martin Storsjö
Date: 2023-11-02T10:49:55+02:00
New Revision: b73d7390732b48014983aa9569e68c139f61bfcb
URL:
https://github.com/llvm/llvm-project/commit/b73d7390732b48014983aa9569e68c139f61bfcb
DIFF:
https://github.com/llvm/llvm-project/commit/b73d7390732b48014983aa9569e68c139f61bfcb.diff
LOG: Revert "[clang-repl] [test] Make an XFAIL more precise (#70991)"
This reverts commit 3bc056d5f0ebe9e4074afa088c3a0355f9ab901a.
This broke on bots with a target triple of x86_64-sie-ps5,
which also appear to behave like the MSVC case.
Added:
Modified:
clang/test/Interpreter/const.cpp
Removed:
diff --git a/clang/test/Interpreter/const.cpp
b/clang/test/Interpreter/const.cpp
index 1412a1d85d6f58f..4b6ce65e3643e64 100644
--- a/clang/test/Interpreter/const.cpp
+++ b/clang/test/Interpreter/const.cpp
@@ -1,6 +1,6 @@
// UNSUPPORTED: system-aix
// see https://github.com/llvm/llvm-project/issues/68092
-// XFAIL: target={{.*}}-windows-msvc
+// XFAIL: system-windows
// RUN: cat %s | clang-repl | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -O2 | FileCheck %s
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] [test] Make an XFAIL more precise (PR #70991)
mstorsjo wrote: > FTR, the "Worker" tab on that buildbot page will point you to the maintainer. Ah, there it is, I tried looking around, but overlooked that one... > But tagging me is also fine in general. Ok, thanks! > I'm unable to repro the problem locally because my local build doesn't seem > to include clang-repl.exe, so the whole clang/test/Interpreter directory is > Unsupported. Is there some cmake parameter to enable JIT? Not sure - by doing `ninja clang-repl` I was able to get those tests running at least. > If you want to XFAIL specifically for the Sony targets, what you suggested > would work. I'm unclear about the "MSVC C++ ABI" aspect, but if that gets the > test to work, go for it. Ok, great, thanks! I'll try that and reland the commit. https://github.com/llvm/llvm-project/pull/70991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] [test] Make an XFAIL more precise (PR #70991)
mstorsjo wrote: > If you still need help reproducing or debugging the issue on our bot, please > let me know. Thanks, much appreciated. Can you test if https://github.com/mstorsjo/llvm-project/commit/clang-repl-xfail seems to run correctly in this environment? Otherwise I'll try to push it tomorrow and see how it fares on the bot. https://github.com/llvm/llvm-project/pull/70991 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-repl] [test] Make an XFAIL more precise (PR #70991)
mstorsjo wrote:
> > > > If you still need help reproducing or debugging the issue on our bot,
> > > > please let me know.
> > >
> > >
> > > Thanks, much appreciated. Can you test if
> > > [mstorsjo@clang-repl-xfail](https://github.com/mstorsjo/llvm-project/commit/clang-repl-xfail)
> > > seems to run correctly in this environment? Otherwise I'll try to push
> > > it tomorrow and see how it fares on the bot.
>
> It failed, but due to a typo in the XFAIL you added:
>
> ```
> target={{.*}-ps4, target={{.*}-ps5
> ```
>
> These should have balanced braces. If I add the missing braces, the test
> passes with an XFAIL on the bot.
Oh, oops - but thanks for checking and verifying with the typo fixed. I'll try
to reland this change now then, with that fixed. Thanks again!
https://github.com/llvm/llvm-project/pull/70991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] e9db60c - Reapply [clang-repl] [test] Make an XFAIL more precise (#70991)
Author: Martin Storsjö
Date: 2023-11-03T11:30:08+02:00
New Revision: e9db60c05e2fb96ff40cbb1f78790abc5de9237e
URL:
https://github.com/llvm/llvm-project/commit/e9db60c05e2fb96ff40cbb1f78790abc5de9237e
DIFF:
https://github.com/llvm/llvm-project/commit/e9db60c05e2fb96ff40cbb1f78790abc5de9237e.diff
LOG: Reapply [clang-repl] [test] Make an XFAIL more precise (#70991)
The const.cpp testcase fails when running in MSVC mode, while it does
succeed in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as
the printout looks like this:
A(1), this = 02559793
A(1), this = 02559793
f: this = 02559793, val = 1
A(1), this = 02559793
f: this = 02559793, val = 1
~A, this = 02559793, val = 1
~A, this = 02559793, val = 1
~A, this = 02559793, val = 1
While the expected printout looks like this:
A(1), this = 02C903E1
f: this = 02C903E1, val = 1
f: this = 02C903E1, val = 1
~A, this = 02C903E1, val = 1
Reapplying with the XFAIL pattern expanded to include PS4/PS5
triples as well, which also seem to have the same behaviour
as MSVC.
Added:
Modified:
clang/test/Interpreter/const.cpp
Removed:
diff --git a/clang/test/Interpreter/const.cpp
b/clang/test/Interpreter/const.cpp
index 4b6ce65e3643e64..ca141d69f84d302 100644
--- a/clang/test/Interpreter/const.cpp
+++ b/clang/test/Interpreter/const.cpp
@@ -1,6 +1,6 @@
// UNSUPPORTED: system-aix
// see https://github.com/llvm/llvm-project/issues/68092
-// XFAIL: system-windows
+// XFAIL: target={{.*}}-windows-msvc, target={{.*}}-ps4, target={{.*}}-ps5
// RUN: cat %s | clang-repl | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -O2 | FileCheck %s
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 89a336a - Revert "Reapply [clang-repl] [test] Make an XFAIL more precise (#70991)"
Author: Martin Storsjö
Date: 2023-11-03T11:55:33+02:00
New Revision: 89a336add722f57f61c99b3eafab1c89f943db5e
URL:
https://github.com/llvm/llvm-project/commit/89a336add722f57f61c99b3eafab1c89f943db5e
DIFF:
https://github.com/llvm/llvm-project/commit/89a336add722f57f61c99b3eafab1c89f943db5e.diff
LOG: Revert "Reapply [clang-repl] [test] Make an XFAIL more precise (#70991)"
This reverts commit e9db60c05e2fb96ff40cbb1f78790abc5de9237e.
This was still failing (unexpectedly passing) on some Sony PS
buildbots.
The issue is that the clang-repl testcases don't depend on what
the default target triple is, but what the host triple is,
which is used for JIT purposes.
Added:
Modified:
clang/test/Interpreter/const.cpp
Removed:
diff --git a/clang/test/Interpreter/const.cpp
b/clang/test/Interpreter/const.cpp
index ca141d69f84d302..4b6ce65e3643e64 100644
--- a/clang/test/Interpreter/const.cpp
+++ b/clang/test/Interpreter/const.cpp
@@ -1,6 +1,6 @@
// UNSUPPORTED: system-aix
// see https://github.com/llvm/llvm-project/issues/68092
-// XFAIL: target={{.*}}-windows-msvc, target={{.*}}-ps4, target={{.*}}-ps5
+// XFAIL: system-windows
// RUN: cat %s | clang-repl | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -O2 | FileCheck %s
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Reapply #2 [clang-repl] [test] Make an XFAIL more precise (#70991) (PR #71168)
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/71168
The const.cpp testcase fails when running in MSVC mode, while it does succeed
in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as the
printout looks like this:
A(1), this = 02559793
A(1), this = 02559793
f: this = 02559793, val = 1
A(1), this = 02559793
f: this = 02559793, val = 1
~A, this = 02559793, val = 1
~A, this = 02559793, val = 1
~A, this = 02559793, val = 1
While the expected printout looks like this:
A(1), this = 02C903E1
f: this = 02C903E1, val = 1
f: this = 02C903E1, val = 1
~A, this = 02C903E1, val = 1
Reapplying with the XFAIL changed to check the host triple, not the target
triple. On an MSVC based build of Clang, but with the default target triple set
to PS4/PS5, we will still see the failure. And a Linux based build of Clang
that targets PS4/PS5 won't see the issue.
From 2fb453c2cdcf982aa2dd50208329785f8c338d45 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Thu, 2 Nov 2023 09:51:33 +0200
Subject: [PATCH] Reapply #2 [clang-repl] [test] Make an XFAIL more precise
(#70991)
The const.cpp testcase fails when running in MSVC mode, while it does
succeed in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as
the printout looks like this:
A(1), this = 02559793
A(1), this = 02559793
f: this = 02559793, val = 1
A(1), this = 02559793
f: this = 02559793, val = 1
~A, this = 02559793, val = 1
~A, this = 02559793, val = 1
~A, this = 02559793, val = 1
While the expected printout looks like this:
A(1), this = 02C903E1
f: this = 02C903E1, val = 1
f: this = 02C903E1, val = 1
~A, this = 02C903E1, val = 1
Reapplying with the XFAIL changed to check the host triple,
not the target triple. On an MSVC based build of Clang, but
with the default target triple set to PS4/PS5, we will still
see the failure. And a Linux based build of Clang that targets
PS4/PS5 won't see the issue.
---
clang/test/Interpreter/const.cpp | 2 +-
llvm/test/lit.cfg.py | 4
llvm/utils/lit/lit/llvm/config.py | 1 +
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/clang/test/Interpreter/const.cpp b/clang/test/Interpreter/const.cpp
index 4b6ce65e3643e64..86358c1a54fbdde 100644
--- a/clang/test/Interpreter/const.cpp
+++ b/clang/test/Interpreter/const.cpp
@@ -1,6 +1,6 @@
// UNSUPPORTED: system-aix
// see https://github.com/llvm/llvm-project/issues/68092
-// XFAIL: system-windows
+// XFAIL: host={{.*}}-windows-msvc
// RUN: cat %s | clang-repl | FileCheck %s
// RUN: cat %s | clang-repl -Xcc -O2 | FileCheck %s
diff --git a/llvm/test/lit.cfg.py b/llvm/test/lit.cfg.py
index ab245b71cdd16a5..022d1aedbdcdbb6 100644
--- a/llvm/test/lit.cfg.py
+++ b/llvm/test/lit.cfg.py
@@ -477,10 +477,6 @@ def have_cxx_shared_library():
if not config.target_triple.startswith(("nvptx", "xcore")):
config.available_features.add("object-emission")
-# Allow checking for specific details in the host triple
-if config.host_triple:
-config.available_features.add('host=%s' % config.host_triple)
-
if config.have_llvm_driver:
config.available_features.add("llvm-driver")
diff --git a/llvm/utils/lit/lit/llvm/config.py
b/llvm/utils/lit/lit/llvm/config.py
index 16cc2968034bf74..79094b839e772e7 100644
--- a/llvm/utils/lit/lit/llvm/config.py
+++ b/llvm/utils/lit/lit/llvm/config.py
@@ -97,6 +97,7 @@ def __init__(self, lit_config, config):
# part of the standard header. But currently they aren't)
host_triple = getattr(config, "host_triple", None)
target_triple = getattr(config, "target_triple", None)
+features.add("host=%s" % host_triple)
features.add("target=%s" % target_triple)
if host_triple and host_triple == target_triple:
features.add("native")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] Reapply #2 [clang-repl] [test] Make an XFAIL more precise (#70991) (PR #71168)
mstorsjo wrote: Posting for a second review instead of just relanding the patch as is; in order to check the host triple, I had to add the `host=triple` string; it was previously only available for tests under `llvm/test`, but let's move it to the common llvm test configuration just like the `target=triple` strings, so that it is available for tests under clang as well. https://github.com/llvm/llvm-project/pull/71168 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [MinGW] MinGW dynamicbase (PR #74979)
https://github.com/mstorsjo requested changes to this pull request. No, you do not need to do this. There's no need to add `--dynamicbase` manually in Clang. As I already posted, both ld.bfd and ld.lld default to `--dynamicbase` enabled since 2020. https://github.com/llvm/llvm-project/pull/74979 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [MinGW] Fix the regression caused by commit 592e935e115ffb451eb9b782376711dab6558fe0, that, in MinGW, Clang can't be built by system Clang 15.0.4. (PR #74982)
mstorsjo wrote: > I have build scripts and patches at: https://github.com/xu-chiheng/Note This does not answer the question. You need to explain what is broken, and why, and how this fixes it. And address the concern that this actually breaks functionality in some cases. I guess this partially answers the question on in what exact environment the issue occurs, although it would require me to dissect your build script environment to figure it out. https://github.com/llvm/llvm-project/pull/74982 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [MinGW] MinGW dynamicbase (PR #74979)
mstorsjo wrote: > > Also > > In Cygwin with binutils 2.41, --dynamicbase make a difference, so I thought > MinGW also need it. No, MinGW does not need it, as it has been enabled by default since binutils 2.36. Apparently that change, https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=514b4e191d5f46de8e142fe216e677a35fa9c4bb, didn't apply to Cygwin but only to MinGW. But if Cygwin works with dynamicbase (I think it might have issues with it but I'm not sure?) then perhaps binutils should be changed to enable dynamicbase by default there, instead of changing compilers to pass the option by default. https://github.com/llvm/llvm-project/pull/74979 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Cygwin] Cygwin driver (PR #74933)
mstorsjo wrote: > > @carlo-bramini has spent some effort on using Clang in Cygwin environments > > before, so as far as I know, it does work in general from before. So this > > change, which adds an entirely new driver for Cygwin environments, would > > need to be explained why it does that (I don't disagree, it's probably the > > right thing to do in general), how things worked before and how this > > changes things. And I would like to have @carlo-bramini's eye on this (and > > all the related Cygwin patches from @xu-chiheng). > > And changes like this need some general tests, have a look at > > `clang/test/Driver` for how other drivers are tested. > > The Cygwin driver is basically the same as MinGW driver with minor difference. Right. What are the actual observable differences to what was executed before? (I presume this before used the `Generic_GCC` toolchain?) Also, I wonder if it would make sense to share the MinGW driver code with Cygwin, and just add exceptions where necessary, instead of duplicating it into a separate one? Maybe, but perhaps not. https://github.com/llvm/llvm-project/pull/74933 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [clang-tools-extra] [libc] [compiler-rt] [libcxx] [openmp] [mlir] [lldb] [flang] [libcxxabi] [lld] [builtins][arm64] Build __init_cpu_features_resolver on Apple platforms (PR #73685)
mstorsjo wrote:
This commit broken building compiler-rt builtins for Windows on aarch64;
building now hits these errors:
```
llvm-project/compiler-rt/lib/builtins/cpu_model.c:1192:2: error: No support for
checking for lse atomics on this platfrom yet.
1192 | #error No support for checking for lse atomics on this platfrom yet.
| ^
llvm-project/compiler-rt/lib/builtins/cpu_model.c:1571:2: error: No support for
checking hwcap on this platform yet.
1571 | #error No support for checking hwcap on this platform yet.
| ^
2 errors generated.
```
Before this change, most of this whole file was ifdeffed out when building on
Windows (and Apple platforms, I would presume), but now most of it is included,
then hitting this `#error`.
I guess it could work to just remove the `#error` cases, but this file suffers
from a pretty deep ifdef nesting jungle, so I'm not sure if that's the best
solution. (FWIW, if we wanted to add aarch64 CPU feature detection for Windows
here, the code would be more of a separate codepath just like the Apple case,
it doesn't share the linux/BSD HWCAP style.)
I can push a quick fix, either removing the `#error` or reverting this commit,
later during the day.
BTW, when compiling the file I also get a bunch of warnings in this style:
```
llvm-project/compiler-rt/lib/builtins/cpu_model.c:1448:36: warning: value size
does not match register size specified by the constraint and modifier
[-Wasm-operand-widths]
1448 | getCPUFeature(ID_AA64PFR1_EL1, ftr);
|^
llvm-project/compiler-rt/lib/builtins/cpu_model.c:1448:5: note: use constraint
modifier "w"
1448 | getCPUFeature(ID_AA64PFR1_EL1, ftr);
| ^
llvm-project/compiler-rt/lib/builtins/cpu_model.c:1345:45: note: expanded from
macro 'getCPUFeature'
1345 | #define getCPUFeature(id, ftr) __asm__("mrs %0, " #id : "=r"(ftr))
|
```
https://github.com/llvm/llvm-project/pull/73685
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[lld] [llvm] [libcxxabi] [compiler-rt] [libc] [openmp] [mlir] [clang-tools-extra] [clang] [lldb] [libcxx] [flang] [builtins][arm64] Build __init_cpu_features_resolver on Apple platforms (PR #73685)
mstorsjo wrote: > > BTW, when compiling the file I also get a bunch of warnings in this style: > > @mstorsjo maybe `unsigned long` is 32 bits on that platform... what's the > target triple? Ah, indeed - yes, Windows has 32 bit `long`s. The triples are `aarch64-windows-gnu` or `aarch64-windows-msvc`. https://github.com/llvm/llvm-project/pull/73685 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Stub out gcc_struct attribute (PR #71148)
mstorsjo wrote:
> `-mms-bitfields` is a GCC x86 specific option (`aarch64-linux-gnu-gcc
> -mms-bitfields -xc /dev/null -E` => `error: unrecognized command-line option
> ‘-mms-bitfields’`).
While it is implemented as an x86 specific option in GCC right now, that
doesn't mean that it only is supposed to have an effect for x86. Upstream GCC
only supports Windows on x86, and my recollection is that lots of the Windows
specific logic is located in x86 specific files, even if the same logic also
should apply for Windows on any other architecture - it's just not implemented
(yet).
As implemented in Clang, the option works for any MinGW target.
As an example:
```c
struct field {
unsigned char a : 4;
unsigned int b : 4;
};
int size = sizeof(struct field);
```
```console
$ clang -target x86_64-windows-gnu -S -o - bitfields.c | grep -A1 size
.globl size# @size
.p2align2, 0x0
size:
.long 8 # 0x8
$ clang -target x86_64-windows-gnu -S -o - bitfields.c -mno-ms-bitfields | grep
-A1 size
.globl size# @size
.p2align2, 0x0
size:
.long 4 # 0x4
$ clang -target aarch64-windows-gnu -S -o - bitfields.c | grep -A1 size
.globl size// @size
.p2align2, 0x0
size:
.word 8 // 0x8
$ clang -target aarch64-windows-gnu -S -o - bitfields.c -mno-ms-bitfields |
grep -A1 size
.globl size// @size
.p2align2, 0x0
size:
.word 4 // 0x4
```
---
> https://gitlab.com/qemu-project/qemu/-/issues/1782#note_1495842591 seems like
> ignored `gcc_struct` for windows-gnu targets (feature request #24757).
> I agree that if there are real needs and the needs seem genuine, Clang should
> support `gcc_struct`.
Yes, this would clearly be good to have. For orthogonality, it would be good to
have both `gcc_struct` and `ms_struct` available. GCC does support them on
non-windows targets as well; I think that can be useful for implementing things
like Wine.
---
As noted somewhere (I don't see the comment to quote right now), the MS
bitfield packing logic (as enabled by `-mms-bitfields`) is enabled by default
when using the MSVC C++ ABI, but not when using the Itanium C++ ABI. But as
referenced, since https://reviews.llvm.org/D81795, we do enable the option
`-mms-bitfields` automatically for MinGW targets which otherwise do use the
Itanium C++ ABI. Being able to override this back to the default format for
individual structs would be great.
I don't know and can't speculate about what the implications would be for being
able to switch to GCC struct layout in the MSVC C++ ABI, though. For individual
structs, I guess it should be doable (I'm only thinking for trivial-ish structs
like the one in my example above, right now though). For anything relating to
C++ classes and the mechanisms behind them, I'm pretty sure one doesn't want to
change how anything of that works. Therefore I don't think it's too relevant to
implement `-mno-ms-bitfields` for MSVC targets (as I guess it could open a huge
can of worms).
https://github.com/llvm/llvm-project/pull/71148
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Stub out gcc_struct attribute (PR #71148)
mstorsjo wrote:
> Microsoft bit-field layout didn't break an overly-specific regression test
> but rendered unusable double to string conversion. The culprit was the
> following snippet:
>
> ```c++
> union Extractor {
> double value;
> struct {
> bool sign : 1;
> u32 exponent : 11;
> u64 mantissa : 52;
> };
> };
> ```
>
> According to MSVC ABI, there should be padding between fields. I hope you
> agree that this is not an intuitive and expected behavior.
It is indeed an unexpected thing. However it is possible to work around it for
all these cases; if you declare the inner structure like this:
```
struct {
u64 sign : 1;
u64 exponent : 11;
u64 mantissa : 52;
};
```
Then there will be no extra padding between the fields.
https://github.com/llvm/llvm-project/pull/71148
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Stub out gcc_struct attribute (PR #71148)
mstorsjo wrote: > One more thing. Re binary compatibility concerns: `-mno-ms-bitfields` on > MinGW is an equally-sized footgun as on MSVC. Without proper header > annotation with `#pragma ms_struct on`, either of them will silently make an > ABI mismatch. However, for some reason, supporting `-mno-ms-bitfields` on > MinGW is not argued upon. I guess this is for historical reasons. Originally the MinGW target had this as an opt-in, and this was indeed a silent ABI mismatch. Users who needed to use affected structs and interact with Microsoft APIs had to remember to build their code with `-mms-bitfields` (and hope they don't link in some code that is built without it, with affected structs in their interface). It became the default only by GCC 4.7 (in 2012), and we picked up on this way much later in Clang, in Clang 11 in 2020. https://github.com/llvm/llvm-project/pull/71148 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] Stub out gcc_struct attribute (PR #71148)
mstorsjo wrote:
> Okay, @mstorsjo @MaskRay, what is the way forward?
I'm totally not authoritative for these things, but...
> Am I right that, as for the user-facing changes, `[[gcc_struct]]` cancelling
> implicit `-mms-bitfilds` on MinGW is fine
Sounds quite fine for me
> and silently ignoring `-m{no-}ms-bitfields` on `windows-msvc` is not?
Silently ignoring options is clearly not good IMO, so either we warn about them
or implement them
> Should we (and if yes, when exactly) disallow `-m{no-,}ms-bitfields`? Should
> the aforementioned `--target=x86_64-pc-windows-msvc -fc++-abi=itanium
> -mms-bitfields` be accepted?
FWIW I wasn't even aware that it was possible to pick a nondefault C++ ABI, so
I don't have a strong opinion on this matter. If it works and doesn't create
inconsistencies, then I don't mind, but I guess the regular Clang maintainers
have more of a final say on that.
> Is it fine to provide `[[gcc_struct]]` on MSVC because of the reasons I
> outlined before?
I would be totally fine with that.
https://github.com/llvm/llvm-project/pull/71148
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 71b3ead - [clang][dataflow] Remove a redundant trailing semicolon. NFC.
Author: Martin Storsjö
Date: 2024-01-04T15:01:17+02:00
New Revision: 71b3ead870107e39e998f6480e545eb01d9d28be
URL:
https://github.com/llvm/llvm-project/commit/71b3ead870107e39e998f6480e545eb01d9d28be
DIFF:
https://github.com/llvm/llvm-project/commit/71b3ead870107e39e998f6480e545eb01d9d28be.diff
LOG: [clang][dataflow] Remove a redundant trailing semicolon. NFC.
This silences the following warning with GCC:
llvm-project/llvm/tools/clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp:89:4:
warning: extra ‘;’ [-Wpedantic]
89 | };
|^
|-
Added:
Modified:
clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
Removed:
diff --git
a/clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
b/clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
index 8d481788af208a..fe5ba5ab5426f7 100644
--- a/clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -86,7 +86,7 @@ class DataflowAnalysisTest : public Test {
const std::optional &MaybeState = BlockStates[Block->getBlockID()];
assert(MaybeState.has_value());
return *MaybeState;
- };
+ }
std::unique_ptr AST;
std::unique_ptr CFCtx;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] [MinGW] Don't look for a GCC in path if the install base has a proper mingw sysroot (PR #76949)
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/76949
This fixes uses of the MSYS2 clang64 environment compilers, if another set of
GCC based compilers are available further back in PATH (which may be explicitly
added, or inherited unintentionally from other software installed).
(The issue in the clang64 environment can be worked around somewhat by
installing *-gcc-compat packages which present aliases named -gcc
within the clang64 environment as well.)
This fixes https://github.com/msys2/MINGW-packages/issues/11495 and
https://github.com/msys2/MINGW-packages/issues/19279.
From 355e2530e855249adf9657c58d4e1a6727d969bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Tue, 19 Dec 2023 15:53:21 +0200
Subject: [PATCH] [clang] [MinGW] Don't look for a GCC in path if the install
base has a proper mingw sysroot
This fixes uses of the MSYS2 clang64 environment compilers, if
another set of GCC based compilers are available further back
in PATH (which may be explicitly added, or inherited unintentionally
from other software installed).
(The issue in the clang64 environment can be worked around somewhat
by installing *-gcc-compat packages which present aliases named
-gcc within the clang64 environment as well.)
This fixes https://github.com/msys2/MINGW-packages/issues/11495
and https://github.com/msys2/MINGW-packages/issues/19279.
---
clang/lib/Driver/ToolChains/MinGW.cpp | 19 --
clang/test/Driver/mingw-sysroot.cpp | 28 +++
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/clang/lib/Driver/ToolChains/MinGW.cpp
b/clang/lib/Driver/ToolChains/MinGW.cpp
index 65512f16357d04..3868657659602e 100644
--- a/clang/lib/Driver/ToolChains/MinGW.cpp
+++ b/clang/lib/Driver/ToolChains/MinGW.cpp
@@ -471,12 +471,23 @@ findClangRelativeSysroot(const Driver &D, const
llvm::Triple &LiteralTriple,
return make_error_code(std::errc::no_such_file_or_directory);
}
+static bool looksLikeMinGWSysroot(const std::string &Directory) {
+ StringRef Sep = llvm::sys::path::get_separator();
+ if (!llvm::sys::fs::exists(Directory + Sep + "include" + Sep + "_mingw.h"))
+return false;
+ if (!llvm::sys::fs::exists(Directory + Sep + "lib" + Sep + "libkernel32.a"))
+return false;
+ return true;
+}
+
toolchains::MinGW::MinGW(const Driver &D, const llvm::Triple &Triple,
const ArgList &Args)
: ToolChain(D, Triple, Args), CudaInstallation(D, Triple, Args),
RocmInstallation(D, Triple, Args) {
getProgramPaths().push_back(getDriver().getInstalledDir());
+ std::string InstallBase = std::string(
+llvm::sys::path::parent_path(getDriver().getInstalledDir()));
// The sequence for detecting a sysroot here should be kept in sync with
// the testTriple function below.
llvm::Triple LiteralTriple = getLiteralTriple(D, getTriple());
@@ -487,13 +498,17 @@ toolchains::MinGW::MinGW(const Driver &D, const
llvm::Triple &Triple,
else if (llvm::ErrorOr TargetSubdir = findClangRelativeSysroot(
getDriver(), LiteralTriple, getTriple(), SubdirName))
Base = std::string(llvm::sys::path::parent_path(TargetSubdir.get()));
+ // If the install base of Clang seems to have mingw sysroot files directly
+ // in the toplevel include and lib directories, use this as base instead of
+ // looking for a triple prefixed GCC in the path.
+ else if (looksLikeMinGWSysroot(InstallBase))
+Base = InstallBase;
else if (llvm::ErrorOr GPPName =
findGcc(LiteralTriple, getTriple()))
Base = std::string(llvm::sys::path::parent_path(
llvm::sys::path::parent_path(GPPName.get(;
else
-Base = std::string(
-llvm::sys::path::parent_path(getDriver().getInstalledDir()));
+Base = InstallBase;
Base += llvm::sys::path::get_separator();
findGccLibDir(LiteralTriple);
diff --git a/clang/test/Driver/mingw-sysroot.cpp
b/clang/test/Driver/mingw-sysroot.cpp
index 911dab4927073d..50152b2ca210d2 100644
--- a/clang/test/Driver/mingw-sysroot.cpp
+++ b/clang/test/Driver/mingw-sysroot.cpp
@@ -14,6 +14,12 @@
// RUN: ln -s %S/Inputs/mingw_ubuntu_posix_tree/usr/x86_64-w64-mingw32
%T/testroot-clang/x86_64-w64-mingw32
// RUN: ln -s %S/Inputs/mingw_arch_tree/usr/i686-w64-mingw32
%T/testroot-clang/i686-w64-mingw32
+// RUN: rm -rf %T/testroot-clang-native
+// RUN: mkdir -p %T/testroot-clang-native/bin
+// RUN: ln -s %clang %T/testroot-clang-native/bin/clang
+// RUN: mkdir -p %T/testroot-clang-native/include/_mingw.h
+// RUN: mkdir -p %T/testroot-clang-native/lib/libkernel32.a
+
// RUN: rm -rf %T/testroot-custom-triple
// RUN: mkdir -p %T/testroot-custom-triple/bin
// RUN: ln -s %clang %T/testroot-custom-triple/bin/clang
@@ -58,6 +64,28 @@
// RUN: env "PATH=%T/testroot-gcc/bin:%PATH%"
%T/testroot-gcc/bin/x86_64-w64-mingw32-clang -target x86_64-w64-mingw32
-rtlib=platform -stdlib=libstdc++ --sysroot="" -c -### %s 2>&1 | FileCheck
-chec
[clang] [clang] [MinGW] Don't look for a GCC in path if the install base has a proper mingw sysroot (PR #76949)
mstorsjo wrote: CC @mati865 @jeremyd2019 @huangqinjin https://github.com/llvm/llvm-project/pull/76949 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] [MinGW] Don't look for a GCC in path if the install base has a proper mingw sysroot (PR #76949)
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/76949
From c67187043168b79e57c0e4f3261293d799852e90 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Tue, 19 Dec 2023 15:53:21 +0200
Subject: [PATCH] [clang] [MinGW] Don't look for a GCC in path if the install
base has a proper mingw sysroot
This fixes uses of the MSYS2 clang64 environment compilers, if
another set of GCC based compilers are available further back
in PATH (which may be explicitly added, or inherited unintentionally
from other software installed).
(The issue in the clang64 environment can be worked around somewhat
by installing *-gcc-compat packages which present aliases named
-gcc within the clang64 environment as well.)
This fixes https://github.com/msys2/MINGW-packages/issues/11495
and https://github.com/msys2/MINGW-packages/issues/19279.
---
clang/lib/Driver/ToolChains/MinGW.cpp | 19 --
clang/test/Driver/mingw-sysroot.cpp | 28 +++
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/clang/lib/Driver/ToolChains/MinGW.cpp
b/clang/lib/Driver/ToolChains/MinGW.cpp
index 65512f16357d04..e2965a08a0b9a2 100644
--- a/clang/lib/Driver/ToolChains/MinGW.cpp
+++ b/clang/lib/Driver/ToolChains/MinGW.cpp
@@ -471,12 +471,23 @@ findClangRelativeSysroot(const Driver &D, const
llvm::Triple &LiteralTriple,
return make_error_code(std::errc::no_such_file_or_directory);
}
+static bool looksLikeMinGWSysroot(const std::string &Directory) {
+ StringRef Sep = llvm::sys::path::get_separator();
+ if (!llvm::sys::fs::exists(Directory + Sep + "include" + Sep + "_mingw.h"))
+return false;
+ if (!llvm::sys::fs::exists(Directory + Sep + "lib" + Sep + "libkernel32.a"))
+return false;
+ return true;
+}
+
toolchains::MinGW::MinGW(const Driver &D, const llvm::Triple &Triple,
const ArgList &Args)
: ToolChain(D, Triple, Args), CudaInstallation(D, Triple, Args),
RocmInstallation(D, Triple, Args) {
getProgramPaths().push_back(getDriver().getInstalledDir());
+ std::string InstallBase =
+ std::string(llvm::sys::path::parent_path(getDriver().getInstalledDir()));
// The sequence for detecting a sysroot here should be kept in sync with
// the testTriple function below.
llvm::Triple LiteralTriple = getLiteralTriple(D, getTriple());
@@ -487,13 +498,17 @@ toolchains::MinGW::MinGW(const Driver &D, const
llvm::Triple &Triple,
else if (llvm::ErrorOr TargetSubdir = findClangRelativeSysroot(
getDriver(), LiteralTriple, getTriple(), SubdirName))
Base = std::string(llvm::sys::path::parent_path(TargetSubdir.get()));
+ // If the install base of Clang seems to have mingw sysroot files directly
+ // in the toplevel include and lib directories, use this as base instead of
+ // looking for a triple prefixed GCC in the path.
+ else if (looksLikeMinGWSysroot(InstallBase))
+Base = InstallBase;
else if (llvm::ErrorOr GPPName =
findGcc(LiteralTriple, getTriple()))
Base = std::string(llvm::sys::path::parent_path(
llvm::sys::path::parent_path(GPPName.get(;
else
-Base = std::string(
-llvm::sys::path::parent_path(getDriver().getInstalledDir()));
+Base = InstallBase;
Base += llvm::sys::path::get_separator();
findGccLibDir(LiteralTriple);
diff --git a/clang/test/Driver/mingw-sysroot.cpp
b/clang/test/Driver/mingw-sysroot.cpp
index 911dab4927073d..50152b2ca210d2 100644
--- a/clang/test/Driver/mingw-sysroot.cpp
+++ b/clang/test/Driver/mingw-sysroot.cpp
@@ -14,6 +14,12 @@
// RUN: ln -s %S/Inputs/mingw_ubuntu_posix_tree/usr/x86_64-w64-mingw32
%T/testroot-clang/x86_64-w64-mingw32
// RUN: ln -s %S/Inputs/mingw_arch_tree/usr/i686-w64-mingw32
%T/testroot-clang/i686-w64-mingw32
+// RUN: rm -rf %T/testroot-clang-native
+// RUN: mkdir -p %T/testroot-clang-native/bin
+// RUN: ln -s %clang %T/testroot-clang-native/bin/clang
+// RUN: mkdir -p %T/testroot-clang-native/include/_mingw.h
+// RUN: mkdir -p %T/testroot-clang-native/lib/libkernel32.a
+
// RUN: rm -rf %T/testroot-custom-triple
// RUN: mkdir -p %T/testroot-custom-triple/bin
// RUN: ln -s %clang %T/testroot-custom-triple/bin/clang
@@ -58,6 +64,28 @@
// RUN: env "PATH=%T/testroot-gcc/bin:%PATH%"
%T/testroot-gcc/bin/x86_64-w64-mingw32-clang -target x86_64-w64-mingw32
-rtlib=platform -stdlib=libstdc++ --sysroot="" -c -### %s 2>&1 | FileCheck
-check-prefix=CHECK_TESTROOT_GCC %s
+// If we're executing clang from a directory with what looks like a mingw
sysroot,
+// with headers in /include and libs in /lib, use that rather than
looking
+// for another GCC in the path.
+//
+// Note, this test has a surprising quirk: We're testing with an install
directory,
+// testroot-clang-native, which lacks the "x86_64-w64-mingw32" subdirectory,
it only
+// has the include and lib subdirectories without any triple prefix.
+//
+// Since commit fd15cb935d7aae25ad62bfe06fe9f17cea58597
[clang] [clang] [MinGW] Don't look for a GCC in path if the install base has a proper mingw sysroot (PR #76949)
mstorsjo wrote: > > Looks mostly good to me, but I wonder if we should change testTriple as > > well. > > I thought so too based on the comment, but reviewing the code it seems > `testTriple` is trying to find evidence that a given triple (and more > specifically arch for things like `i386` vs `i686`) is valid. The evidence > found by `looksLikeMinGWSysroot` does not provide any hint about what the > triple or arch name should be, so I don't think it helps `testTriple`. Thanks, this explanation is absolutely spot on. (In all honesty, I had forgot about `testTriple` when I wrote this patch - and despite the comment right next to the code I touched, I didn't remember to check it...) Although, on a second thought, it might actually still be good to adjust it in sync. If we're invoking Clang with `-m32` and deciding on whether to use i386/i586/i686, and we end up using the install base as sysroot, without inferring any triple from there, we shouldn't go on and check another unrelated GCC in path in order to influence this. Therefore, I think we perhaps should amend this with the following: ```diff diff --git a/clang/lib/Driver/ToolChains/MinGW.cpp b/clang/lib/Driver/ToolChains/MinGW.cpp index e2965a08a0b9..18fc9d4b6807 100644 --- a/clang/lib/Driver/ToolChains/MinGW.cpp +++ b/clang/lib/Driver/ToolChains/MinGW.cpp @@ -793,9 +793,15 @@ static bool testTriple(const Driver &D, const llvm::Triple &Triple, if (D.SysRoot.size()) return true; llvm::Triple LiteralTriple = getLiteralTriple(D, Triple); + std::string InstallBase = + std::string(llvm::sys::path::parent_path(D.getInstalledDir())); if (llvm::ErrorOr TargetSubdir = findClangRelativeSysroot(D, LiteralTriple, Triple, SubdirName)) return true; + // If the install base itself looks like a mingw sysroot, we'll use that + // - don't use any potentially unrelated gcc to influence what triple to use. + if (looksLikeMinGWSysroot(InstallBase)) +return false; if (llvm::ErrorOr GPPName = findGcc(LiteralTriple, Triple)) return true; // If we neither found a colocated sysroot or a matching gcc executable, ``` Actually, for such cases, we could potentially check for the per-target runtime installs, e.g. looking for `/include/` or `/lib/`. Switching between multiple arches with e.g. `-m32` in such a setup could work, if all the arch specific files are in `/lib/`, but I'm not sure if anyone does full mingw setups with such a hierarchy (yet). So this would be a separate potential future step. https://github.com/llvm/llvm-project/pull/76949 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] [MinGW] Don't look for a GCC in path if the install base has a proper mingw sysroot (PR #76949)
https://github.com/mstorsjo updated
https://github.com/llvm/llvm-project/pull/76949
From ce2a49c1a052b30fb1df91f3a7293e89e0a8726d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Tue, 19 Dec 2023 15:53:21 +0200
Subject: [PATCH] [clang] [MinGW] Don't look for a GCC in path if the install
base has a proper mingw sysroot
This fixes uses of the MSYS2 clang64 environment compilers, if
another set of GCC based compilers are available further back
in PATH (which may be explicitly added, or inherited unintentionally
from other software installed).
(The issue in the clang64 environment can be worked around somewhat
by installing *-gcc-compat packages which present aliases named
-gcc within the clang64 environment as well.)
This fixes https://github.com/msys2/MINGW-packages/issues/11495
and https://github.com/msys2/MINGW-packages/issues/19279.
---
clang/lib/Driver/ToolChains/MinGW.cpp | 25 ++--
clang/test/Driver/mingw-sysroot.cpp | 28 +++
2 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/clang/lib/Driver/ToolChains/MinGW.cpp
b/clang/lib/Driver/ToolChains/MinGW.cpp
index 65512f16357d04..18fc9d4b6807e3 100644
--- a/clang/lib/Driver/ToolChains/MinGW.cpp
+++ b/clang/lib/Driver/ToolChains/MinGW.cpp
@@ -471,12 +471,23 @@ findClangRelativeSysroot(const Driver &D, const
llvm::Triple &LiteralTriple,
return make_error_code(std::errc::no_such_file_or_directory);
}
+static bool looksLikeMinGWSysroot(const std::string &Directory) {
+ StringRef Sep = llvm::sys::path::get_separator();
+ if (!llvm::sys::fs::exists(Directory + Sep + "include" + Sep + "_mingw.h"))
+return false;
+ if (!llvm::sys::fs::exists(Directory + Sep + "lib" + Sep + "libkernel32.a"))
+return false;
+ return true;
+}
+
toolchains::MinGW::MinGW(const Driver &D, const llvm::Triple &Triple,
const ArgList &Args)
: ToolChain(D, Triple, Args), CudaInstallation(D, Triple, Args),
RocmInstallation(D, Triple, Args) {
getProgramPaths().push_back(getDriver().getInstalledDir());
+ std::string InstallBase =
+ std::string(llvm::sys::path::parent_path(getDriver().getInstalledDir()));
// The sequence for detecting a sysroot here should be kept in sync with
// the testTriple function below.
llvm::Triple LiteralTriple = getLiteralTriple(D, getTriple());
@@ -487,13 +498,17 @@ toolchains::MinGW::MinGW(const Driver &D, const
llvm::Triple &Triple,
else if (llvm::ErrorOr TargetSubdir = findClangRelativeSysroot(
getDriver(), LiteralTriple, getTriple(), SubdirName))
Base = std::string(llvm::sys::path::parent_path(TargetSubdir.get()));
+ // If the install base of Clang seems to have mingw sysroot files directly
+ // in the toplevel include and lib directories, use this as base instead of
+ // looking for a triple prefixed GCC in the path.
+ else if (looksLikeMinGWSysroot(InstallBase))
+Base = InstallBase;
else if (llvm::ErrorOr GPPName =
findGcc(LiteralTriple, getTriple()))
Base = std::string(llvm::sys::path::parent_path(
llvm::sys::path::parent_path(GPPName.get(;
else
-Base = std::string(
-llvm::sys::path::parent_path(getDriver().getInstalledDir()));
+Base = InstallBase;
Base += llvm::sys::path::get_separator();
findGccLibDir(LiteralTriple);
@@ -778,9 +793,15 @@ static bool testTriple(const Driver &D, const llvm::Triple
&Triple,
if (D.SysRoot.size())
return true;
llvm::Triple LiteralTriple = getLiteralTriple(D, Triple);
+ std::string InstallBase =
+ std::string(llvm::sys::path::parent_path(D.getInstalledDir()));
if (llvm::ErrorOr TargetSubdir =
findClangRelativeSysroot(D, LiteralTriple, Triple, SubdirName))
return true;
+ // If the install base itself looks like a mingw sysroot, we'll use that
+ // - don't use any potentially unrelated gcc to influence what triple to use.
+ if (looksLikeMinGWSysroot(InstallBase))
+return false;
if (llvm::ErrorOr GPPName = findGcc(LiteralTriple, Triple))
return true;
// If we neither found a colocated sysroot or a matching gcc executable,
diff --git a/clang/test/Driver/mingw-sysroot.cpp
b/clang/test/Driver/mingw-sysroot.cpp
index 911dab4927073d..50152b2ca210d2 100644
--- a/clang/test/Driver/mingw-sysroot.cpp
+++ b/clang/test/Driver/mingw-sysroot.cpp
@@ -14,6 +14,12 @@
// RUN: ln -s %S/Inputs/mingw_ubuntu_posix_tree/usr/x86_64-w64-mingw32
%T/testroot-clang/x86_64-w64-mingw32
// RUN: ln -s %S/Inputs/mingw_arch_tree/usr/i686-w64-mingw32
%T/testroot-clang/i686-w64-mingw32
+// RUN: rm -rf %T/testroot-clang-native
+// RUN: mkdir -p %T/testroot-clang-native/bin
+// RUN: ln -s %clang %T/testroot-clang-native/bin/clang
+// RUN: mkdir -p %T/testroot-clang-native/include/_mingw.h
+// RUN: mkdir -p %T/testroot-clang-native/lib/libkernel32.a
+
// RUN: rm -rf %T/testroot-custom-triple
// RUN: mkdir -p %T/testroot-custom-triple/bin
// RUN: ln
[clang] [clang] [MinGW] Don't look for a GCC in path if the install base has a proper mingw sysroot (PR #76949)
mstorsjo wrote: > > Although, on a second thought, it might actually still be good to adjust it > > in sync. If we're invoking Clang with `-m32` and deciding on whether to use > > i386/i586/i686, and we end up using the install base as sysroot, without > > inferring any triple from there, we shouldn't go on and check another > > unrelated GCC in path in order to influence this. Therefore, I think we > > perhaps should amend this with the following: > > Yes, I think that it would be better to avoid any decisions based on an > unrelated GCC and the additional check looks good to me. Ok, updated the PR with the patch that way; will merge it sometime later if nobody has any further objections to this. https://github.com/llvm/llvm-project/pull/76949 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] [MinGW] Don't look for a GCC in path if the install base has a proper mingw sysroot (PR #76949)
https://github.com/mstorsjo closed https://github.com/llvm/llvm-project/pull/76949 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [libunwind] Convert a few options from CACHE PATH to CACHE STRING (PR #77534)
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/77534
This applies the same change as in
760261a3daf98882ccbd177e3133fb4a058f47ad (where they were applied to libcxxabi
and libcxx) to libunwind as well.
These options can reasonably be set either as an absolute or relative path, but
if set as type PATH, they are rewritten from relative into absolute relative to
the build directory, while the relative form is intended to be relative to the
install prefix.
From f4d654ff157f7a1ae3237d22dbbc541e6c083c4f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Mon, 8 Jan 2024 14:32:47 +0200
Subject: [PATCH] [libunwind] Convert a few options from CACHE PATH to CACHE
STRING
This applies the same change as in
760261a3daf98882ccbd177e3133fb4a058f47ad (where they were applied
to libcxxabi and libcxx) to libunwind as well.
These options can reasonably be set either as an absolute or
relative path, but if set as type PATH, they are rewritten from
relative into absolute relative to the build directory, while
the relative form is intended to be relative to the install prefix.
---
libunwind/CMakeLists.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libunwind/CMakeLists.txt b/libunwind/CMakeLists.txt
index 248e888619e40b..bb1b052f61d875 100644
--- a/libunwind/CMakeLists.txt
+++ b/libunwind/CMakeLists.txt
@@ -105,9 +105,9 @@ set(CMAKE_MODULE_PATH
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
${CMAKE_MODULE_PATH})
-set(LIBUNWIND_INSTALL_INCLUDE_DIR "${CMAKE_INSTALL_INCLUDEDIR}" CACHE PATH
+set(LIBUNWIND_INSTALL_INCLUDE_DIR "${CMAKE_INSTALL_INCLUDEDIR}" CACHE STRING
"Path where built libunwind headers should be installed.")
-set(LIBUNWIND_INSTALL_RUNTIME_DIR "${CMAKE_INSTALL_BINDIR}" CACHE PATH
+set(LIBUNWIND_INSTALL_RUNTIME_DIR "${CMAKE_INSTALL_BINDIR}" CACHE STRING
"Path where built libunwind runtime libraries should be installed.")
set(LIBUNWIND_SHARED_OUTPUT_NAME "unwind" CACHE STRING "Output name for the
shared libunwind runtime library.")
@@ -115,7 +115,7 @@ set(LIBUNWIND_STATIC_OUTPUT_NAME "unwind" CACHE STRING
"Output name for the stat
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
set(LIBUNWIND_LIBRARY_DIR
${LLVM_LIBRARY_OUTPUT_INTDIR}/${LLVM_DEFAULT_TARGET_TRIPLE})
- set(LIBUNWIND_INSTALL_LIBRARY_DIR
lib${LLVM_LIBDIR_SUFFIX}/${LLVM_DEFAULT_TARGET_TRIPLE} CACHE PATH
+ set(LIBUNWIND_INSTALL_LIBRARY_DIR
lib${LLVM_LIBDIR_SUFFIX}/${LLVM_DEFAULT_TARGET_TRIPLE} CACHE STRING
"Path where built libunwind libraries should be installed.")
if(LIBCXX_LIBDIR_SUBDIR)
string(APPEND LIBUNWIND_LIBRARY_DIR /${LIBUNWIND_LIBDIR_SUBDIR})
@@ -127,7 +127,7 @@ else()
else()
set(LIBUNWIND_LIBRARY_DIR
${CMAKE_BINARY_DIR}/lib${LIBUNWIND_LIBDIR_SUFFIX})
endif()
- set(LIBUNWIND_INSTALL_LIBRARY_DIR lib${LIBUNWIND_LIBDIR_SUFFIX} CACHE PATH
+ set(LIBUNWIND_INSTALL_LIBRARY_DIR lib${LIBUNWIND_LIBDIR_SUFFIX} CACHE STRING
"Path where built libunwind libraries should be installed.")
endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] [Driver] Treat MuslEABIHF as a hardfloat environment wrt multiarch directories (PR #77536)
https://github.com/mstorsjo created
https://github.com/llvm/llvm-project/pull/77536
If using multiarch directories with musl, the multiarch directory still uses
*-linux-gnu triples - which may or may not be intentional, while it is somewhat
consistent at least.
However, for musl armhf targets, make sure that this also picks
arm-linux-gnueabihf, rather than arm-linux-gnueabi.
From f715cfc716e5a4bacdc0ef041f6a53c6821e81cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Martin=20Storsj=C3=B6?=
Date: Mon, 8 Jan 2024 12:35:36 +0200
Subject: [PATCH] [clang] [Driver] Treat MuslEABIHF as a hardfloat environment
wrt multiarch directories
If using multiarch directories with musl, the multiarch directory
still uses *-linux-gnu triples - which may or may not be intentional,
while it is somewhat consistent at least.
However, for musl armhf targets, make sure that this also picks
arm-linux-gnueabihf, rather than arm-linux-gnueabi.
---
clang/lib/Driver/ToolChains/Gnu.cpp | 8 ++--
clang/lib/Driver/ToolChains/Linux.cpp | 8 ++--
clang/test/Driver/linux-ld.c | 9 +
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/clang/lib/Driver/ToolChains/Gnu.cpp
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 24681dfdc99c03..771240dac7a83e 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2668,7 +2668,9 @@ void
Generic_GCC::GCCInstallationDetector::AddDefaultGCCPrefixes(
case llvm::Triple::arm:
case llvm::Triple::thumb:
LibDirs.append(begin(ARMLibDirs), end(ARMLibDirs));
-if (TargetTriple.getEnvironment() == llvm::Triple::GNUEABIHF) {
+if (TargetTriple.getEnvironment() == llvm::Triple::GNUEABIHF ||
+TargetTriple.getEnvironment() == llvm::Triple::MuslEABIHF ||
+TargetTriple.getEnvironment() == llvm::Triple::EABIHF) {
TripleAliases.append(begin(ARMHFTriples), end(ARMHFTriples));
} else {
TripleAliases.append(begin(ARMTriples), end(ARMTriples));
@@ -2677,7 +2679,9 @@ void
Generic_GCC::GCCInstallationDetector::AddDefaultGCCPrefixes(
case llvm::Triple::armeb:
case llvm::Triple::thumbeb:
LibDirs.append(begin(ARMebLibDirs), end(ARMebLibDirs));
-if (TargetTriple.getEnvironment() == llvm::Triple::GNUEABIHF) {
+if (TargetTriple.getEnvironment() == llvm::Triple::GNUEABIHF ||
+TargetTriple.getEnvironment() == llvm::Triple::MuslEABIHF ||
+TargetTriple.getEnvironment() == llvm::Triple::EABIHF) {
TripleAliases.append(begin(ARMebHFTriples), end(ARMebHFTriples));
} else {
TripleAliases.append(begin(ARMebTriples), end(ARMebTriples));
diff --git a/clang/lib/Driver/ToolChains/Linux.cpp
b/clang/lib/Driver/ToolChains/Linux.cpp
index 735af54f114cef..4300a2bdff1791 100644
--- a/clang/lib/Driver/ToolChains/Linux.cpp
+++ b/clang/lib/Driver/ToolChains/Linux.cpp
@@ -61,12 +61,16 @@ std::string Linux::getMultiarchTriple(const Driver &D,
case llvm::Triple::thumb:
if (IsAndroid)
return "arm-linux-androideabi";
-if (TargetEnvironment == llvm::Triple::GNUEABIHF)
+if (TargetEnvironment == llvm::Triple::GNUEABIHF ||
+TargetEnvironment == llvm::Triple::MuslEABIHF ||
+TargetEnvironment == llvm::Triple::EABIHF)
return "arm-linux-gnueabihf";
return "arm-linux-gnueabi";
case llvm::Triple::armeb:
case llvm::Triple::thumbeb:
-if (TargetEnvironment == llvm::Triple::GNUEABIHF)
+if (TargetEnvironment == llvm::Triple::GNUEABIHF ||
+TargetEnvironment == llvm::Triple::MuslEABIHF ||
+TargetEnvironment == llvm::Triple::EABIHF)
return "armeb-linux-gnueabihf";
return "armeb-linux-gnueabi";
case llvm::Triple::x86:
diff --git a/clang/test/Driver/linux-ld.c b/clang/test/Driver/linux-ld.c
index 15643d6491ae52..d5cc3103a3a746 100644
--- a/clang/test/Driver/linux-ld.c
+++ b/clang/test/Driver/linux-ld.c
@@ -541,6 +541,15 @@
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/ubuntu_12.04_LTS_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-12-04-ARM-HF %s
+//
+// Check that musleabihf is treated as a hardfloat config, with respect to
+// multiarch directories.
+//
+// RUN: %clang -### %s -no-pie 2>&1 \
+// RUN: --target=arm-unknown-linux-musleabihf -rtlib=platform
--unwindlib=platform \
+// RUN: --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/ubuntu_12.04_LTS_multiarch_tree \
+// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-12-04-ARM-HF %s
// CHECK-UBUNTU-12-04-ARM-HF: "{{.*}}ld{{(.exe)?}}"
"--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-UBUNTU-12-04-ARM-HF:
"{{.*}}/usr/lib/arm-linux-gnueabihf{{/|}}crt1.o"
// CHECK-UBUNTU-12-04-ARM-HF:
"{{.*}}/usr/lib/arm-linux-gnueabihf{{/|}}crti.o"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] [libunwind] Convert a few options from CACHE PATH to CACHE STRING (PR #77534)
https://github.com/mstorsjo closed https://github.com/llvm/llvm-project/pull/77534 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] [Driver] Treat MuslEABIHF as a hardfloat environment wrt multiarch directories (PR #77536)
mstorsjo wrote: > `bool isEABIHF` from clang/lib/CodeGen/Targets/ARM.cpp can probably be > factored. Yep - any suggestion on where we could move it? Up to the `Triple` class? https://github.com/llvm/llvm-project/pull/77536 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] [Driver] Treat MuslEABIHF as a hardfloat environment wrt multiarch directories (PR #77536)
https://github.com/mstorsjo closed https://github.com/llvm/llvm-project/pull/77536 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] 8e21802 - [clang] [MinGW] Fix paths on Gentoo
Author: Mark Harmstone
Date: 2022-07-08T00:37:08+03:00
New Revision: 8e218026f8d5eabfdef9141ae5e26aa91d1933e6
URL:
https://github.com/llvm/llvm-project/commit/8e218026f8d5eabfdef9141ae5e26aa91d1933e6
DIFF:
https://github.com/llvm/llvm-project/commit/8e218026f8d5eabfdef9141ae5e26aa91d1933e6.diff
LOG: [clang] [MinGW] Fix paths on Gentoo
There's code in clang/lib/Driver/ToolChains/Gnu.cpp for Clang to use Gentoo's
include and lib paths, but this is missing for mingw, meaning that any C++
programs using the STL will fail to compile.
See https://bugs.gentoo.org/788430
Differential Revision: https://reviews.llvm.org/D111081
Added:
Modified:
clang/lib/Driver/ToolChains/MinGW.cpp
clang/lib/Driver/ToolChains/MinGW.h
clang/test/Driver/mingw-sysroot.cpp
clang/test/Driver/mingw.cpp
Removed:
diff --git a/clang/lib/Driver/ToolChains/MinGW.cpp
b/clang/lib/Driver/ToolChains/MinGW.cpp
index c4b4f8e9b89bb..ae7c4c56bf9e7 100644
--- a/clang/lib/Driver/ToolChains/MinGW.cpp
+++ b/clang/lib/Driver/ToolChains/MinGW.cpp
@@ -339,8 +339,9 @@ void tools::MinGW::Linker::ConstructJob(Compilation &C,
const JobAction &JA,
// Simplified from
Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple.
static bool findGccVersion(StringRef LibDir, std::string &GccLibDir,
- std::string &Ver) {
- auto Version = toolchains::Generic_GCC::GCCVersion::Parse("0.0.0");
+ std::string &Ver,
+ toolchains::Generic_GCC::GCCVersion &Version) {
+ Version = toolchains::Generic_GCC::GCCVersion::Parse("0.0.0");
std::error_code EC;
for (llvm::sys::fs::directory_iterator LI(LibDir, EC), LE; !EC && LI != LE;
LI = LI.increment(EC)) {
@@ -371,7 +372,7 @@ void toolchains::MinGW::findGccLibDir() {
for (StringRef CandidateSysroot : SubdirNames) {
llvm::SmallString<1024> LibDir(Base);
llvm::sys::path::append(LibDir, CandidateLib, "gcc", CandidateSysroot);
- if (findGccVersion(LibDir, GccLibDir, Ver)) {
+ if (findGccVersion(LibDir, GccLibDir, Ver, GccVer)) {
SubdirName = std::string(CandidateSysroot);
return;
}
@@ -438,6 +439,11 @@ toolchains::MinGW::MinGW(const Driver &D, const
llvm::Triple &Triple,
getFilePaths().push_back(GccLibDir);
getFilePaths().push_back(
(Base + SubdirName + llvm::sys::path::get_separator() + "lib").str());
+
+ // Gentoo
+ getFilePaths().push_back(
+ (Base + SubdirName + llvm::sys::path::get_separator() +
"mingw/lib").str());
+
getFilePaths().push_back(Base + "lib");
// openSUSE
getFilePaths().push_back(Base + SubdirName + "/sys-root/mingw/lib");
@@ -593,6 +599,11 @@ void toolchains::MinGW::AddClangSystemIncludeArgs(const
ArgList &DriverArgs,
addSystemInclude(DriverArgs, CC1Args,
Base + SubdirName + llvm::sys::path::get_separator() +
"include");
+
+ // Gentoo
+ addSystemInclude(DriverArgs, CC1Args,
+ Base + SubdirName + llvm::sys::path::get_separator() +
"usr/include");
+
addSystemInclude(DriverArgs, CC1Args, Base + "include");
}
@@ -620,7 +631,7 @@ void toolchains::MinGW::AddClangCXXStdlibIncludeArgs(
}
case ToolChain::CST_Libstdcxx:
-llvm::SmallVector, 4> CppIncludeBases;
+llvm::SmallVector, 7> CppIncludeBases;
CppIncludeBases.emplace_back(Base);
llvm::sys::path::append(CppIncludeBases[0], SubdirName, "include", "c++");
CppIncludeBases.emplace_back(Base);
@@ -630,6 +641,15 @@ void toolchains::MinGW::AddClangCXXStdlibIncludeArgs(
llvm::sys::path::append(CppIncludeBases[2], "include", "c++", Ver);
CppIncludeBases.emplace_back(GccLibDir);
llvm::sys::path::append(CppIncludeBases[3], "include", "c++");
+CppIncludeBases.emplace_back(GccLibDir);
+llvm::sys::path::append(CppIncludeBases[4], "include",
+"g++-v" + GccVer.Text);
+CppIncludeBases.emplace_back(GccLibDir);
+llvm::sys::path::append(CppIncludeBases[5], "include",
+"g++-v" + GccVer.MajorStr + "." + GccVer.MinorStr);
+CppIncludeBases.emplace_back(GccLibDir);
+llvm::sys::path::append(CppIncludeBases[6], "include",
+"g++-v" + GccVer.MajorStr);
for (auto &CppIncludeBase : CppIncludeBases) {
addSystemInclude(DriverArgs, CC1Args, CppIncludeBase);
CppIncludeBase += Slash;
diff --git a/clang/lib/Driver/ToolChains/MinGW.h
b/clang/lib/Driver/ToolChains/MinGW.h
index c9553b4f46520..f15f99dc8a8c0 100644
--- a/clang/lib/Driver/ToolChains/MinGW.h
+++ b/clang/lib/Driver/ToolChains/MinGW.h
@@ -103,6 +103,7 @@ class LLVM_LIBRARY_VISIBILITY MinGW : public ToolChain {
std::string Base;
std::string GccLibDir;
+ clang::driver::toolchains::Generic_GCC::GCCVersion GccVer;
std::string Ver;
std::string SubdirName;
mutable std::unique_ptr Preproc
[clang] b069801 - [clang] [Serialization] Fix swapped PPOpts/ExistingPPOpts parameters. NFC.
Author: Martin Storsjö
Date: 2022-07-09T00:11:45+03:00
New Revision: b069801ffb6d11143c2b611a220827120113c7a1
URL:
https://github.com/llvm/llvm-project/commit/b069801ffb6d11143c2b611a220827120113c7a1
DIFF:
https://github.com/llvm/llvm-project/commit/b069801ffb6d11143c2b611a220827120113c7a1.diff
LOG: [clang] [Serialization] Fix swapped PPOpts/ExistingPPOpts parameters. NFC.
The two first parameters of checkPreprocessorOptions are "PPOpts,
ExistingPPOpts".
All other callers of the function pass them consistently.
This avoids confusion when working on the code.
Differential Revision: https://reviews.llvm.org/D129277
Added:
Modified:
clang/lib/Serialization/ASTReader.cpp
Removed:
diff --git a/clang/lib/Serialization/ASTReader.cpp
b/clang/lib/Serialization/ASTReader.cpp
index 096f4a5514b17..bb98660717e70 100644
--- a/clang/lib/Serialization/ASTReader.cpp
+++ b/clang/lib/Serialization/ASTReader.cpp
@@ -5171,8 +5171,9 @@ namespace {
bool ReadPreprocessorOptions(const PreprocessorOptions &PPOpts,
bool Complain,
std::string &SuggestedPredefines) override {
- return checkPreprocessorOptions(ExistingPPOpts, PPOpts, nullptr, FileMgr,
- SuggestedPredefines, ExistingLangOpts);
+ return checkPreprocessorOptions(PPOpts, ExistingPPOpts,
/*Diags=*/nullptr,
+ FileMgr, SuggestedPredefines,
+ ExistingLangOpts);
}
};
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] 9a3eeae - [clang-tidy] Fix the condition for building CTTestTidyModule
Author: Martin Storsjö
Date: 2022-03-25T21:22:46+02:00
New Revision: 9a3eeae3218f0f8a082d8aabdf4f26e30a86170d
URL:
https://github.com/llvm/llvm-project/commit/9a3eeae3218f0f8a082d8aabdf4f26e30a86170d
DIFF:
https://github.com/llvm/llvm-project/commit/9a3eeae3218f0f8a082d8aabdf4f26e30a86170d.diff
LOG: [clang-tidy] Fix the condition for building CTTestTidyModule
This is the correct intended condition; the problematic case where
we don't want to try to build the plugin is "WIN32 AND LLVM_LINK_LLVM_DYLIB"
and thus the negation is "NOT WIN32 OR NOT LLVM_LINK_LLVM_DYLIB".
Differential Revision: https://reviews.llvm.org/D121687
Added:
Modified:
clang-tools-extra/test/CMakeLists.txt
Removed:
diff --git a/clang-tools-extra/test/CMakeLists.txt
b/clang-tools-extra/test/CMakeLists.txt
index d64366cba2328..2cdf186081efc 100644
--- a/clang-tools-extra/test/CMakeLists.txt
+++ b/clang-tools-extra/test/CMakeLists.txt
@@ -73,7 +73,7 @@ foreach(dep ${LLVM_UTILS_DEPS})
endforeach()
if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
- if (NOT WIN32 AND NOT LLVM_LINK_LLVM_DYLIB)
+ if (NOT WIN32 OR NOT LLVM_LINK_LLVM_DYLIB)
llvm_add_library(
CTTestTidyModule
MODULE clang-tidy/CTTestTidyModule.cpp
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] 18b4a8b - [clang-tidy] Rename the make-confusable-table executable
Author: Martin Storsjö
Date: 2022-07-28T12:00:20+03:00
New Revision: 18b4a8bcf3553174f770f09528c9bd01c8cebfe7
URL:
https://github.com/llvm/llvm-project/commit/18b4a8bcf3553174f770f09528c9bd01c8cebfe7
DIFF:
https://github.com/llvm/llvm-project/commit/18b4a8bcf3553174f770f09528c9bd01c8cebfe7.diff
LOG: [clang-tidy] Rename the make-confusable-table executable
Rename it to clang-tidy-confusable-chars-gen, to make its role
clearer in a wider context.
In cross builds, the caller might want to provide this tool
externally (to avoid needing to rebuild it in the cross build).
In such a case, having the tool properly namespaced makes its role
clearer.
This matches how the clang-pseudo-gen tool was renamed in
a43fef05d4fae32f02365c7b8fef2aa631d23628 / D126725.
Differential Revision: https://reviews.llvm.org/D129798
Added:
Modified:
clang-tools-extra/clang-tidy/misc/CMakeLists.txt
clang-tools-extra/clang-tidy/misc/ConfusableTable/CMakeLists.txt
llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/ConfusableTable/BUILD.gn
Removed:
diff --git a/clang-tools-extra/clang-tidy/misc/CMakeLists.txt
b/clang-tools-extra/clang-tidy/misc/CMakeLists.txt
index 04172db29ea5e..ee8fe0b37fce9 100644
--- a/clang-tools-extra/clang-tidy/misc/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/misc/CMakeLists.txt
@@ -4,11 +4,11 @@ set(LLVM_LINK_COMPONENTS
)
if(LLVM_USE_HOST_TOOLS)
- build_native_tool(make-confusable-table make_confusable_table)
+ build_native_tool(clang-tidy-confusable-chars-gen make_confusable_table)
set(make_confusable_table_target "${make_confusable_table}")
else()
- set(make_confusable_table $)
- set(make_confusable_table_target make-confusable-table)
+ set(make_confusable_table $)
+ set(make_confusable_table_target clang-tidy-confusable-chars-gen)
endif()
add_subdirectory(ConfusableTable)
diff --git a/clang-tools-extra/clang-tidy/misc/ConfusableTable/CMakeLists.txt
b/clang-tools-extra/clang-tidy/misc/ConfusableTable/CMakeLists.txt
index a35f206fbf783..f0ad2dbc0c578 100644
--- a/clang-tools-extra/clang-tidy/misc/ConfusableTable/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/misc/ConfusableTable/CMakeLists.txt
@@ -1,6 +1,6 @@
set(LLVM_LINK_COMPONENTS Support)
list(REMOVE_ITEM LLVM_COMMON_DEPENDS clang-tablegen-targets)
-add_llvm_executable(make-confusable-table
+add_llvm_executable(clang-tidy-confusable-chars-gen
BuildConfusableTable.cpp
)
diff --git
a/llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/ConfusableTable/BUILD.gn
b/llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/ConfusableTable/BUILD.gn
index 10521474ce57e..25025c499f04a 100644
---
a/llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/ConfusableTable/BUILD.gn
+++
b/llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/misc/ConfusableTable/BUILD.gn
@@ -1,4 +1,4 @@
-executable("make-confusable-table") {
+executable("clang-tidy-confusable-chars-gen") {
deps = [ "//llvm/lib/Support" ]
sources = [ "BuildConfusableTable.cpp" ]
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] dc95d0c - [clang-tidy] Add CLANG_TIDY_CONFUSABLE_CHARS_GEN cmake cache variable to avoid building when cross compiling
Author: Martin Storsjö
Date: 2022-07-28T12:00:21+03:00
New Revision: dc95d0c525636aed53a3b38258efa2dff4c83edf
URL:
https://github.com/llvm/llvm-project/commit/dc95d0c525636aed53a3b38258efa2dff4c83edf
DIFF:
https://github.com/llvm/llvm-project/commit/dc95d0c525636aed53a3b38258efa2dff4c83edf.diff
LOG: [clang-tidy] Add CLANG_TIDY_CONFUSABLE_CHARS_GEN cmake cache variable to
avoid building when cross compiling
This is similar to the LLVM_TABLEGEN, CLANG_TABLEGEN and
CLANG_PSEUDO_GEN cmake cache variables.
Differential Revision: https://reviews.llvm.org/D129799
Added:
Modified:
clang-tools-extra/clang-tidy/misc/CMakeLists.txt
Removed:
diff --git a/clang-tools-extra/clang-tidy/misc/CMakeLists.txt
b/clang-tools-extra/clang-tidy/misc/CMakeLists.txt
index ee8fe0b37fce9..de76b4b00c360 100644
--- a/clang-tools-extra/clang-tidy/misc/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/misc/CMakeLists.txt
@@ -3,7 +3,13 @@ set(LLVM_LINK_COMPONENTS
Support
)
-if(LLVM_USE_HOST_TOOLS)
+set(CLANG_TIDY_CONFUSABLE_CHARS_GEN "clang-tidy-confusable-chars-gen" CACHE
+ STRING "Host clang-tidy-confusable-chars-gen executable. Saves building if
cross-compiling.")
+
+if(NOT CLANG_TIDY_CONFUSABLE_CHARS_GEN STREQUAL
"clang-tidy-confusable-chars-gen")
+ set(make_confusable_table ${CLANG_TIDY_CONFUSABLE_CHARS_GEN})
+ set(make_confusable_table_target ${CLANG_TIDY_CONFUSABLE_CHARS_GEN})
+elseif(LLVM_USE_HOST_TOOLS)
build_native_tool(clang-tidy-confusable-chars-gen make_confusable_table)
set(make_confusable_table_target "${make_confusable_table}")
else()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
