[PATCH] D33010: Make google-build-using-namespace skip std::.*literals
marejde updated this revision to Diff 98914.
marejde added a comment.
Removed use of nested namespace definition in test (C++17) and added a couple
of more namespaces with "literals" in name that check should warn for.
https://reviews.llvm.org/D33010
Files:
clang-tidy/google/UsingNamespaceDirectiveCheck.cpp
clang-tidy/google/UsingNamespaceDirectiveCheck.h
test/clang-tidy/google-namespaces.cpp
Index: test/clang-tidy/google-namespaces.cpp
===
--- test/clang-tidy/google-namespaces.cpp
+++ test/clang-tidy/google-namespaces.cpp
@@ -6,3 +6,47 @@
// CHECK: :[[@LINE-1]]:1: warning: do not use namespace using-directives; use using-declarations instead [google-build-using-namespace]
using spce::core; // no-warning
+
+namespace std {
+inline namespace literals {
+inline namespace chrono_literals {
+}
+inline namespace complex_literals {
+}
+inline namespace string_literals {
+}
+}
+}
+
+using namespace std::chrono_literals;// no-warning
+using namespace std::complex_literals; // no-warning
+using namespace std::literals; // no-warning
+using namespace std::literals::chrono_literals; // no-warning
+using namespace std::literals::complex_literals; // no-warning
+using namespace std::literals::string_literals; // no-warning
+using namespace std::string_literals;// no-warning
+
+namespace literals {}
+
+using namespace literals;
+// CHECK: :[[@LINE-1]]:1: warning: do not use namespace using-directives; use using-declarations instead [google-build-using-namespace]
+
+namespace foo {
+inline namespace literals {
+inline namespace bar_literals {}
+}
+}
+
+using namespace foo::literals;
+// CHECK: :[[@LINE-1]]:1: warning: do not use namespace using-directives; use using-declarations instead [google-build-using-namespace]
+
+using namespace foo::bar_literals;
+// CHECK: :[[@LINE-1]]:1: warning: do not use namespace using-directives; use using-declarations instead [google-build-using-namespace]
+
+using namespace foo::literals::bar_literals;
+// CHECK: :[[@LINE-1]]:1: warning: do not use namespace using-directives; use using-declarations instead [google-build-using-namespace]
+
+namespace foo_literals {}
+
+using namespace foo_literals;
+// CHECK: :[[@LINE-1]]:1: warning: do not use namespace using-directives; use using-declarations instead [google-build-using-namespace]
Index: clang-tidy/google/UsingNamespaceDirectiveCheck.h
===
--- clang-tidy/google/UsingNamespaceDirectiveCheck.h
+++ clang-tidy/google/UsingNamespaceDirectiveCheck.h
@@ -38,6 +38,9 @@
: ClangTidyCheck(Name, Context) {}
void registerMatchers(ast_matchers::MatchFinder *Finder) override;
void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
+
+private:
+ bool isStdLiteralsNamespace(const NamespaceDecl *NS);
};
} // namespace build
Index: clang-tidy/google/UsingNamespaceDirectiveCheck.cpp
===
--- clang-tidy/google/UsingNamespaceDirectiveCheck.cpp
+++ clang-tidy/google/UsingNamespaceDirectiveCheck.cpp
@@ -34,12 +34,32 @@
if (U->isImplicit() || !Loc.isValid())
return;
+ // Do not warn if namespace is a std namespace with user-defined literals. The
+ // user-defined literals can only be used with a using directive.
+ if (isStdLiteralsNamespace(U->getNominatedNamespace()))
+return;
+
diag(Loc, "do not use namespace using-directives; "
"use using-declarations instead");
// TODO: We could suggest a list of using directives replacing the using
// namespace directive.
}
+bool UsingNamespaceDirectiveCheck::isStdLiteralsNamespace(
+const NamespaceDecl *NS) {
+ if (!NS->getName().endswith("literals"))
+return false;
+
+ const auto *Parent = dyn_cast_or_null(NS->getParent());
+ if (!Parent)
+return false;
+
+ if (Parent->isStdNamespace())
+return true;
+
+ return Parent->getName() == "literals" && Parent->getParent() &&
+ Parent->getParent()->isStdNamespace();
+}
} // namespace build
} // namespace google
} // namespace tidy
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33082: Fix Libc++ build with MinGW64
mati865 accepted this revision. mati865 added a comment. This revision is now accepted and ready to land. I don't know if it is MSYS2 specific or general MinGW issue but liblibc++.a is created. Could you check your build? Here is line to blame: https://github.com/llvm-mirror/libcxx/blob/master/lib/CMakeLists.txt#L246 https://reviews.llvm.org/D33082 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33135: [ASTMatchers] Add support for floatLiterals
Lekensteyn added a comment.
By the way, I think that `long double` is less common than long unsigned
literals, so changing unsigned to uint64_t might be something more important?
Comment at: include/clang/ASTMatchers/Dynamic/Parser.h:25
///:= true | false
+/// := 1.0 | 2e-3 | 3.45e67
/// := [0-9]+
aaron.ballman wrote:
> It'd be good to list the actual grammar rather than a few examples.
I am concerned that listing a very precise grammar actually makes this less
readable (see also the StringLiteral example).
If a grammar is used instead, how about this:
:= [0-9]+.[0-9]* | [0-9]+.[0-9]*[eE][-+]?[0-9]+
Comment at: include/clang/ASTMatchers/Dynamic/VariantValue.h:335
unsigned Unsigned;
+double Double;
bool Boolean;
aaron.ballman wrote:
> This may or may not be a good idea, but do we want to put the values into an
> APFloat rather than a double? My concern with double is that (0) it may be
> subtly different if the user wants a 16- or 32-bit float explicitly, (1) it
> won't be able to represent long double values, or quad double.
>
> I'm thinking this value could be passed directly from the C++ API as an
> APFloat, float, or double, or provided using a StringRef for the dynamic API.
(32-bit) double values are a superset of (16-bit) float values, that should be
OK.
Long doubles are possible in the AST (e.g. for `0.1L`), but neither C11 nor
C++14 seem to define a quad double literal type (so that should be of a lesser
concern).
Reasons why I chose for double instead of APFloat:
- `strtod` is readily available and does not abort the program. By contrast,
`APFloat(StringRef)` trips on assertions if the input is invalid.
- I was not sure if the APFloat class can be used in an union.
Comment at: lib/ASTMatchers/Dynamic/Parser.cpp:180
/// \brief Consume an unsigned literal.
void consumeUnsignedLiteral(TokenInfo *Result) {
+bool isFloatingLiteral = false;
aaron.ballman wrote:
> This function should be renamed and the comment updated.
How does "consumeNumberLiteral" sound?
https://reviews.llvm.org/D33135
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33094: [ASTMatchers] Add clang-query support for equals matcher
Lekensteyn updated this revision to Diff 98917.
Lekensteyn marked 9 inline comments as done.
Lekensteyn retitled this revision from "[ASTMatchers] Add equals support for
integer and boolean literals" to "[ASTMatchers] Add clang-query support for
equals matcher".
Lekensteyn edited the summary of this revision.
Lekensteyn added a comment.
v1 -> v2:
- Add CharacterLiteral and FloatingLiterals support
- updated documentation comment to include examples for all four supported
matcher types
- updated docs with dump_ast_matchers.py
Depends on:
- https://reviews.llvm.org/D33093 for boolean support
- https://reviews.llvm.org/D33135 for float support
https://reviews.llvm.org/D33094
Files:
docs/LibASTMatchersReference.html
include/clang/ASTMatchers/ASTMatchers.h
lib/ASTMatchers/Dynamic/Registry.cpp
unittests/ASTMatchers/Dynamic/RegistryTest.cpp
Index: unittests/ASTMatchers/Dynamic/RegistryTest.cpp
===
--- unittests/ASTMatchers/Dynamic/RegistryTest.cpp
+++ unittests/ASTMatchers/Dynamic/RegistryTest.cpp
@@ -511,6 +511,41 @@
EXPECT_FALSE(matches("int i = 1;", Value));
}
+TEST_F(RegistryTest, EqualsMatcher) {
+ Matcher BooleanStmt = constructMatcher(
+ "cxxBoolLiteral", constructMatcher("equals", VariantValue(true)))
+ .getTypedMatcher();
+ EXPECT_TRUE(matches("bool x = true;", BooleanStmt));
+ EXPECT_FALSE(matches("bool x = false;", BooleanStmt));
+ EXPECT_FALSE(matches("bool x = 0;", BooleanStmt));
+
+ BooleanStmt = constructMatcher(
+ "cxxBoolLiteral", constructMatcher("equals", VariantValue(0)))
+ .getTypedMatcher();
+ EXPECT_TRUE(matches("bool x = false;", BooleanStmt));
+ EXPECT_FALSE(matches("bool x = true;", BooleanStmt));
+ EXPECT_FALSE(matches("bool x = 0;", BooleanStmt));
+
+ Matcher DoubleStmt = constructMatcher(
+ "floatLiteral", constructMatcher("equals", VariantValue(1.2)))
+ .getTypedMatcher();
+ EXPECT_TRUE(matches("double x = 1.2;", DoubleStmt));
+ EXPECT_TRUE(matches("double x = 12e-1;", DoubleStmt));
+ EXPECT_FALSE(matches("double x = 1.23;", DoubleStmt));
+
+ Matcher IntegerStmt = constructMatcher(
+ "integerLiteral", constructMatcher("equals", VariantValue(42)))
+ .getTypedMatcher();
+ EXPECT_TRUE(matches("int x = 42;", IntegerStmt));
+ EXPECT_FALSE(matches("int x = 1;", IntegerStmt));
+
+ Matcher CharStmt = constructMatcher(
+ "characterLiteral", constructMatcher("equals", VariantValue('x')))
+ .getTypedMatcher();
+ EXPECT_TRUE(matches("int x = 'x';", CharStmt));
+ EXPECT_FALSE(matches("int x = 120;", CharStmt));
+}
+
} // end anonymous namespace
} // end namespace dynamic
} // end namespace ast_matchers
Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -56,20 +56,24 @@
registerMatcher(#name, internal::makeMatcherAutoMarshall(\
::clang::ast_matchers::name, #name));
+#define REGISTER_MATCHER_OVERLOAD(name)\
+ registerMatcher(#name, \
+ llvm::make_unique(name##Callbacks))
+
#define SPECIFIC_MATCHER_OVERLOAD(name, Id)\
static_cast<::clang::ast_matchers::name##_Type##Id>( \
::clang::ast_matchers::name)
+#define MATCHER_OVERLOAD_ENTRY(name, Id) \
+internal::makeMatcherAutoMarshall(SPECIFIC_MATCHER_OVERLOAD(name, Id), \
+ #name)
+
#define REGISTER_OVERLOADED_2(name)\
do { \
-std::unique_ptr Callbacks[] = { \
-internal::makeMatcherAutoMarshall(SPECIFIC_MATCHER_OVERLOAD(name, 0), \
- #name), \
-internal::makeMatcherAutoMarshall(SPECIFIC_MATCHER_OVERLOAD(name, 1), \
- #name)}; \
-registerMatcher( \
-#name, \
-llvm::make_unique(Callbacks)); \
+std::unique_ptr name##Callbacks[] = { \
+MATCHER_OVERLOAD_ENTRY(name, 0), \
+MATCHER_OVERLOAD_ENTRY(name, 1)}; \
+REGISTER_MATCHER_OVERLOAD(name); \
} while (0)
/// \brief Generate a registry map with all the known matchers.
@@ -83,7 +87,6 @@
// findAll
//
// Other:
- // equals
// equalsNode
REGISTER_OVERLOADED_2(callee);
@@ -96,6 +99,13 @@
[clang-tools-extra] r303001 - [clang-tidy] TwineLocalCheck: add param # checking
Author: yawanng
Date: Sat May 13 23:14:59 2017
New Revision: 303001
URL: http://llvm.org/viewvc/llvm-project?rev=303001&view=rev
Log:
[clang-tidy] TwineLocalCheck: add param # checking
Summary:
The statement **getArg** tries to get the first one without checking, which may
cause segmentation fault.
Reviewers: chh, bkramer
Reviewed By: bkramer
Subscribers: cfe-commits, xazax.hun
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D33103
Modified:
clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
Modified: clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp?rev=303001&r1=303000&r2=303001&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/llvm/TwineLocalCheck.cpp Sat May 13
23:14:59 2017
@@ -35,8 +35,11 @@ void TwineLocalCheck::check(const MatchF
// of the initializer.
const Expr *C = VD->getInit()->IgnoreImplicit();
-while (isa(C))
+while (isa(C)) {
+ if (cast(C)->getNumArgs() == 0)
+break;
C = cast(C)->getArg(0)->IgnoreParenImpCasts();
+}
SourceRange TypeRange =
VD->getTypeSourceInfo()->getTypeLoc().getSourceRange();
Modified: clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp?rev=303001&r1=303000&r2=303001&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/llvm-twine-local.cpp Sat May 13
23:14:59 2017
@@ -5,6 +5,7 @@ class Twine {
public:
Twine(const char *);
Twine(int);
+ Twine();
Twine &operator+(const Twine &);
};
}
@@ -29,4 +30,35 @@ int main() {
// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: twine variables are prone to
use-after-free bugs
// CHECK-MESSAGES: note: FIX-IT applied suggested code changes
// CHECK-FIXES: const char * Prefix = false ? "__INT_FAST" : "__UINT_FAST";
+
+ const Twine t2 = Twine();
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: twine variables are prone to
use-after-free bugs
+// CHECK-MESSAGES: note: FIX-IT applied suggested code changes
+// CHECK-FIXES: std::string t2 = (Twine()).str();
+ foo(Twine() + "b");
+
+ const Twine t3 = Twine(42);
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: twine variables are prone to
use-after-free bugs
+// CHECK-MESSAGES: note: FIX-IT applied suggested code changes
+// CHECK-FIXES: std::string t3 = (Twine(42)).str();
+
+ const Twine t4 = Twine(42) + "b";
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: twine variables are prone to
use-after-free bugs
+// CHECK-MESSAGES: note: FIX-IT applied suggested code changes
+// CHECK-FIXES: std::string t4 = (Twine(42) + "b").str();
+
+ const Twine t5 = Twine() + "b";
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: twine variables are prone to
use-after-free bugs
+// CHECK-MESSAGES: note: FIX-IT applied suggested code changes
+// CHECK-FIXES: std::string t5 = (Twine() + "b").str();
+
+ const Twine t6 = true ? Twine() : Twine(42);
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: twine variables are prone to
use-after-free bugs
+// CHECK-MESSAGES: note: FIX-IT applied suggested code changes
+// CHECK-FIXES: std::string t6 = (true ? Twine() : Twine(42)).str();
+
+ const Twine t7 = false ? Twine() : Twine("b");
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: twine variables are prone to
use-after-free bugs
+// CHECK-MESSAGES: note: FIX-IT applied suggested code changes
+// CHECK-FIXES: std::string t7 = (false ? Twine() : Twine("b")).str();
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D32690: [clang-tidy] modernize-use-emplace: Remove unnecessary make_tuple calls
Prazek accepted this revision. Prazek added a comment. This revision is now accepted and ready to land. LGTM https://reviews.llvm.org/D32690 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33173: Modify test to look for patterns in stderr as well
sepavloff created this revision.
With the change https://reviews.llvm.org/D33013 driver does not build
compilation object if command line is invalid, in particular, if
unrecognized option is provided. In such cases it prints diagnostics
on stderr. The test 'clang-tidy/diagnostic.cpp' checks reaction on
unrecognized option and will fail when https://reviews.llvm.org/D33013 is
applied. With this
change the test works in either case.
https://reviews.llvm.org/D33173
Files:
test/clang-tidy/diagnostic.cpp
Index: test/clang-tidy/diagnostic.cpp
===
--- test/clang-tidy/diagnostic.cpp
+++ test/clang-tidy/diagnostic.cpp
@@ -1,11 +1,11 @@
// RUN: clang-tidy -checks='-*,modernize-use-override' %s.nonexistent.cpp -- |
FileCheck -check-prefix=CHECK1 -implicit-check-not='{{warning:|error:}}' %s
-// RUN: clang-tidy -checks='-*,clang-diagnostic-*,google-explicit-constructor'
%s -- -fan-unknown-option | FileCheck -check-prefix=CHECK2
-implicit-check-not='{{warning:|error:}}' %s
-// RUN: clang-tidy
-checks='-*,google-explicit-constructor,clang-diagnostic-literal-conversion' %s
-- -fan-unknown-option | FileCheck -check-prefix=CHECK3
-implicit-check-not='{{warning:|error:}}' %s
+// RUN: clang-tidy -checks='-*,clang-diagnostic-*,google-explicit-constructor'
%s -- -fan-unknown-option 2>&1 | FileCheck -check-prefix=CHECK2
-implicit-check-not='{{warning:|error:}}' %s
+// RUN: clang-tidy
-checks='-*,google-explicit-constructor,clang-diagnostic-literal-conversion' %s
-- -fan-unknown-option 2>&1 | FileCheck -check-prefix=CHECK3
-implicit-check-not='{{warning:|error:}}' %s
// RUN: clang-tidy
-checks='-*,modernize-use-override,clang-diagnostic-macro-redefined' %s --
-DMACRO_FROM_COMMAND_LINE | FileCheck -check-prefix=CHECK4
-implicit-check-not='{{warning:|error:}}' %s
// CHECK1: error: error reading '{{.*}}.nonexistent.cpp'
[clang-diagnostic-error]
-// CHECK2: error: unknown argument: '-fan-unknown-option'
[clang-diagnostic-error]
-// CHECK3: error: unknown argument: '-fan-unknown-option'
[clang-diagnostic-error]
+// CHECK2: error: unknown argument: '-fan-unknown-option'
+// CHECK3: error: unknown argument: '-fan-unknown-option'
// CHECK2: :[[@LINE+2]]:9: warning: implicit conversion from 'double' to 'int'
changes value from 1.5 to 1 [clang-diagnostic-literal-conversion]
// CHECK3: :[[@LINE+1]]:9: warning: implicit conversion from 'double' to 'int'
changes value
Index: test/clang-tidy/diagnostic.cpp
===
--- test/clang-tidy/diagnostic.cpp
+++ test/clang-tidy/diagnostic.cpp
@@ -1,11 +1,11 @@
// RUN: clang-tidy -checks='-*,modernize-use-override' %s.nonexistent.cpp -- | FileCheck -check-prefix=CHECK1 -implicit-check-not='{{warning:|error:}}' %s
-// RUN: clang-tidy -checks='-*,clang-diagnostic-*,google-explicit-constructor' %s -- -fan-unknown-option | FileCheck -check-prefix=CHECK2 -implicit-check-not='{{warning:|error:}}' %s
-// RUN: clang-tidy -checks='-*,google-explicit-constructor,clang-diagnostic-literal-conversion' %s -- -fan-unknown-option | FileCheck -check-prefix=CHECK3 -implicit-check-not='{{warning:|error:}}' %s
+// RUN: clang-tidy -checks='-*,clang-diagnostic-*,google-explicit-constructor' %s -- -fan-unknown-option 2>&1 | FileCheck -check-prefix=CHECK2 -implicit-check-not='{{warning:|error:}}' %s
+// RUN: clang-tidy -checks='-*,google-explicit-constructor,clang-diagnostic-literal-conversion' %s -- -fan-unknown-option 2>&1 | FileCheck -check-prefix=CHECK3 -implicit-check-not='{{warning:|error:}}' %s
// RUN: clang-tidy -checks='-*,modernize-use-override,clang-diagnostic-macro-redefined' %s -- -DMACRO_FROM_COMMAND_LINE | FileCheck -check-prefix=CHECK4 -implicit-check-not='{{warning:|error:}}' %s
// CHECK1: error: error reading '{{.*}}.nonexistent.cpp' [clang-diagnostic-error]
-// CHECK2: error: unknown argument: '-fan-unknown-option' [clang-diagnostic-error]
-// CHECK3: error: unknown argument: '-fan-unknown-option' [clang-diagnostic-error]
+// CHECK2: error: unknown argument: '-fan-unknown-option'
+// CHECK3: error: unknown argument: '-fan-unknown-option'
// CHECK2: :[[@LINE+2]]:9: warning: implicit conversion from 'double' to 'int' changes value from 1.5 to 1 [clang-diagnostic-literal-conversion]
// CHECK3: :[[@LINE+1]]:9: warning: implicit conversion from 'double' to 'int' changes value
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33013: Driver must return non-zero code on errors in command line
sepavloff updated this revision to Diff 98930.
sepavloff added a comment.
Herald added a subscriber: klimek.
Added missed case
The patch missed a case when Compilation object is created during work of
clang based tool, it resulted in fail of the test 'clang-tidy/diagnostic.cpp'.
This addition to the patch add proper checks, hopefully, to all invocations of
'Driver::BuildCompilation'. Small changes are required in clang-tools-extra,
they are tracked by https://reviews.llvm.org/D33173.
https://reviews.llvm.org/D33013
Files:
lib/Driver/Driver.cpp
lib/Frontend/CreateInvocationFromCommandLine.cpp
lib/Tooling/CompilationDatabase.cpp
lib/Tooling/Tooling.cpp
test/Driver/aarch64-cpus.c
test/Driver/amdgpu-features.c
test/Driver/arm-darwin-builtin.c
test/Driver/arm-default-build-attributes.s
test/Driver/cl-outputs.c
test/Driver/clang_f_opts.c
test/Driver/cuda-external-tools.cu
test/Driver/debug-options.c
test/Driver/gfortran.f90
test/Driver/split-debug.h
test/Driver/unknown-arg.c
test/Index/index-attrs.c
test/Index/index-attrs.cpp
tools/driver/driver.cpp
unittests/Driver/ToolChainTest.cpp
Index: unittests/Driver/ToolChainTest.cpp
===
--- unittests/Driver/ToolChainTest.cpp
+++ unittests/Driver/ToolChainTest.cpp
@@ -60,6 +60,7 @@
std::unique_ptr C(TheDriver.BuildCompilation(
{"-fsyntax-only", "--gcc-toolchain=", "foo.cpp"}));
+ EXPECT_TRUE(C);
std::string S;
{
@@ -99,6 +100,7 @@
std::unique_ptr C(TheDriver.BuildCompilation(
{"-fsyntax-only", "--gcc-toolchain=", "foo.cpp"}));
+ EXPECT_TRUE(C);
std::string S;
{
@@ -128,15 +130,24 @@
Driver CCDriver("/home/test/bin/clang", "arm-linux-gnueabi", Diags,
InMemoryFileSystem);
+ CCDriver.setCheckInputsExist(false);
Driver CXXDriver("/home/test/bin/clang++", "arm-linux-gnueabi", Diags,
InMemoryFileSystem);
+ CXXDriver.setCheckInputsExist(false);
Driver CLDriver("/home/test/bin/clang-cl", "arm-linux-gnueabi", Diags,
InMemoryFileSystem);
-
- std::unique_ptr CC(CCDriver.BuildCompilation({"foo.cpp"}));
- std::unique_ptr CXX(CXXDriver.BuildCompilation({"foo.cpp"}));
- std::unique_ptr CL(CLDriver.BuildCompilation({"foo.cpp"}));
-
+ CLDriver.setCheckInputsExist(false);
+
+ std::unique_ptr CC(CCDriver.BuildCompilation(
+ { "/home/test/bin/clang", "foo.cpp"}));
+ std::unique_ptr CXX(CXXDriver.BuildCompilation(
+ { "/home/test/bin/clang++", "foo.cpp"}));
+ std::unique_ptr CL(CLDriver.BuildCompilation(
+ { "/home/test/bin/clang-cl", "foo.cpp"}));
+
+ EXPECT_TRUE(CC);
+ EXPECT_TRUE(CXX);
+ EXPECT_TRUE(CL);
EXPECT_TRUE(CCDriver.CCCIsCC());
EXPECT_TRUE(CXXDriver.CCCIsCXX());
EXPECT_TRUE(CLDriver.IsCLMode());
Index: tools/driver/driver.cpp
===
--- tools/driver/driver.cpp
+++ tools/driver/driver.cpp
@@ -454,40 +454,41 @@
SetBackdoorDriverOutputsFromEnvVars(TheDriver);
std::unique_ptr C(TheDriver.BuildCompilation(argv));
- int Res = 0;
- SmallVector, 4> FailingCommands;
- if (C.get())
+ int Res = 1;
+ if (C.get()) {
+SmallVector, 4> FailingCommands;
Res = TheDriver.ExecuteCompilation(*C, FailingCommands);
- // Force a crash to test the diagnostics.
- if (TheDriver.GenReproducer) {
-Diags.Report(diag::err_drv_force_crash)
+// Force a crash to test the diagnostics.
+if (TheDriver.GenReproducer) {
+ Diags.Report(diag::err_drv_force_crash)
<< !::getenv("FORCE_CLANG_DIAGNOSTICS_CRASH");
-// Pretend that every command failed.
-FailingCommands.clear();
-for (const auto &J : C->getJobs())
- if (const Command *C = dyn_cast(&J))
-FailingCommands.push_back(std::make_pair(-1, C));
- }
+ // Pretend that every command failed.
+ FailingCommands.clear();
+ for (const auto &J : C->getJobs())
+if (const Command *C = dyn_cast(&J))
+ FailingCommands.push_back(std::make_pair(-1, C));
+}
- for (const auto &P : FailingCommands) {
-int CommandRes = P.first;
-const Command *FailingCommand = P.second;
-if (!Res)
- Res = CommandRes;
-
-// If result status is < 0, then the driver command signalled an error.
-// If result status is 70, then the driver command reported a fatal error.
-// On Windows, abort will return an exit code of 3. In these cases,
-// generate additional diagnostic information if possible.
-bool DiagnoseCrash = CommandRes < 0 || CommandRes == 70;
+for (const auto &P : FailingCommands) {
+ int CommandRes = P.first;
+ const Command *FailingCommand = P.second;
+ if (!Res)
+Res = CommandRes;
+
+ // If result status is < 0, then the driver command signalled an error.
+ // If result status is 70, then the driver command reported a fatal error.
+ // On Windows, abort will return an exit code of 3. In t
[PATCH] D32977: [OpenCL] Emit function-scope variable in constant address space as static variable
yaxunl added inline comments.
Comment at: lib/Sema/SemaDecl.cpp:10286
+ // these variables must be a compile time constant.
+ VDecl->getType().getAddressSpace() == LangAS::opencl_constant)
CheckForConstantInitializer(Init, DclT);
rjmccall wrote:
> yaxunl wrote:
> > Anastasia wrote:
> > > yaxunl wrote:
> > > > rjmccall wrote:
> > > > > yaxunl wrote:
> > > > > > rjmccall wrote:
> > > > > > > Should this rule apply even in C++ mode? I can't remember if
> > > > > > > there are any OpenCL/C++ hybrids.
> > > > > > No. This rule (static local variable needs to be initialised with
> > > > > > compile-time constant) only applies to C and OpenCL.
> > > > > > In C++ static local variable can be initialised with
> > > > > > non-compile-time constant, in which case Clang will emit atomic
> > > > > > instructions to make sure it is only initialised once.
> > > > > >
> > > > > > Currently OpenCL 2.2 defines OpenCL C++ but clang does not support
> > > > > > it.
> > > > > Yes, I understand that C++ generally allows static locals to be
> > > > > lazily initialized, and that that rule would (probably) still apply
> > > > > to ordinary static locals in OpenCL C++. However, I would expect
> > > > > that OpenCL C++ rule is that __constant local variables still need to
> > > > > be statically initialized, because there's no plausible way in the
> > > > > OpenCL implementation model to actually put lazily-initialized
> > > > > variables in the constant address space. Assuming that's correct,
> > > > > then I would recommend reworking this whole chain of conditions to:
> > > > >
> > > > > // Don't check the initializer if the declaration is malformed.
> > > > > if (VDecl->isInvalidDecl()) {
> > > > > // do nothing
> > > > >
> > > > > // OpenCL __constant locals must be constant-initialized, even in
> > > > > OpenCL C++.
> > > > > } else if (VDecl->getType().getAddressSpace() ==
> > > > > LangAS::opencl_constant) {
> > > > > CheckForConstantInitializer(Init, DclT);
> > > > >
> > > > > // Otherwise, C++ does not restrict the initializer.
> > > > > } else if (getLangOpts().CPlusPlus) {
> > > > > // do nothing
> > > > >
> > > > > // C99 6.7.8p4: All the expressions in an initializer for an object
> > > > > that has
> > > > > // static storage duration shall be constant expressions or string
> > > > > literals.
> > > > > } else if (VDecl->getStorageClass() == SC_Static) {
> > > > > CheckForConstantInitializer(Init, DclT);
> > > > >
> > > > > // C89 is stricter than C99 for aggregate initializers.
> > > > > // C89 6.5.7p3: All the expressions [...] in an initializer list
> > > > > // for an object that has aggregate or union type shall be
> > > > > // constant expressions.
> > > > > } else if (!getLangOpts().C99 &&
> > > > > VDecl->getType()->isAggregateType() && isa(Init)) {
> > > > > Expr *Culprit;
> > > > > if (!Init->isConstantInitializer(Context, false, &Culprit)) {
> > > > > ...
> > > > > }
> > > > > }
> > > > Agree that even OpenCL C++ is unable to lazy initialise function-scope
> > > > var in constant addr space. Will do.
> > > I think the original way would be much simpler to read and understand
> > > though.
> > >
> > > To be honest I wouldn't complicate things now for the feature we don't
> > > support. I feel OpenCL C++ should be represented as a separate LangOpt
> > > since there are some places that will require special handling due to
> > > deviation from C++. I would rather extend things later in more systematic
> > > way.
> > I will delete the comment about OpenCL C++ when committing.
> I disagree. Simple chains like this are almost always superior to building
> up complex logical conditions: the priorities between conditions are clearer
> (such as the interaction between __constant and C++ here), each condition can
> be conveniently documented without having to add comments to the middle of an
> expression, and there's less need to build up (A && !B) conditions just to
> make sure that cases are routed to the right place. If the body of a clause
> is complex, it's usually a good idea to extract it into a separate function
> anyway, as has already been done here with CheckForConstantInitializer.
>
> Deleting the comment about OpenCL C++ seems silly. The comment is correct
> and explains why the clauses need to be ordered the way they are, and someone
> implementing OpenCL C++ support later will not think to add it back.
>
> Please trust me that you would not want to use a different LangOpt for OpenCL
> C++. OpenCL C++ may feel a little different from normal C++ to a user, but
> for the compiler its deviations are tiny compared to the number of ways in
> which C++ deviates from C. The major C++ features that really cut across the
> frontend are all still there: templates, references, type members, function
> overloading, operator overloading,
[libcxxabi] r303016 - Revert r302978 and r302981.
Author: ahatanak
Date: Sun May 14 13:46:19 2017
New Revision: 303016
URL: http://llvm.org/viewvc/llvm-project?rev=303016&view=rev
Log:
Revert r302978 and r302981.
Revert the two commits to understand why the following aarch64 bot is
failing.
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux
Removed:
libcxxabi/trunk/test/exception_object_alignment.sh.cpp
Modified:
libcxxabi/trunk/src/cxa_exception.hpp
Modified: libcxxabi/trunk/src/cxa_exception.hpp
URL:
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/cxa_exception.hpp?rev=303016&r1=303015&r2=303016&view=diff
==
--- libcxxabi/trunk/src/cxa_exception.hpp (original)
+++ libcxxabi/trunk/src/cxa_exception.hpp Sun May 14 13:46:19 2017
@@ -61,21 +61,7 @@ struct _LIBCXXABI_HIDDEN __cxa_exception
size_t referenceCount;
#endif
-// This field is annotated with attribute aligned so that the exception
-// object following the field is sufficiently aligned and there is no
-// gap between the field and the exception object. r276215 made a change to
-// annotate _Unwind_Exception in unwind.h with __attribute__((aligned)),
but
-// we cannot incorporate the fix on Darwin since it is an ABI-breaking
-// change, which is why we need the attribute on this field.
-//
-// For ARM EHABI, we do not align this field since _Unwind_Exception is an
-// alias of _Unwind_Control_Block, which is not annotated with
-// __attribute__((aligned).
-#if defined(_LIBCXXABI_ARM_EHABI)
_Unwind_Exception unwindHeader;
-#else
-_Unwind_Exception unwindHeader __attribute__((aligned));
-#endif
};
// http://sourcery.mentor.com/archives/cxx-abi-dev/msg01924.html
@@ -110,13 +96,7 @@ struct _LIBCXXABI_HIDDEN __cxa_dependent
void* primaryException;
#endif
-// See the comment in __cxa_exception as to why this field has attribute
-// aligned.
-#if defined(_LIBCXXABI_ARM_EHABI)
_Unwind_Exception unwindHeader;
-#else
-_Unwind_Exception unwindHeader __attribute__((aligned));
-#endif
};
struct _LIBCXXABI_HIDDEN __cxa_eh_globals {
Removed: libcxxabi/trunk/test/exception_object_alignment.sh.cpp
URL:
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/exception_object_alignment.sh.cpp?rev=303015&view=auto
==
--- libcxxabi/trunk/test/exception_object_alignment.sh.cpp (original)
+++ libcxxabi/trunk/test/exception_object_alignment.sh.cpp (removed)
@@ -1,48 +0,0 @@
-//=== exception_object_alignment.sh.cpp
---===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-
-// UNSUPPORTED: libcxxabi-no-exceptions
-
-// RUN: %build -O1
-// RUN: %run
-
-// This test used to fail on Darwin because field unwindHeader of struct
-// __cxa_exception and the exception object that immediately followed were not
-// 16B aligned. It would segfault in class derived's constructor when a movaps
-// tried to write to a memory operand that was not 16B aligned.
-
-namespace {
-
-struct S {
- int a;
- int __attribute__((aligned(16))) b;
-};
-
-class base1 {
-protected:
- virtual ~base1() throw() {}
-};
-
-class derived: public base1 {
-public:
- derived() : member() {}
-private:
- S member;
-};
-
-}
-
-int main() {
- try {
-throw derived();
- }
- catch(...) {
- }
- return 0;
-}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33082: Fix Libc++ build with MinGW64
compnerd requested changes to this revision.
compnerd added inline comments.
This revision now requires changes to proceed.
Comment at: include/__locale:370
static const mask blank = _ISblank;
-#elif defined(_LIBCPP_MSVCRT)
+#elif defined(_LIBCPP_WIN32API)
typedef unsigned short mask;
Are these really Win32? These are really more libc compatibility things I
thought?
Comment at: include/stdio.h:113
// snprintf
-#if defined(_LIBCPP_MSVCRT)
+#if defined(_LIBCPP_WIN32API)
extern "C" {
Again, I dont think that this is Win32 API related. This is a libc
implementation detail. If I were to build libc++ against musl and Win32, these
would be present, right?
Comment at: include/wchar.h:169
-#if defined(__cplusplus) && defined(_LIBCPP_MSVCRT)
+#if defined(__cplusplus) && defined(_LIBCPP_WIN32API) // Needed in MinGW as
well
extern "C" {
Again not sure that this is Win32 API specific.
Comment at: src/new.cpp:186
void* p;
-#if defined(_LIBCPP_MSVCRT)
+#if defined(_LIBCPP_WIN32API)
while ((p = _aligned_malloc(size, static_cast(alignment))) ==
nullptr)
This is definitely msvcrt specific. It is possible for an alternate c library
to provide definitions here.
Comment at: src/new.cpp:259
if (ptr)
-#if defined(_LIBCPP_MSVCRT)
+#if defined(_LIBCPP_WIN32API)
::_aligned_free(ptr);
Part of the change above.
Comment at: src/support/win32/locale_win32.cpp:125
+
+#ifndef _LIBCPP_MSVCRT
+float strtof_l(const char* nptr, char** endptr, locale_t loc) {
Would you mind using:
#if !defined(_LIBCPP_MSVCRT)
instead?
Comment at: src/system_error.cpp:68
-#if defined(_LIBCPP_MSVCRT)
+#if defined(_LIBCPP_WIN32API)
string do_strerror_r(int ev) {
I think that MSVCRT is more appropriate here.
https://reviews.llvm.org/D33082
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33080: [Libc++] Use #pragma push_macro/pop_macro to better handle min/max on Windows
compnerd requested changes to this revision.
compnerd added a comment.
This revision now requires changes to proceed.
I think that we should sink the `min`/`max` checks into `__undef_macros`. I
don't like the idea of littering that check everywhere.
Comment at: include/__config:1218
+# if defined(_LIBCPP_COMPILER_MSVC)
+# define _LIBCPP_PUSH_MACROS \
+ __pragma(push_macro("min")) \
clang-format these please? It does a nice job of aligning the `\`.
https://reviews.llvm.org/D33080
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33082: Fix Libc++ build with MinGW64
smeenai added a comment. @compnerd see my previous comment: > @EricWF and I discussed this on IRC a bit. I'm not a fan of overloading > _LIBCPP_WIN32API for this purpose, since to me that macro is meant for > guarding Windows API functions, not for CRT functions. Eric suggested adding > a new macro _LIBCPP_MSVCRT_LIKE, which I'd be fine with. `_LIBCPP_MSVCRT` isn't defined for MinGW (since they have their own CRT headers), so we need a new macro that's defined for both MSVCRT and MinGW. https://reviews.llvm.org/D33082 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33082: Fix Libc++ build with MinGW64
compnerd added a comment. Sure, a `_LIBCPP_MSVCRT_LIKE` WFM. I just want to make sure that we don''t conflate the underlying libc implementation with the Win32 API set. https://reviews.llvm.org/D33082 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33082: Fix Libc++ build with MinGW64
smeenai added a comment. In https://reviews.llvm.org/D33082#754451, @compnerd wrote: > Sure, a `_LIBCPP_MSVCRT_LIKE` WFM. I just want to make sure that we don''t > conflate the underlying libc implementation with the Win32 API set. Yup, that was my concern as well. In https://reviews.llvm.org/D33082#754262, @mati865 wrote: > I don't know if it is MSYS2 specific or general MinGW issue but liblibc++.a > is created. Could you check your build? > Here is line to blame: > https://github.com/llvm-mirror/libcxx/blob/master/lib/CMakeLists.txt#L246 Sounds like a cmake prefix issue. We should be able to fix this by unconditionally setting `CMAKE_STATIC_LIBRARY_PREFIX` to `lib` instead of changing the output name, I think. https://reviews.llvm.org/D33082 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D28954: [analyzer] Add support for symbolic float expressions
lirhea added a comment. In https://reviews.llvm.org/D28954#714936, @ddcc wrote: > Rebase, update tests, fix bugs Excuse me,I want to download full codes of this version,but I have no idea how to do it,can you tell me? And my system is windows. https://reviews.llvm.org/D28954 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33177: any: Add availability for experimental::bad_any_cast
dexonsmith created this revision.
As a follow up to r302172, add missing availability for bad_any_cast.
rdar://problem/32161524
https://reviews.llvm.org/D33177
Files:
libcxx/include/__config
libcxx/include/experimental/any
libcxx/test/std/experimental/any/any.class/any.assign/copy.pass.cpp
libcxx/test/std/experimental/any/any.class/any.assign/move.pass.cpp
libcxx/test/std/experimental/any/any.class/any.assign/value.pass.cpp
libcxx/test/std/experimental/any/any.class/any.cons/copy.pass.cpp
libcxx/test/std/experimental/any/any.class/any.cons/move.pass.cpp
libcxx/test/std/experimental/any/any.class/any.cons/value.pass.cpp
libcxx/test/std/experimental/any/any.class/any.modifiers/clear.pass.cpp
libcxx/test/std/experimental/any/any.class/any.modifiers/swap.pass.cpp
libcxx/test/support/experimental_any_helpers.h
Index: libcxx/test/support/experimental_any_helpers.h
===
--- libcxx/test/support/experimental_any_helpers.h
+++ libcxx/test/support/experimental_any_helpers.h
@@ -55,6 +55,7 @@
// Assert that an 'any' object stores the specified 'Type' and 'value'.
template
+_LIBCPP_AVAILABILITY_THROW_BAD_ANY_CAST
void assertContains(std::experimental::any const& a, int value = 1) {
assert(!a.empty());
RTTI_ASSERT(a.type() == typeid(Type));
@@ -64,6 +65,7 @@
// Modify the value of a "test type" stored within an any to the specified
// 'value'.
template
+_LIBCPP_AVAILABILITY_THROW_BAD_ANY_CAST
void modifyValue(std::experimental::any& a, int value) {
assert(!a.empty());
RTTI_ASSERT(a.type() == typeid(Type));
Index: libcxx/test/std/experimental/any/any.class/any.modifiers/swap.pass.cpp
===
--- libcxx/test/std/experimental/any/any.class/any.modifiers/swap.pass.cpp
+++ libcxx/test/std/experimental/any/any.class/any.modifiers/swap.pass.cpp
@@ -9,12 +9,7 @@
// UNSUPPORTED: c++98, c++03, c++11
-// XFAIL: with_system_cxx_lib=macosx10.12
-// XFAIL: with_system_cxx_lib=macosx10.11
-// XFAIL: with_system_cxx_lib=macosx10.10
-// XFAIL: with_system_cxx_lib=macosx10.9
-// XFAIL: with_system_cxx_lib=macosx10.7
-// XFAIL: with_system_cxx_lib=macosx10.8
+// XFAIL: availability=macosx
//
Index: libcxx/test/std/experimental/any/any.class/any.modifiers/clear.pass.cpp
===
--- libcxx/test/std/experimental/any/any.class/any.modifiers/clear.pass.cpp
+++ libcxx/test/std/experimental/any/any.class/any.modifiers/clear.pass.cpp
@@ -9,12 +9,7 @@
// UNSUPPORTED: c++98, c++03, c++11
-// XFAIL: with_system_cxx_lib=macosx10.12
-// XFAIL: with_system_cxx_lib=macosx10.11
-// XFAIL: with_system_cxx_lib=macosx10.10
-// XFAIL: with_system_cxx_lib=macosx10.9
-// XFAIL: with_system_cxx_lib=macosx10.7
-// XFAIL: with_system_cxx_lib=macosx10.8
+// XFAIL: availability=macosx
//
Index: libcxx/test/std/experimental/any/any.class/any.cons/value.pass.cpp
===
--- libcxx/test/std/experimental/any/any.class/any.cons/value.pass.cpp
+++ libcxx/test/std/experimental/any/any.class/any.cons/value.pass.cpp
@@ -9,12 +9,7 @@
// UNSUPPORTED: c++98, c++03, c++11
-// XFAIL: with_system_cxx_lib=macosx10.12
-// XFAIL: with_system_cxx_lib=macosx10.11
-// XFAIL: with_system_cxx_lib=macosx10.10
-// XFAIL: with_system_cxx_lib=macosx10.9
-// XFAIL: with_system_cxx_lib=macosx10.7
-// XFAIL: with_system_cxx_lib=macosx10.8
+// XFAIL: availability=macosx
//
Index: libcxx/test/std/experimental/any/any.class/any.cons/move.pass.cpp
===
--- libcxx/test/std/experimental/any/any.class/any.cons/move.pass.cpp
+++ libcxx/test/std/experimental/any/any.class/any.cons/move.pass.cpp
@@ -9,12 +9,7 @@
// UNSUPPORTED: c++98, c++03, c++11
-// XFAIL: with_system_cxx_lib=macosx10.12
-// XFAIL: with_system_cxx_lib=macosx10.11
-// XFAIL: with_system_cxx_lib=macosx10.10
-// XFAIL: with_system_cxx_lib=macosx10.9
-// XFAIL: with_system_cxx_lib=macosx10.7
-// XFAIL: with_system_cxx_lib=macosx10.8
+// XFAIL: availability=macosx
//
Index: libcxx/test/std/experimental/any/any.class/any.cons/copy.pass.cpp
===
--- libcxx/test/std/experimental/any/any.class/any.cons/copy.pass.cpp
+++ libcxx/test/std/experimental/any/any.class/any.cons/copy.pass.cpp
@@ -9,12 +9,7 @@
// UNSUPPORTED: c++98, c++03, c++11
-// XFAIL: with_system_cxx_lib=macosx10.12
-// XFAIL: with_system_cxx_lib=macosx10.11
-// XFAIL: with_system_cxx_lib=macosx10.10
-// XFAIL: with_system_cxx_lib=macosx10.9
-// XFAIL: with_system_cxx_lib=macosx10.7
-// XFAIL: with_system_cxx_lib=macosx10.8
+// XFAIL: availability=macosx
//
Index: libcxx/test/std/experimental/any/any.class/any.assign/value.pass.cpp
===
--- libcx
r303026 - Fix PR32933: crash on lambda capture of VLA
Author: faisalv
Date: Sun May 14 20:49:19 2017
New Revision: 303026
URL: http://llvm.org/viewvc/llvm-project?rev=303026&view=rev
Log:
Fix PR32933: crash on lambda capture of VLA
https://bugs.llvm.org/show_bug.cgi?id=32933
Turns out clang wasn't really handling vla's (*) in C++11's for-range entirely
correctly.
For e.g. This would lead to generation of buggy IR:
void foo(int b) {
int vla[b];
b = -1; // This store would affect the '__end = vla + b'
for (int &c : vla)
c = 0;
}
Additionally, code-gen would get confused when VLA's were reference-captured by
lambdas, and then used in a for-range, which would result in an attempt to
generate IR for '__end = vla + b' within the lambda's body - without any
capture of 'b' - hence the assertion.
This patch modifies clang, so that for VLA's it translates the end pointer
approximately into:
__end = __begin + sizeof(vla)/sizeof(vla->getElementType())
As opposed to the __end = __begin + b;
I considered passing a magic value into codegen - or having codegen special
case the '__end' variable when it referred to a variably-modified type, but I
decided against that approach, because it smelled like I would be increasing a
complicated form of coupling, that I think would be even harder to maintain
than the above approach (which can easily be optimized (-O1) to refer to the
run-time bound that was calculated upon array's creation or copied into the
lambda's closure object).
(*) why oh why gcc would you enable this by default?! ;)
Modified:
cfe/trunk/lib/Sema/SemaStmt.cpp
cfe/trunk/test/CodeGenCXX/vla.cpp
cfe/trunk/test/SemaCXX/for-range-examples.cpp
Modified: cfe/trunk/lib/Sema/SemaStmt.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaStmt.cpp?rev=303026&r1=303025&r2=303026&view=diff
==
--- cfe/trunk/lib/Sema/SemaStmt.cpp (original)
+++ cfe/trunk/lib/Sema/SemaStmt.cpp Sun May 14 20:49:19 2017
@@ -2268,9 +2268,57 @@ Sema::BuildCXXForRangeStmt(SourceLocatio
BoundExpr = IntegerLiteral::Create(
Context, CAT->getSize(), Context.getPointerDiffType(), RangeLoc);
else if (const VariableArrayType *VAT =
- dyn_cast(UnqAT))
-BoundExpr = VAT->getSizeExpr();
- else {
+ dyn_cast(UnqAT)) {
+// For a variably modified type we can't just use the expression within
+// the array bounds, since we don't want that to be re-evaluated here.
+// Rather, we need to determine what it was when the array was first
+// created - so we resort to using sizeof(vla)/sizeof(element).
+// For e.g.
+// void f(int b) {
+//int vla[b];
+//b = -1; <-- This should not affect the num of iterations below
+//for (int &c : vla) { .. }
+// }
+
+// FIXME: This results in codegen generating IR that recalculates the
+// run-time number of elements (as opposed to just using the IR Value
+// that corresponds to the run-time value of each bound that was
+// generated when the array was created.) If this proves too
embarassing
+// even for unoptimized IR, consider passing a magic-value/cookie to
+// codegen that then knows to simply use that initial llvm::Value (that
+// corresponds to the bound at time of array creation) within
+// getelementptr. But be prepared to pay the price of increasing a
+// customized form of coupling between the two components - which
could
+// be hard to maintain as the codebase evolves.
+
+ExprResult SizeOfVLAExprR = ActOnUnaryExprOrTypeTraitExpr(
+EndVar->getLocation(), UETT_SizeOf,
+/*isType=*/true,
+CreateParsedType(VAT->desugar(), Context.getTrivialTypeSourceInfo(
+ VAT->desugar(), RangeLoc))
+.getAsOpaquePtr(),
+EndVar->getSourceRange());
+if (SizeOfVLAExprR.isInvalid())
+ return StmtError();
+
+ExprResult SizeOfEachElementExprR = ActOnUnaryExprOrTypeTraitExpr(
+EndVar->getLocation(), UETT_SizeOf,
+/*isType=*/true,
+CreateParsedType(VAT->desugar(),
+ Context.getTrivialTypeSourceInfo(
+ VAT->getElementType(), RangeLoc))
+.getAsOpaquePtr(),
+EndVar->getSourceRange());
+if (SizeOfEachElementExprR.isInvalid())
+ return StmtError();
+
+BoundExpr =
+ActOnBinOp(S, EndVar->getLocation(), tok::slash,
+ SizeOfVLAExprR.get(), SizeOfEachElementExprR.get());
+if (BoundExpr.isInvalid())
+ return StmtError();
+
+ } else {
// Can't be a DependentSizedArrayType or an IncompleteArrayType since
// UnqAT is not incomplete and Range is no
r303027 - [NFC] Remove some comments (IR aid) from a test file erroneous committed in r303026
Author: faisalv
Date: Sun May 14 20:54:02 2017
New Revision: 303027
URL: http://llvm.org/viewvc/llvm-project?rev=303027&view=rev
Log:
[NFC] Remove some comments (IR aid) from a test file erroneous committed in
r303026
Modified:
cfe/trunk/test/CodeGenCXX/vla.cpp
Modified: cfe/trunk/test/CodeGenCXX/vla.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/vla.cpp?rev=303027&r1=303026&r2=303027&view=diff
==
--- cfe/trunk/test/CodeGenCXX/vla.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/vla.cpp Sun May 14 20:54:02 2017
@@ -79,32 +79,6 @@ void test2(int b) {
for (int d : varr) 0;
}
-#if 0
- %0 = load i32, i32* %b.addr, align 4
- %1 = zext i32 %0 to i64
- %2 = load i32, i32* %c.addr, align 4
- %3 = zext i32 %2 to i64
- %4 = call i8* @llvm.stacksave()
- store i8* %4, i8** %saved_stack, align 8
- %5 = mul nuw i64 %1, %3
- %vla = alloca i32, i64 %5, align 16
- store i32 15, i32* %c.addr, align 4
- store i32 15, i32* %b.addr, align 4
- store i32* %vla, i32** %__range, align 8
-
-
- %6 = load i32*, i32** %__range, align 8
- store i32* %6, i32** %__begin, align 8
- %7 = load i32*, i32** %__range, align 8
- %8 = mul nuw i64 %1, %3
- %9 = mul nuw i64 4, %8
- %10 = mul nuw i64 4, %3
- %div = udiv i64 %9, %10
- %vla.index = mul nsw i64 %div, %3
- %add.ptr = getelementptr inbounds i32, i32* %7, i64 %vla.index
- store i32* %add.ptr, i32** %__end, align 8
-#endif
-
void test3(int b, int c) {
// CHECK-LABEL: define void {{.*}}test3{{.*}}(i32 %b, i32 %c)
int varr[b][c];
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33177: any: Add availability for experimental::bad_any_cast
mehdi_amini accepted this revision. mehdi_amini added a comment. This revision is now accepted and ready to land. LGTM. https://reviews.llvm.org/D33177 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33178: Remove requirement for libunwind sources.
Shiz created this revision.
Herald added a subscriber: mgorny.
As per r241993, libunwind_ext.h is not used anymore, and thus only the public
libunwind includes are needed.
This eases distro packaging efforts and removes an unneeded requirement for
out-of-tree building.
Repository:
rL LLVM
https://reviews.llvm.org/D33178
Files:
libcxxabi/CMakeLists.txt
Index: libcxxabi/CMakeLists.txt
===
--- libcxxabi/CMakeLists.txt
+++ libcxxabi/CMakeLists.txt
@@ -504,21 +504,6 @@
NO_DEFAULT_PATH
)
- find_path(
-LIBCXXABI_LIBUNWIND_SOURCES
-libunwind_ext.h
-PATHS ${LIBCXXABI_LIBUNWIND_PATH}/src/
- ${LIBCXXABI_LIBUNWIND_INCLUDES}/../src/
- ${LLVM_MAIN_SRC_DIR}/projects/libunwind/src/
- ${LLVM_MAIN_SRC_DIR}/runtimes/libunwind/src/
-NO_DEFAULT_PATH
- )
-
- if (LIBCXXABI_LIBUNWIND_SOURCES STREQUAL
"LIBCXXABI_LIBUNWIND_SOURCES-NOTFOUND")
-message(WARNING "LIBCXXABI_LIBUNWIND_SOURCES was not specified and
couldn't be infered.")
-set(LIBCXXABI_LIBUNWIND_SOURCES "")
- endif()
-
if (LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL STREQUAL
"LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL-NOTFOUND")
set(LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL "")
endif()
@@ -526,10 +511,6 @@
if (NOT LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL STREQUAL "")
include_directories("${LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL}")
endif()
-
- if (NOT LIBCXXABI_LIBUNWIND_SOURCES STREQUAL "")
-include_directories("${LIBCXXABI_LIBUNWIND_SOURCES}")
- endif()
endif()
# Add source code. This also contains all of the logic for deciding linker
flags
Index: libcxxabi/CMakeLists.txt
===
--- libcxxabi/CMakeLists.txt
+++ libcxxabi/CMakeLists.txt
@@ -504,21 +504,6 @@
NO_DEFAULT_PATH
)
- find_path(
-LIBCXXABI_LIBUNWIND_SOURCES
-libunwind_ext.h
-PATHS ${LIBCXXABI_LIBUNWIND_PATH}/src/
- ${LIBCXXABI_LIBUNWIND_INCLUDES}/../src/
- ${LLVM_MAIN_SRC_DIR}/projects/libunwind/src/
- ${LLVM_MAIN_SRC_DIR}/runtimes/libunwind/src/
-NO_DEFAULT_PATH
- )
-
- if (LIBCXXABI_LIBUNWIND_SOURCES STREQUAL "LIBCXXABI_LIBUNWIND_SOURCES-NOTFOUND")
-message(WARNING "LIBCXXABI_LIBUNWIND_SOURCES was not specified and couldn't be infered.")
-set(LIBCXXABI_LIBUNWIND_SOURCES "")
- endif()
-
if (LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL STREQUAL "LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL-NOTFOUND")
set(LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL "")
endif()
@@ -526,10 +511,6 @@
if (NOT LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL STREQUAL "")
include_directories("${LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL}")
endif()
-
- if (NOT LIBCXXABI_LIBUNWIND_SOURCES STREQUAL "")
-include_directories("${LIBCXXABI_LIBUNWIND_SOURCES}")
- endif()
endif()
# Add source code. This also contains all of the logic for deciding linker flags
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r303030 - Silence buildbots by tweaking an IR codegen test to be less specific w register names.
Author: faisalv
Date: Sun May 14 21:56:02 2017
New Revision: 303030
URL: http://llvm.org/viewvc/llvm-project?rev=303030&view=rev
Log:
Silence buildbots by tweaking an IR codegen test to be less specific w register
names.
Modified:
cfe/trunk/test/CodeGenCXX/vla.cpp
Modified: cfe/trunk/test/CodeGenCXX/vla.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/vla.cpp?rev=303030&r1=303029&r2=303030&view=diff
==
--- cfe/trunk/test/CodeGenCXX/vla.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/vla.cpp Sun May 14 21:56:02 2017
@@ -104,7 +104,7 @@ void test3(int b, int c) {
//CHECK-NEXT: [[VLA_SIZEOF_DIM2:%.*]] = mul nuw i64 4, [[VLA_DIM2_PRE]]
//CHECK-NEXT: [[VLA_NUM_ELEMENTS:%.*]] = udiv i64 [[VLA_SIZEOF]],
[[VLA_SIZEOF_DIM2]]
//CHECK-NEXT: [[VLA_END_INDEX:%.*]] = mul nsw i64 [[VLA_NUM_ELEMENTS]],
[[VLA_DIM2_PRE]]
- //CHECK-NEXT: [[VLA_END_PTR:%.*]] = getelementptr inbounds i32, i32* %7, i64
[[VLA_END_INDEX]]
+ //CHECK-NEXT: [[VLA_END_PTR:%.*]] = getelementptr inbounds i32, i32*
{{%.*}}, i64 [[VLA_END_INDEX]]
//CHECK-NEXT: store i32* [[VLA_END_PTR]], i32** %__end
for (auto &d : varr) 0;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D28954: [analyzer] Add support for symbolic float expressions
ddcc added a comment. In https://reviews.llvm.org/D28954#754478, @lirhea wrote: > In https://reviews.llvm.org/D28954#714936, @ddcc wrote: > > > Rebase, update tests, fix bugs > > > Excuse me,I want to download full codes of this version,but I have no idea > how to do it,can you tell me? > And my system is windows, I haven't install anything about Phabricator. > Thank you! You're probably better off waiting for these patches (https://reviews.llvm.org/D28952, https://reviews.llvm.org/D28953, and https://reviews.llvm.org/D28954) to land rather than grabbing the commits, since some of these diffs are old and I haven't had a chance to rebase and retest them yet. But if you want to try them now, you'll need to compile Clang/LLVM from source, since they haven't landed in any release. I'm also not sure how well the CMake bindings for Z3 work on Windows, it's not a platform I've tested. Either grab the raw diffs of these three commits using "download raw diff" from the web interface, or using Arcanist's `arc patch` commit. Alternatively, I have an older tree with all three commits at https://github.com/ddcc/clang/tree/debug , just revert the debugging commit. https://reviews.llvm.org/D28954 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r303031 - [DOXYGEN] Minor improvements in doxygen comments.
Author: kromanova Date: Sun May 14 22:25:04 2017 New Revision: 303031 URL: http://llvm.org/viewvc/llvm-project?rev=303031&view=rev Log: [DOXYGEN] Minor improvements in doxygen comments. Separated very long brief sections into two sections. I got an OK from Eric Christopher to commit doxygen comments without prior code review upstream. Modified: cfe/trunk/lib/Headers/avxintrin.h cfe/trunk/lib/Headers/emmintrin.h cfe/trunk/lib/Headers/mmintrin.h cfe/trunk/lib/Headers/pmmintrin.h cfe/trunk/lib/Headers/prfchwintrin.h cfe/trunk/lib/Headers/smmintrin.h cfe/trunk/lib/Headers/tmmintrin.h cfe/trunk/lib/Headers/xmmintrin.h Modified: cfe/trunk/lib/Headers/avxintrin.h URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avxintrin.h?rev=303031&r1=303030&r2=303031&view=diff == --- cfe/trunk/lib/Headers/avxintrin.h (original) +++ cfe/trunk/lib/Headers/avxintrin.h Sun May 14 22:25:04 2017 @@ -1458,12 +1458,13 @@ _mm256_blendv_ps(__m256 __a, __m256 __b, /// \brief Computes two dot products in parallel, using the lower and upper ///halves of two [8 x float] vectors as input to the two computations, and ///returning the two dot products in the lower and upper halves of the -///[8 x float] result. The immediate integer operand controls which input -///elements will contribute to the dot product, and where the final results -///are returned. In general, for each dot product, the four corresponding -///elements of the input vectors are multiplied; the first two and second -///two products are summed, then the two sums are added to form the final -///result. +///[8 x float] result. +/// +///The immediate integer operand controls which input elements will +///contribute to the dot product, and where the final results are returned. +///In general, for each dot product, the four corresponding elements of the +///input vectors are multiplied; the first two and second two products are +///summed, then the two sums are added to form the final result. /// /// \headerfile /// @@ -1497,15 +1498,16 @@ _mm256_blendv_ps(__m256 __a, __m256 __b, /* Vector shuffle */ /// \brief Selects 8 float values from the 256-bit operands of [8 x float], as -///specified by the immediate value operand. The four selected elements in -///each operand are copied to the destination according to the bits -///specified in the immediate operand. The selected elements from the first -///256-bit operand are copied to bits [63:0] and bits [191:128] of the -///destination, and the selected elements from the second 256-bit operand -///are copied to bits [127:64] and bits [255:192] of the destination. For -///example, if bits [7:0] of the immediate operand contain a value of 0xFF, -///the 256-bit destination vector would contain the following values: b[7], -///b[7], a[7], a[7], b[3], b[3], a[3], a[3]. +///specified by the immediate value operand. +/// +///The four selected elements in each operand are copied to the destination +///according to the bits specified in the immediate operand. The selected +///elements from the first 256-bit operand are copied to bits [63:0] and +///bits [191:128] of the destination, and the selected elements from the +///second 256-bit operand are copied to bits [127:64] and bits [255:192] of +///the destination. For example, if bits [7:0] of the immediate operand +///contain a value of 0xFF, the 256-bit destination vector would contain the +///following values: b[7], b[7], a[7], a[7], b[3], b[3], a[3], a[3]. /// /// \headerfile /// @@ -1557,13 +1559,14 @@ _mm256_blendv_ps(__m256 __a, __m256 __b, 12 + (((mask) >> 6) & 0x3)); }) /// \brief Selects four double-precision values from the 256-bit operands of -///[4 x double], as specified by the immediate value operand. The selected -///elements from the first 256-bit operand are copied to bits [63:0] and -///bits [191:128] in the destination, and the selected elements from the -///second 256-bit operand are copied to bits [127:64] and bits [255:192] in -///the destination. For example, if bits [3:0] of the immediate operand -///contain a value of 0xF, the 256-bit destination vector would contain the -///following values: b[3], a[3], b[1], a[1]. +///[4 x double], as specified by the immediate value operand. +/// +///The selected elements from the first 256-bit operand are copied to bits +///[63:0] and bits [191:128] in the destination, and the selected elements +///from the second 256-bit operand are copied to bits [127:64] and bits +///[255:192] in the destination. For example, if bits [3:0] of the immediate +///operand contain a value of 0xF, the 256-bit destination vector would +///contain the following values: b[3], a[3], b[1], a[1].
