Summary:
This patch adds OCaml APIs for LLVMGetNormalDest and LLVMGetUnwindDest
on InvokeInsts, as well as LLVMGetNumArgOperands on CallInsts and
InvokeInsts.
Reviewers: whitequark
Reviewed By: whitequark
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D52204
llvm-svn: 342433
Summary:
For --pack-dyn-relocs=android, finalizeSections calls
LinkerScript::assignAddresses and
AndroidPackedRelocationSection::updateAllocSize in a loop,
where assignAddresses lays out the ELF image, then updateAllocSize
determines the size of the Android packed relocation table by encoding it.
Encoding the table requires knowing the values of relocation addends.
To get the addend of a TLS relocation, updateAllocSize can call getSymVA
on a TLS symbol before setPhdrs has initialized Out::TlsPhdr, producing an
error:
<file> has an STT_TLS symbol but doesn't have an SHF_TLS section
Fix the problem by initializing Out::TlsPhdr immediately after the program
headers are created. The segment's p_vaddr field isn't initialized until
setPhdrs, so use FirstSec->Addr, which is what setPhdrs would use.
FirstSec will typically refer to the .tdata or .tbss output section, whose
(tentative) address was computed by assignAddresses.
Android currently avoids this problem because it uses emutls and doesn't
support ELF TLS. This problem doesn't apply to --pack-dyn-relocs=relr
because SHR_RELR only handles relative relocations without explicit addends
or info.
Fixes https://bugs.llvm.org/show_bug.cgi?id=37841.
Reviewers: ruiu, pcc, chh, javed.absar, espindola
Subscribers: emaste, arichardson, llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D51671
llvm-svn: 342432
This reverts r342395 as it caused error
> Argument value type does not match pointer operand type!
> %0 = atomicrmw volatile xchg i8* %_Value1, i32 1 monotonic, !dbg !25
> i8in function atomic_flag_test_and_set
> fatal error: error in backend: Broken function found, compilation aborted!
on bot http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/
More details are available at https://reviews.llvm.org/D52080
llvm-svn: 342431
There seems to be a separate command line tokenization issue that
prevents just ':\s*$' from working, since then the pattern argument
isn't quoted, and grep.exe misinterprets the backslash somehow.
llvm-svn: 342430
Summary:
The GlobalIFunc value kind has not yet been added to the OCaml
API. This patch only extends the enum, so that e.g. classify_value
will not crash. No support for manipulating or building GlobalIFuncs
is added at this point.
Reviewers: whitequark, deadalnix
Reviewed By: whitequark
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D52198
llvm-svn: 342429
Summary:
The token type has not yet been added to the OCaml API. This
patch only extends the enum, so that e.g. classify_type will not
crash. No support for manipulating or building tokens is added at this
point.
Reviewers: whitequark
Reviewed By: whitequark
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D52197
llvm-svn: 342428
Summary:
The OCaml bindings have become out of date and several opcodes have
been added to the C API without corresponding additions to the OCaml
API.
Reviewers: whitequark, mgorny
Reviewed By: whitequark
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D52196
llvm-svn: 342427
When building static fat libraries, we need to ensure that we use libtool rather
than llvm-ar to create the library. Duplicate the rules from LLVM to ensure
that we correctly build the fat libraries when building compiler-rt standalone.
This also requires that we duplicate the workaround for the `DYLD_LIBRARY_PATH`
for SIP. Additionally, ensure that we set the `CMAKE_*_ARCHIVE_FINISH` variable
to ensure that we do not try to use `ranlib` on that target.
llvm-svn: 342425
Summary:
EarlyCSE can make IR changes that will leave MemorySSA with accesses claiming to be optimized, but for which a subsequent MemorySSA run will yield a different optimized result.
Due to relying on AA queries, we can't fix this in general, unless we recompute MemorySSA.
Adding some tests to track this and a basic verify for future potential failures.
Reviewers: george.burgess.iv, gberry
Subscribers: sanjoy, jlebar, Prazek, llvm-commits
Differential Revision: https://reviews.llvm.org/D51960
llvm-svn: 342422
Summary:
We run the tests for -Wthread-safety-{negative,verbose} with the new
attributes as well as the old ones. Also put the macros in a header so
that we don't have to copy them all around.
The warn-thread-safety-parsing.cpp test checks for warnings depending on
the actual attribute name, so it can't undergo the same treatment.
Together with D49275 this should fix PR33754.
Reviewers: aaron.ballman, delesley, grooverdan
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52141
llvm-svn: 342418
Test failed as D52120 made ExprMutationAnalyzer smarter, fixed by:
- Add move-ctor for `Mutable` to make it actually movable.
- Properly implement `remove_reference`.
The failed test case is:
void negativeVarIsMoved() {
for (auto M : View<Iterator<Mutable>>()) {
auto Moved = std::move(M);
}
}
Before D52120, `std::move(M)` itself is considered as a mutation to `M`,
while after D52120 it's only considered as a cast to rvalue, the
move-assignment is what causes the actual mutation. The test case didn't
mock things properly so the intended move-assignement was actually a
copy-assignment.
llvm-svn: 342417
Add support mips64(el)-linux-gnuabin32 triples, and set them to N32.
Debian architecture name mipsn32/mipsn32el are also added. Set
UseIntegratedAssembler for N32 if we can detect it.
Patch by YunQiang Su.
Differential revision: https://reviews.llvm.org/D51408
llvm-svn: 342416
Previously we would dump the names of enum types, but not their
enumerator values. This adds support for enumerator values. In
doing so, we have to introduce a general purpose mechanism for
caching symbol indices of field list members. Unlike global
types, FieldList members do not have a TypeIndex. So instead,
we identify them by the pair {TypeIndexOfFieldList, IndexInFieldList}.
llvm-svn: 342415
Previously for cv-qualified types, we would just ignore them
and they would never get printed. Now we can enumerate them
and cache them like any other symbol type.
llvm-svn: 342414
Fixes a number of issues:
- Global variables are not used for communication
- Trait should be defined on a graph, not on a node
- Defining the trait on a graph allows us to use a correct allocator,
no longer crashing while printing trimmed graphs
Differential Revision: https://reviews.llvm.org/D52183
llvm-svn: 342413
A General-dynamic tls access can be written using a R_PPC64_TLSGD16 relocation
if the target got entry is within 16 bits of the TOC-base. This patch adds
support for R_PPC64_TLSGD16 by relaxing it the same as a R_PPC64_GOT_TLSGD16_LO.
Differential Revision: https://reviews.llvm.org/D52055
llvm-svn: 342411
There are a growing number of places when we either want to read or write an
instruction when handling a half16 relocation type. On big-endian the buffer
pointer is pointing into the middle of the word we want and on little-endian it
is pointing to the start of the word. These 2 helpers are to simplify reading
and writing in these contexts.
Differential Revision: https://reviews.llvm.org/D52115
llvm-svn: 342410
Summary:
This is a follow up of D52008 and should make the analyzer being able to handle perfect forwardings in real world cases where forwardings are done through multiple layers of function calls with `std::forward`.
Fixes PR38891.
Reviewers: lebedev.ri, JonasToth, george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin, mikhail.ramalho, Szelethus, cfe-commits
Differential Revision: https://reviews.llvm.org/D52120
llvm-svn: 342409
getLoopID has different control flow for two cases: If there is a
single loop latch and for any other number of loop latches (0 and more
than one). The latter case should return the same result if there is
only a single latch. We can save the preceding redundant search for a
latch by handling both cases with the same code.
Differential Revision: https://reviews.llvm.org/D52118
llvm-svn: 342406
We were mapping an instruction every time we saw something we couldn't map
before this. Since each illegal mapping is unique, we only have to do this once.
This makes it so that we don't map illegal instructions when the previous
mapped instruction was illegal.
In CTMark (AArch64), this results in 240 fewer instruction mappings on
average over 619 files in total. The largest improvement is 12576 fewer
mappings in one file, and the smallest is 0. The median improvement is 101
fewer mappings.
llvm-svn: 342405
Summary:
The IR reference for the `byval` attribute states:
```
This indicates that the pointer parameter should really be passed by value
to the function. The attribute implies that a hidden copy of the pointee is
made between the caller and the callee, so the callee is unable to modify
the value in the caller. This attribute is only valid on LLVM pointer arguments.
```
However, on Win64, this attribute is unimplemented and the raw pointer is
passed to the callee instead. This is problematic, because frontend authors
relying on the implicit hidden copy (as happens for every other calling
convention) will see the passed value silently (if mutable memory) or
loudly (by means of a crash) modified because the callee treats the
location as scratch memory space it is allowed to mutate.
At this point, it's worth taking a step back to understand the context.
In most calling conventions, aggregates that are too large to be passed
in registers, instead get *copied* to the stack at a fixed (computable
from the signature) offset of the stack pointer. At the LLVM, we hide
this hidden copy behind the byval attribute. The caller passes a pointer
to the desired data and the callee receives a pointer, but these pointers
are not the same. In particular, the pointer that the callee receives
points to temporary stack memory allocated as part of the call lowering.
In most calling conventions, this pointer is never realized in registers
or memory. The temporary memory is simply defined by an implicit
offset from the stack pointer at function entry.
Win64, uniquely, works differently. The structure is still passed in
memory, but instead of being stored at an implicit memory offset, the
caller computes a pointer to the temporary memory and passes it to
the callee as a regular pointer (taking up a register, or if all
registers are taken up, an additional stack slot). Presumably, this
was done to allow eliding the copy when passing aggregates through
several functions on the stack.
This explains why ignoring the `byval` attribute mostly works on Win64.
The argument simply gets passed as a pointer and as long as we're ok
with the callee trampling all over that memory, there are no ill effects.
However, it does contradict the documentation of the `byval` attribute
which specifies that there is to be an implicit copy.
Frontends can of course work around this by never emitting the `byval`
attribute for Win64 and creating `alloca`s for the requisite temporary
stack slots (and that does appear to be what frontends are doing).
However, the presence of the `byval` attribute is not a trap for
frontend authors, since it seems to work, but silently modifies the
passed memory contrary to documentation.
I see two solutions:
- Disallow the `byval` attribute in the verifier if using the Win64
calling convention.
- Make it work by simply emitting a temporary stack copy as we would
with any other calling convention (frontends can of course always
not use the attribute if they want to elide the copy).
This patch implements the second option (make it work), though I would
be fine with the first also.
Ref: https://github.com/JuliaLang/julia/issues/28338
Reviewers: rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D51842
llvm-svn: 342402
dllimported symbols go through an import stub that's called __imp_ followed by
the name the stub points to. Make that work.
Differential Revision: https://reviews.llvm.org/D52145
llvm-svn: 342401
isSupportedValue explicitly checked and accepted many types of value,
primarily for debugging reasons. Remove most of these checks and do a
bit of refactoring now that the pass is more stable. This also enables
ZExts to be sources, but this has very little practical benefit at the
moment extend instructions will still be introduced.
Differential Revision: https://reviews.llvm.org/D52080
llvm-svn: 342395
Summary:
PR37913 documents wrong behaviour for a templated exception factory function.
The check does misidentify dependent types as not derived from std::exception.
The fix to this problem is to ignore dependent types, the analysis works correctly
on the instantiated function.
Reviewers: aaron.ballman, alexfh, hokein, ilya-biryukov
Reviewed By: alexfh
Subscribers: lebedev.ri, nemanjai, mgorny, kbarton, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D48714
llvm-svn: 342393
We allow overflowing instructions if they're decreasing and only used
by an unsigned compare. Add the extra condition that the icmp cannot
be using a negative immediate.
Differential Revision: https://reviews.llvm.org/D52102
llvm-svn: 342392
Summary:
In order for this test to work the log file needs to be removed from both
from the host and device. To fix this the `rm` `RUN` lines have been
replaced with `RUN: rm` followed by `RUN: %device_rm`.
Initially I tried having it so that `RUN: %run rm` implicitly runs `rm`
on the host as well so that only one `RUN` line is needed. This
simplified writing the test however that had two large drawbacks.
* It's potentially very confusing (e.g. for use of the device scripts outside
of the lit tests) if asking for `rm` to run on device also causes files
on the host to be deleted.
* This doesn't work well with the glob patterns used in the test.
The host shell expands the `%t.log.*` glob pattern and not on the
device so we could easily miss deleting old log files from previous
test runs if the corresponding file doesn't exist on the host.
So instead deletion of files on the device and host are explicitly
separate commands.
The command to delete files from a device is provided by a new
substitution `%device_rm` as suggested by Filipe Cabecinhas.
The semantics of `%device_rm` are that:
* It provides a way remove files from a target device when
the host is not the same as the target. In the case that the
host and target are the same it is a no-op.
* It interprets shell glob patterns in the context of the device
file system instead of the host file system.
This solves the globbing problem provided the argument is quoted so
that lit's underlying shell doesn't try to expand the glob pattern.
* It supports the `-r` and `-f` flags of the `rm` command,
with the same semantics.
Right now an implementation of `%device_rm` is provided only for
ios devices. For all other devices a lit warning is emitted and
the `%device_rm` is treated as a no-op. This done to avoid changing
the behaviour for other device types but leaves room for others
to implement `%device_rm`.
The ios device implementation uses the `%run` wrapper to do the work
of removing files on a device.
The `iossim_run.py` script has been fixed so that it just runs `rm`
on the host operating system because the device and host file system
are the same.
rdar://problem/41126835
Reviewers: vsk, kubamracek, george.karpenkov, eugenis
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D51648
llvm-svn: 342391
Summary:
Hello, i would like to suggest a fix for one of the checks in clang-tidy.The bug was reported in https://bugs.llvm.org/show_bug.cgi?id=32575 where you can find more information.
For example:
```
template <typename T0>
struct S {
template <typename T>
void g() const {
int a;
(void)a;
}
};
void f() {
S<int>().g<int>();
}
```
this piece of code should not trigger any warning by the check modernize-redundant-void-arg but when we execute the following command
```
clang_tidy -checks=-*,modernize-redundant-void-arg test.cpp -- -std=c++11
```
we obtain the following warning:
/Users/eco419/Desktop/clang-tidy.project/void-redundand_2/test.cpp:6:6: warning: redundant void argument list in function declaration [modernize-redundant-void-arg]
(void)a;
^~~~
Reviewers: aaron.ballman, hokein, alexfh, JonasToth
Reviewed By: aaron.ballman, JonasToth
Subscribers: JonasToth, lebedev.ri, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D52135
llvm-svn: 342388
Rebase rL341954 since https://bugs.llvm.org/show_bug.cgi?id=38912
has been fixed by rL342055.
Precommit testing performed:
* Overnight runs of csmith comparing the output between programs
compiled with gvn-hoist enabled/disabled.
* Bootstrap builds of clang with UbSan/ASan configurations.
llvm-svn: 342387
Create a temporary file in the system temporary directory instead of creating a
file in the current directory, which may be not writable. (Fix for an issue
introduced in r342283.)
llvm-svn: 342386
Summary:
Completing inside the expression command now uses the new description API
to also provide additional information to the user. For now this information
are the types of variables/fields and the signatures of completed function calls.
Reviewers: #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D52103
llvm-svn: 342385
Summary:
The init expression of a VarDecl is overwritten in the "To" context if we
import a VarDecl without an init expression (and with a definition). Please
refer to the added tests, especially InitAndDefinitionAreInDifferentTUs. This
patch fixes the malfunction by importing the whole Decl chain similarly as we
did that in case of FunctionDecls. We handle the init expression similarly to
a definition, alas only one init expression will be in the merged ast.
Reviewers: a_sidorin, xazax.hun, r.stahl, a.sidorin
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D51597
llvm-svn: 342384
whitequark