- Feb 03, 2018
-
-
Erik Pilkington authored
This commit cleans up the expression parser, using a new style: - parse* functions now return Node pointers. - The mangled name is now held in Db and accessed with look() and consume() - LLVM coding style This style is meant to avoid the 2 most common types of bugs in the old demanger, namely misusing the Names stack (ie, calling back() on empty) and going out of bounds on the mangled name. I also think it makes the demangler a lot cleaner. Differential revision: https://reviews.llvm.org/D41887 llvm-svn: 324111
-
Amara Emerson authored
Differential Revision: https://reviews.llvm.org/D42832 llvm-svn: 324110
-
Sanjay Patel authored
llvm-svn: 324109
-
Rafael Espindola authored
This reverts commit r324107. I will have to test it on OS X. llvm-svn: 324108
-
Rafael Espindola authored
This starts adding dso_local to clang. The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go away. My objective for now is to move enough of it to clang to remove the need for the TargetMachine one to handle PIE copy relocations and -fno-plt. With that it should then be easy to implement a -fno-copy-reloc in clang. This patch just adds the cases where we assume a symbol to be local based on the file being compiled for an executable or a shared library. llvm-svn: 324107
-
Craig Topper authored
[X86] Remove checks for FeatureAVX512 from the X86 assembly parser. Remove mcpu/mattr from assembly test command lines. Summary: We should always be able to accept AVX512 registers and instructions in llvm-mc. The only subtarget mode that should be checked is 16-bit vs 32-bit vs 64-bit mode. I've also removed all the mattr/mcpu lines from test RUN lines to be consistent with this. Most were due to AVX512, but a few were for other features. Fixes PR36202 Reviewers: RKSimon, echristo, bkramer Reviewed By: echristo Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42824 llvm-svn: 324106
-
Sam McCall authored
llvm-svn: 324105
-
Fangrui Song authored
Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42674 llvm-svn: 324104
-
Yaxun Liu authored
This requires corresponding llvm change. Differential Revision: https://reviews.llvm.org/D40956 llvm-svn: 324102
-
Yaxun Liu authored
This requires corresponding clang change. Differential Revision: https://reviews.llvm.org/D40955 llvm-svn: 324101
-
- Feb 02, 2018
-
-
Clement Courbet authored
See https://reviews.llvm.org/D42793#996098 for context. llvm-svn: 324099
-
Erich Keane authored
When trying to track down a different bug, we discovered that calling __builtin_va_arg on a vec3f type caused the SROA pass to issue a warning that there was an illegal access. Further research showed that the vec3f type is alloca'ed as size '12', but the _builtin_va_arg code on x86_64 was always loading this out of registers as {double, double}. Thus, the 2nd store into the vec3f was storing in bytes 12-15! This patch alters the original implementation which always assumed {double, double} to use the actual coerced type instead, so the LLVM-IR generated is a load/GEP/store of a <2 x float> and a float, rather than a double and a double. Tests were added for all combinations I could think of that would fit in 2 FP registers, and all work exactly as expected. Differential Revision: https://reviews.llvm.org/D42811 llvm-svn: 324098 -
Ben Hamilton authored
Summary: The following Objective-C code currently incorrectly triggers clang-tidy's performance-unnecessary-value-param check: ``` % cat /tmp/performance-unnecessary-value-param-arc.m void foo(id object) { } clang-tidy /tmp/performance-unnecessary-value-param-arc.m -checks=-\*,performance-unnecessary-value-param -- -xobjective-c -fobjc-abi-version=2 -fobjc-arc 1 warning generated. /src/llvm/tools/clang/tools/extra/test/clang-tidy/performance-unnecessary-value-param-arc.m:10:13: warning: the parameter 'object' is copied for each invocation but only used as a const reference; consider making it a const reference [performance-unnecessary-value-param] void foo(id object) { } ~~ ^ const & ``` This is wrong for a few reasons: 1) Objective-C doesn't have references, so `const &` is not going to help 2) ARC heavily optimizes the "expensive" copy which triggers the warning This fixes the issue by disabling the warning for non-C++, as well as disabling it for objects under ARC memory management for Objective-C++. Fixes https://bugs.llvm.org/show_bug.cgi?id=32075 Test Plan: New tests added. Ran tests with `make -j12 check-clang-tools`. Reviewers: alexfh, hokein Reviewed By: hokein Subscribers: stephanemoore, klimek, xazax.hun, cfe-commits, Wizard Differential Revision: https://reviews.llvm.org/D42812 llvm-svn: 324097 -
James Henderson authored
llvm-svn: 324096
-
George Rimar authored
Was requested during review of D42798. llvm-svn: 324095
-
Simon Pilgrim authored
llvm-svn: 324094
-
Sam McCall authored
llvm-svn: 324093
-
Ivan A. Kosarev authored
This patch implements analysis for new-format TBAA access tags with aggregate types as their final access types. Differential Revision: https://reviews.llvm.org/D41501 llvm-svn: 324092
-
Kamil Rytarowski authored
Late fix for SVN r. 324034 Add new interceptors: strlcpy(3) and strlcat(3) There was forgotten an addition of len to the return value. llvm-svn: 324091
-
Benjamin Kramer authored
llvm-svn: 324084
-
Benjamin Kramer authored
The matchers in this check are prone to create ODR violations otherwise. No functionality change. llvm-svn: 324083
-
Sam McCall authored
llvm-svn: 324081
-
Benjamin Kramer authored
llvm-svn: 324080
-
Benjamin Kramer authored
This also makes the code ready for int128, even though I think it's currently impossible to get an int128 into this code path. llvm-svn: 324079
-
James Henderson authored
Differential Revision: https://reviews.llvm.org/D42481 llvm-svn: 324078
-
James Henderson authored
This change adds support to llvm-dwarfdump for dumping DWARF5 .debug_rnglists sections in regular ELF files. It is not complete, in that several DW_RLE_* encodings are currently not supported, but does dump the headert and the basic ranges for DW_RLE_start_length and DW_RLE_start_end encodings. Obvious next steps are to add verbose dumping that dumps the raw encodings, rather than the interpreted contents, to add -verify support of the section (e.g. to show that the correct number of offsets are specified), add dumping of .debug_rnglists.dwo, and to add support for other encodings. Reviewed by: dblaikie, JDevlieghere Differential Revision: https://reviews.llvm.org/D42481 llvm-svn: 324077
-
George Rimar authored
llvm-svn: 324076
-
George Rimar authored
This fixes PR36187. Patch teaches ThinLTO to drop non-prevailing variables, just like we recently did for functions (in r323633). Differential revision: https://reviews.llvm.org/D42798 llvm-svn: 324075
-
Sjoerd Meijer authored
llvm-svn: 324074
-
Eric Liu authored
llvm-svn: 324073
-
George Rimar authored
Was suggested during review of D42635, because linking an .s file as a binary file was confusing. llvm-svn: 324072
-
Mikael Holmen authored
Summary: When creating the debug fragments for a SRA'd variable, use the types' allocation sizes. This fixes issues where the pass would emit too small fragments, placed at the wrong offset, for padded types. An example of this is long double on x86. The type is represented using x86_fp80, which is 10 bytes, but the value is aligned to 12/16 bytes. The padding is included in the type's DW_AT_byte_size attribute; therefore, the fragments should also include that. Newer GCC releases (I tested 7.2.0) emit 12/16-byte pieces for long double. Earlier releases, e.g. GCC 5.5.0, behaved as LLVM did, i.e. by emitting a 10-byte piece, followed by an empty 2/6-byte piece for the padding. Failing to cover all `DW_AT_byte_size' bytes of a value with non-empty pieces results in the value being printed as <optimized out> by GDB. Patch by: David Stenberg Reviewers: aprantl, JDevlieghere Reviewed By: aprantl, JDevlieghere Subscribers: llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D42807 llvm-svn: 324066
-
Eric Liu authored
Summary: Some STL symbols are defined in inline namespaces. For example, ``` namespace std { inline namespace __cxx11 { typedef ... string; } } ``` Currently, this will be `std::__cxx11::string`; however, `std::string` is desired. Inline namespaces are treated as transparent scopes. This reflects the way they're most commonly used for lookup. Ideally we'd include them, but at query time it's hard to find all the inline namespaces to query: the preamble doesn't have a dedicated list. Reviewers: sammccall, hokein Reviewed By: sammccall Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits Differential Revision: https://reviews.llvm.org/D42796 llvm-svn: 324065 -
Simon Atanasyan authored
Initially LLD generates Elf_Rel relocations for O32 ABI and Elf_Rela relocations for N32 / N64 ABIs. In other words, format of input and output relocations was always the same. Now LLD generates all output relocations using Elf_Rel format only. It conforms to ABIs requirement. The patch suggested by Alexander Richardson. llvm-svn: 324064
-
Jonas Paulsson authored
When handling vectors with non byte-sized elements, reverse the order of the elements in the built integer if the target is Big-Endian. SystemZ tests updated. Review: Eli Friedman, Ulrich Weigand. https://reviews.llvm.org/D42786 llvm-svn: 324063
-
Ilya Biryukov authored
Summary: It should be safe, since other code paths are already generating implicit members even in invalid CXXRecordDecls (e.g. lookup). If we don't generate implicit members on CXXRecordDecl's completion, they will be generated by next lookup of constructors. This causes a crash when the following conditions are met: - a CXXRecordDecl is invalid, - it is provided via ExternalASTSource (e.g. from PCH), - it has inherited constructors (they create ShadowDecls), - lookup of its constructors was not run before ASTWriter serialized it. This may require the ShadowDecls created for inherited constructors to be removed from the class, but that's no longer possible since class is provided by ExternalASTSource. See provided lit test for an example. Reviewers: bkramer Reviewed By: bkramer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D42810 llvm-svn: 324062 -
Jonas Paulsson authored
When getNode() is called to create an EXTRACT_VECTOR_ELT, assert that the result VT is at least as wide as the vector element type. Review: Eli Friedman llvm-svn: 324061
-
Jonas Paulsson authored
test/CodeGen/SystemZ/vec-trunc-to-i1.ll was marked as a temporary FAIL when it was previously updated when it needed one more COPY. This was however wrong, since the loop body had been reduced significantly, and it was actually an improvement. Review: Ulrich Weigand. llvm-svn: 324060
-
Martin Storsjo authored
This fixes building Qt as shared libraries with clang in MinGW mode; previously subclasses of the QObjectData class (in other DLLs than the base DLL) failed to find the typeinfo symbols (that neither were emitted in the base DLL nor in the DLL containing the subclass). If the virtual destructor in the newly added testcase wouldn't be pure (or if there'd be another non-pure virtual method), it'd be a key function and things would work out even before this change. Make sure to locally emit the typeinfo for these classes as well. This matches what GCC does in this specific testcase. This fixes the root issue that spawned PR35146. (The difference to GCC that is initially described in that bug still is present though.) Differential Revision: https://reviews.llvm.org/D42641 llvm-svn: 324059
-
Shiva Chen authored
llvm-objdump could get C feature by ELF::EF_RISCV_RVC e_flag, so then we don't have to add -mattr=+c on the command line. Differential Revision: https://reviews.llvm.org/D42629 llvm-svn: 324058
-