Running tests with -t prints all lldb commands being run. It makes sense
to print all the build commands as well.
Differential Revision: https://reviews.llvm.org/D112212
The patch [1] introduced this FIXME but ended up not being removed when fixed.
[1]: f68df12fb0
Signed-off-by: Luís Ferreira <contact@lsferreira.net>
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D112586
Unqualify (constant) arrays recursively, just like we do for pointers.
This allows for better pretty printer matching.
Differential Revision: https://reviews.llvm.org/D112708
The TailDuplicator merged two blocks, even if the first one ended with
a terminator, resulting in invalid MIR, where a terminator is in the
middle of a block.
Abort merging if the first block ends with a terminator.
Differential Revision: https://reviews.llvm.org/D112226
InsertionGuards move constructor is currently the compiler synthesized implementation which is very bug prone. A move constructed InsertionGuard will get the same builder and insertion point as the one it is constructed from, leading to insertion point being restored twice. This can even happen in non obvious situations on some compilers, such as when returning a move constructible struct from a function.
This patch fixes the issue by properly implementing the move constructor. An InsertionGuard that was used to move construct another InsertionGuard is simply inactive and will not restore the insertion point.
I chose to explicitly delete the move assign operator as its semantics are not clear cut. If one were to strictly follow the rule of 5, you'd have to restore the insertion point before then taking ownership of the others guards fields. I believe that to be rather confusing and/or surprising however. One may still get such semantics using llvm::Optional or std::optional and the emplace method if really needed.
Differential Revision: https://reviews.llvm.org/D112749
Adapt hoistPaddingOnTensors to leave replacing and erasing the old pad tensor operation to the caller. This change makes the function pattern friendly.
Depends On D112003
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D112255
We're missing all cases where the return value is a type alias.
Unfortunately, this includes things we care about, such as
`std::vector<T>::operator[]` (return value is `const_reference`,
not `const T&`).
Match the canonical type instead.
Differential Revision: https://reviews.llvm.org/D112722
For x86, most contempory mingw toolchains use i686 as 32 bit
x86 arch target.
As long as the target triple is set to the right form, this works
fine, either as the compiler's default target, or via e.g.
a triple prefix like i686-w64-mingw32-clang.
However, if the unprefixed toolchain targets x86_64, but the user
tries to switch it to target 32 bit by adding the -m32 option, the
computeTargetTriple function in Clang, together with
Triple::get32BitArchVariant, sets the arch to i386. This causes
the right sysroot to not be found.
When targeting an arch where there are potential spelling ambiguities
with respect to the sysroots (i386 and arm), check if the driver can
find a sysroot with the arch name - if not, try a couple other
candidates.
Differential Revision: https://reviews.llvm.org/D111952
Adapt the rewriteAsPaddedOp method to use the OpBuilder instead of the PatterRewriter.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D112003
It seems that llvm-objcopy stores data temporarily misaligned with the
requirements of the underlaying struct from libBinaryFormat, and UBSan
generates a runtime error.
Instead of trying to reinterpret the memory as the struct itself, simply
access the `char *` pointer that we are interested in, and that do not
have alignment restrictions.
This problem was pointed out in a comment of D111164.
Differential Revision: https://reviews.llvm.org/D112744
Shift node is still needed to check if the shift is shr or shl to increment/decrement offset. Do not override the node.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D112733
- [[format_arg(N)]] tells Clang that a method returns a format string with
specifiers equivalent to those passed in the string at argument #N. It
obviously requires the argument and the return type to be strings both.
- `instancetype` is a special return type available in Objective-C class
definitions that Clang expands to the most-derived statically known type on
use.
- In Objective-C mode, NSString is allowed in lieu of a C string, both as input
and output. However, _in the definition of NSString_, Clang rejects format_arg
on methods that return NSString. This PR addresses this issue by substituting
`instancetype` with the enclosing definition's type during the validation of
`format_arg`.
Reviewed By: ahatanak
Differential Revision: https://reviews.llvm.org/D112670
Radar-Id: rdar://84729746
I'm not sure if there's a way to make this a bit more general - the
property that matters is that there's /some/ itanium ABI target the
tests can use to compile - not link or run in this case. But this seems
sufficient for the llgdb tests, so it should be sufficient (though
perhaps not necessary) for this roundtrip test.
Compilation is all that's needed here - linking helped avoid certain
false positives in llvm-dwarfdump --verify related to overlapping
functions when those functions were actually in distinct sections.
That's since been fixed, so we can adjust the test to only compile, and
not link.
The new name better suits the type.
This patch also changes the signature of the run method (it now returns a
WrapperFunctionResult), and adds runWithSPSRet methods that deserialize the
function result using SPS.
Together these chages bring this type into close alignment with its ORC runtime
counterpart.
There's another test that opens an hard-coded port to talk to debugserver
(TestPlatformSDK.py). Make sure this port and the one in that other
test are different to avoid that potential conflict.
Previously we were relying on the dynamic loader to take care of this
but it simple and correct for us to do it here instead.
Now we initialize bss segments as part of `__wasm_init_memory` at the
same time we initialize passive segments.
In addition we extent the us of `__wasm_init_memory` outside of shared
memory situations. Specifically it is now used to initialize bss
segments when the memory is imported.
Differential Revision: https://reviews.llvm.org/D112667
Functions in different sections (common in object files - inline
functions, -ffunction-sections, etc) can't overlap, so factor in the
section when diagnosing overlapping address ranges.
This removes a major false-positive when running llvm-dwarfdump on
unlinked code.
WrapperFunctionCall represents a call to a wrapper function as a pair of a
target function (as an ExecutorAddr), and an argument buffer range (as an
ExecutorAddrRange). WrapperFunctionCall instances can be serialized via
SPS to send to remote machines (only the argument buffer address range is
copied, not any buffer content).
This utility will simplify the implementation of JITLinkMemoryManager
allocation actions in the ORC runtime.
We weren't setting the listener back to the unhijacked one in this
case, so that a continue after the stop fails. It thinks the process
is still running. Also add tests for this behavior.
Differential Revision: https://reviews.llvm.org/D112747
This has no uses and the ValueObjectDynamicValue already tracks
its ownership through the parent it is passed when made. I can't
find any vestiges of the use of this API, maybe it was from some
earlier design?
Resetting the backing ivar was the only job the destructor did, so I
set that to default as well.
Differential Revision: https://reviews.llvm.org/D112677
While "null()" is accepted as a data statement constant when it
corresponds to a pointer object, "null(mold=p)" and "null(p)"
are not allowed. The current error messages simply complain
that null is not an array. This patch adds a context-sensitive
message to the effect that a data statement constant followed
by non-empty parentheses must be an array or structure constructor.
(Note that f18 can't simply special-case the name "null" when parsing
data statement constants, since programs are free to repurpose that
name as an array or derived type.)
Differential Revision: https://reviews.llvm.org/D112740
Pavel Labath