- Feb 06, 2018
-
-
Nirav Dave authored
Revert "[libc++] Fix PR35491 - std::array of zero-size doesn't work with non-default constructible types." Revert "Fix initialization of array<const T, 0> with GCC." Revert "Make array<const T, 0> non-CopyAssignable and make swap and fill ill-formed." This reverts commit r324182, r324185, and r324194 which were causing issues with zero-length std::arrays. llvm-svn: 324309
-
Richard Trieu authored
Don't call a method when the pointer is null. llvm-svn: 324308
-
Marshall Clow authored
llvm-svn: 324307
-
Reid Kleckner authored
Summary: This patch adds some initial support for Windows control flow guard. At the end of the day, the linker needs to synthesize a table of RVAs very similar to the structured exception handler table (/safeseh). Both /safeseh and /guard:cf take sections of symbol table indices (.sxdata and .gfids$y) and turn them into RVA tables referenced by the load config struct in the CRT through special symbols. Reviewers: ruiu, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42592 llvm-svn: 324306
-
Derek Schuff authored
Wasm uses the expand action for several FP compare ops, and that behavior changed. llvm-svn: 324305
-
Reid Kleckner authored
llvm-svn: 324304
-
Ahmed Charles authored
llvm-svn: 324303
-
Alex Shlyapnikov authored
Differential revision: https://reviews.llvm.org/D40903 llvm-svn: 324302
-
Reid Kleckner authored
This reverts r323297. It breaks building grub. llvm-svn: 324301
-
Rui Ueyama authored
GNU gold has these options. Differential Revision: https://reviews.llvm.org/D42929 llvm-svn: 324300
-
Teresa Johnson authored
Summary: Removing the dropped symbols will prevent indirect call promotion in the ThinLTO Backend from adding a new reference to a symbol, which can result in linker unsats. This can happen when we compile with a sample profile collected from one binary by used for another, which may have profiled targets that aren't used in the new binary. Note that until dropDeadSymbols handles variables and aliases (in progress), we may not be able to remove the declaration and can still have an issue. Reviewers: grimar, davidxl Subscribers: mehdi_amini, inglorion, llvm-commits, eraman Differential Revision: https://reviews.llvm.org/D42816 llvm-svn: 324299
-
Paul Robinson authored
llvm-svn: 324298
-
Reid Kleckner authored
llvm-svn: 324297
-
Alex Shlyapnikov authored
Summary: This patch (on top of https://reviews.llvm.org/D35755) provides the clang side necessary to enable the Solaris port of the sanitizers implemented by https://reviews.llvm.org/D40898, https://reviews.llvm.org/D40899, and https://reviews.llvm.org/D40900). A few features of note: * While compiler-rt cmake/base-config-ix.cmake (COMPILER_RT_OS_DIR) places the runtime libs in a tolower(CMAKE_SYSTEM_NAME) directory, clang defaults to the OS part of the target triplet (solaris2.11 in the case at hand). The patch makes them agree on compiler-rt's idea. * While Solaris ld accepts a considerable number of GNU ld options for compatibility, it only does so for the double-dash forms. clang unfortunately is inconsistent here and sometimes uses the double-dash form, sometimes the single-dash one that confuses the hell out of Solaris ld. I've changed the affected places to use the double-dash form that should always work. * As described in https://reviews.llvm.org/D40899, Solaris ld doesn't create the __start___sancov_guards/__stop___sancov_guards labels gld/gold/lld do, so I'm including additional runtime libs into the link that provide them. * One test uses -fstack-protector, but unlike other systems libssp hasn't been folded into Solaris libc, but needs to be linked with separately. * For now, only 32-bit x86 asan is enabled on Solaris. 64-bit x86 should follow, but sparc (which requires additional compiler-rt changes not yet submitted) fails miserably due to a llvmsparc backend limitation: fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported. However, inside the gcc tree, Solaris/sparc asan works almost as well as x86. Reviewers: rsmith, alekseyshl Reviewed By: alekseyshl Subscribers: jyknight, fedor.sergeev, cfe-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D40903 llvm-svn: 324296
-
Craig Topper authored
llvm-svn: 324295
-
Craig Topper authored
[X86] Relax restrictions on what setcc condition codes can be folded with a sext when AVX512 is enabled. We now allow all signed comparisons and not equal. The complement that needs to be added for this is no worse than the extend. And the vector output forms of pcmpeq/pcmpgt have better latency than the k-register version on SKX. llvm-svn: 324294
-
Davide Italiano authored
llvm-svn: 324293
-
Marshall Clow authored
llvm-svn: 324292
-
Peter Collingbourne authored
Differential Revision: https://reviews.llvm.org/D42934 llvm-svn: 324291
-
Marshall Clow authored
Remove <experimental/string_view>; use <string_view> instead. See https://libcxx.llvm.org/TS_deprecation.html llvm-svn: 324290
-
Sanjay Patel authored
In the motivating case from PR35681 and represented by the macro-fuse-cmp test: https://bugs.llvm.org/show_bug.cgi?id=35681 ...there's a 37 -> 31 byte size win for the loop because we eliminate the big base address offsets. SPEC2017 on Ryzen shows no significant perf difference. Differential Revision: https://reviews.llvm.org/D42607 llvm-svn: 324289
-
Eugene Zemtsov authored
llvm-svn: 324288
-
Jason Molenda authored
to use Mach-O cpu types instead of the ArchSpec enum value, and handle the case of bridgeos. llvm-svn: 324287
-
Peter Collingbourne authored
This change reduces the live range of the loaded function pointer, resulting in a slight code size decrease (~10KB in clang), and also improves the security of CFI for virtual calls by making it less likely that the function pointer will be spilled, and ensuring that it is not spilled across a function call boundary. Fixes PR35353. Differential Revision: https://reviews.llvm.org/D42725 llvm-svn: 324286
-
Francis Visoiu Mistrih authored
X86FrameLowering sets stack size to 0 if redzone is enabled. llvm-svn: 324285
-
Vitaly Buka authored
Summary: Before Xcode 4.5, undefined weak symbols don't work reliably on Darwin: https://stackoverflow.com/questions/6009321/weak-symbol-link-on-mac-os-x Therefore this patch disables their use before Mac OS X 10.9 which is the first version only supported by Xcode 4.5 and above. Reviewers: glider, kcc, vitalybuka Reviewed By: vitalybuka Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41346 llvm-svn: 324284
-
Francis Visoiu Mistrih authored
This allows us to make sure we're always having the same sizes in both remarks and warnings. llvm-svn: 324283
-
Erik Pilkington authored
Differential revision: https://reviews.llvm.org/D41889 llvm-svn: 324282
-
Adrian Prantl authored
llvm-svn: 324281
-
Davide Italiano authored
(a while ago). <rdar://problem/20416388> llvm-svn: 324280
-
Paul Robinson authored
llvm-svn: 324279
-
Daniel Neilson authored
Summary: This change is part of step five in the series of changes to remove alignment argument from memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the LowerMemIntrinsics pass to cease using the old getAlignment() API of MemoryIntrinsic in favour of getting source & dest specific alignments through the new API. Steps: Step 1) Remove alignment parameter and create alignment parameter attributes for memcpy/memmove/memset. ( rL322965, rC322964, rL322963 ) Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. ( rL323597 ) Step 3) Update Clang to use the new IRBuilder API. ( rC323617 ) Step 4) Update Polly to use the new IRBuilder API. ( rL323618 ) Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment() and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273 ) Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reference http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html llvm-svn: 324278
-
Benjamin Kramer authored
Apparently this doesn't get included transitively on some systems. llvm-svn: 324277
-
Sanjay Patel authored
This example causes a compile-time explosion: define i16 @foo(i16 %in) { %x = zext i16 %in to i32 %a1 = mul i32 %x, %x %a2 = mul i32 %a1, %a1 %a3 = mul i32 %a2, %a2 %a4 = mul i32 %a3, %a3 %a5 = mul i32 %a4, %a4 %a6 = mul i32 %a5, %a5 %a7 = mul i32 %a6, %a6 %a8 = mul i32 %a7, %a7 %a9 = mul i32 %a8, %a8 %a10 = mul i32 %a9, %a9 %a11 = mul i32 %a10, %a10 %a12 = mul i32 %a11, %a11 %a13 = mul i32 %a12, %a12 %a14 = mul i32 %a13, %a13 %a15 = mul i32 %a14, %a14 %a16 = mul i32 %a15, %a15 %a17 = mul i32 %a16, %a16 %a18 = mul i32 %a17, %a17 %a19 = mul i32 %a18, %a18 %a20 = mul i32 %a19, %a19 %a21 = mul i32 %a20, %a20 %a22 = mul i32 %a21, %a21 %a23 = mul i32 %a22, %a22 %a24 = mul i32 %a23, %a23 %T = trunc i32 %a24 to i16 ret i16 %T } llvm-svn: 324276 -
Jan Kratochvil authored
Differential revision: https://reviews.llvm.org/D42891 llvm-svn: 324275
-
Krzysztof Parzyszek authored
Differential Revision: https://reviews.llvm.org/D42788 llvm-svn: 324274
-
Daniel Neilson authored
Summary: This change is part of step five in the series of changes to remove alignment argument from memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the SimplifyLibCalls pass to cease using the old IRBuilder createMemCpy/createMemMove single-alignment APIs in favour of the new API that allows setting source and destination alignments independently. Steps: Step 1) Remove alignment parameter and create alignment parameter attributes for memcpy/memmove/memset. ( rL322965, rC322964, rL322963 ) Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. ( rL323597 ) Step 3) Update Clang to use the new IRBuilder API. ( rC323617 ) Step 4) Update Polly to use the new IRBuilder API. ( rL323618 ) Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment() and [get|set]SourceAlignment() instead. ( rL323886, rL323891, r3L24148 ) Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods. Reference http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html llvm-svn: 324273
-
Rafael Espindola authored
The difference is that WriteAddends also takes IsRela into consideration. llvm-svn: 324271
-
Paul Robinson authored
The major visible difference here is that in line-table dumps, directory and file names are wrapped in double-quotes; previously, directory names got single quotes and file names were not quoted at all. The improvement in this patch is that when a DWARF v5 line table header has indirect strings, in a verbose dump these will all have their section[offset] printed as well as the name itself. This matches the format used for dumping strings in the .debug_info section. Differential Revision: https://reviews.llvm.org/D42802 llvm-svn: 324270
-
Akira Hatanaka authored
The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
-