[PATCH] D24933: Enable configuration files in clang
sepavloff updated this revision to Diff 78652.
sepavloff added a comment.
Herald added a subscriber: aemerson.
Updated patch.
- Restrict the search for config files specified by mangled clang name to
binary directory only,
- Allow the search for config files specified by `--config` in binary directory
also,
- Added tests for using mangled clang names and nested file inclusion.
https://reviews.llvm.org/D24933
Files:
docs/UsersManual.rst
include/clang/Driver/Driver.h
lib/Driver/Driver.cpp
test/Driver/Inputs/config-1.cfg
test/Driver/Inputs/config-2.cfg
test/Driver/Inputs/config-3.cfg
test/Driver/Inputs/config/config-4.cfg
test/Driver/config-file.c
test/Driver/config-file2.c
test/Driver/lit.local.cfg
tools/driver/driver.cpp
Index: tools/driver/driver.cpp
===
--- tools/driver/driver.cpp
+++ tools/driver/driver.cpp
@@ -305,6 +305,35 @@
return 1;
}
+// Directories searched for configuration specified by option '--config'.
+static const char * const SearchDirs[] = { "~/.llvm" };
+
+/// Deduce configuration name if it is encoded in the executable name.
+///
+/// \param ConfigFile [out] Is assigned configuration file path.
+/// \param ProgramName [in] clang executable path.
+/// \return True if configuration file was found.
+///
+/// If clang executable is named e.g. 'armv7l-clang' the function tries to
+/// find config file 'armv7l.cfg'. If it is found, its path is put into
+/// ConfigFile and the function returns true.
+///
+static bool findConfigFileFromProgramName(
+llvm::SmallVectorImpl &ConfigFile, StringRef ProgramName) {
+ ConfigFile.clear();
+ StringRef PName = llvm::sys::path::stem(ProgramName);
+ size_t Pos = PName.find("-clang");
+ if (Pos != StringRef::npos) {
+ConfigFile.append(PName.begin(), PName.begin() + Pos);
+const StringRef Ext(".cfg");
+ConfigFile.append(Ext.begin(), Ext.end());
+std::string CName(ConfigFile.begin(), ConfigFile.size());
+return llvm::cl::searchForFile(ConfigFile, ArrayRef(),
+ ProgramName, CName);
+ }
+ return false;
+}
+
int main(int argc_, const char **argv_) {
llvm::sys::PrintStackTraceOnErrorSignal(argv_[0]);
llvm::PrettyStackTraceProgram X(argc_, argv_);
@@ -330,6 +359,31 @@
llvm::BumpPtrAllocator A;
llvm::StringSaver Saver(A);
+ // Try reading options from configuration file.
+ llvm::SmallString<128> ConfigFile;
+ llvm::cl::SearchResult SRes;
+
+ // First try config file specified in command line. It has higher priority
+ // than any other way to specify configuration.
+ SRes = llvm::cl::findConfigFileFromArgs(ConfigFile, argv, SearchDirs, true);
+ if (llvm::cl::checkConfigFileSearchResult(SRes, ConfigFile, SearchDirs, true,
+ProgName))
+return 1;
+
+ // If config file is not specified explicitly, try to determine configuration
+ // implicitly. First try to deduce configuration from executable name. For
+ // instance, a file 'armv7l-clang' applies config file 'armv7l.cfg'. Second,
+ // try to find file 'clang.cfg'.
+ if (SRes == llvm::cl::SearchResult::NotSpecified) {
+if (findConfigFileFromProgramName(ConfigFile, ProgName))
+ SRes = llvm::cl::SearchResult::Successful;
+ }
+
+ if (SRes == llvm::cl::SearchResult::Successful) {
+unsigned NumOpts;
+llvm::cl::readConfigFile(ConfigFile, Saver, argv, NumOpts);
+ }
+
// Parse response files using the GNU syntax, unless we're in CL mode. There
// are two ways to put clang in CL compatibility mode: argv[0] is either
// clang-cl or cl, or --driver-mode=cl is on the command line. The normal
@@ -446,6 +500,8 @@
ProcessWarningOptions(Diags, *DiagOpts, /*ReportDiags=*/false);
Driver TheDriver(Path, llvm::sys::getDefaultTargetTriple(), Diags);
+ if (!ConfigFile.empty())
+TheDriver.setConfigFile(ConfigFile.str());
SetInstallDir(argv, TheDriver, CanonicalPrefixes);
insertTargetAndModeArgs(TargetAndMode.first, TargetAndMode.second, argv,
Index: test/Driver/lit.local.cfg
===
--- test/Driver/lit.local.cfg
+++ test/Driver/lit.local.cfg
@@ -4,6 +4,8 @@
config.substitutions.insert(0,
('%clang_cc1',
"""*** Do not use 'clang -cc1' in Driver tests. ***""") )
+config.substitutions.append( ('%bindir',
+ os.path.dirname(config.clang)) )
# Remove harmful environmental variables for clang Driver tests.
# Some might be useful for other tests so they are only removed here.
Index: test/Driver/config-file2.c
===
--- /dev/null
+++ test/Driver/config-file2.c
@@ -0,0 +1,29 @@
+// REQUIRES: shell
+
+//--- Invocation qqq-clang tries to find config file qqq.cfg
+//
+// RUN: mkdir -p %T/testbin
+// RUN: [ ! -s %T/testbin/qqq-clang ] || rm %T/testbin/qqq-clang
+// RUN: ln -s %clang %T/testbin/qqq-clang
+// RUN:
r287483 - Add doxygen comments to immintrin.h's intrinsics.
Author: kromanova
Date: Sun Nov 20 02:35:05 2016
New Revision: 287483
URL: http://llvm.org/viewvc/llvm-project?rev=287483&view=rev
Log:
Add doxygen comments to immintrin.h's intrinsics.
The doxygen comments are automatically generated based on Sony's intrinsics docu
ment.
I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream. This patch was internally reviewed by Charles Li.
Modified:
cfe/trunk/lib/Headers/immintrin.h
Modified: cfe/trunk/lib/Headers/immintrin.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/immintrin.h?rev=287483&r1=287482&r2=287483&view=diff
==
--- cfe/trunk/lib/Headers/immintrin.h (original)
+++ cfe/trunk/lib/Headers/immintrin.h Sun Nov 20 02:35:05 2016
@@ -69,9 +69,44 @@
Intel documents these as being in immintrin.h, and
they depend on typedefs from avxintrin.h. */
+/// \brief Converts a 256-bit vector of [8 x float] into a 128-bit vector
+///containing 16-bit half-precision float values.
+///
+/// \headerfile
+///
+/// \code
+/// __m128i _mm256_cvtps_ph(__m256 a, const int imm);
+/// \endcode
+///
+/// This intrinsic corresponds to the \c VCVTPS2PH instruction.
+///
+/// \param a
+///A 256-bit vector containing 32-bit single-precision float values to be
+///converted to 16-bit half-precision float values.
+/// \param imm
+///An immediate value controlling rounding using bits [2:0]:
+///000: Nearest
+///001: Down
+///010: Up
+///011: Truncate
+///1XX: Use MXCSR.RC for rounding
+/// \returns A 128-bit vector containing the converted 16-bit half-precision
+///float values.
#define _mm256_cvtps_ph(a, imm) __extension__ ({ \
(__m128i)__builtin_ia32_vcvtps2ph256((__v8sf)(__m256)(a), (imm)); })
+/// \brief Converts a 128-bit vector containing 16-bit half-precision float
+///values into a 256-bit vector of [8 x float].
+///
+/// \headerfile
+///
+/// This intrinsic corresponds to the \c VCVTPH2PS instruction.
+///
+/// \param __a
+///A 128-bit vector containing 16-bit half-precision float values to be
+///converted to 32-bit single-precision float values.
+/// \returns A vector of [8 x float] containing the converted 32-bit
+///single-precision float values.
static __inline __m256 __attribute__((__always_inline__, __nodebug__,
__target__("f16c")))
_mm256_cvtph_ps(__m128i __a)
{
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D24933: Enable configuration files in clang
hfinkel added a comment. What happens with unused arguments in the configuration files? This feature looks potentially useful for me, but only if it suppresses unused-argument warnings. For example, if I put -L/usr/local/lib -stdlib=libc++ into a configuration file, I can't have these: clang-4.0: warning: argument unused during compilation: '-L/usr/local/lib' [-Wunused-command-line-argument] clang-4.0: warning: argument unused during compilation: '-stdlib=libc++' [-Wunused-command-line-argument] pop up when compiling all over the place. https://reviews.llvm.org/D24933 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26829: [clang] Allow lexer to handle string_view literals
AntonBikineev updated this revision to Diff 78654.
AntonBikineev added a comment.
Richard, thanks, I addressed your comments.
https://reviews.llvm.org/D26829
Files:
include/clang/Lex/LiteralSupport.h
lib/Lex/Lexer.cpp
lib/Lex/LiteralSupport.cpp
lib/Sema/SemaDeclCXX.cpp
test/SemaCXX/cxx1z-user-defined-literals.cpp
Index: test/SemaCXX/cxx1z-user-defined-literals.cpp
===
--- test/SemaCXX/cxx1z-user-defined-literals.cpp
+++ test/SemaCXX/cxx1z-user-defined-literals.cpp
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -std=c++1z %s -include %s -verify
+
+#ifndef INCLUDED
+#define INCLUDED
+
+#pragma clang system_header
+namespace std {
+ using size_t = decltype(sizeof(0));
+
+ struct string_view {};
+ string_view operator""sv(const char*, size_t);
+}
+
+#else
+
+using namespace std;
+string_view s = "foo"sv;
+const char* p = "bar"sv; // expected-error {{no viable conversion}}
+char error = 'x'sv; // expected-error {{invalid suffix}} expected-error
{{expected ';'}}
+
+#endif
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -12908,7 +12908,7 @@
// Literal suffix identifiers that do not start with an underscore
// are reserved for future standardization.
Diag(FnDecl->getLocation(), diag::warn_user_literal_reserved)
- << NumericLiteralParser::isValidUDSuffix(getLangOpts(), LiteralName);
+ << StringLiteralParser::isValidUDSuffix(getLangOpts(), LiteralName);
}
return false;
Index: lib/Lex/LiteralSupport.cpp
===
--- lib/Lex/LiteralSupport.cpp
+++ lib/Lex/LiteralSupport.cpp
@@ -1708,3 +1708,12 @@
return SpellingPtr-SpellingStart;
}
+
+/// Determine whether a suffix is a valid ud-suffix. We avoid treating reserved
+/// suffixes as ud-suffixes, because the diagnostic experience is better if we
+/// treat it as an invalid suffix.
+bool StringLiteralParser::isValidUDSuffix(const LangOptions &LangOpts,
+ StringRef Suffix) {
+ return NumericLiteralParser::isValidUDSuffix(LangOpts, Suffix) ||
+ Suffix == "sv";
+}
Index: include/clang/Lex/LiteralSupport.h
===
--- include/clang/Lex/LiteralSupport.h
+++ include/clang/Lex/LiteralSupport.h
@@ -259,6 +259,8 @@
return UDSuffixOffset;
}
+ static bool isValidUDSuffix(const LangOptions &LangOpts, StringRef Suffix);
+
private:
void init(ArrayRef StringToks);
bool CopyStringFragment(const Token &Tok, const char *TokBegin,
Index: lib/Lex/Lexer.cpp
===
--- lib/Lex/Lexer.cpp
+++ lib/Lex/Lexer.cpp
@@ -1713,9 +1713,10 @@
getLangOpts());
if (!isIdentifierBody(Next)) {
// End of suffix. Check whether this is on the whitelist.
- IsUDSuffix = (Chars == 1 && Buffer[0] == 's') ||
- NumericLiteralParser::isValidUDSuffix(
- getLangOpts(), StringRef(Buffer, Chars));
+ const StringRef CompleteSuffix(Buffer, Chars);
+ const LangOptions &LangOpts = getLangOpts();
+ IsUDSuffix =
+ StringLiteralParser::isValidUDSuffix(LangOpts, CompleteSuffix);
break;
}
Index: test/SemaCXX/cxx1z-user-defined-literals.cpp
===
--- test/SemaCXX/cxx1z-user-defined-literals.cpp
+++ test/SemaCXX/cxx1z-user-defined-literals.cpp
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -std=c++1z %s -include %s -verify
+
+#ifndef INCLUDED
+#define INCLUDED
+
+#pragma clang system_header
+namespace std {
+ using size_t = decltype(sizeof(0));
+
+ struct string_view {};
+ string_view operator""sv(const char*, size_t);
+}
+
+#else
+
+using namespace std;
+string_view s = "foo"sv;
+const char* p = "bar"sv; // expected-error {{no viable conversion}}
+char error = 'x'sv; // expected-error {{invalid suffix}} expected-error {{expected ';'}}
+
+#endif
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -12908,7 +12908,7 @@
// Literal suffix identifiers that do not start with an underscore
// are reserved for future standardization.
Diag(FnDecl->getLocation(), diag::warn_user_literal_reserved)
- << NumericLiteralParser::isValidUDSuffix(getLangOpts(), LiteralName);
+ << StringLiteralParser::isValidUDSuffix(getLangOpts(), LiteralName);
}
return false;
Index: lib/Lex/LiteralSupport.cpp
===
--- lib/Lex/LiteralSupport.cpp
+++ lib/Lex/LiteralSupport.cpp
@@ -1708,3 +1708,12 @@
return SpellingPtr-SpellingStart;
}
+
+/// Determine whethe
[PATCH] D26465: [Diag] Optimize DiagnosticIDs::getDiagnosticSeverity
ogoffart added a comment. ping? https://reviews.llvm.org/D26465 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26350: Keep invalid Switch in the AST
ogoffart added a comment. ping? https://reviews.llvm.org/D26350 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D24933: Enable configuration files in clang
sepavloff marked 5 inline comments as done.
sepavloff added a comment.
> Rather than inventing a new mechanism, could we extend our existing `@file`
> facility to support comments and nested inclusion of further `@file`s?
Reusing `@file` is an attractive idea, but it cannot be implemented due to
compatibility reason. The file in `@file` is resolved relative to current
directory in both msvc and libiberty. Current directory may change during
build, so use of `@file` to deliver set of flags to every invocation of clang
becomes unrealistic. Config files instead are taken from well-known places and
if a user set `CFLAGS='--config abc.cfg'` in call to make, it should work as
intended.
> For `clang --config myfile.cfg`, should it also search the current working
> directory?
I believe no, current directory is not reliable place for configurations, as it
may change during build.
> Whoever makes the `blah-clang` symlink should get to control what the default
> configuration for `blah-clang` is, I think.
The patch is changed so that config file for `blah-clang` is searched for
*only* in the directory where `blah-clang` resides. It prevents a user from
overwriting 'system' config files. The idea is that the files in the binary
directory are prepared by SDK suppliers who adapt clang for specific needs.
> I'm not keen on it searching in `~/.llvm`.
The patch is changed so that `~/.llvm` is searched only of config files
specified explicitly by `--config`. A user can specify full path to the config
file: `clang --config ~/.llvm/abc.cfg`. By making the search in `~/.llvm` we
make work with config files a bit more convenient.
> you can replace a blah-clang symlink with a shell script containing `exec
> clang @blah.cfg "@$"`
Due to intermediate shell the environment variables which were not exported
would be lost. This solution is OK for build system but from viewpoint of
compiler, which must work in any build system, it is too fragile.
Comment at: docs/UsersManual.rst:667
+extension `cfg` if it is not specified yet, and the obtained file name is
searched
+for in the directories: `~/.llvm` and the directory where clang executable
resides.
+The first found file is used. It is an error if the required file cannot be
found.
srhines wrote:
> rsmith wrote:
> > hans wrote:
> > > The "add .cfg extension" magic seems a little awkward. It seems this is
> > > mixing the possibility of taking a filename and taking some other name.
> > >
> > > For `clang --config myfile.cfg`, should it also search the current
> > > working directory?
> > >
> > > I'm not keen on it searching in `~/.llvm`.
> > I'm also not keen on searching `~/.llvm`. Whoever makes the `blah-clang`
> > symlink should get to control what the default configuration for
> > `blah-clang` is, I think. But then this seems to immediately lead to the
> > conclusion that we don't need this implicit-config-file feature at all,
> > since you can replace a `blah-clang` symlink with a shell script containing
> > `exec clang @blah.cfg "@$"` -- and it's better to handle it that way, since
> > you get more control over where the config file lives.
> Android is essentially taking the shell script wrapper approach today
> (although we are using python, and we don't do a lot with it just yet).
Agree, removed this feature.
Comment at: docs/UsersManual.rst:694
+the including file. For instance if a config file `~/.llvm/target.cfg` contains
+directive `os/linux.opts`, the file `linux.opts` is searched for in the
directory
+`~/.llvm/os`.
hans wrote:
> I guess you mean directive `@os/linux.opts`?
Yes, thank you for the catch.
Comment at: test/Driver/config-file.c:10
+
+// RUN: not %clang --config inexistent.cfg -c %s -### 2>&1 | FileCheck %s
-check-prefix CHECK-INEX-NOSEARCH
+// CHECK-INEX-NOSEARCH: Configuration {{.*}}inexistent.cfg' specified by
option '--config' cannot be found in directories:
hans wrote:
> This test will fail if I have a `~/.llvm/inexistent.cfg` file on my machine.
Changed the name to more long and awkward to reduce chance of clash.
Comment at: test/Driver/config-file.c:13
+// CHECK-INEX-NOSEARCH: ~/.llvm
+// CHECK-INEX-NOSEARCH: /etc/llvm
+
hans wrote:
> Where did `/etc/llvm` come from?
Remnants of the previous variant, removed.
Comment at: test/Driver/config-file.c:14
+// CHECK-INEX-NOSEARCH: /etc/llvm
+
+// RUN: %clang --config %S/Inputs/config-2.cfg -### 2>&1 | FileCheck %s
-check-prefix CHECK-HHH-NOFILE
hans wrote:
> There is no test checking the functionality that finds a config file based on
> the clang executable name.
Added tests (file config-file2.c).
https://reviews.llvm.org/D24933
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
[PATCH] D24933: Enable configuration files in clang
mgorny added a comment. In https://reviews.llvm.org/D24933#600884, @sepavloff wrote: > > Whoever makes the `blah-clang` symlink should get to control what the > > default configuration for `blah-clang` is, I think. > > The patch is changed so that config file for `blah-clang` is searched for > *only* in the directory where `blah-clang` resides. It prevents a user from > overwriting 'system' config files. The idea is that the files in the binary > directory are prepared by SDK suppliers who adapt clang for specific needs. I think this killed my use case. Could this be extended to somehow allow providing configuration for the compiler installed in standard *nix layout? I.e. make it possible to make it search ../../etc/clang or something like that? >> you can replace a blah-clang symlink with a shell script containing `exec >> clang @blah.cfg "@$"` > > Due to intermediate shell the environment variables which were not exported > would be lost. This solution is OK for build system but from viewpoint of > compiler, which must work in any build system, it is too fragile. I think you are wrong here, or I'm missing something. When clang is spawned, only exported variables are passed to it. An intermediate shell layer won't change this. However, I don't think forcing an additional wrapper for all clang invocations is a neat idea. https://reviews.llvm.org/D24933 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26258: [AVX512][clang] Amending vpmultishiftqb
coby abandoned this revision. coby added a comment. deprecated. Repository: rL LLVM https://reviews.llvm.org/D26258 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26750: [clang-tidy] Add modernize-use-default-member-init check
malcolm.parsons updated this revision to Diff 78663.
malcolm.parsons added a comment.
Use llvm_unreachable.
Ignore template instantiations.
https://reviews.llvm.org/D26750
Files:
clang-tidy/modernize/CMakeLists.txt
clang-tidy/modernize/ModernizeTidyModule.cpp
clang-tidy/modernize/UseDefaultMemberInitCheck.cpp
clang-tidy/modernize/UseDefaultMemberInitCheck.h
docs/ReleaseNotes.rst
docs/clang-tidy/checks/list.rst
docs/clang-tidy/checks/modernize-use-default-member-init.rst
test/clang-tidy/modernize-use-default-member-init-assignment.cpp
test/clang-tidy/modernize-use-default-member-init.cpp
Index: test/clang-tidy/modernize-use-default-member-init.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-default-member-init.cpp
@@ -0,0 +1,220 @@
+// RUN: %check_clang_tidy %s modernize-use-default-member-init %t -- -- -std=c++11
+
+struct S {
+};
+
+struct PositiveValueInt {
+ PositiveValueInt() : i() {}
+ // CHECK-FIXES: PositiveValueInt() {}
+ const int i;
+ // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use default member initializer for 'i' [modernize-use-default-member-init]
+ // CHECK-FIXES: const int i{};
+};
+
+struct PositiveInt {
+ PositiveInt() : j(1) {}
+ // CHECK-FIXES: PositiveInt() {}
+ int j;
+ // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use default member initializer for 'j' [modernize-use-default-member-init]
+ // CHECK-FIXES: int j{1};
+};
+
+struct PositiveValueDouble {
+ PositiveValueDouble() : d() {}
+ // CHECK-FIXES: PositiveValueDouble() {}
+ double d;
+ // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: use default member initializer for 'd' [modernize-use-default-member-init]
+ // CHECK-FIXES: double d{};
+};
+
+struct PositiveDouble {
+ PositiveDouble() : f(2.5463e43) {}
+ // CHECK-FIXES: PositiveDouble() {}
+ double f;
+ // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: use default member initializer for 'f' [modernize-use-default-member-init]
+ // CHECK-FIXES: double f{2.5463e43};
+};
+
+struct PositiveValueBool {
+ PositiveValueBool() : b() {}
+ // CHECK-FIXES: PositiveValueBool() {}
+ bool b;
+ // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: use default member initializer for 'b' [modernize-use-default-member-init]
+ // CHECK-FIXES: bool b{};
+};
+
+struct PositiveBool {
+ PositiveBool() : a(true) {}
+ // CHECK-FIXES: PositiveBool() {}
+ bool a;
+ // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: use default member initializer for 'a' [modernize-use-default-member-init]
+ // CHECK-FIXES: bool a{true};
+};
+
+struct PositiveValuePointer {
+ PositiveValuePointer() : p() {}
+ // CHECK-FIXES: PositiveValuePointer() {}
+ int *p;
+ // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: use default member initializer for 'p' [modernize-use-default-member-init]
+ // CHECK-FIXES: int *p{};
+};
+
+struct PositiveNullPointer {
+ PositiveNullPointer() : q(nullptr) {}
+ // CHECK-FIXES: PositiveNullPointer() {}
+ int *q;
+ // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: use default member initializer for 'q' [modernize-use-default-member-init]
+ // CHECK-FIXES: int *q{nullptr};
+};
+
+enum Enum { Foo, Bar };
+struct PositiveEnum {
+ PositiveEnum() : e(Foo) {}
+ // CHECK-FIXES: PositiveEnum() {}
+ Enum e;
+ // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: use default member initializer for 'e' [modernize-use-default-member-init]
+ // CHECK-FIXES: Enum e{Foo};
+};
+
+template
+struct NegativeTemplate {
+NegativeTemplate() : t() {}
+T t;
+};
+
+NegativeTemplate nti;
+NegativeTemplate ntd;
+
+struct NegativeDefaultMember {
+ NegativeDefaultMember() {}
+ int i = 2;
+};
+
+struct NegativeClass : S {
+ NegativeClass() : s() {}
+ S s;
+};
+
+struct NegativeBase : S {
+ NegativeBase() : S() {}
+};
+
+struct NegativeDefaultOtherMember{
+ NegativeDefaultOtherMember() : i(3) {}
+ int i = 4;
+};
+
+struct NegativeUnion {
+ NegativeUnion() : d(5.0) {}
+ union {
+int i;
+double d;
+ };
+};
+
+struct NegativeBitField
+{
+ NegativeBitField() : i(6) {}
+ int i : 5;
+};
+
+struct NegativeNotDefaultInt
+{
+ NegativeNotDefaultInt(int) : i(7) {}
+ int i;
+};
+
+struct ExistingInt {
+ ExistingInt(short) : e1(), e2(), e3(), e4() {}
+ // CHECK-MESSAGES: :[[@LINE-1]]:24: warning: member initializer for 'e1' is redundant [modernize-use-default-member-init]
+ // CHECK-MESSAGES: :[[@LINE-2]]:30: warning: member initializer for 'e2' is redundant [modernize-use-default-member-init]
+ // CHECK-FIXES: ExistingInt(short) : e3(), e4() {}
+ ExistingInt(int) : e1(0), e2(0), e3(0), e4(0) {}
+ // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: member initializer for 'e1' is redundant [modernize-use-default-member-init]
+ // CHECK-MESSAGES: :[[@LINE-2]]:29: warning: member initializer for 'e2' is redundant [modernize-use-default-member-init]
+ // CHECK-FIXES: ExistingInt(int) : e3(0), e4(0) {}
+ ExistingInt(long) : e1(5), e2(5), e3(5), e4(5) {}
+ // CHECK-MESSAGES: :[[@LINE-1]]:37: warning: member initia
[libcxx] r287507 - Merge r286774 - Fixes PR30979
Author: ericwf
Date: Sun Nov 20 15:33:12 2016
New Revision: 287507
URL: http://llvm.org/viewvc/llvm-project?rev=287507&view=rev
Log:
Merge r286774 - Fixes PR30979
Modified:
libcxx/branches/release_39/include/tuple
libcxx/branches/release_39/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/move.pass.cpp
Modified: libcxx/branches/release_39/include/tuple
URL:
http://llvm.org/viewvc/llvm-project/libcxx/branches/release_39/include/tuple?rev=287507&r1=287506&r2=287507&view=diff
==
--- libcxx/branches/release_39/include/tuple (original)
+++ libcxx/branches/release_39/include/tuple Sun Nov 20 15:33:12 2016
@@ -681,7 +681,7 @@ public:
<
_CheckArgsConstructor<
_Dummy
- >::template __enable_implicit<_Tp...>(),
+ >::template __enable_implicit<_Tp const&...>(),
bool
>::type = false
>
@@ -699,7 +699,7 @@ public:
<
_CheckArgsConstructor<
_Dummy
- >::template __enable_explicit<_Tp...>(),
+ >::template __enable_explicit<_Tp const&...>(),
bool
>::type = false
>
@@ -717,7 +717,7 @@ public:
<
_CheckArgsConstructor<
_Dummy
- >::template __enable_implicit<_Tp...>(),
+ >::template __enable_implicit<_Tp const&...>(),
bool
>::type = false
>
@@ -736,7 +736,7 @@ public:
<
_CheckArgsConstructor<
_Dummy
- >::template __enable_explicit<_Tp...>(),
+ >::template __enable_explicit<_Tp const&...>(),
bool
>::type = false
>
Modified:
libcxx/branches/release_39/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/move.pass.cpp
URL:
http://llvm.org/viewvc/llvm-project/libcxx/branches/release_39/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/move.pass.cpp?rev=287507&r1=287506&r2=287507&view=diff
==
---
libcxx/branches/release_39/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/move.pass.cpp
(original)
+++
libcxx/branches/release_39/test/std/utilities/tuple/tuple.tuple/tuple.cnstr/move.pass.cpp
Sun Nov 20 15:33:12 2016
@@ -35,6 +35,52 @@ struct ConstructsWithTupleLeaf
}
};
+// move_only type which triggers the empty base optimization
+struct move_only_ebo {
+ move_only_ebo() = default;
+ move_only_ebo(move_only_ebo&&) = default;
+};
+
+// a move_only type which does not trigger the empty base optimization
+struct move_only_large final {
+ move_only_large() : value(42) {}
+ move_only_large(move_only_large&&) = default;
+ int value;
+};
+
+template
+void test_sfinae() {
+using Tup = std::tuple;
+using Alloc = std::allocator;
+using Tag = std::allocator_arg_t;
+// special members
+{
+static_assert(std::is_default_constructible::value, "");
+static_assert(std::is_move_constructible::value, "");
+static_assert(!std::is_copy_constructible::value, "");
+static_assert(!std::is_constructible::value, "");
+}
+// args constructors
+{
+static_assert(std::is_constructible::value, "");
+static_assert(!std::is_constructible::value, "");
+static_assert(!std::is_constructible::value, "");
+}
+// uses-allocator special member constructors
+{
+static_assert(std::is_constructible::value, "");
+static_assert(std::is_constructible::value,
"");
+static_assert(!std::is_constructible::value, "");
+static_assert(!std::is_constructible::value,
"");
+}
+// uses-allocator args constructors
+{
+static_assert(std::is_constructible::value,
"");
+static_assert(!std::is_constructible::value, "");
+static_assert(!std::is_constructible::value,
"");
+}
+}
+
int main()
{
{
@@ -72,4 +118,8 @@ int main()
d_t d((ConstructsWithTupleLeaf()));
d_t d2(static_cast(d));
}
+{
+test_sfinae();
+test_sfinae();
+}
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26900: [cmake] Obtain LLVM_CMAKE_PATH from llvm-config
mgorny created this revision.
mgorny added reviewers: beanz, rnk, chapuni, chandlerc.
mgorny added a subscriber: cfe-commits.
Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config instead of reconstructing it locally.
https://reviews.llvm.org/D26900
Files:
CMakeLists.txt
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -16,7 +16,8 @@
"--libdir"
"--includedir"
"--prefix"
- "--src-root")
+ "--src-root"
+ "--cmakedir")
execute_process(
COMMAND ${CONFIG_COMMAND}
RESULT_VARIABLE HAD_ERROR
@@ -41,6 +42,7 @@
list(GET CONFIG_OUTPUT 3 INCLUDE_DIR)
list(GET CONFIG_OUTPUT 4 LLVM_OBJ_ROOT)
list(GET CONFIG_OUTPUT 5 MAIN_SRC_DIR)
+ list(GET CONFIG_OUTPUT 6 LLVM_CMAKE_PATH)
if(NOT MSVC_IDE)
set(LLVM_ENABLE_ASSERTIONS ${ENABLE_ASSERTIONS}
@@ -58,7 +60,6 @@
find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
NO_DEFAULT_PATH)
- set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
set(LLVMCONFIG_FILE "${LLVM_CMAKE_PATH}/LLVMConfig.cmake")
if(EXISTS ${LLVMCONFIG_FILE})
list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -16,7 +16,8 @@
"--libdir"
"--includedir"
"--prefix"
- "--src-root")
+ "--src-root"
+ "--cmakedir")
execute_process(
COMMAND ${CONFIG_COMMAND}
RESULT_VARIABLE HAD_ERROR
@@ -41,6 +42,7 @@
list(GET CONFIG_OUTPUT 3 INCLUDE_DIR)
list(GET CONFIG_OUTPUT 4 LLVM_OBJ_ROOT)
list(GET CONFIG_OUTPUT 5 MAIN_SRC_DIR)
+ list(GET CONFIG_OUTPUT 6 LLVM_CMAKE_PATH)
if(NOT MSVC_IDE)
set(LLVM_ENABLE_ASSERTIONS ${ENABLE_ASSERTIONS}
@@ -58,7 +60,6 @@
find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
NO_DEFAULT_PATH)
- set(LLVM_CMAKE_PATH "${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/cmake/llvm")
set(LLVMCONFIG_FILE "${LLVM_CMAKE_PATH}/LLVMConfig.cmake")
if(EXISTS ${LLVMCONFIG_FILE})
list(APPEND CMAKE_MODULE_PATH "${LLVM_CMAKE_PATH}")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26885: [libcxx] Fix max_size() across all containers
mclow.lists added inline comments.
Comment at: test/std/containers/associative/map/map.access/max_size.pass.cpp:24
+
+template size_t alloc_max_size(Alloc const &a) {
+ typedef std::allocator_traits AT;
How about a newline here? (after the `template<>`)
And why not hoist this into "test_allocator.h"?
https://reviews.llvm.org/D26885
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D24289: Add warning when assigning enums to bitfields without an explicit unsigned underlying type
Thanks for the great explanation, I agree with this advice. I'm going to
investigate writing a new patch to do this.
On Fri, Nov 18, 2016 at 1:59 PM, Arthur O'Dwyer
wrote:
> On Thu, Nov 17, 2016 at 2:14 PM, Sasha Bermeister
> wrote:
>
>> Although I agree with your philosophical discussion and suggestions, the
>> reality is that MSVC's behavior is not a bug and compilers are free to
>> interpret enum bitfields with no explicit underlying type in any way they
>> want (see spec reference in GCC bug link), with a signed interpretation
>> being a valid one. I'd say it's undefined behavior in C/C++ to store an
>> enum in a bitfield without specifying an underlying type, since the
>> compiler is free to interpret this bitfield in any way it wants -- in
>> general, if you haven't specified an underlying type you should probably be
>> warned when trying to store it in a bitfield because the compiler may not
>> do what you expect.
>>
>
> Incorrect. The following program has perfectly well defined behavior:
>
> enum E { e = 0 };
> struct S { E bf : 4; } s;
> int main() { s.bf = e; }
>
> No compiler in the world should produce a warning on the above program.
>
> Also, once you've got a struct type containing an offending bit-field,
> *any* use of that bit-field is subject to the implementation-defined
> behavior you noticed on MSVC. It's not just limited to
> assignment-expressions of constants. That's why it's important to produce a
> warning on the *declaration* of the bit-field, not on each subsequent
> expression that refers to that bit-field.
>
> enum E2 { e = 0, f = 1, g = 2, h = 3 };
> struct S2 { E2 bf : 2; } s; // this line should trigger a diagnostic
> int main() { s.bf = e; }
>
> Also, the current patch's diagnostic wording suggests to "consider giving
> the enum E an unsigned underlying type", which would be very bad advice in
> this situation (because it only works in C++11, and because it triggers a
> GCC bug, and because it has non-local effects on the program's semantics).
> The correct advice is to "consider giving the bit-field bf a width of 3
> bits instead of 2."
>
> HTH,
> –Arthur
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r287512 - Adjust uses_alloc_types helpers for later changes
Author: ericwf
Date: Sun Nov 20 18:41:32 2016
New Revision: 287512
URL: http://llvm.org/viewvc/llvm-project?rev=287512&view=rev
Log:
Adjust uses_alloc_types helpers for later changes
Modified:
libcxx/trunk/test/support/uses_alloc_types.hpp
Modified: libcxx/trunk/test/support/uses_alloc_types.hpp
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/support/uses_alloc_types.hpp?rev=287512&r1=287511&r2=287512&view=diff
==
--- libcxx/trunk/test/support/uses_alloc_types.hpp (original)
+++ libcxx/trunk/test/support/uses_alloc_types.hpp Sun Nov 20 18:41:32 2016
@@ -191,7 +191,7 @@ private:
typename detail::Identity::type..., CtorAlloc const& alloc) {
return alloc;
}
-
+public:
const TypeID* args_id;
UsesAllocatorType constructor_called = UA_None;
CtorAlloc allocator;
@@ -208,6 +208,10 @@ public:
UsesAllocatorV1() : Base(&makeArgumentID<>()) {}
+UsesAllocatorV1(UsesAllocatorV1 const&)
+: Base(&makeArgumentID()) {}
+UsesAllocatorV1(UsesAllocatorV1 &&)
+: Base(&makeArgumentID()) {}
// Non-Uses Allocator Ctor
template = false>
UsesAllocatorV1(Args&&... args) : Base(&makeArgumentID()) {};
@@ -237,6 +241,10 @@ public:
using CtorAlloc = typename Base::CtorAlloc;
UsesAllocatorV2() : Base(&makeArgumentID<>()) {}
+UsesAllocatorV2(UsesAllocatorV2 const&)
+: Base(&makeArgumentID()) {}
+UsesAllocatorV2(UsesAllocatorV2 &&)
+: Base(&makeArgumentID()) {}
// Non-Uses Allocator Ctor
template = false>
@@ -259,6 +267,10 @@ public:
using CtorAlloc = typename Base::CtorAlloc;
UsesAllocatorV3() : Base(&makeArgumentID<>()) {}
+UsesAllocatorV3(UsesAllocatorV3 const&)
+: Base(&makeArgumentID()) {}
+UsesAllocatorV3(UsesAllocatorV3 &&)
+: Base(&makeArgumentID()) {}
// Non-Uses Allocator Ctor
template = false>
@@ -287,7 +299,10 @@ public:
using CtorAlloc = typename Base::CtorAlloc;
NotUsesAllocator() : Base(&makeArgumentID<>()) {}
-
+NotUsesAllocator(NotUsesAllocator const&)
+: Base(&makeArgumentID()) {}
+NotUsesAllocator(NotUsesAllocator &&)
+: Base(&makeArgumentID()) {}
// Non-Uses Allocator Ctor
template = false>
NotUsesAllocator(Args&&... args) : Base(&makeArgumentID()) {};
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26882: Refactor how FunctionDecl handles constexpr:
hubert.reinterpretcast added inline comments.
Comment at: include/clang/AST/Decl.h:1915
+IsConstexprSpecified = IC;
+IsConstexpr = IC;
+ }
How is the `inline` property transmitted here? Why does the
`setImplicitlyConstexpr` function need to call `setImplicitlyInline`?
Comment at: include/clang/AST/Decl.h:1919
+ /// Flag that this function as implicitly constexpr
+ /// C++11 [dcl.constexpr]p2: constexpr functions and constexpr constructors
+ /// are implicitly inline functions (7.1.2).
The quote does not seem to be pertinent here. Maybe have it a few lines down?
Comment at: include/clang/AST/Decl.h:1923
+IsConstexpr = IC;
+setImplicitlyInline();
+ }
I am quite sure this is not the right thing to do when `IC` is `false`.
Comment at: lib/Sema/SemaDecl.cpp:8085
// C++ Concepts TS [dcl.spec.concept]p2: Every concept definition is
// implicity defined to be a constexpr declaration (implicitly inline)
+ NewFD->setImplicitlyConstexpr(true);
The parenthetical here seems to be no longer needed.
Comment at: lib/Sema/SemaDecl.cpp:9107
<< FixItHint::CreateRemoval(DS.getConstexprSpecLoc());
-FD->setConstexpr(false);
+FD->setImplicitlyConstexpr(false);
}
This reads wrong to me. I get that the idea is that the function should not be
semantically considered `constexpr`, but the choice of `setImplicitlyConstexpr`
seems odd.
Comment at: test/CXX/concepts-ts/dcl.dcl/dcl.spec/dcl.spec.concept/p2.cpp:21
+static_assert(FCSizeOfU4(), "");
+static_assert(FCSizeOfU4(), "size of argument not equal to expected
(4)"); // expected-error {{static_assert failed "size of argument not equal to
expected (4)"}}
+
This does not strike me as being very portable (I may be mistaken about how
`clang -cc1` works though). I think it would be much safer to use `char [8]`
here (and in general for the size matching).
https://reviews.llvm.org/D26882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r287513 - Mark variadic lock guard tests as XFAIL with modules, since they have to define macros to expose the new ABI
Author: ericwf Date: Sun Nov 20 19:10:52 2016 New Revision: 287513 URL: http://llvm.org/viewvc/llvm-project?rev=287513&view=rev Log: Mark variadic lock guard tests as XFAIL with modules, since they have to define macros to expose the new ABI Modified: libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_adopt_lock.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_assign.fail.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_copy.fail.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.fail.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex_cxx03.pass.cpp libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_types.pass.cpp Modified: libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_adopt_lock.pass.cpp URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_adopt_lock.pass.cpp?rev=287513&r1=287512&r2=287513&view=diff == --- libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_adopt_lock.pass.cpp (original) +++ libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_adopt_lock.pass.cpp Sun Nov 20 19:10:52 2016 @@ -10,6 +10,10 @@ // UNSUPPORTED: libcpp-has-no-threads // UNSUPPORTED: c++98, c++03 +// FIXME: When modules are enabled we can't affect the contents of +// by defining a macro +// XFAIL: -fmodules + // // template class lock_guard; Modified: libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_assign.fail.cpp URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_assign.fail.cpp?rev=287513&r1=287512&r2=287513&view=diff == --- libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_assign.fail.cpp (original) +++ libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_assign.fail.cpp Sun Nov 20 19:10:52 2016 @@ -10,6 +10,10 @@ // UNSUPPORTED: libcpp-has-no-threads // UNSUPPORTED: c++98, c++03 +// FIXME: When modules are enabled we can't affect the contents of +// by defining a macro +// XFAIL: -fmodules + // // template class lock_guard; Modified: libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_copy.fail.cpp URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_copy.fail.cpp?rev=287513&r1=287512&r2=287513&view=diff == --- libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_copy.fail.cpp (original) +++ libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_copy.fail.cpp Sun Nov 20 19:10:52 2016 @@ -10,6 +10,10 @@ // UNSUPPORTED: libcpp-has-no-threads // UNSUPPORTED: c++98, c++03 +// FIXME: When modules are enabled we can't affect the contents of +// by defining a macro +// XFAIL: -fmodules + // // template class lock_guard; Modified: libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.fail.cpp URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.fail.cpp?rev=287513&r1=287512&r2=287513&view=diff == --- libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.fail.cpp (original) +++ libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.fail.cpp Sun Nov 20 19:10:52 2016 @@ -10,6 +10,10 @@ // UNSUPPORTED: libcpp-has-no-threads // UNSUPPORTED: c++98, c++03 +// FIXME: When modules are enabled we can't affect the contents of +// by defining a macro +// XFAIL: -fmodules + // // template class lock_guard; Modified: libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.pass.cpp URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.pass.cpp?rev=287513&r1=287512&r2=287513&view=diff == --- libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.pass.cpp (original) +++ libcxx/trunk/test/std/thread/thread.mutex/thread.lock/thread.lock.guard/variadic_mutex.pass.cpp Sun Nov 20 19:10:52 2
[PATCH] D26587: [X86][AVX512][InlineASM][MS][clang] (I|G)CC Memory adjustments compatibility
coby updated this revision to Diff 78681.
Repository:
rL LLVM
https://reviews.llvm.org/D26587
Files:
test/CodeGen/ms-inline-asm-avx512-memory-adjustments.c
Index: test/CodeGen/ms-inline-asm-avx512-memory-adjustments.c
===
--- test/CodeGen/ms-inline-asm-avx512-memory-adjustments.c
+++ test/CodeGen/ms-inline-asm-avx512-memory-adjustments.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 %s -triple x86_64-unknown-linux-gnu -emit-llvm -target-cpu
skylake-avx512 -fasm-blocks -o - | FileCheck %s
+
+// Case1: Check integrity of inspected patch upon broadcasting
+// Case2: Check integrity of inspected patch upon SIMD mem ref
+
+void F() {
+ char a;
+ // CHECK: vaddps xmm1, xmm2, dword ptr $0{1to4}
+ // CHECK: vaddps xmm1, xmm2, xmmword ptr $1
+ __asm vaddps xmm1, xmm2, [a]{1to4}
+ __asm vaddps xmm1, xmm2, [a]
+}
Index: test/CodeGen/ms-inline-asm-avx512-memory-adjustments.c
===
--- test/CodeGen/ms-inline-asm-avx512-memory-adjustments.c
+++ test/CodeGen/ms-inline-asm-avx512-memory-adjustments.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 %s -triple x86_64-unknown-linux-gnu -emit-llvm -target-cpu skylake-avx512 -fasm-blocks -o - | FileCheck %s
+
+// Case1: Check integrity of inspected patch upon broadcasting
+// Case2: Check integrity of inspected patch upon SIMD mem ref
+
+void F() {
+ char a;
+ // CHECK: vaddps xmm1, xmm2, dword ptr $0{1to4}
+ // CHECK: vaddps xmm1, xmm2, xmmword ptr $1
+ __asm vaddps xmm1, xmm2, [a]{1to4}
+ __asm vaddps xmm1, xmm2, [a]
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26903: [libcxx] Add tests (but not implementation)
CaseyCarter added a comment. I'll take a look at these tomorrow; I don't have easy access to my implementation with the changes from P0510 and P0504 from home (it's waiting on a compiler bugfix to checkin). Comment at: test/std/utilities/variant/variant.get/get_type.pass.cpp:18 +// template constexpr const T& get(const variant& v); +// template constexpr const T&& get(const variant&& v); + Space at end-of-line here. https://reviews.llvm.org/D26903 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26415: [XRay] Support AArch64 in Clang
This revision was automatically updated to reflect the committed changes.
Closed by commit rL287518: [XRay] Support AArch64 in Clang (authored by
dberris).
Changed prior to commit:
https://reviews.llvm.org/D26415?vs=78216&id=78685#toc
Repository:
rL LLVM
https://reviews.llvm.org/D26415
Files:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/XRay/xray-instrument-cpu.c
cfe/trunk/test/Driver/XRay/xray-instrument-os.c
Index: cfe/trunk/test/Driver/XRay/xray-instrument-cpu.c
===
--- cfe/trunk/test/Driver/XRay/xray-instrument-cpu.c
+++ cfe/trunk/test/Driver/XRay/xray-instrument-cpu.c
@@ -1,4 +1,4 @@
// RUN: not %clang -o /dev/null -v -fxray-instrument -c %s
-// XFAIL: amd64-, x86_64-, x86_64h-, arm
+// XFAIL: amd64-, x86_64-, x86_64h-, arm, aarch64, arm64
// REQUIRES: linux
typedef int a;
Index: cfe/trunk/test/Driver/XRay/xray-instrument-os.c
===
--- cfe/trunk/test/Driver/XRay/xray-instrument-os.c
+++ cfe/trunk/test/Driver/XRay/xray-instrument-os.c
@@ -1,4 +1,4 @@
// RUN: not %clang -o /dev/null -v -fxray-instrument -c %s
// XFAIL: -linux-
-// REQUIRES-ANY: amd64, x86_64, x86_64h, arm
+// REQUIRES-ANY: amd64, x86_64, x86_64h, arm, aarch64, arm64
typedef int a;
Index: cfe/trunk/lib/Driver/Tools.cpp
===
--- cfe/trunk/lib/Driver/Tools.cpp
+++ cfe/trunk/lib/Driver/Tools.cpp
@@ -4900,14 +4900,20 @@
if (Args.hasFlag(options::OPT_fxray_instrument,
options::OPT_fnoxray_instrument, false)) {
const char *const XRayInstrumentOption = "-fxray-instrument";
-if (Triple.getOS() == llvm::Triple::Linux &&
-(Triple.getArch() == llvm::Triple::arm ||
- Triple.getArch() == llvm::Triple::x86_64)) {
- // Supported.
-} else {
+if (Triple.getOS() == llvm::Triple::Linux)
+ switch (Triple.getArch()) {
+ case llvm::Triple::x86_64:
+ case llvm::Triple::arm:
+ case llvm::Triple::aarch64:
+// Supported.
+break;
+ default:
+D.Diag(diag::err_drv_clang_unsupported)
+<< (std::string(XRayInstrumentOption) + " on " + Triple.str());
+ }
+else
D.Diag(diag::err_drv_clang_unsupported)
- << (std::string(XRayInstrumentOption) + " on " + Triple.str());
-}
+ << (std::string(XRayInstrumentOption) + " on non-Linux target OS");
CmdArgs.push_back(XRayInstrumentOption);
if (const Arg *A =
Args.getLastArg(options::OPT_fxray_instruction_threshold_,
Index: cfe/trunk/test/Driver/XRay/xray-instrument-cpu.c
===
--- cfe/trunk/test/Driver/XRay/xray-instrument-cpu.c
+++ cfe/trunk/test/Driver/XRay/xray-instrument-cpu.c
@@ -1,4 +1,4 @@
// RUN: not %clang -o /dev/null -v -fxray-instrument -c %s
-// XFAIL: amd64-, x86_64-, x86_64h-, arm
+// XFAIL: amd64-, x86_64-, x86_64h-, arm, aarch64, arm64
// REQUIRES: linux
typedef int a;
Index: cfe/trunk/test/Driver/XRay/xray-instrument-os.c
===
--- cfe/trunk/test/Driver/XRay/xray-instrument-os.c
+++ cfe/trunk/test/Driver/XRay/xray-instrument-os.c
@@ -1,4 +1,4 @@
// RUN: not %clang -o /dev/null -v -fxray-instrument -c %s
// XFAIL: -linux-
-// REQUIRES-ANY: amd64, x86_64, x86_64h, arm
+// REQUIRES-ANY: amd64, x86_64, x86_64h, arm, aarch64, arm64
typedef int a;
Index: cfe/trunk/lib/Driver/Tools.cpp
===
--- cfe/trunk/lib/Driver/Tools.cpp
+++ cfe/trunk/lib/Driver/Tools.cpp
@@ -4900,14 +4900,20 @@
if (Args.hasFlag(options::OPT_fxray_instrument,
options::OPT_fnoxray_instrument, false)) {
const char *const XRayInstrumentOption = "-fxray-instrument";
-if (Triple.getOS() == llvm::Triple::Linux &&
-(Triple.getArch() == llvm::Triple::arm ||
- Triple.getArch() == llvm::Triple::x86_64)) {
- // Supported.
-} else {
+if (Triple.getOS() == llvm::Triple::Linux)
+ switch (Triple.getArch()) {
+ case llvm::Triple::x86_64:
+ case llvm::Triple::arm:
+ case llvm::Triple::aarch64:
+// Supported.
+break;
+ default:
+D.Diag(diag::err_drv_clang_unsupported)
+<< (std::string(XRayInstrumentOption) + " on " + Triple.str());
+ }
+else
D.Diag(diag::err_drv_clang_unsupported)
- << (std::string(XRayInstrumentOption) + " on " + Triple.str());
-}
+ << (std::string(XRayInstrumentOption) + " on non-Linux target OS");
CmdArgs.push_back(XRayInstrumentOption);
if (const Arg *A =
Args.getLastArg(options::OPT_fxray_instruction_threshold_,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r287518 - [XRay] Support AArch64 in Clang
Author: dberris
Date: Sun Nov 20 21:24:59 2016
New Revision: 287518
URL: http://llvm.org/viewvc/llvm-project?rev=287518&view=rev
Log:
[XRay] Support AArch64 in Clang
This patch adds XRay support in Clang for AArch64 target.
This patch is one of a series:
LLVM: https://reviews.llvm.org/D26412
compiler-rt: https://reviews.llvm.org/D26413
Author: rSerge
Reviewers: rengolin, dberris
Subscribers: aemerson, cfe-commits, iid_iunknown
Differential Revision: https://reviews.llvm.org/D26415
Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/XRay/xray-instrument-cpu.c
cfe/trunk/test/Driver/XRay/xray-instrument-os.c
Modified: cfe/trunk/lib/Driver/Tools.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=287518&r1=287517&r2=287518&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Sun Nov 20 21:24:59 2016
@@ -4900,14 +4900,20 @@ void Clang::ConstructJob(Compilation &C,
if (Args.hasFlag(options::OPT_fxray_instrument,
options::OPT_fnoxray_instrument, false)) {
const char *const XRayInstrumentOption = "-fxray-instrument";
-if (Triple.getOS() == llvm::Triple::Linux &&
-(Triple.getArch() == llvm::Triple::arm ||
- Triple.getArch() == llvm::Triple::x86_64)) {
- // Supported.
-} else {
+if (Triple.getOS() == llvm::Triple::Linux)
+ switch (Triple.getArch()) {
+ case llvm::Triple::x86_64:
+ case llvm::Triple::arm:
+ case llvm::Triple::aarch64:
+// Supported.
+break;
+ default:
+D.Diag(diag::err_drv_clang_unsupported)
+<< (std::string(XRayInstrumentOption) + " on " + Triple.str());
+ }
+else
D.Diag(diag::err_drv_clang_unsupported)
- << (std::string(XRayInstrumentOption) + " on " + Triple.str());
-}
+ << (std::string(XRayInstrumentOption) + " on non-Linux target OS");
CmdArgs.push_back(XRayInstrumentOption);
if (const Arg *A =
Args.getLastArg(options::OPT_fxray_instruction_threshold_,
Modified: cfe/trunk/test/Driver/XRay/xray-instrument-cpu.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/XRay/xray-instrument-cpu.c?rev=287518&r1=287517&r2=287518&view=diff
==
--- cfe/trunk/test/Driver/XRay/xray-instrument-cpu.c (original)
+++ cfe/trunk/test/Driver/XRay/xray-instrument-cpu.c Sun Nov 20 21:24:59 2016
@@ -1,4 +1,4 @@
// RUN: not %clang -o /dev/null -v -fxray-instrument -c %s
-// XFAIL: amd64-, x86_64-, x86_64h-, arm
+// XFAIL: amd64-, x86_64-, x86_64h-, arm, aarch64, arm64
// REQUIRES: linux
typedef int a;
Modified: cfe/trunk/test/Driver/XRay/xray-instrument-os.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/XRay/xray-instrument-os.c?rev=287518&r1=287517&r2=287518&view=diff
==
--- cfe/trunk/test/Driver/XRay/xray-instrument-os.c (original)
+++ cfe/trunk/test/Driver/XRay/xray-instrument-os.c Sun Nov 20 21:24:59 2016
@@ -1,4 +1,4 @@
// RUN: not %clang -o /dev/null -v -fxray-instrument -c %s
// XFAIL: -linux-
-// REQUIRES-ANY: amd64, x86_64, x86_64h, arm
+// REQUIRES-ANY: amd64, x86_64, x86_64h, arm, aarch64, arm64
typedef int a;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
