| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 261672
|
| |
|
|
|
|
|
|
| |
debug info."
This and the corresponding Clang change caused PR26715.
llvm-svn: 261671
|
| |
|
|
|
|
|
|
| |
debug info." and r261657
r261634 and r261633 seems to have caused PR26715. r261657 depends on the former two.
llvm-svn: 261670
|
| |
|
|
|
|
| |
context. This eliminates false-positive diagnostics about null pointer dereferences (etc) in the controlling expression.
llvm-svn: 261669
|
| |
|
|
| |
llvm-svn: 261668
|
| |
|
|
|
|
|
|
|
|
|
| |
The .tbss section is in the middle of a PT_LOAD. Whatever treatment we
give to its address we must also give to the offset.
We were ignoring it for address computations, but not for offset.
Fixes pr26712.
llvm-svn: 261667
|
| |
|
|
| |
llvm-svn: 261666
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently, the ARM Constant Island may not converge (or not converge quickly).
This patch let it move to the closest water after the user if it doesn't converge after 15 iterations.
This address https://llvm.org/bugs/show_bug.cgi?id=25339
Reviewers: t.p.northover, srhines, kristof.beyls, aadg, rengolin
Subscribers: weimingz, aemerson, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D16890
llvm-svn: 261665
|
| |
|
|
| |
llvm-svn: 261664
|
| |
|
|
|
|
|
|
|
|
| |
This patch moves BitcodeFile instantiation into createObjectFile.
Previously, we handle bitcode files outside that function and did
not handle for --whole-archive.
http://reviews.llvm.org/D17527
llvm-svn: 261663
|
| |
|
|
|
|
|
|
|
|
|
| |
Implements a mostly-conventional redzone for the userspace
stack. Because we have unsigned load/store offsets we continue to use a
local SP subtracted from the incoming SP but do not write it back to
memory.
Differential Revision: http://reviews.llvm.org/D17525
llvm-svn: 261662
|
| |
|
|
|
|
|
| |
Since they're scheduled to be updated soon, we'll just comment out this test for
the moment, and re-commit when the bots are updated.
llvm-svn: 261661
|
| |
|
|
| |
llvm-svn: 261660
|
| |
|
|
|
|
| |
Less indenting, named local variables, more descriptive names.
llvm-svn: 261659
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first issue is that we longjmp from ScopedInterceptor scope
when called from an ignored lib. This leaves thr->in_ignored_lib set.
This, in turn, disables handling of sigaction. This, in turn,
corrupts tsan state since signals delivered asynchronously.
Another issue is that we can ignore synchronization in asignal
handler, if the signal is delivered into an IgnoreSync region.
Since signals are generally asynchronous, they should ignore
memory access/synchronization/interceptor ignores.
This could lead to false positives in signal handlers.
llvm-svn: 261658
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that LLVM r259973 allows replacing a temporary type with another
temporary we can rely on the original implementation.
It is possible for enums to be created as part of
their own declcontext. In this case a FwdDecl will be created
twice. This doesn't cause a problem because both FwdDecls are
entered into the ReplaceMap: finalize() will replace the first
FwdDecl with the second and then replace the second with
complete type.
Thanks to echristo for pointing this out.
llvm-svn: 261657
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
locally unwind
It is problematic if the inlinee has a cleanupret which unwinds to
caller and we inline it into a call site which doesn't unwind.
If the funclet unwinds anywhere other than to the caller,
then we will give the funclet two unwind destinations.
This will result in a verifier failure.
Seeing as how the caller wasn't an invoke (which would locally unwind)
and that the funclet cannot unwind to caller, we must conclude that an
'unwind to caller' cleanupret is dynamically unreachable.
This fixes PR26698.
Differential Revision: http://reviews.llvm.org/D17536
llvm-svn: 261656
|
| |
|
|
| |
llvm-svn: 261655
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r261551 due to failing tests in windows bots:
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/10054
Failing Tests (4):
Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.CaseInsensitive
Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.DirectoryIteration
Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.MappedFiles
Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.UseExternalName
llvm-svn: 261654
|
| |
|
|
| |
llvm-svn: 261653
|
| |
|
|
| |
llvm-svn: 261652
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes the R_AARCH64_ABS64 relocation when used in shared mode,
where it requires a dynamic R_AARCH64_RELATIVE relocation. To correct set
the addend on the dynamic relocation (since it will be used by the dynamic
linker), a new TargetInfo specific hook was created (getDynRelativeAddend)
to get the correct addend based on relocation type.
The patch fixes the issues when creating shared library code against
{init,fini}_array, where it issues R_AARCH64_ABS64 relocation against
local symbols.
llvm-svn: 261651
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix a bug in epilog generation where the incoming stack arguments were
not being popped for fastcc functions when -tailcallopt was passed.
Reviewers: t.p.northover, mcrosier, jmolloy, rengolin
Subscribers: aemerson, rengolin, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D16894
llvm-svn: 261650
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is a straight cut and paste of the existing code and is intended to
be the first step in solving part of PR26702:
https://llvm.org/bugs/show_bug.cgi?id=26702
We should be able to reuse most of this and delete the nearly identical
existing code in visitOr(). Then, we can enhance visitXor() to use the
same code too.
llvm-svn: 261649
|
| |
|
|
|
|
| |
LWG#2590, but there are no code changes, just additional tests
llvm-svn: 261648
|
| |
|
|
| |
llvm-svn: 261647
|
| |
|
|
| |
llvm-svn: 261646
|
| |
|
|
|
|
|
| |
Use uniform style for inline code blocks, specify language for YAML code blocks,
various formatting fixes etc.
llvm-svn: 261645
|
| |
|
|
| |
llvm-svn: 261644
|
| |
|
|
| |
llvm-svn: 261643
|
| |
|
|
| |
llvm-svn: 261642
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17512
llvm-svn: 261641
|
| |
|
|
| |
llvm-svn: 261640
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The scalar float/double function bodies are a direct copy/paste
with usage of the CLC wrappers to vectorize them.
This commit also adds in the FP_ILOGB0 and FP_ILOGBNAN macros which are
equal to the results of ilogb(0.0f) and ilogb(float nan) respectively.
v2: Add FP_ILOGB0 and FP_ILOGBNAN definitions
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Jan Vesely <jan.vesely@rutgers.edu>
v1 Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 261639
|
| |
|
|
|
|
|
|
| |
Adding closer to the end of macro }->})
Differential Revision: http://reviews.llvm.org/D17506
llvm-svn: 261638
|
| |
|
|
| |
llvm-svn: 261637
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
On arm64, linux<=4.4 and Android<=M there is a bug, which prevents single-stepping from working when
the system comes back from suspend, because of incorrectly initialized CPUs. This did not really
affect Android<M, because it did not use software suspend, but it is a problem for M, which uses
suspend (doze) quite extensively. Fortunately, it seems that the first CPU is not affected by
this bug, so this commit implements a workaround by forcing the inferior to execute on the first
cpu whenever we are doing single stepping.
While inside, I have moved the implementations of Resume() and SingleStep() to the thread class
(instead of process).
Reviewers: tberghammer, ovyalov
Subscribers: aemerson, rengolin, tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D17509
llvm-svn: 261636
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17506
llvm-svn: 261635
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15977
llvm-svn: 261634
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15976
llvm-svn: 261633
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch is intended to improve pointer arithmetic checker.
From now on it only warns when the pointer arithmetic is likely to cause an
error. For example when the pointer points to a single object, or an array of
derived types.
Differential Revision: http://reviews.llvm.org/D14203
llvm-svn: 261632
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Signalfd is not used in the code anymore, and given that the same functionality can be achieved
with the new MainLoop class, it's unlikely we will need it in the future. Remove all traces of
it.
Reviewers: tberghammer, ovyalov
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D17510
llvm-svn: 261631
|
| |
|
|
| |
llvm-svn: 261630
|
| |
|
|
| |
llvm-svn: 261629
|
| |
|
|
| |
llvm-svn: 261628
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pattern that triggers it. This essentially requires an immutable
function analysis, as that will survive anything we do to invalidate it.
When we have such patterns, the function analysis manager will not get
cleared between runs of the proxy.
If we actually need an assert about how things are queried, we can add
more elaborate machinery for computing it, but so far I'm not aware of
significant value provided.
Thanks to Justin Lebar for noticing this when he made a (seemingly
innocuous) change to FunctionAttrs that is enough to trigger it in one
test there. Now it is covered by a direct test of the pass manager code.
llvm-svn: 261627
|
| |
|
|
| |
llvm-svn: 261626
|
| |
|
|
| |
llvm-svn: 261625
|
| |
|
|
|
|
|
|
|
|
|
| |
system.
Previously, this was only being tested with larger integration tests.
That makes it hard to isolated specific issues with it, and makes the
APIs themselves less well tested. Add a unittest based around the same
patterns used for testing the general pass manager.
llvm-svn: 261624
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If we want classify OoO or not, using getSchedModel().isOutOfOrder()
could be more proper way than using Subtarget->isLikeA9().
Reviewers: jmolloy, rengolin
Differential Revision: http://reviews.llvm.org/D17433
llvm-svn: 261623
|