Summary: The output of clang-tidy itself already has enough newlines, so the resulting output is more in line with the usual compiler output.
Patch by svenpanne.
Reviewers: alexfh, JonasToth
Reviewed By: JonasToth
Subscribers: JonasToth, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61850
llvm-svn: 360883
It broke the Clang build, see llvm-commits thread.
> Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now.
>
> Follow-up of D61781.
llvm-svn: 360878
Summary:
There are several reasons for doing this:
- generally, there's no reason to differentiate between a section being
absent and it being present, but empty
- it matches more closely what llvm DWARF parser is doing (which also
doesn't differentiate the two cases)
- SymbolFileDWARF also doesn't differentiate the two cases, which makes
porting the rest of sections easier
- it fixes a bug in how the return-null-if-empty logic was implemented
(it returned nullptr only the second time we tried to get the
debug_aranges section), which meant that we hit an assert when trying
to parse an empty-but-present section
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: zturner, lldb-commits
Differential Revision: https://reviews.llvm.org/D61942
llvm-svn: 360874
Summary:
This patch adds the ability to precisely address debug info in
situations when a single file can have more than one debug-info-bearing
sections (as is the case with type units in DWARF v4).
The changes here can be classified into roughly three categories:
- the code which addresses a debug info by offset gets an additional
argument, which specifies the section one should look into.
- the DIERef class also gets an additional member variable specifying
the section. This way, code dealing with DIERefs can know which
section is the object referring to.
- the user_id_t encoding steals one bit from the dwarf_id field to store
the section. This means the total number of separate object files
(apple .o, or normal .dwo) is limited to 2 billion, but that is fine
as it's not possible to hit that number without switching to DWARF64
anyway.
This patch is functionally equivalent to (and inspired by) the two
patches (D61503 and D61504) by Jan Kratochvil, but there are differences
in the implementation:
- it uses an enum instead of a bool flag to differentiate the sections
- it increases the size of DIERef struct instead of reducing the amount
of addressable debug info
- it sets up DWARFDebugInfo to store the units in a single vector
instead of two. This sets us up for the future in which type units can
also live in the debug_info section, and I believe it's cleaner
because there's no need for unit index remapping
There are no tests with this patch as this is essentially NFC until
we start parsing type units from the debug_types section.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: arphaman, jankratochvil, lldb-commits
Differential Revision: https://reviews.llvm.org/D61908
llvm-svn: 360872
Summary:
The complex DOT instructions perform a dot-product on quadtuplets from
two source vectors and the resuling wide real or wide imaginary is
accumulated into the destination register. The instructions come in two
forms:
Vector form, e.g.
cdot z0.s, z1.b, z2.b, #90 - complex dot product on four 8-bit quad-tuplets,
accumulating results in 32-bit elements. The
complex numbers in the second source vector are
rotated by 90 degrees.
cdot z0.d, z1.h, z2.h, #180 - complex dot product on four 16-bit quad-tuplets,
accumulating results in 64-bit elements.
The complex numbers in the second source
vector are rotated by 180 degrees.
Indexed form, e.g.
cdot z0.s, z1.b, z2.b[3], #0 - complex dot product on four 8-bit quad-tuplets,
with specified quadtuplet from second source vector,
accumulating results in 32-bit elements.
cdot z0.d, z1.h, z2.h[1], #0 - complex dot product on four 16-bit quad-tuplets,
with specified quadtuplet from second source vector,
accumulating results in 64-bit elements.
The specification can be found here:
https://developer.arm.com/docs/ddi0602/latest
Reviewed By: SjoerdMeijer, rovka
Differential Revision: https://reviews.llvm.org/D61903
llvm-svn: 360870
Summary: When run-clang-tidy is given the -quiet flag, do not output the potentially hundreds of enabled check names at the beginning.
Patch by svenpanne.
Reviewers: alexfh, JonasToth
Reviewed By: JonasToth
Subscribers: JonasToth, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61849
llvm-svn: 360869
While here, update some ppc64le specific check to isPPC64(), if it
applies to big-endian as well, in the hope that it will ease the support
of big-endian if people are interested in this area. The big-endian
variant is used by at least FreeBSD, Gentoo Linux, Adélie Linux, and
Void Linux.
llvm-svn: 360868
Summary:
Add support for the following instructions:
* MUL (indexed and unpredicated vectors forms)
* SQDMULH (indexed and unpredicated vectors forms)
* SQRDMULH (indexed and unpredicated vectors forms)
* SMULH (unpredicated, predicated form added in SVE)
* UMULH (unpredicated, predicated form added in SVE)
* PMUL (unpredicated)
The specification can be found here:
https://developer.arm.com/docs/ddi0602/latest
Reviewed By: SjoerdMeijer, rovka
Differential Revision: https://reviews.llvm.org/D61902
llvm-svn: 360867
Summary:
The definition of the builtins __builtin_bswap32, __builtin_bitreverse32, __builtin_rotateleft32 and __builtin_rotateright32 rely on that the int type is 32 bits wide on the target.
The defintions of the builtins __builtin_bswap64, __builtin_bitreverse64, __builtin_rotateleft64, and __builtin_rotateright64 rely on that the long long type is 64 bits wide.
On targets where this is not the case (e.g. AVR) clang will generate faulty code (wrong llvm assembler intrinsics).
This patch add support for using 'Z' (the int32_t type) in Bultins.def. The builtins above are changed to be based on the int32_t type instead of the int type, and the int64_t type instead of the long long type.
The AVR backend (experimental) have a native int type that is only 16 bits wide. The supplied testcase will therefore fail if running the testcase on trunk as clang will convert e.g. __builtin_bitreverse32 into llvm.bitreverse.i16 on AVR.
Reviewers: dylanmckay, spatel, rsmith, efriedma
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D61845
llvm-svn: 360863
Clang integrated assembler was unable to build libunwind PPC32 assembly code,
present in functions used to save/restore register context.
This change consists in replacing the assembly style used in libunwind source,
to one that is compatible with both Clang integrated assembler as well as
GNU assembler.
Patch by Leandro Lupori!
Differential Revision: https://reviews.llvm.org/D61792
llvm-svn: 360862
This change makes each unwind step inspect the instruction at the
return address and, if needed, read r2 from its saved location and
modify the context appropriately.
The unwind logic is able to handle both ELFv1 and ELFv2 stacks.
Reported by Bug 41050
Patch by Leandro Lupori!
Differential Revision: https://reviews.llvm.org/D59694
llvm-svn: 360861
In the r360676 "Apply clang format. NFC" I applied clang-format
for whole ELFDumper.cpp. It caused a little discussion,
one of the points mentioned was that previously nicely lined up
tables are not so nice now.
This patch reverts them.
llvm-svn: 360860
Module IDs can appear in diagnostic messages.
This patch adds some auxiliary symbols to improve their readability.
Differential Revision: https://reviews.llvm.org/D61857
llvm-svn: 360858
This does the similar for error messages as rL344011 has done for warnings.
With llvm::lto::LTO, the error might appear when LTO::run() is executed.
In that case, the calling code cannot know which module causes the error
and, subsequently, cannot hint the user.
Differential Revision: https://reviews.llvm.org/D61880
llvm-svn: 360857
Removed extra parameter from !prof branch_weights metadata of
a call instruction according to the spec.
Differential Revision: https://reviews.llvm.org/D61932
llvm-svn: 360843
This reverts "r360833: [Clang][PP] Add the __FILE_NAME__ builtin macro."
The tests are failing on Windows bots, reverting the patchset until I can
work out why.
llvm-svn: 360842
Previously, we handled common symbols as a kind of Defined symbol,
but what we were doing for common symbols is pretty different from
regular defined symbols.
Common symbol and defined symbol are probably as different as shared
symbol and defined symbols are different.
This patch introduces CommonSymbol to represent common symbols.
After symbols are resolved, they are converted to Defined symbols
residing in a .bss section.
Differential Revision: https://reviews.llvm.org/D61895
llvm-svn: 360841
SymbolTable's add-family functions have lots of parameters because
when they have to create a new symbol, they forward given arguments
to Symbol's constructors. Therefore, the functions take at least as
many arguments as their corresponding constructors.
This patch simplifies the add-family functions. Now, the functions
take a symbol instead of arguments to construct a symbol. If there's
no existing symbol, a given symbol is memcpy'ed to the symbol table.
Otherwise, the functions attempt to merge the existing and a given
new symbol.
I also eliminated `CanOmitFromDynSym` parameter, so that the functions
take really one argument.
Symbol classes are trivially constructible, so looks like constructing
them to pass to add-family functions is as cheap as passing a lot of
arguments to the functions. A quick benchmark showed that this patch
seems performance-neutral.
This is a preparation for
http://lists.llvm.org/pipermail/llvm-dev/2019-April/131902.html
Differential Revision: https://reviews.llvm.org/D61855
llvm-svn: 360838
pkill reads the process name as a pattern, not a raw name. This means
that if the process name contains + or other regex characters, pkill
fails.
llvm-svn: 360835
This patch adds the `__FILE_NAME__` macro that expands to the
last component of the path, similar to `__FILE__` except with
a guarantee that only the last path component (without the
separator) will be rendered.
I intend to follow through with discussion of this with WG14
as a potential inclusion in the C standard or failing that,
try to discuss this with GCC developers since this extension
is desired by GCC and Clang users/developers alike.
Differential Revision: https://reviews.llvm.org/D61756
llvm-svn: 360833
Modifies the DenseMapInfo<SymbolStringPtr>::getHashValue method to take its
argument by const-ref rather than by value (to avoid unnecessary ref-counting
operations) and to defer to DenseMapInfo<void*> for the hash value computation
(since SymbolStringPtrs are just pointers under the hood).
llvm-svn: 360831
Roman Lebedev