| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
FastDemangle gives us a C-string that we own (which is allocated in SymbolDemangler::GetDemangledCopy).
As we are not deleting the string, we leak memory whenever we call SubsPrimitiveParmItanium.
Reviewers: javed.absar
Subscribers: kristof.beyls, chrib, lldb-commits
Differential Revision: https://reviews.llvm.org/D47418
llvm-svn: 333353
|
| |
|
|
| |
llvm-svn: 333352
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
That's r333325, as well as follow-up "Fix GCC handling of ATOMIC_VAR_INIT"
r333327.
Marshall asked to revert:
Let's have a discussion about how to implement this so that it is more friendly
to people with installed code bases. We've had *extremely* loud responses to
unilaterally adding warnings - especially ones that can't be easily disabled -
to the libc++ code base in the past.
llvm-svn: 333351
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When requesting to dump both the parent chain and children, we used to
print the DIE more than once because we propagated the dump options to
the parent without clearing the respective flags. This commit fixes this
oversight and adds a test.
rdar://39415292
Differential revision: https://reviews.llvm.org/D47263
llvm-svn: 333350
|
| |
|
|
|
|
|
|
| |
better use of other functions and to reduce width to 256 and 128 bits were possible."
This wasn't supposed to be commited yet.
llvm-svn: 333349
|
| |
|
|
|
|
| |
This reduces from 12 builtins to 6 since we no longer need a mask and maskz version.
llvm-svn: 333348
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
other functions and to reduce width to 256 and 128 bits were possible.
Summary:
We only need to use 512 bit vectors all the way through v8i64 reductions since those max instructions are new to avx512f and only available in 512 bits until SKX.
For v16i32 and floating point we have legacy 128/256 bit instructions we can use.
I've tried to use other intrinsics to reduce the verbosity of the code and avoid having to mention all the shuffles. I've also removed all the -1 shuffle indices so the output sequence is fully specified and not left to backend optimization.
Reviewers: RKSimon, spatel, GBuella
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D47401
llvm-svn: 333347
|
| |
|
|
|
|
| |
This allows us to avoid having mask and maskz variant. Reducing from 12 intrinsics to 6.
llvm-svn: 333346
|
| |
|
|
|
|
|
|
|
|
| |
Summary: When compiling with modules, these missing includes cause the build to fail (as the header can't be compiled into a module).
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D47412
llvm-svn: 333345
|
| |
|
|
| |
llvm-svn: 333344
|
| |
|
|
|
|
|
|
| |
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D47410
llvm-svn: 333343
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This resolves unnecessary the header dependency from
Core to DataFormatters. Patch is necessary for the introduction of
C++ modules to the LLDB build system.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47409
llvm-svn: 333342
|
| |
|
|
| |
llvm-svn: 333341
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
ClangDiagnosticsEmitter.cpp:1047:57: warning: this statement may fall through [-Wimplicit-fallthrough=]
Builder.PrintFatalError("Unknown modifier type: " + Modifier);
~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
ClangDiagnosticsEmitter.cpp:1048:5: note: here
case MT_Select: {
^
Reviewers: rsmith, rtrieu
Reviewed By: rtrieu
Subscribers: rtrieu, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47340
llvm-svn: 333340
|
| |
|
|
|
|
|
|
| |
This option prevent from removing file symbols while removing symbols.
Differential Revision: https://reviews.llvm.org/D46830
llvm-svn: 333339
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fix a few more bot failures due to r333335:
- don't match path other than file name, since the delimiter is
different for Windows
- The summary IDs in thinlto-function-summary-refgraph.ll may vary
and therefore can't be matched exactly, because the ordering depends
on the iteration order of the index map which is keyed by GUID. The GUID
for private values will depend on the path.
llvm-svn: 333338
|
| |
|
|
|
|
|
| |
Don't try to match the exact GUID for private symbols, as the
hashed name includes the file path.
llvm-svn: 333337
|
| |
|
|
|
|
|
| |
Change value in vector from StringRef to std::string to avoid errors
when trying to initialize from a std::string.
llvm-svn: 333336
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Implements AsmWriter support for printing the module summary index to
assembly with the format discussed in the RFC "LLVM Assembly format for
ThinLTO Summary".
Implements just enough of the parsing support to recognize and ignore
the summary entries. As agreed in the RFC thread, this will be the
behavior when assembling the IR. A follow on change will implement
parsing/assembling of the summary entries for use by tools that
currently build the summary index from bitcode.
Reviewers: dexonsmith, pcc
Subscribers: inglorion, eraman, steven_wu, dblaikie, llvm-commits
Differential Revision: https://reviews.llvm.org/D46699
llvm-svn: 333335
|
| |
|
|
| |
llvm-svn: 333334
|
| |
|
|
| |
llvm-svn: 333333
|
| |
|
|
|
|
|
| |
Style guide says `else`s after returns are iffy, and I agree. I also
don't know what broke the comments here and in CFLAA, but *shrug*.
llvm-svn: 333332
|
| |
|
|
| |
llvm-svn: 333331
|
| |
|
|
| |
llvm-svn: 333330
|
| |
|
|
|
|
|
|
|
| |
Interceptors initialization may try to allocate memory and to call not
initialized allocator.
It's similar to r326025 for CFI.
llvm-svn: 333329
|
| |
|
|
|
|
|
|
|
| |
Fuchsia's _zx_port_wait no longer takes the count argument. This
change also updates all symbol uses to use the underscored versions.
Differential Revision: https://reviews.llvm.org/D47403
llvm-svn: 333328
|
| |
|
|
|
|
| |
r333325 from D47225 added warning checks, and the test was written to be C++11 correct by using ATOMIC_VAR_INIT (note that the committee fixed that recently...). It seems like GCC can't handle ATOMIC_VAR_INIT well because it generates 'type 'std::atomic<int>' cannot be initialized with an initializer list' on bot libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03. Drop the ATOMIC_VAR_INITs since they weren't required to test the diagnostics.
llvm-svn: 333327
|
| |
|
|
|
|
|
|
|
|
|
| |
These functions are obsolete. The analyzer would advice to replace them with
memcmp(), memcpy() or memmove(), or memset().
Patch by Tom Rix!
Differential Revision: https://reviews.llvm.org/D41881
llvm-svn: 333326
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The atomic non-member functions accept pointers to std::atomic / std::atomic_flag as well as to the non-atomic value. These are all dereferenced unconditionally when lowered, and therefore will fault if null. It's a tiny gotcha for new users, especially when they pass in NULL as expected value (instead of passing a pointer to a NULL value). We can therefore use the nonnull attribute to denote that:
- A warning should be generated if the argument is null
- It is undefined behavior if the argument is null (because a dereference will segfault)
This patch adds support for this attribute for clang and GCC, and sticks to the subset of the syntax both supports. In particular, work around this GCC oddity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60625
The attributes are documented:
- https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html
- https://clang.llvm.org/docs/AttributeReference.html#nullability-attributes
I'm authoring a companion clang patch for the __c11_* and __atomic_* builtins, which currently only warn on a subset of the pointer parameters.
In all cases the check needs to be explicit and not use the empty nonnull list, because some of the overloads are for atomic<T*> and the values themselves are allowed to be null.
<rdar://problem/18473124>
Reviewers: arphaman, EricWF
Subscribers: aheejin, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47225
llvm-svn: 333325
|
| |
|
|
|
|
| |
Reflow brings said comment below 80 cols
llvm-svn: 333324
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reverting this to see if this is causing the failures of the
clang-with-thin-lto-ubuntu bot.
[IPSCCP] Use PredicateInfo to propagate facts from cmp instructions.
This patch updates IPSCCP to use PredicateInfo to propagate
facts to true branches predicated by EQ and to false branches
predicated by NE.
As a follow up, we should be able to extend it to also propagate additional
facts about nonnull.
Reviewers: davide, mssimpso, dberlin, efriedma
Reviewed By: davide, dberlin
Differential Revision: https://reviews.llvm.org/D45330
llvm-svn: 333323
|
| |
|
|
| |
llvm-svn: 333322
|
| |
|
|
| |
llvm-svn: 333321
|
| |
|
|
|
|
| |
incorrectly labeled as avx512f.
llvm-svn: 333320
|
| |
|
|
|
|
|
| |
This reverts commit d734f2aa3f76fbf355ecd2bbe081d0c1f49867ab.
Also known as r333311. A very small but nonzero number of bots fail.
llvm-svn: 333319
|
| |
|
|
| |
llvm-svn: 333318
|
| |
|
|
|
|
| |
It seems GCC and clang disagree. Talked to mclow on IRC, disabling for now.
llvm-svn: 333317
|
| |
|
|
|
|
|
| |
This adds basic support for the Swift calling convention with PPC64 targets.
Patch provided by Atul Sowani in bug report #37223
llvm-svn: 333316
|
| |
|
|
|
|
| |
No matching constructor
llvm-svn: 333315
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The uint64_ts that we pass around AA to represent MemoryLocation sizes
are logically an Optional<uint64_t>. In D44748, we want to add an extra
'imprecise' bit to this Optional<uint64_t> to represent whether a given
MemoryLocation size is an upper-bound or an exact size. For more context
on why, please see D44748.
That patch is quite large, but reviewers seem to be OK with the
approach. In D45581 (my first attempt to split 'noise' out of D44748),
reames asked that I land a precursor that is solely replacing uint64_t
with LocationSize, which starts out as `using LocationSize = uint64_t;`.
He also gave me the OK to submit this rename without further review.
llvm-svn: 333314
|
| |
|
|
|
|
| |
Previously, we wrote only the least significant 32 bits.
llvm-svn: 333313
|
| |
|
|
| |
llvm-svn: 333312
|
| |
|
|
|
|
|
|
|
|
| |
The checksum will not reflect the real source, so there's no clear
reason to include them in the debug info. Also this was causing a
crash on the DWARF side.
Differential Revision: https://reviews.llvm.org/D47260
llvm-svn: 333311
|
| |
|
|
| |
llvm-svn: 333310
|
| |
|
|
| |
llvm-svn: 333309
|
| |
|
|
| |
llvm-svn: 333308
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The return value of sys::getDefaultTargetTriple, which is derived from
-DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target,
and in the future also to control the search path directly; as such it
should be used textually, without interpretation by LLVM.
Normalization of this value may lead to unexpected results, for example
if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu,
normalization will transform that value to x86_64--linux-gnu. Driver will
use that value to search for tools prefixed with x86_64--linux-gnu- which
may be confusing. This is also inconsistent with the behavior of the
--target flag which is taken as-is without any normalization and overrides
the value of LLVM_DEFAULT_TARGET_TRIPLE.
Users of sys::getDefaultTargetTriple already perform their own
normalization as needed, so this change shouldn't impact existing logic.
Differential Revision: https://reviews.llvm.org/D47153
llvm-svn: 333307
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: krytarowski, eugenis
Reviewed By: eugenis
Differential Revision: https://review.llvm.org/D47146
llvm-svn: 333306
|
| |
|
|
|
|
| |
The patch r331783 caused regression in one of our internal application. So revert it now, will investigate it further.
llvm-svn: 333305
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It seems to me that files in include/lldb/API/ are headers that should
be exposed to liblldb users. Because SystemInitializerFull.h exposes details of
lldb_private, I think having it there is not the right thing to do. Since it's
only included from files in source/API, we should move it there and treat it as
private.
Reviewers: labath, clayborg
Reviewed By: labath, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47342
llvm-svn: 333304
|