We need to know whether the destructor is trivial in order to tell
whether other parts of the class are valid (in particular, this affects
whether the type is a literal type, which affects whether defaulted
special members can be declared constexpr or are implicitly constexpr).
llvm-svn: 362184
The magnitude range of normalized _Float16 is 2^-14 (~6e-5) to
(2-2^-10)*2^15 (65504). You might think, then, that the code is
correct to defne FLT16_MIN_EXP and FLT16_MAX_EXP to be -14 and 15
respectively. However, for some reason the C specification actually
specifies a bias for these macros:
C11 5.2.4.2.2:
- minimum negative integer such that FLT_RADIX raised to one less than
that power is a normalized floating-point number, e_min:
FLT_MIN_EXP
DBL_MIN_EXP
LDBL_MIN_EXP
- maximum integer such that FLT_RADIX raised to one less than that
power is a representable finite floating-point number, e_max:
FLT_MAX_EXP
DBL_MAX_EXP
LDBL_MAX_EXP
FLT16_MIN_EXP and FLT16_MAX_EXP should clearly be biased the same way,
and other compilers do in fact do so, as do our OpenCL headers for `half`.
Additionally, FLT16_MIN_10_EXP is just wrong.
llvm-svn: 362183
and returned to the context in which 'this' should be captured.
This means we now always mark 'this' referenced from the context in
which it's actually referenced, rather than potentially from some
context nested within that.
llvm-svn: 362182
Since we share headers between host and target builds, we need to use
the same version for both.
Differential Revision: https://reviews.llvm.org/D62712
llvm-svn: 362181
the captured region scope.
This removes a case where we would build expressions (and mark
declarations odr-used) in the wrong scope.
Remove the now-unused 'capture initializer' field on sema::Capture
(except for 'this' captures, which still need to be cleaned up).
No functionality change intended (except that we now very slightly more
precisely determine whether we need to use a capture or not when another
captured region encloses an OpenMP captured region).
llvm-svn: 362179
function scope.
This removes one of the last few cases where we build expressions in the
wrong function scope context. No functionality change intended.
llvm-svn: 362178
There is likely also an underlying bug in all code that calls
CPlusPlusNameParser with nullptrs, but this patch can also stand for
itself.
rdar://problem/49072829
llvm-svn: 362177
The result types aren't mentioned in the pattern name so really shouldn't be in the PatFrags.
The users of these either have their own type constraint or rely on the type constranit system to realize the only legal extend would be to f64.
llvm-svn: 362175
Summary:
My main goal here is to make lldb-server work with Android Studio.
This is currently not the case because lldb-server is started in platform mode listening on a domain socket. When Android Studio connects to it lldb-server crashes because even though it's listening on a domain socket as soon as it gets a connection it asserts that it's a TCP connection, which will obviously fails for any non-tcp connection.
To do this I came up with a new method called GetConnectURI() in Socket that returns the URI needed to connect to the connected portion of the socket.
Reviewers: labath, clayborg, xiaobai
Reviewed By: labath
Subscribers: mgorny, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62089
llvm-svn: 362173
Instead of duplicating access to the directive stack throughout
SemaOpenMP.cpp, consolidate it to a few methods and call those
everywhere else. In passing, simplify adjacent code where possible.
No functionality change intended.
llvm-svn: 362172
The LoadExt table defaults to all combinations being Legal. For
vector types, only src VTs with an i1 element type were ever changed.
So we don't need to mark them legal manually.
llvm-svn: 362170
Summary:
Clangd's framework is assembled by copying binaries from the lib and bin directories into a bundle shape. This results in an invalid bundle code signature because the signature only applies to the binaries not the resources.
This patch adds two new options to `llvm_codesign` to enable re-signing the library and XPC service as bundles.
The `BUNDLE_PATH` option allow specifying an explicit path to codesign, which enables signing bundles which aren't generated using CMake's `FRAMEWORK` or `BUNDLE` target properties.
The `FORCE` option allows re-signing binaries that have already been signed. This is required for how clangd exposes the clangd library and tools as both XPC and non-XPC services using the same binary.
Reviewers: jkorous, bogner
Reviewed By: bogner
Subscribers: mgorny, ilya-biryukov, dexonsmith, arphaman, kadircet, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62693
llvm-svn: 362169
Summary:
Keeps track of the enums that were used by saving them as DIGlobalVariables,
since CodeView emits debug info for global constants.
Reviewers: rnk
Subscribers: aprantl, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62635
llvm-svn: 362166
Summary:
When creating a ThreadPlan to step through a trampoline, we ask the
ObjC language runtime and the CPP language runtime to come up with such a thread
plan if the dynamic loader fails to give us one. I don't see why this behavior
can't be language agnostic.
Differential Revision: https://reviews.llvm.org/D61921
llvm-svn: 362164
Looks like armv8 can't handle a thousand threads, which GWP-ASan
requests when running a synchronised mutex test. Limiting this to 100 to
attempt to fix the build issue.
llvm-svn: 362163
Summary:
Add the names of the input files responsible for each error to the
messages.
Reviewers: sbc100, azakai
Subscribers: dschuff, jgravelle-google, aheejin, sunfish, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62704
llvm-svn: 362162
Separate the remark serialization to YAML from the LLVM Diagnostics.
This adds a new serialization abstraction: remarks::Serializer. It's
completely independent from lib/IR and it provides an easy way to
replace YAML by providing a new remarks::Serializer.
Differential Revision: https://reviews.llvm.org/D62632
llvm-svn: 362160
As reported here https://bugs.llvm.org/show_bug.cgi?id=42000, it was
possible to get the constexpr version of __builtin_*_overflow to give
the wrong answer.
This was because when extending the operands to fit the largest type (so
that the math could be done), the decision on whether to sign/zero
extend the operands was based on the result signedness, not on the
operands signedness.
In the reported case, (unsigned char)255 - (int)100 needed
to have each extended to the int in order to do the math. However, when
extending the first operand to 'int', we incorrectly sign extended it
instead of zero extending. Thus, the result didnt fit back into the
unsigned char.
The fix for this was simply to choose zero/sign extension based on the
sign of the operand itself.
Differential Revision: https://reviews.llvm.org/D62665
llvm-svn: 362157
I don't have a test case for these, but there is a test case for D62266
where, even after all the constant-folding patches, we still end up
with endless combine loop. Which makes sense, since we don't constant
fold for opaque constants.
llvm-svn: 362156
Previously, this used a statement like this:
Map[A] = Map[B];
This is equivalent to the following:
const auto &Src = Map[B];
auto &Dest = Map[A];
Dest = Src;
The second statement, "auto &Dest = Map[A];" can insert a new
element into the DenseMap, which can potentially grow and reallocate
the DenseMap's internal storage, which will invalidate the existing
reference to the source. When doing the actual assignment,
the Src reference is dereferenced, accessing memory that was
freed when the DenseMap grew.
This issue hasn't shown up when LLVM was built with Clang, because
the right hand side ended up dereferenced before evaulating the
left hand side. (If the value type is a larger data type, Clang doesn't
do this but behaves like GCC.)
With GCC, a cast to Value* isn't enough to make it dereference the
right hand side reference before invoking operator[] (while that is
enough to make Clang/LLVM do the right thing for larger types), but
storing it in an intermediate variable in a separate statement works.
This fixes PR42065.
Differential Revision: https://reviews.llvm.org/D62624
llvm-svn: 362150
- unused parameter warnings
- don't use single-letter template parameter names, like we do in libc++
- sign-comparison warnings
- unused variables in the tests
- unused local typedefs in the tests
- the use of #include_next
- field reordering in the tests
- unused lambda captures
Note that the rationale for why the static_casts to unsigned are OK is
that last - first must always be non-negative, since [first, last) is
a valid range.
llvm-svn: 362148
Summary:
Only vector tests are being affected here,
since subtraction by scalar constant is rewritten
as addition by negated constant.
No surprising test changes.
https://rise4fun.com/Alive/pbT
This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs.
Reviewers: RKSimon, craig.topper, spatel
Reviewed By: RKSimon
Subscribers: javed.absar, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62257
llvm-svn: 362146
Summary:
Again only vectors affected. Frustrating. Let me take a look into that..
https://rise4fun.com/Alive/AAq
This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.
Reviewers: RKSimon, craig.topper, spatel
Reviewed By: RKSimon
Subscribers: javed.absar, JDevlieghere, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62294
llvm-svn: 362145
Summary:
This prevents regressions in next patch,
and somewhat recovers from the regression to AMDGPU test in D62223.
It is indeed not great that we leave vector decrement,
don't transform it into vector add all-ones..
https://rise4fun.com/Alive/ZRl
This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.
Reviewers: RKSimon, craig.topper, spatel, arsenm
Reviewed By: RKSimon, arsenm
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62263
llvm-svn: 362144
Summary:
Direct sibling of D62223 patch.
While i don't have a direct motivational pattern for this,
it would seem to make sense to handle both patterns (or none),
for symmetry?
The aarch64 changes look neutral;
sparc and systemz look like improvement (one less instruction each);
x86 changes - 32bit case improves, 64bit case shows that LEA no longer
gets constructed, which may be because that whole test is `-mattr=+slow-lea,+slow-3ops-lea`
https://rise4fun.com/Alive/ffh
This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.
Reviewers: RKSimon, craig.topper, spatel, t.p.northover
Reviewed By: t.p.northover
Subscribers: t.p.northover, jyknight, javed.absar, kristof.beyls, fedor.sergeev, jrtc27, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62252
llvm-svn: 362143
Summary:
The main motivation is shown by all these `neg` instructions that are now created.
In particular, the `@reg32_lshr_by_negated_unfolded_sub_b` test.
AArch64 test changes all look good (`neg` created), or neutral.
X86 changes look neutral (vectors), or good (`neg` / `xor eax, eax` created).
I'm not sure about `X86/ragreedy-hoist-spill.ll`, it looks like the spill
is now hoisted into preheader (which should still be good?),
2 4-byte reloads become 1 8-byte reload, and are elsewhere,
but i'm not sure how that affects that loop.
I'm unable to interpret AMDGPU change, looks neutral-ish?
This is hopefully a step towards solving [[ https://bugs.llvm.org/show_bug.cgi?id=41952 | PR41952 ]].
https://rise4fun.com/Alive/pkdq (we are missing more patterns, i'll submit them later)
This is a recommit, originally committed in rL361852, but reverted
to investigate test-suite compile-time hangs, and then reverted in
rL362109 to fix missing constant folds that were causing
endless combine loops.
Reviewers: craig.topper, RKSimon, spatel, arsenm
Reviewed By: RKSimon
Subscribers: bjope, qcolombet, kzhuravl, jvesely, wdng, nhaehnle, yaxunl, javed.absar, dstuttard, tpr, t-tye, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62223
llvm-svn: 362142
Summary:
The tests for r362121 ran dsymutil against a test binary every time.
This caused problems on lld-x86_64-ubuntu-fast as dsymutil required
a lipo tool be available to process those binaries.
This change rewrites the new test cases in macho-disassemble-g-dsym
to use bespoke test binaries (exe and dwarf) simplifying the test's
runtime dependencies.
The changes to tools/llvm-objdump/MachODump.cpp are unchanged from
r362121
Reviewers: pete, lhames, JDevlieghere
Reviewed By: pete
Subscribers: smeenai, aprantl, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62694
llvm-svn: 362141
increase the MachO/x86-64 stub alignment to 8.
Stub alignment should be guaranteed for any section containing RuntimeDyld
stubs/GOT-entries. To do this we should pad and align all sections containing
stubs, not just code sections.
This commit also bumps the MachO/x86-64 stub alignment to 8, so that GOT entries
will be aligned.
llvm-svn: 362139
Summary:
See D60593 for further information.
This patch pulls out the mutex implementation and the required definitions file.
We implement our own mutex for GWP-ASan currently, because:
1. We must be compatible with the sum of the most restrictive elements of the supporting allocator's build system. Current targets for GWP-ASan include Scudo (on Linux and Fuchsia), and bionic (on Android).
2. Scudo specifies `-nostdlib++ -nonodefaultlibs`, meaning we can't use `std::mutex` or `mtx_t`.
3. We can't use `sanitizer_common`'s mutex, as the supporting allocators cannot afford the extra maintenance (Android, Fuchsia) and code size (Fuchsia) overheads that this would incur.
In future, we would like to implement a shared base mutex for GWP-ASan, Scudo and sanitizer_common. This will likely happen when both GWP-ASan and Scudo standalone are not in the development phase, at which point they will have stable requirements.
Reviewers: vlad.tsyrklevich, morehouse, jfb
Reviewed By: morehouse
Subscribers: dexonsmith, srhines, cfe-commits, kubamracek, mgorny, cryptoad, jfb, #sanitizers, llvm-commits, vitalybuka, eugenis
Tags: #sanitizers, #llvm, #clang
Differential Revision: https://reviews.llvm.org/D61923
llvm-svn: 362138
Richard Smith