| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because path can be constructed from a ton of different types, including string
and wide strings, this caused it's streaming operators to suck up all sorts
of silly types via silly conversions. For example:
using namespace std::experimental::filesystem::v1;
std::wstring w(L"wide");
std::cout << w; // converts to path.
This patch tentatively adopts the resolution to LWG2989 and fixes the issue
by making the streaming operators friends of path.
llvm-svn: 324189
|
|
|
|
| |
llvm-svn: 324188
|
|
|
|
|
|
|
| |
Previously copy_file didn't handle the case where the input and
output were the same file.
llvm-svn: 324187
|
|
|
|
| |
llvm-svn: 324186
|
|
|
|
|
|
|
|
|
|
|
|
| |
The standard isn't exactly clear how std::array should handle zero-sized arrays
with const element types. In particular W.R.T. copy assignment, swap, and fill.
This patch takes the position that those operations should be ill-formed,
and makes changes to libc++ to make it so.
This follows up on commit r324182.
llvm-svn: 324185
|
|
|
|
|
|
|
|
|
|
| |
(and/or/xor X, (bitcast Y)) when casting between GPRs and mask operations.
This reduces the number of transitions between k-registers and GPRs, reducing the number of instructions.
There's still some room for improvement to remove more transitions, but this is a good start.
llvm-svn: 324184
|
|
|
|
| |
llvm-svn: 324183
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructible types.
Summary:
This patch fixes llvm.org/PR35491 and LWG2157 (https://cplusplus.github.io/LWG/issue2157)
The fix attempts to maintain ABI compatibility by replacing the array with a instance of `aligned_storage`.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: lichray, cfe-commits
Differential Revision: https://reviews.llvm.org/D41223
llvm-svn: 324182
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
x), cst)) -> (and/or/xor (sextload/zextload x), (sext/zext cst)) make sure we check the legality of the full extended load.
Summary:
If the load is already an extended load we should be using the memory VT for the legality check, not just the VT of the current extension.
I don't have a test case, just noticed it while investigating some load extension improvements.
Reviewers: RKSimon, spatel, niravd
Reviewed By: niravd
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42783
llvm-svn: 324181
|
|
|
|
|
|
| |
Hopefully help make this a lot more maintainable
llvm-svn: 324180
|
|
|
|
|
|
|
|
| |
Better to assume that any value type may be commuted, not just MVTs.
No test case right now, but discovered while investigating possible shuffle combines.
llvm-svn: 324179
|
|
|
|
|
|
| |
This is necessary to prevent the shuffles from being combined/simplified in an upcoming patch.
llvm-svn: 324178
|
|
|
|
|
|
|
|
| |
Clang already stopped using these a couple months ago.
The test cases aren't great as there is nothing forcing the operations to stay in k-registers so some of them moved back to scalar ops due to the bitcasts being moved around.
llvm-svn: 324177
|
|
|
|
| |
llvm-svn: 324176
|
|
|
|
|
|
|
|
|
| |
This resolver conforms to the LegacyJITSymbolResolver interface, and will be
replaced with a null-returning resolver conforming to the newer
orc::SymbolResolver interface in the near future. This patch renames the class
to avoid a clash.
llvm-svn: 324175
|
|
|
|
|
|
|
|
|
|
|
| |
This, in instcombine, allows conversions to i8/i16/i32 (very
common cases) even if the resulting type is not legal according
to the data layout. This can often open up extra combine
opportunities.
Differential Revision: https://reviews.llvm.org/D42424
llvm-svn: 324174
|
|
|
|
|
|
| |
Fixed build issue when building with g++-4.8 (specialization after instantiation).
llvm-svn: 324173
|
|
|
|
|
|
|
| |
From the discussion in D41835 it looks possible the change will be backed out,
but for now let's fix the RISCV tests.
llvm-svn: 324172
|
|
|
|
| |
llvm-svn: 324171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, RISCV32TargetInfo or RISCV64TargetInfo were created
unconditionally. Use LinuxTargetInfo<RISCV??TargetInfo> to ensure that the
proper OS-specific defines are present.
This patch only adds logic to instantiate LinuxTargetInfo and leaves a TODO,
as I'm reluctant to add logic for other targets (e.g. FreeBSD, RTEMS) until
I've produced and tested at least one binary for that OS+target combo.
Thanks to @mgrang to reporting the issue.
llvm-svn: 324170
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Splitting basic blocks into multiple statements if there are now
additional scalar dependencies gives more freedom to the scheduler, but
more statements also means higher compile-time complexity. Switch to
finer statement granularity, the additional compile time should be
limited by the number of operations quota.
The regression tests are written for the -polly-stmt-granularity=bb
setting, therefore we add that flag to those tests that break with the
new default. Some of the tests only fail because the statements are
named differently due to a basic block resulting in multiple statements,
but which are removed during simplification of statements without
side-effects. Previous commits tried to reduce this effect, but it is
not completely avoidable.
Differential Revision: https://reviews.llvm.org/D42151
llvm-svn: 324169
|
|
|
|
|
|
|
|
|
|
| |
Do not add a "_last" suffix to the statement name if there is no (other)
main statement for a basic block. In other words, it becomes the main
statement itself. This further reduces the statement naming difference
between -polly-stmt-granularity=bb and
-polly-stmt-granularity=scalar-indep.
llvm-svn: 324168
|
|
|
|
|
|
|
|
| |
Due to Buildbot failures - most likely that's because target triples were not
specified in the tests, even though the checker behaves differently with
different target triples.
llvm-svn: 324167
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a security check which is disabled by default but will be enabled
whenever the user consciously enables the security package. If mmap()ed memory
is both writable and executable, it makes it easier for the attacker to execute
arbitrary code when contents of this memory are compromised. Some applications
require such mmap()s though, such as different sorts of JIT.
Patch by David Carlier!
Differential Revision: https://reviews.llvm.org/D42645
llvm-svn: 324166
|
|
|
|
| |
llvm-svn: 324165
|
|
|
|
|
|
|
|
|
|
|
| |
When Clang encounters an already invalid class declaration, it can
emit incorrect diagnostics about the exception specification on
some of its members. This patch temporarily works around that
incorrect diagnostic.
The clang bug was introduced in r324062.
llvm-svn: 324164
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: kcc
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42874
llvm-svn: 324163
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
macro is explicitly returning NULL
We already suppress such reports for inlined functions, we should then
get the same behavior for macros.
The underlying reason is that the same macro, can be called from many
different contexts, and nullability can only be expected in _some_ of
them.
Assuming that the macro can return null in _all_ of them sometimes leads
to a large number of false positives.
E.g. consider the test case for the dynamic cast implementation in
macro: in such cases, the bug report is unwanted.
Tracked in rdar://36304776
Differential Revision: https://reviews.llvm.org/D42404
llvm-svn: 324161
|
|
|
|
|
|
|
|
| |
We could in principle support such pack expansion, using techniques similar to
what we do for pack expansion of lambdas, but it's not clear it's worthwhile.
For now at least, cleanly reject these cases rather than crashing.
llvm-svn: 324160
|
|
|
|
|
|
|
|
| |
in debugserver. This is already set this way in the lldb
project files but not in debugserver. Updating for
consistency.
llvm-svn: 324158
|
|
|
|
|
|
|
|
|
|
|
|
| |
Group all synthetic symbols in the in single struct to match
the ELF linker.
This change is part of a larger change to add more linker
symbols such as `_end` and `_edata`.
Differential Revision: https://reviews.llvm.org/D42866
llvm-svn: 324157
|
|
|
|
|
|
|
|
|
|
|
|
| |
into a std::string so we don't run off the end of the array when
there is no nul byte in ProcessElfCore::parseLinuxNotes.
Found with ASAN testing.
<rdar://problem/37134319>
Differential revision: https://reviews.llvm.org/D42828
llvm-svn: 324156
|
|
|
|
| |
llvm-svn: 324155
|
|
|
|
| |
llvm-svn: 324154
|
|
|
|
|
|
|
|
|
| |
Clang previously reported an empty union as having a unique object
representation. This was incorrect and was fixed in a recent Clang commit.
This patch fixes the libc++ tests.
llvm-svn: 324153
|
|
|
|
|
|
| |
We want to check that we can assign to an lvalue here, not a prvalue.
llvm-svn: 324152
|
|
|
|
|
|
| |
parsing a trailing-return-type of a (function pointer) variable declaration.
llvm-svn: 324151
|
|
|
|
|
|
|
|
| |
GNU linkers have this option.
Differential Revision: https://reviews.llvm.org/D42858
llvm-svn: 324150
|
|
|
|
|
|
|
|
| |
Summary:
Small NFC change to change the name of the function used getting and setting
the alignment of a memset.
llvm-svn: 324148
|
|
|
|
|
|
|
|
| |
combineVectorSizedSetCCEquality.
This is running pre-legalize, we should try to use target independent nodes. This will give the best opportunity for target independent optimizations.
llvm-svn: 324147
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D42823
llvm-svn: 324146
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D42865
llvm-svn: 324145
|
|
|
|
|
|
|
|
| |
Without extra instructions and uses, swapMayExposeCSEOpportunities() would change
the icmp (as seen in the check lines), so we were not actually testing patterns
that should be handled by D41480.
llvm-svn: 324143
|
|
|
|
| |
llvm-svn: 324142
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D42859
llvm-svn: 324141
|
|
|
|
|
|
| |
nullptr is not available on older Darwin systems.
llvm-svn: 324136
|
|
|
|
|
|
| |
X86ISelLowering.cpp. NFC
llvm-svn: 324135
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Clang incorrectly reports empty unions as having a unique object representation. However, this is not correct since `sizeof(EmptyUnion) == 1` AKA it has 8 bits of padding. Therefore it should be treated the same as an empty struct and report `false`.
@erichkeane also suggested this fix should be merged into the 6.0 release branch, so the initial release of `__has_unique_object_representations` is as bug-free as possible.
Reviewers: erichkeane, rsmith, aaron.ballman, majnemer
Reviewed By: erichkeane
Subscribers: cfe-commits, erichkeane
Differential Revision: https://reviews.llvm.org/D42863
llvm-svn: 324134
|
|
|
|
| |
llvm-svn: 324133
|
|
|
|
|
|
|
|
| |
libprotobuf-mutator accepts protobufs with missing fields, which means
clang-proto-fuzzer does as well. clang-proto-to-cxx should match this
behavior.
llvm-svn: 324132
|