| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were always setting the block alignment to 2 bytes in Thumb mode
and 4-bytes in ARM mode (r325754, and r325012), but this could cause
reducing the block alignment when it already had been aligned (e.g.
in Thumb mode when the block is a CPE that was already 4-byte aligned).
Patch by Momchil Velikov, I've only added a test.
Differential Revision: https://reviews.llvm.org/D43777
llvm-svn: 326232
|
|
|
|
|
|
|
|
|
|
| |
Following DW_AT_sibling attributes completely defeats the pruning pass.
Although clang doesn't generate the DW_AT_sibling attribute we should
still handle it correctly.
Differential revision: https://reviews.llvm.org/D43439
llvm-svn: 326231
|
|
|
|
| |
llvm-svn: 326230
|
|
|
|
| |
llvm-svn: 326229
|
|
|
|
|
|
| |
The bots don't seem to like the .inc file. I must be missing some cmake incantation.
llvm-svn: 326228
|
|
|
|
|
|
|
|
|
|
| |
Summary: This fixes a glitch where ``operator: value`` in a text proto would mess up the underlying formatting since it gets parsed as a kw_operator instead of an identifier.
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43830
llvm-svn: 326227
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D43807
llvm-svn: 326226
|
|
|
|
|
|
|
|
| |
These tables add 3000 lines to X86InstrInfo.cpp. And if we ever manage to auto generate them they'll be a separate file anyway.
Differential Revision: https://reviews.llvm.org/D43806
llvm-svn: 326225
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Supports common prologue/epilogue instructions.
Reviewers: clayborg, labath
Reviewed By: clayborg, labath
Subscribers: davide, anajuliapc, alexandreyy, lbianc, nemanjai, mgorny, kbarton
Differential Revision: https://reviews.llvm.org/D43345
Author: Leandro Lupori <leandro.lupori@gmail.com>
llvm-svn: 326224
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is done via new LIBUNWIND_TEST_COMPILER_FLAGS and
LIBUNWIND_TEST_LINKER_FLAGS variables.
Reviewed By: sdardis
Differential Revision: https://reviews.llvm.org/D43585
llvm-svn: 326223
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: benhamilton, hokein
Reviewed By: benhamilton
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43775
llvm-svn: 326222
|
|
|
|
|
|
|
|
| |
This is a slight reduction of one of the benchmarks
that suffered with D43079. Cost model changes should
not cause this test to remain scalarized.
llvm-svn: 326221
|
|
|
|
| |
llvm-svn: 326220
|
|
|
|
|
|
|
|
|
| |
Return a new CompilerRT Path on NetBSD: "netbsd", instead of
getOS(), which returns a string like "netbsd8.9.12".
Sponsored by <The NetBSD Foundation>
llvm-svn: 326219
|
|
|
|
|
|
|
| |
This test contained a copy of the inferior used by most of llgs test.
This was done to enable better paralelization, but now it's irrelevant.
llvm-svn: 326218
|
|
|
|
|
|
|
|
| |
This is a slight reduction of one of the benchmarks
that suffered with D43079. Cost model changes should
not cause this test to remain scalarized.
llvm-svn: 326217
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a workarond for the fallout from D42644:
[asan] Intercept std::rethrow_exception indirectly.
Reported problem on NetBSD/amd64:
$ sh ./projects/compiler-rt/test/sanitizer_common/asan-i386-NetBSD/NetBSD/Output/ttyent.cc.script
/usr/lib/i386/libgcc.a(unwind-dw2.o): In function `_Unwind_RaiseException':
unwind-dw2.c:(.text+0x1b41): multiple definition of `_Unwind_RaiseException'
/public/llvm-build/lib/clang/7.0.0/lib/netbsd/libclang_rt.asan-i386.a(asan_interceptors.cc.o):/public/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:337: first defined here
clang-7.0: error: linker command failed with exit code 1 (use -v to see invocation)
llvm-svn: 326216
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently when abort is enabled, we get a diagnostic saying "Fallback
path used .... " and the program terminates. To actually figure out what
the reason is, we need to run again with another verbose argument
"-pass-remarks-missed=gisel". Instead, when we are going to abort,
we might as well print expensive remarks.
https://reviews.llvm.org/D43796
llvm-svn: 326215
|
|
|
|
| |
llvm-svn: 326214
|
|
|
|
|
|
|
| |
requiring a modern macOS (at least 10.11)
Reviewer: Jason Molenda
llvm-svn: 326213
|
|
|
|
|
|
|
| |
If several member expressions are mapped and they reference the same
address as a base, but access different members, this must be allowed.
llvm-svn: 326212
|
|
|
|
| |
llvm-svn: 326211
|
|
|
|
| |
llvm-svn: 326210
|
|
|
|
|
|
| |
Should fix the build in some bots.
llvm-svn: 326209
|
|
|
|
|
|
|
|
| |
Re-enable commit r323991 now that r325931 has been committed to make
MachineOperand::isRenamable() check more conservative w.r.t. code
changes and opt-in on a per-target basis.
llvm-svn: 326208
|
|
|
|
|
|
|
| |
Now we don't mark a PT_LOAD as readable if all its sections are
SHF_ARM_PURECODE.
llvm-svn: 326207
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Instead of using `AlignedChunkHeaderSize`, introduce a `constexpr` function
`getHeaderSize` in the `Chunk` namespace. Switch `RoundUpTo` to a `constexpr`
as well (so we can use it in `constexpr` declarations). Mark a few variables
in the areas touched as `const`.
Overall this has no functional change, and is mostly to make things a bit more
consistent.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: delcypher, #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D43772
llvm-svn: 326206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes a few issues djasper@ brought up in his review of D43522.
Test Plan:
make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43598
llvm-svn: 326205
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::unique_ptr<>"
This reverts commit rL326201
This broke gcc4.8 builds, compiler just segfaults:¬
http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/14909¬
http://lab.llvm.org:8011/builders/clang-x86_64-linux-abi-test/builds/22673¬
llvm-svn: 326204
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::unique_ptr<>"
This reverts commit rL326202
This broke gcc4.8 builds, compiler just segfaults:
http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/14909
http://lab.llvm.org:8011/builders/clang-x86_64-linux-abi-test/builds/22673
llvm-svn: 326203
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::unique_ptr<>
Summary:
I'm not sure whether there are any principal reasons why it returns raw owning pointer,
or it is just a old code that was not updated post-C++11.
I'm not too sure what testing i should do, because `check-all` is not error clean here for some reason,
but it does not //appear// asif those failures are related to these changes.
This is Clang-tools-extra part.
Clang part is D43779.
Reviewers: klimek, bkramer, alexfh, pcc
Reviewed By: alexfh
Subscribers: ioeric, jkorous-apple, cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D43780
llvm-svn: 326202
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::unique_ptr<>
Summary:
Noticed during review of D41102.
I'm not sure whether there are any principal reasons why it returns raw owning pointer,
or it is just a old code that was not updated post-C++11.
I'm not too sure what testing i should do, because `check-all` is not error clean here for some reason,
but it does not //appear// asif those failures are related to these changes.
This is clang part.
Clang-tools-extra part is D43780.
Reviewers: klimek, bkramer, alexfh, pcc
Reviewed By: alexfh
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D43779
llvm-svn: 326201
|
|
|
|
| |
llvm-svn: 326198
|
|
|
|
| |
llvm-svn: 326195
|
|
|
|
| |
llvm-svn: 326194
|
|
|
|
| |
llvm-svn: 326193
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ObjC defines `@autoreleasepool` and `@synchronized` control blocks. These
used to be formatted according to the `AfterObjCDeclaration` brace-
wrapping flag, which is not very consistent.
This patch changes the behavior to use the `AfterControlStatement` flag
instead. This should not affect the behavior unless a custom brace
wrapping mode is used.
Reviewers: krasimir, djasper, klimek, benhamilton
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43232
llvm-svn: 326192
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The blocks used to be formatted using the "default" behavior, and would
thus be mistaken for function calls followed by blocks: this could lead
to unexpected inlining of the block and extra line-break before the
opening brace.
They are now formatted similarly to `@autoreleasepool` blocks, as
expected:
@synchronized(self) {
f();
}
Reviewers: krasimir, djasper, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43114
llvm-svn: 326191
|
|
|
|
|
|
| |
SplitBinaryOpsAndApply
llvm-svn: 326189
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Since r325479 the DataLayout includes a program address space. However, it
is not possible to use `call %foo` if foo is a `i8(...) addrspace(200)` and
the DataLayout specifies address space 200 as the address space for functions.
With this change the IR parser will still accept variables in the program
address space as well as address space 0 for call and invoke functions.
Reviewers: pcc, arsenm, bjope, dylanmckay, theraven
Reviewed By: dylanmckay
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D43645
llvm-svn: 326188
|
|
|
|
| |
llvm-svn: 326187
|
|
|
|
|
|
|
|
|
|
| |
Add test that verifies that we don't follow DWARF values with a
reference form class, such as DW_AT_sibling.
Since clang doesn't generate the latter attribute, we added a PowerPC
test generated on an old PowerBook G4. (Thanks Adrian!)
llvm-svn: 326183
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until this patch, only `powerpc` and `ppc32` were recognized as valid
PowerPC 32-bit architectures in a target triple. This was incompatible
with the triple `ppc-apple-darwin` as returned for libObject. I found
out about this when working on a test case using a binary generated on
an old PowerBook G4.
We had the choice of either fix this in the Mach-O object parser or
in the Triple implementation. I chose the latter because it feels like
the most canonical place.
Differential revision: https://reviews.llvm.org/D43760
llvm-svn: 326182
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case we update a ValuePHI node created earlier, we could update it
based on a different OpPHI which could be in a different block.
We need to update the TempToBlock mapping reflecting the new block,
otherwise we would end up placing the new phi node in a wrong block.
This problem is exposed by the test case in
https://bugs.llvm.org/show_bug.cgi?id=36504.
This patch fixes a slightly simpler problem than in the bug report. In
the bug's re-producer, the additional problem is that we are re-using a
ValuePHI node with to few incoming values for the new OpPHI. If this
patch makes sense, I will follow it up with a patch that creates a new
PHI node if the existing PHI node has a different number of incoming
values.
Reviewers: davide, dberlin
Reviewed By: dberlin
Differential Revision: https://reviews.llvm.org/D43770
llvm-svn: 326181
|
|
|
|
| |
llvm-svn: 326180
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Imagine that we have sections A, B, C, where A == C and
symbol ordering file containing symbols: symC, symB, symA
Previously because of ICF it was possible that final order would be
B, A or B, C. That violates order specified in ordering file.
Patch changes that.
Differential revision: https://reviews.llvm.org/D43234
llvm-svn: 326179
|
|
|
|
|
|
|
|
|
| |
Since getNode() might not always return the requsted opcode, for instance if
called with (ISD::AND, -1) arguments, there should be a check so that
SelectCode() is only called when appropriate.
Review: Ulrich Weigand
llvm-svn: 326178
|
|
|
|
|
|
|
|
|
|
|
| |
The only cases I can come up with where this invalidation needs to
happen is when there's a deletion somewhere. If we find more creative
test-cases, we can probably go with another approach mentioned on
PR36529.
Fixes PR36529.
llvm-svn: 326177
|
|
|
|
|
|
|
|
|
|
|
| |
referenced by DSOs.
It should be possible to resolve undefined symbols in dynamic libraries
using symbols defined in a linker script.
Differential Revision: https://reviews.llvm.org/D43011
llvm-svn: 326176
|
|
|
|
|
|
|
|
|
|
|
|
| |
It appears that there were many cases where we were directly (through
templates) calling the dtor of MemoryAccess, which is conceptually an
abstract class.
This hasn't been a problem, since the data members of all of the
subclasses of MemoryAccess have been POD. I'm planning on changing that.
:)
llvm-svn: 326175
|