These were uncovered when porting the mangling tests in
ms-templates.cpp from clang/CodeGenCXX over to demangling
tests. The main issues fixed here are surrounding integer
literal signed and unsignedness, empty array dimensions,
and pointer and reference non-type template parameters.
Differential Revision: https://reviews.llvm.org/D50512
llvm-svn: 339434
Enabling ARMCodeGenPrepare by default caused a whole load of
failures. This is due to zexts and truncs not being handled properly.
ZExts are messy so it's just easier to disable for now and truncs
are allowed only as 'sinks'. I still need to figure out why allowing
them as 'sources' causes so many failures. The other main changes are
that we are explicit in the types that we converting to, it's now
always 'TypeSize'. Type support is also now performed while checking
for valid opcodes as it unnecessarily complicated having the checks
are different stages.
I've moved the tests around too, so we have the zext and truncs in
their own file as well as the overflowing opcode tests.
Differential Revision: https://reviews.llvm.org/D50518
llvm-svn: 339432
Summary:
The current code enables aligned allocation functions when compiling in C++17
and later. This is a problem because aligned allocation functions might not
be supported on the target platform, which leads to an error at link time.
Since r338934, Clang knows not to define __cpp_aligned_new when it's not
available on the target platform -- this commit takes advantage of that to
only use aligned allocation functions when they are available.
Reviewers: vsapsai, EricWF
Subscribers: christof, dexonsmith, cfe-commits, EricWF, mclow.lists
Differential Revision: https://reviews.llvm.org/D50344
llvm-svn: 339431
Summary:
Introduces funclet-based unwinding for Objective-C and fixes an issue
where global blocks can't have their isa pointers initialised on
Windows.
After discussion with Dustin, this changes the name mangling of
Objective-C types to prevent a C++ catch statement of type struct X*
from catching an Objective-C object of type X*.
Reviewers: rjmccall, DHowett-MSFT
Reviewed By: rjmccall, DHowett-MSFT
Subscribers: mgrang, mstorsjo, smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D50144
llvm-svn: 339428
This patch modifies `consume` function to allow retrieval of limited
number of symbols. This is the "cheap" implementation of top-level
limiting iterator. In the future we would like to have a complete limit
iterator implementation to insert it into the query subtrees, but in the
meantime this version would be enough for a fully-functional
proof-of-concept Dex implementation.
Reviewers: ioeric, ilya-biryukov
Reviewed by: ioeric
Differential Revision: https://reviews.llvm.org/D50500
llvm-svn: 339426
This patch fixes a wrong type bug inside ParsedAttr::TypeTagForDatatypeData.
The details to the best of my knowledge are as follow. The incredible thing
is that everything works out just fine by chance due to a sequence of lucky
coincidences in the layout of various types.
The struct ParsedAttr::TypeTagForDatatypeData contains among other things
a ParsedType *MatchingCType, where ParsedType is just OpaquePtr<QualType>.
However the member MatchingCType is initialized in the constructor for
type_tag_for_datatype attribute as follows:
new (&ExtraData.MatchingCType) ParsedType(matchingCType);
This results in the ParsedType being constructed in the location of the
ParsedType * Later ParsedAttr::getMatchingCType do return
*getTypeTagForDatatypeDataSlot().MatchingCType; which instead of
dereferencing the ParsedType * will dereference the QualType inside
the ParsedType. Now this QualType in this case contains no qualifiers
and therefore is a valid Type *. Therefore getMatchingCType returns a
Type or at least the stuff that is in the first sizeof(void*) bytes of it,
But it turns out that Type inherits from ExtQualsCommonBase and that the
first member of ExtQualsCommonBase is a const Type *const BaseType. This
Type * in this case points to the original Type pointed to by the
QualType and so everything works fine even though all the types were wrong.
This bug was only found because I changed the layout of Type,
which obviously broke all of this long chain of improbable events.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D50532
llvm-svn: 339423
Part of the logic has been moved to helper functions to (hopefully) improve
readability.
Added a few code comments to better describe how the algorithm works.
No functional change intended.
llvm-svn: 339421
This extension emits the guard cf table without inserting the
instrumentation. Currently that's what clang-cl does with /guard:cf
anyway, but this allows a user to request that explicitly.
Differential Revision: https://reviews.llvm.org/D50513
llvm-svn: 339420
The previous name sounds like it inserts cfguard implementation, but it
really just emits the table of address-taken functions. Change the name
to better reflect that.
Clang will be updated in the next commit.
llvm-svn: 339419
performance-for-range-copy check.
Summary:
The upstream change r336737 make the check too smart to fix the case
where loop variable could be used as `const auto&`.
But for the case below, changing to `const auto _` will introduce
an unused complier warning.
```
for (auto _ : state) {
// no references for _.
}
```
This patch omit this case, and it is safe to do it as the case is very rare.
Reviewers: ilya-biryukov, alexfh
Subscribers: xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D50447
llvm-svn: 339415
If code is compiled for X86 without SSE support, the register save area
doesn't contain FPU registers, so `AMD64FpEndOffset` should be equal to
`AMD64GpEndOffset`.
llvm-svn: 339414
It turns out that postThunkContents() is only used for
sorting symbols in .symtab.
Though we can instead move the logic to SymbolTableBaseSection::finalizeContents(),
postpone calling it and then get rid of postThunkContents completely.
Differential revision: https://reviews.llvm.org/D49547
llvm-svn: 339413
We have a crash issue when handling the empty -defsym.
For parsing this option we are using ScriptParser class which is used
generally for reading the linker script. For empty defsym case, we
pass the empty memory buffer and crash in the place removed in https://reviews.llvm.org/rL336436.
But reverting of the above patch would not help here (we would still crash but a bit later). And
even after fixing the crash we would report something like
"lld.exe: error: -defsym:1: unexpected EOF"
It is probably not the appropriate message because mentions EOF.
I think the issue should be handled on a higher level like this patch does.
So we do not want to pass the empty memory buffer first of all I believe.
Differential revision: https://reviews.llvm.org/D50498
llvm-svn: 339412
MemorySSA currently creates MemoryAccesses for lifetime intrinsics, and
sometimes treats them as clobbers. This may/may not be the best way
forward, but while we're doing it, we should consider
MayAlias/PartialAlias to be clobbers.
The ideal fix here is probably to remove all of this reasoning about
lifetimes from MemorySSA + put it into the passes that need to care. But
that's a wayyy broader fix that needs some consensus, and we have
miscompiles + a release branch today, and this should solve the
miscompiles just as well.
differential revision is D43269. Landing without an explicit LGTM (and
without using the special please-autoclose-this syntax) so we can still
use that revision as a place to decide what the right fix here is.
llvm-svn: 339411
r339380 changed the trailing types of ParsedAttr to use llvm::TrailingObjects.
However, it did not copy over one of the size attributes, causing a too
small allocation for this object. The error was detected with
AddressSanitizer use-after-poison
llvm-svn: 339409
This reverts commit r339405, it's failing on Darwin buildbots because
it doesn't seem to have a tgkill/thr_kill2 interface. It has a
__pthread_kill() syscall, but that relies on having a handle to the
thread's port which is not equivalent to it's tid.
llvm-svn: 339408
Summary:
i64x2 and f64x2 operations are not implemented in V8, so we normally
do not want to emit them. However, they are in the SIMD spec proposal,
so we still want to be able to test them in the toolchain. This patch
adds a flag to enable their emission.
Reviewers: aheejin, dschuff
Subscribers: sunfish, jgravelle-google, sbc100, llvm-commits
Differential Revision: https://reviews.llvm.org/D50423
Patch by Thomas Lively (tlively)
llvm-svn: 339407
Summary:
glibc can call SafeStack instrumented code even after the last pthread
data destructor has run. Delay cleaning-up unsafe stacks for threads
until the thread is dead by having future threads clean-up prior threads
stacks.
Reviewers: pcc, eugenis
Reviewed By: eugenis
Subscribers: cryptoad, eugenis, kubamracek, delcypher, llvm-commits, #sanitizers, kcc
Differential Revision: https://reviews.llvm.org/D50406
llvm-svn: 339405
Summary:
Case case of the switch statement here makes the same call, but it is
already done at the start of the function.
Reviewers: rsmith, dblaikie
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50409
llvm-svn: 339402
Summary:
gcc does not like
const Region *Region;
It wants a different name for the variable.
Is there a better convention for what name to use in such a case?
Reviewers: sbc100, aheejin
Subscribers: aheejin, jgravelle-google, dschuff, llvm-commits
Differential Revision: https://reviews.llvm.org/D50472
Patch by Alon Zakai (kripken)
llvm-svn: 339398
Summary:
The TType encoding, LSDA encoding, and personality encoding are all
passed explicitly by CodeGen to the assembler through .cfi_* directives,
so only the AsmPrinter needs to know about them.
The FDE CFI encoding however, controls the encoding of the label
implicitly created by the .cfi_startproc directive. That directive seems
to be special in that it doesn't take an encoding, so the assembler just
has to know how to encode one DSO-local label reference from .eh_frame
to .text.
As a result, it looks like MC will continue to have to know when the
large code model is in use. Perhaps we could invent a '.cfi_startproc
[large]' flag so that this knowledge doesn't need to pollute the
assembler.
Reviewers: davide, lliu0, JDevlieghere
Subscribers: hiraditya, fedor.sergeev, llvm-commits
Differential Revision: https://reviews.llvm.org/D50533
llvm-svn: 339397
This patch cleans up unused functions, variables, sign compare issues, and
addresses some -Warning flags which are now enabled including -Wcast-qual.
Not all the warning flags in LibompHandleFlags.cmake are enabled, but some
are with this patch.
Some __kmp_gtid_from_* macros in kmp.h are switched to static inline functions
which allows us to remove the awkward definition of KMP_DEBUG_ASSERT() and
KMP_ASSERT() macros which used the comma operator. This had to be done for the
innumerable -Wunused-value warnings related to KMP_DEBUG_ASSERT()
Differential Revision: https://reviews.llvm.org/D49105
llvm-svn: 339393
Summary: Edited `loop_proto_to_llvm` to emit metadata at the end of the generated IR. This metadata will increase the vector width when the IR is optimized.
Reviewers: morehouse, kcc
Reviewed By: morehouse
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D50530
llvm-svn: 339392
This makes the code easier to read and will make an upcoming patch I have easier to review because that patch needed this refactoring to reuse some of the functions.
llvm-svn: 339391
As sent on cfe-commits:
"You need to use "friend TrailingObjects;" here, not
"friend class TrailingObjects;", to avoid breaking MSVC
(which doesn't implement injected-class-names quite according to spec)."
llvm-svn: 339389
Zachary Turner