This is the subject of an active NB comment. Regardless of what the Working
Paper currently says, asking this question is morally wrong, because the
answer can change when the type is completed. C1XX now detects such
precondition violations and complains about them; perhaps Clang should too.
Fixes D28591.
llvm-svn: 292281
Correctly populating Machine PHIs relies on knowing exactly how the IR level
CFG was lowered to MachineIR. This needs to be tracked by any translation
phases that meddle (currently only SwitchInst handling).
This reapplies r291973 which was reverted because of testing failures. Fixes:
+ Don't return an ArrayRef to a local temporary.
+ Incorporate Kristof's suggested comment improvements.
llvm-svn: 292278
When support for `basic_string_view` was added to string it also
added new assignment operators from `basic_string_view`. These caused
ambiguity when assigning from a braced initializer. This patch fixes
that regression by making the basic_string_view assignment operator
rank lower in overload resolution by making it a template.
llvm-svn: 292276
I hope that for any code, it is changed only with good reason and only
when the author knows what they are doing...
There is of course good reason to comment here about the subtlety of the
process, and I've left that comment in tact.
llvm-svn: 292275
instead of members.
No state was being provided by the object so this seems strictly
simpler.
I've also tried to improve the name and comments for the functions to
more thoroughly document what they are doing.
llvm-svn: 292274
that we know has exactly one element when all we are going to do is get
that one element out of it.
Instead, pass around that one element.
There are more simplifications to come in this code...
llvm-svn: 292273
Summary: Add a test case for LICM when promoting locals that may be read after the throw within the loop.
Reviewers: eli.friedman, hfinkel, sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28822
llvm-svn: 292261
Remove the failing tests for __fixunssfdi() and __fixunsdfdi() that
relied on undefined (and most likely obsolete in terms of compiler-rt
implementation behavior).
Both tests presumed that 0x1.p+64 would be converted to
0xFFFFFFFFFFFFFFFFLL, that is the largest value in uint64 range.
However, the C/C++ standards do not specify the behavior for converting
a floating-point value to an integer of smaller range, and in this case
both libgcc and compiler-rt implementations return 0 instead.
Since the current behavior is correct with regards to standards
and there is no good way of expressing 0xFFFFFFFFFFFFFFFFLL in single-
or double-precision float, I've removed the failing test altogether.
Differential Revision: https://reviews.llvm.org/D28146
llvm-svn: 292257
Update SOVERSION to use just the major version number rather than
major+minor, to match the new versioning scheme where only major is used
to indicate API/ABI version.
Since two-digit SOVERSIONs were introduced post 3.9 branching, this
change does not risk any SOVERSION collisions. In the past,
two-component X.Y SOVERSIONs were shortly used but those will not
interfere with the new ones since the new versions start at 4.
Differential Revision: https://reviews.llvm.org/D28730
llvm-svn: 292255
If a memory instruction will be vectorized, but it's pointer operand is
non-consecutive-like, the instruction is a gather or scatter operation. Its
pointer operand will be non-uniform. This should fix PR31671.
Reference: https://llvm.org/bugs/show_bug.cgi?id=31671
Differential Revision: https://reviews.llvm.org/D28819
llvm-svn: 292254
Making this variable non-static avoids the need for locking to ensure
that the initialization is thread-safe which in turns eliminates the
runtime dependency on libc++abi library (for __cxa_guard_acquire and
__cxa_guard_release) which makes it possible to link scudo against
pure C programs.
Differential Revision: https://reviews.llvm.org/D28757
llvm-svn: 292253
other test cases.
Summary: Refactor out LoopInfo computation so that it can be
used by other test cases.
So i am changing this test proactively for later commit, which will use
this function.
Reviewers: sanjoy, hfinkel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28778
llvm-svn: 292250
Summary:
Python bindings cannot support Python 3 without work being done to fix Unicode c-string conversion.
This was attempted in https://reviews.llvm.org/D26082. That patch was reverted due to memory access issues on Linux.
This revision fixes enough language compatibility issues for the clang module to be loaded and raise an error if the Python version is not 2.
Reviewers: mgorny, MathieuDuponchelle, rengolin, compnerd
Reviewed By: compnerd
Differential Revision: https://reviews.llvm.org/D28682
llvm-svn: 292247
r292188 confused MSVC because of the combined lack of a default
case and return statement.
Move the unreachable outside of the NumLibFuncs case, to make it
obvious that all cases should be handled.
llvm_unreachable is __declspec(noreturn), so I'm assuming this
does appease MSVC.
llvm-svn: 292246
CheckDesignatedInitializer wasn't taking into account the base classes
when computing the index for the field in the derived class, which
caused the test case to crash during IRGen because of a malformed AST.
rdar://problem/26795040
Differential Revision: https://reviews.llvm.org/D28705
llvm-svn: 292245
Even with the fix from r291630, this still causes problems. I get
widespread assertion failures in the Swift runtime's WeakRefCount::increment()
function. I sent a reduced testcase in reply to the commit.
llvm-svn: 292242
runnig LCSSA over them prior to running the loop pipeline.
This also teaches the loop PM to verify that LCSSA form is preserved
throughout the pipeline's run across the loop nest.
Most of the test updates just leverage this new functionality. One has to be
relaxed with the new PM as IVUsers is less powerful when it sees LCSSA input.
Differential Revision: https://reviews.llvm.org/D28743
llvm-svn: 292241
Summary: This copies over some functionality we have in ELF/Error.{cpp,h} and makes it available in COFF/Error.{cpp,h}
Reviewers: pcc, rafael, ruiu
Subscribers:
Differential Revision: https://reviews.llvm.org/D28692
llvm-svn: 292240
Also, add the corresponding match to the AssumptionCache's 'Affected Values' list.
Differential Revision: https://reviews.llvm.org/D28485
llvm-svn: 292239
Running lit tests and unit tests of ASan and TSan on macOS has very bad performance when running with a high number of threads. This is caused by xnu (the macOS kernel), which currently doesn't handle mapping and unmapping of sanitizer shadow regions (reserved VM which are several terabytes large) very well. The situation is so bad that increasing the number of threads actually makes the total testing time larger. The macOS buildbots are affected by this. Note that we can't easily limit the number of sanitizer testing threads without affecting the rest of the tests.
This patch adds a special "group" into lit, and limits the number of concurrently running tests in this group. This helps solve the contention problem, while still allowing other tests to run in full, that means running lit with -j8 will still with 8 threads, and parallelism is only limited in sanitizer tests.
Differential Revision: https://reviews.llvm.org/D28420
llvm-svn: 292232
Running lit tests and unit tests of ASan and TSan on macOS has very bad performance when running with a high number of threads. This is caused by xnu (the macOS kernel), which currently doesn't handle mapping and unmapping of sanitizer shadow regions (reserved VM which are several terabytes large) very well. The situation is so bad that increasing the number of threads actually makes the total testing time larger. The macOS buildbots are affected by this. Note that we can't easily limit the number of sanitizer testing threads without affecting the rest of the tests.
This patch adds a special "group" into lit, and limits the number of concurrently running tests in this group. This helps solve the contention problem, while still allowing other tests to run in full, that means running lit with -j8 will still with 8 threads, and parallelism is only limited in sanitizer tests.
Differential Revision: https://reviews.llvm.org/D28420
llvm-svn: 292231
D28684 changed llvm::zlib to return Error instead of Status.
It was accepted and committed in r292214, but then reverted in r292217
because I missed that clang code also needs to be updated.
Patch do that.
D28684 recommitted again as r292226
Differential revision: https://reviews.llvm.org/D28807
llvm-svn: 292227
No any changes, will follow up with D28807 commit containing APLi change for clang
to fix build issues happened.
Original commit message:
[Support/Compression] - Change zlib API to return Error instead of custom status.
Previously API returned custom enum values.
Patch changes it to return Error with string description.
That should help users to report errors in universal way.
Differential revision: https://reviews.llvm.org/D28684
llvm-svn: 292226
Stephan T. Lavavej