r287437 - Introduce a helper class for building complex constant initializers. NFC.
Author: rjmccall
Date: Sat Nov 19 02:17:24 2016
New Revision: 287437
URL: http://llvm.org/viewvc/llvm-project?rev=287437&view=rev
Log:
Introduce a helper class for building complex constant initializers. NFC.
I've adopted this in most of the places it makes sense, but v-tables
and CGObjCMac will need a second pass.
Added:
cfe/trunk/lib/CodeGen/ConstantBuilder.h
Modified:
cfe/trunk/include/clang/AST/DeclObjC.h
cfe/trunk/lib/CodeGen/CGBlocks.cpp
cfe/trunk/lib/CodeGen/CGCUDANV.cpp
cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
Modified: cfe/trunk/include/clang/AST/DeclObjC.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclObjC.h?rev=287437&r1=287436&r2=287437&view=diff
==
--- cfe/trunk/include/clang/AST/DeclObjC.h (original)
+++ cfe/trunk/include/clang/AST/DeclObjC.h Sat Nov 19 02:17:24 2016
@@ -870,6 +870,9 @@ public:
PropertyControl getPropertyImplementation() const {
return PropertyControl(PropertyImplementation);
}
+ bool isOptional() const {
+return getPropertyImplementation() == PropertyControl::Optional;
+ }
void setPropertyIvarDecl(ObjCIvarDecl *Ivar) {
PropertyIvarDecl = Ivar;
Modified: cfe/trunk/lib/CodeGen/CGBlocks.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBlocks.cpp?rev=287437&r1=287436&r2=287437&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBlocks.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBlocks.cpp Sat Nov 19 02:17:24 2016
@@ -16,6 +16,7 @@
#include "CGObjCRuntime.h"
#include "CodeGenFunction.h"
#include "CodeGenModule.h"
+#include "ConstantBuilder.h"
#include "clang/AST/DeclObjC.h"
#include "llvm/ADT/SmallSet.h"
#include "llvm/IR/CallSite.h"
@@ -77,63 +78,63 @@ static llvm::Constant *buildBlockDescrip
const CGBlockInfo &blockInfo) {
ASTContext &C = CGM.getContext();
- llvm::Type *ulong = CGM.getTypes().ConvertType(C.UnsignedLongTy);
- llvm::Type *i8p = nullptr;
+ llvm::IntegerType *ulong =
+cast(CGM.getTypes().ConvertType(C.UnsignedLongTy));
+ llvm::PointerType *i8p = nullptr;
if (CGM.getLangOpts().OpenCL)
i8p =
llvm::Type::getInt8PtrTy(
CGM.getLLVMContext(),
C.getTargetAddressSpace(LangAS::opencl_constant));
else
-i8p = CGM.getTypes().ConvertType(C.VoidPtrTy);
+i8p = CGM.VoidPtrTy;
- SmallVector elements;
+ ConstantBuilder builder(CGM);
+ auto elements = builder.beginStruct();
// reserved
- elements.push_back(llvm::ConstantInt::get(ulong, 0));
+ elements.addInt(ulong, 0);
// Size
// FIXME: What is the right way to say this doesn't fit? We should give
// a user diagnostic in that case. Better fix would be to change the
// API to size_t.
- elements.push_back(llvm::ConstantInt::get(ulong,
-
blockInfo.BlockSize.getQuantity()));
+ elements.addInt(ulong, blockInfo.BlockSize.getQuantity());
// Optional copy/dispose helpers.
if (blockInfo.NeedsCopyDispose) {
// copy_func_helper_decl
-elements.push_back(buildCopyHelper(CGM, blockInfo));
+elements.add(buildCopyHelper(CGM, blockInfo));
// destroy_func_decl
-elements.push_back(buildDisposeHelper(CGM, blockInfo));
+elements.add(buildDisposeHelper(CGM, blockInfo));
}
// Signature. Mandatory ObjC-style method descriptor @encode sequence.
std::string typeAtEncoding =
CGM.getContext().getObjCEncodingForBlock(blockInfo.getBlockExpr());
- elements.push_back(llvm::ConstantExpr::getBitCast(
+ elements.add(llvm::ConstantExpr::getBitCast(
CGM.GetAddrOfConstantCString(typeAtEncoding).getPointer(), i8p));
// GC layout.
if (C.getLangOpts().ObjC1) {
if (CGM.getLangOpts().getGC() != LangOptions::NonGC)
- elements.push_back(CGM.getObjCRuntime().BuildGCBlockLayout(CGM,
blockInfo));
+ elements.add(CGM.getObjCRuntime().BuildGCBlockLayout(CGM, blockInfo));
else
- elements.push_back(CGM.getObjCRuntime().BuildRCBlockLayout(CGM,
blockInfo));
+ elements.add(CGM.getObjCRuntime().BuildRCBlockLayout(CGM, blockInfo));
}
else
-elements.push_back(llvm::Constant::getNullValue(i8p));
-
- llvm::Constant *init = llvm::ConstantStruct::getAnon(elements);
+elements.addNullPointer(i8p);
unsigned AddrSpace = 0;
if (C.getLangOpts().OpenCL)
AddrSpace = C.getTargetAddressSpace(LangAS::opencl_constant);
+
llvm::GlobalVariable *global =
-new llvm::GlobalVariable(CGM.getModule(), init->getType(), true,
- llvm::GlobalValue::InternalLinkage,
- init, "__block_descriptor_tmp", nullptr,
- llvm::GlobalValue::NotThreadLocal,
- AddrSpace);
+elements.finishAn
[PATCH] D26887: [Driver] Fix finding multilib gcc install on Gentoo (with gcc-config)
mgorny created this revision.
mgorny added reviewers: chandlerc, bruno, bkramer.
mgorny added a subscriber: cfe-commits.
Herald added subscribers: srhines, danalbert.
Fix the gcc-config code to support multilib gcc installs properly. This
solves two problems: -mx32 using the 64-bit gcc directory (due to matching
installation triple), and -m32 not respecting gcc-config at all (due to
mismatched installation triple).
In order to fix the former issue, split the multilib scan out of
Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple() (the code
is otherwise unchanged), and call it for each installation found via
gcc-config.
In order to fix the latter issue, split the gcc-config processing out of
Generic_GCC::GCCInstallationDetector::init() and repeat it for all
triples, including extra and biarch triples. The only change
in the gcc-config code itself is adding the call to multilib scan.
Convert the gentoo_linux_gcc_multi_version_tree test input to multilib
x86_64+32+x32 install, and add appropriate tests to linux-header-search
and linux-ld.
https://reviews.llvm.org/D26887
Files:
lib/Driver/ToolChains.cpp
lib/Driver/ToolChains.h
test/Driver/Inputs/gentoo_linux_gcc_multi_version_tree/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/32/crtbegin.o
test/Driver/Inputs/gentoo_linux_gcc_multi_version_tree/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/x32/crtbegin.o
test/Driver/Inputs/gentoo_linux_gcc_multi_version_tree/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/32/crtbegin.o
test/Driver/Inputs/gentoo_linux_gcc_multi_version_tree/usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/x32/crtbegin.o
test/Driver/linux-header-search.cpp
test/Driver/linux-ld.c
Index: test/Driver/linux-ld.c
===
--- test/Driver/linux-ld.c
+++ test/Driver/linux-ld.c
@@ -1662,3 +1662,56 @@
// CHECK-MUSL-ARMEBHF:"-dynamic-linker" "/lib/ld-musl-armebhf.so.1"
// CHECK-MUSL-AARCH64:"-dynamic-linker" "/lib/ld-musl-aarch64.so.1"
// CHECK-MUSL-AARCH64_BE: "-dynamic-linker" "/lib/ld-musl-aarch64_be.so.1"
+
+// Check whether multilib gcc install works fine on Gentoo with gcc-config
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-unknown-linux-gnu -rtlib=platform \
+// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_multi_version_tree \
+// RUN: --gcc-toolchain="" \
+// RUN: | FileCheck --check-prefix=CHECK-LD-GENTOO %s
+// CHECK-LD-GENTOO-NOT: warning:
+// CHECK-LD-GENTOO: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-LD-GENTOO: "--eh-frame-hdr"
+// CHECK-LD-GENTOO: "-m" "elf_x86_64"
+// CHECK-LD-GENTOO: "-dynamic-linker"
+// CHECK-LD-GENTOO: "{{.*}}/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/crtbegin.o"
+// CHECK-LD-GENTOO: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3"
+// CHECK-LD-GENTOO: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/lib"
+// CHECK-LD-GENTOO: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../.."
+// CHECK-LD-GENTOO: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
+// CHECK-LD-GENTOO: "-lc"
+// CHECK-LD-GENTOO: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=i686-unknown-linux-gnu -rtlib=platform \
+// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_multi_version_tree \
+// RUN: --gcc-toolchain="" \
+// RUN: | FileCheck --check-prefix=CHECK-LD-GENTOO-32 %s
+// CHECK-LD-GENTOO-32-NOT: warning:
+// CHECK-LD-GENTOO-32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-LD-GENTOO-32: "--eh-frame-hdr"
+// CHECK-LD-GENTOO-32: "-m" "elf_i386"
+// CHECK-LD-GENTOO-32: "-dynamic-linker"
+// CHECK-LD-GENTOO-32: "{{.*}}/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/32/crtbegin.o"
+// CHECK-LD-GENTOO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/32"
+// CHECK-LD-GENTOO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/lib"
+// CHECK-LD-GENTOO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../.."
+// CHECK-LD-GENTOO-32: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
+// CHECK-LD-GENTOO-32: "-lc"
+// CHECK-LD-GENTOO-32: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-unknown-linux-gnux32 -rtlib=platform \
+// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_multi_version_tree \
+// RUN: --gcc-toolchain="" \
+// RUN: | FileCheck --check-prefix=CHECK-LD-GENTOO-X32 %s
+// CHECK-LD-GENTOO-X32-NOT: warning:
+// CHECK-LD-GENTOO-X32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-LD-GENTOO-X32: "--eh-frame-hdr"
+// CHECK-LD-GENTOO-X32: "-m" "elf32_x86_64"
+// CHECK-LD-GENTOO-X32: "-dynamic-linker"
+// CHECK-LD-GENTOO-X32: "{{.*}}/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/x32/crtbegin.o"
+// CHECK-LD-GENTOO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/x32"
+// CHECK-LD-GENTOO-X32: "-L[[SYSROOT]]/usr/lib
[PATCH] D26829: [clang] Allow lexer to handle string_view literals
AntonBikineev added inline comments.
Comment at: lib/Lex/LiteralSupport.cpp:1716-1717
+StringLiteralParser::UDSuffixResult
+StringLiteralParser::isValidUDSuffix(const LangOptions &LangOpts,
+ StringRef Suffix) {
+ if (!LangOpts.CPlusPlus11 || Suffix.empty())
rsmith wrote:
> Just make this call `NumericLiteralParser::isValidUDSuffix` and then check
> for the `sv` case. All the numeric suffixes are also valid string literal
> suffixes for the form `operator""suffix`.
This makes sense for the call sites we currently have.
> All the numeric suffixes are also valid string literal suffixes for the form
> operator""suffix.
Don't really understand this part. It seems inconsistent if one calls, say,
``` StringLiteralParser::isValidUDSuffix(LangOpts(), "if") ```
and gets
```true```
https://reviews.llvm.org/D26829
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D25869: [Driver] Add unit tests for Distro detection
mgorny updated this revision to Diff 78625.
mgorny added a comment.
Added a test for Exherbo.
https://reviews.llvm.org/D25869
Files:
unittests/Driver/CMakeLists.txt
unittests/Driver/DistroTest.cpp
Index: unittests/Driver/DistroTest.cpp
===
--- /dev/null
+++ unittests/Driver/DistroTest.cpp
@@ -0,0 +1,305 @@
+//===- unittests/Driver/DistroTest.cpp --- ToolChains tests ---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// Unit tests for Distro detection.
+//
+//===--===//
+
+#include "clang/Driver/Distro.h"
+#include "clang/Basic/VirtualFileSystem.h"
+#include "llvm/Support/raw_ostream.h"
+#include "gtest/gtest.h"
+using namespace clang;
+using namespace clang::driver;
+
+namespace {
+
+// The tests include all release-related files for each distribution
+// in the VFS, in order to make sure that earlier tests do not
+// accidentally result in incorrect distribution guess.
+
+TEST(DistroTest, DetectUbuntu) {
+ vfs::InMemoryFileSystem UbuntuTrustyFileSystem;
+ // Ubuntu uses Debian Sid version.
+ UbuntuTrustyFileSystem.addFile("/etc/debian_version", 0,
+ llvm::MemoryBuffer::getMemBuffer("jessie/sid\n"));
+ UbuntuTrustyFileSystem.addFile("/etc/lsb-release", 0,
+ llvm::MemoryBuffer::getMemBuffer("DISTRIB_ID=Ubuntu\n"
+ "DISTRIB_RELEASE=14.04\n"
+ "DISTRIB_CODENAME=trusty\n"
+ "DISTRIB_DESCRIPTION=\"Ubuntu 14.04 LTS\"\n"));
+ UbuntuTrustyFileSystem.addFile("/etc/os-release", 0,
+ llvm::MemoryBuffer::getMemBuffer("NAME=\"Ubuntu\"\n"
+ "VERSION=\"14.04, Trusty Tahr\"\n"
+ "ID=ubuntu\n"
+ "ID_LIKE=debian\n"
+ "PRETTY_NAME=\"Ubuntu 14.04 LTS\"\n"
+ "VERSION_ID=\"14.04\"\n"
+ "HOME_URL=\"http://www.ubuntu.com/\"\n";
+ "SUPPORT_URL=\"http://help.ubuntu.com/\"\n";
+ "BUG_REPORT_URL=\"http://bugs.launchpad.net/ubuntu/\"\n";));
+
+ Distro UbuntuTrusty{UbuntuTrustyFileSystem};
+ ASSERT_EQ(Distro(Distro::UbuntuTrusty), UbuntuTrusty);
+ ASSERT_TRUE(UbuntuTrusty.IsUbuntu());
+ ASSERT_FALSE(UbuntuTrusty.IsRedhat());
+ ASSERT_FALSE(UbuntuTrusty.IsOpenSUSE());
+ ASSERT_FALSE(UbuntuTrusty.IsDebian());
+
+ vfs::InMemoryFileSystem UbuntuYakketyFileSystem;
+ UbuntuYakketyFileSystem.addFile("/etc/debian_version", 0,
+ llvm::MemoryBuffer::getMemBuffer("stretch/sid\n"));
+ UbuntuYakketyFileSystem.addFile("/etc/lsb-release", 0,
+ llvm::MemoryBuffer::getMemBuffer("DISTRIB_ID=Ubuntu\n"
+ "DISTRIB_RELEASE=16.10\n"
+ "DISTRIB_CODENAME=yakkety\n"
+ "DISTRIB_DESCRIPTION=\"Ubuntu 16.10\"\n"));
+ UbuntuYakketyFileSystem.addFile("/etc/os-release", 0,
+ llvm::MemoryBuffer::getMemBuffer("NAME=\"Ubuntu\"\n"
+ "VERSION=\"16.10 (Yakkety Yak)\"\n"
+ "ID=ubuntu\n"
+ "ID_LIKE=debian\n"
+ "PRETTY_NAME=\"Ubuntu 16.10\"\n"
+ "VERSION_ID=\"16.10\"\n"
+ "HOME_URL=\"http://www.ubuntu.com/\"\n";
+ "SUPPORT_URL=\"http://help.ubuntu.com/\"\n";
+ "BUG_REPORT_URL=\"http://bugs.launchpad.net/ubuntu/\"\n";
+ "PRIVACY_POLICY_URL=\"http://www.ubuntu.com/legal/terms-and-policies/privacy-policy\"\n";
+ "VERSION_CODENAME=yakkety\n"
+ "UBUNTU_CODENAME=yakkety\n"));
+
+ Distro UbuntuYakkety{UbuntuYakketyFileSystem};
+ ASSERT_EQ(Distro(Distro::UbuntuYakkety), UbuntuYakkety);
+ ASSERT_TRUE(UbuntuYakkety.IsUbuntu());
+ ASSERT_FALSE(UbuntuYakkety.IsRedhat());
+ ASSERT_FALSE(UbuntuYakkety.IsOpenSUSE());
+ ASSERT_FALSE(UbuntuYakkety.IsDebian());
+}
+
+TEST(DistroTest, DetectRedhat) {
+ vfs::InMemoryFileSystem Fedora25FileSystem;
+ Fedora25FileSystem.addFile("/etc/system-release-cpe", 0,
+ llvm::MemoryBuffer::getMemBuffer("cpe:/o:fedoraproject:fedora:25\n"));
+ // Both files are symlinks to fedora-release.
+ Fedora25FileSystem.addFile("/etc/system-release", 0,
+ llvm::MemoryBuffer::getMemBuffer("Fedora releas
[PATCH] D26458: Protect nested-exceptions tests under no-exceptions
rmaprath added a comment.
In https://reviews.llvm.org/D26458#594069, @EricWF wrote:
> There are cases where it is useful to be able to name `std::nested_exception`
> while exceptions are disabled.
I was thinking about the opposite. That is, we might want to consider disabling
the `` header altogether when compiling with `-fno-exceptions`. My
particular use case is to do with futures:
void make_hello(std::promise &p, bool set_exception) {
if (set_exception)
p.set_exception(std::make_exception_ptr(
std::runtime_error {"No hellos left."}));
else
p.set_value("Hello world!");
}
This will compile fine with `-fno-exceptions` and when the client thread
attempts to read from the promise, whole program would crash. May be they
deserve it, but I feel like it's something we can help with; if we disable the
`` header, this code wouldn't compile under `-fno-exceptions`.
In what cases do we need to allow various exception types under
`-fno-exceptions`?
Cheers,
/ Asiri
Repository:
rL LLVM
https://reviews.llvm.org/D26458
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26458: Protect nested-exceptions tests under no-exceptions
rmaprath added a comment. On the other hand, disabling `` would mean disabling some parts of the library as well (in this case, `std::promise::set_exception`). Perhaps that's a bad path to follow. Not sure. Repository: rL LLVM https://reviews.llvm.org/D26458 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26735: [OpenCL] Disable && (address of label) GNU extension for OpenCL
keryell added a comment. +1 Please do not remove anything, since it may be useful in some contexts. I do not think there are negative tests in the Khronos OpenCL conformance test suite anyway. https://reviews.llvm.org/D26735 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r287449 - Change setDiagnosticsOutputFile to take a unique_ptr from a raw pointer (NFC)
Author: mehdi_amini
Date: Sat Nov 19 12:19:41 2016
New Revision: 287449
URL: http://llvm.org/viewvc/llvm-project?rev=287449&view=rev
Log:
Change setDiagnosticsOutputFile to take a unique_ptr from a raw pointer (NFC)
Summary:
This makes it explicit that ownership is taken. Also replace all `new`
with make_unique<> at call sites.
Reviewers: anemet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D26884
Modified:
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=287449&r1=287448&r2=287449&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Sat Nov 19 12:19:41 2016
@@ -195,7 +195,8 @@ namespace clang {
return;
}
-Ctx.setDiagnosticsOutputFile(new yaml::Output(OptRecordFile->os()));
+Ctx.setDiagnosticsOutputFile(
+llvm::make_unique(OptRecordFile->os()));
if (CodeGenOpts.getProfileUse() != CodeGenOptions::ProfileNone)
Ctx.setDiagnosticHotnessRequested(true);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r287458 - Remove alignment from ctors/dtors lists in an attempt to placate LTO.
Author: rjmccall Date: Sat Nov 19 14:12:25 2016 New Revision: 287458 URL: http://llvm.org/viewvc/llvm-project?rev=287458&view=rev Log: Remove alignment from ctors/dtors lists in an attempt to placate LTO. Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=287458&r1=287457&r2=287458&view=diff == --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original) +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Sat Nov 19 14:12:25 2016 @@ -756,9 +756,15 @@ void CodeGenModule::EmitCtorList(CtorLis ctors.add(ctor.finish()); } - (void) ctors.finishAndCreateGlobal(GlobalName, getPointerAlign(), - /*constant*/ false, - llvm::GlobalValue::AppendingLinkage); + auto list = +ctors.finishAndCreateGlobal(GlobalName, getPointerAlign(), +/*constant*/ false, +llvm::GlobalValue::AppendingLinkage); + + // The LTO linker doesn't seem to like it when we set an alignment + // on appending variables. Take it off as a workaround. + list->setAlignment(0); + Fns.clear(); } ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r287463 - [CMake] Fixing clang standalone build
Author: cbieneman
Date: Sat Nov 19 15:14:59 2016
New Revision: 287463
URL: http://llvm.org/viewvc/llvm-project?rev=287463&view=rev
Log:
[CMake] Fixing clang standalone build
I broke this in r287406 and r287407.
Modified:
cfe/trunk/tools/clang-offload-bundler/CMakeLists.txt
cfe/trunk/tools/driver/CMakeLists.txt
Modified: cfe/trunk/tools/clang-offload-bundler/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-offload-bundler/CMakeLists.txt?rev=287463&r1=287462&r2=287463&view=diff
==
--- cfe/trunk/tools/clang-offload-bundler/CMakeLists.txt (original)
+++ cfe/trunk/tools/clang-offload-bundler/CMakeLists.txt Sat Nov 19 15:14:59
2016
@@ -1,10 +1,14 @@
set(LLVM_LINK_COMPONENTS BitWriter Core Object Support)
+if(NOT CLANG_BUILT_STANDALONE)
+ set(tablegen_deps intrinsics_gen)
+endif()
+
add_clang_executable(clang-offload-bundler
ClangOffloadBundler.cpp
DEPENDS
- intrinsics_gen
+ ${tablegen_deps}
)
set(CLANG_OFFLOAD_BUNDLER_LIB_DEPS
Modified: cfe/trunk/tools/driver/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/CMakeLists.txt?rev=287463&r1=287462&r2=287463&view=diff
==
--- cfe/trunk/tools/driver/CMakeLists.txt (original)
+++ cfe/trunk/tools/driver/CMakeLists.txt Sat Nov 19 15:14:59 2016
@@ -24,13 +24,17 @@ if(CLANG_PLUGIN_SUPPORT)
set(LLVM_NO_DEAD_STRIP 1)
endif()
+if(NOT CLANG_BUILT_STANDALONE)
+ set(tablegen_deps intrinsics_gen)
+endif()
+
add_clang_tool(clang
driver.cpp
cc1_main.cpp
cc1as_main.cpp
DEPENDS
- intrinsics_gen
+ ${tablegen_deps}
)
target_link_libraries(clang
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D26829: [clang] Allow lexer to handle string_view literals
On 19 Nov 2016 2:36 am, "Anton Bikineev" wrote:
AntonBikineev added inline comments.
Comment at: lib/Lex/LiteralSupport.cpp:1716-1717
+StringLiteralParser::UDSuffixResult
+StringLiteralParser::isValidUDSuffix(const LangOptions &LangOpts,
+ StringRef Suffix) {
+ if (!LangOpts.CPlusPlus11 || Suffix.empty())
rsmith wrote:
> Just make this call `NumericLiteralParser::isValidUDSuffix` and then
check for the `sv` case. All the numeric suffixes are also valid string
literal suffixes for the form `operator""suffix`.
This makes sense for the call sites we currently have.
> All the numeric suffixes are also valid string literal suffixes for the
form operator""suffix.
Don't really understand this part. It seems inconsistent if one calls, say,
``` StringLiteralParser::isValidUDSuffix(LangOpts(), "if") ```
and gets
```true```
That is valid in the case of `operator ""if`, so `if` is a valid string
literal suffix (as is any numeric literal suffix).
https://reviews.llvm.org/D26829
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D26893: [Sema] Fix assert on valid during template argument deduction
erik.pilkington created this revision.
erik.pilkington added a reviewer: rsmith.
erik.pilkington added a subscriber: cfe-commits.
This patch fixes an assert that fired when diagnosing a failed template
argument deduction attempt. The problem is that when deducing template
arguments for a template specialization, if there are insufficient template
arguments, we return `Sema::TDK_TooFewArguments`, which is meant to be used
with call arguments, not template arguments and therefore confuses the
diagnostic handling. This patch fixes the assert by instead returning
`Sema::TDK_MiscellaneousDeductionFailure`.
This fixes a regression introduced in r274077, recorded by PR31043. Thanks!
https://reviews.llvm.org/D26893
Files:
lib/Sema/SemaTemplateDeduction.cpp
test/SemaTemplate/deduction.cpp
Index: test/SemaTemplate/deduction.cpp
===
--- test/SemaTemplate/deduction.cpp
+++ test/SemaTemplate/deduction.cpp
@@ -273,3 +273,13 @@
}
void g() { f(X()); }
}
+
+namespace PR31043 {
+template
+struct tuple {};
+
+template
+int foo(tuple); // expected-note{{candidate template ignored: failed
template argument deduction}}
+
+int z = foo(tuple<>{}); // expected-error{{no matching function call to 'foo'}}
+}
Index: lib/Sema/SemaTemplateDeduction.cpp
===
--- lib/Sema/SemaTemplateDeduction.cpp
+++ lib/Sema/SemaTemplateDeduction.cpp
@@ -1921,8 +1921,9 @@
// Check whether we have enough arguments.
if (!hasTemplateArgumentForDeduction(Args, ArgIdx, NumArgs))
-return NumberOfArgumentsMustMatch ? Sema::TDK_TooFewArguments
- : Sema::TDK_Success;
+return NumberOfArgumentsMustMatch
+ ? Sema::TDK_MiscellaneousDeductionFailure
+ : Sema::TDK_Success;
if (Args[ArgIdx].isPackExpansion()) {
// FIXME: We follow the logic of C++0x [temp.deduct.type]p22 here,
Index: test/SemaTemplate/deduction.cpp
===
--- test/SemaTemplate/deduction.cpp
+++ test/SemaTemplate/deduction.cpp
@@ -273,3 +273,13 @@
}
void g() { f(X()); }
}
+
+namespace PR31043 {
+template
+struct tuple {};
+
+template
+int foo(tuple); // expected-note{{candidate template ignored: failed template argument deduction}}
+
+int z = foo(tuple<>{}); // expected-error{{no matching function call to 'foo'}}
+}
Index: lib/Sema/SemaTemplateDeduction.cpp
===
--- lib/Sema/SemaTemplateDeduction.cpp
+++ lib/Sema/SemaTemplateDeduction.cpp
@@ -1921,8 +1921,9 @@
// Check whether we have enough arguments.
if (!hasTemplateArgumentForDeduction(Args, ArgIdx, NumArgs))
-return NumberOfArgumentsMustMatch ? Sema::TDK_TooFewArguments
- : Sema::TDK_Success;
+return NumberOfArgumentsMustMatch
+ ? Sema::TDK_MiscellaneousDeductionFailure
+ : Sema::TDK_Success;
if (Args[ArgIdx].isPackExpansion()) {
// FIXME: We follow the logic of C++0x [temp.deduct.type]p22 here,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
