Reviewed here: https://reviews.llvm.org/D91409 by Aaron.
Highlights of the review:
- avoid an underlying type for enums
- avoid enum bit fields (MSVC packing anomalies) and favor static_casts to unsigned bit-fields
Patch by Thorsten Schuett <schuett@gmail.com> w some minor fixes in SemaType.cpp where a couple asserts had to be repaired to deal with lack of implicit coversion to int.
Thanks Thorsten!
As Richard Smith pointed out in the review of D90123, both the C and C++
standard call it lvalue and rvalue, so let's stick to the same spelling
in Clang.
When an overloaded member function has a ref-qualifier, like:
class X {
void f() &&;
void f(int) &;
};
we would print strange notes when the ref-qualifier doesn't fit the value
category:
X x;
x.f();
X().f(0);
would both print a note "no known conversion from 'X' to 'X' for object
argument" on their relevant overload instead of pointing out the
mismatch in value category.
At first I thought the solution is easy: just use the FailureKind member
of the BadConversionSequence struct. But it turns out that we weren't
properly setting this for function arguments. So I went through
TryReferenceInit to make sure we're doing that right, and found a number
of notes in the existing tests that improved as well.
Fixes PR47791.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D90123
This patch turns VPWidenGEPRecipe into a VPValue and uses it
during VPlan construction and codegeneration instead of the plain IR
reference where possible.
Reviewed By: dmgreen
Differential Revision: https://reviews.llvm.org/D84683
In an effort to make code around flag determination more readable, and (possibly) prepare for a follow up change, factor out some of the flag detection logic. In the process, reduce the number of locations we mutate wrap flags by a couple.
Note that this isn't NFC. The old code tried for NSW xor (NUW || NW). This is, two different paths computed different sets of wrap flags. The new code will try for all three. The result is that some expressions end up with a few extra flags set.
This is used to test RemoveRedundantDbgInstrs(), which is used by other
passes.
Reviewed By: ychen
Differential Revision: https://reviews.llvm.org/D91477
This patch reduces the copy paste in the unittest/CodeGen folder by moving the
common compiler setup phase in a header file.
Differential revision: https://reviews.llvm.org/D91061
9218ff50f9 removed the BUILD.txt file, and as a subtle side-effect
libLLVMFrontendOpenACC wasn't a dependency of `ninja check` anymore.
However llvm-config requires all components to be built, and the
relevant test is broken when libLLVMFrontendOpenACC isn't built.
Unittest for libLLVMFrontendOpenACC are pending, but this addition
should fix some bots in the meantime.
Describe in the BackEnd Developer's Guide. Instrument a few backends.
Remove an old unused timing facility. Add a null backend for timing
the parser.
Differential Revision: https://reviews.llvm.org/D91388
This was changed recently with D90554 / f7eac51b9b
...because we had a regression testing blindspot for intrinsics
that are expected to be lowered to libcalls.
In general, we want the *size* cost for a scalar call to be cheap
even if the other costs are expensive - we expect it to just be
a branch with some optional stack manipulation.
It is likely that we will want to carve out some
exceptions/overrides to this rule as follow-up patches for
calls that have some general and/or target-specific difference
to the expected lowering.
This was noticed as a regression in unrolling, so we have a test
for that now along with a couple of direct cost model tests.
If the assumed scalarization costs for the oversized vector
calls are not realistic, that would be another follow-up
refinement of the cost models.
Clang supports compiling CUDA source files,
CUDA header files may contain CUDA specific code
that is why they have special extension, which
can be recognized by nvcc (CUDA compiler driver)
as CUDA source file.
Format them by default as well.
Reviewed By: MyDeveloperDay
Patch By: tomilov
Differential Revision: https://reviews.llvm.org/D90780
See discussion in https://bugs.llvm.org/show_bug.cgi?id=45073 / https://reviews.llvm.org/D66324#2334485
the implementation is known-broken for certain inputs,
the bugreport was up for a significant amount of timer,
and there has been no activity to address it.
Therefore, just completely rip out all of misexpect handling.
I suspect, fixing it requires redesigning the internals of MD_misexpect.
Should anyone commit to fixing the implementation problem,
starting from clean slate may be better anyways.
This reverts commit 7bdad08429,
and some of it's follow-ups, that don't stand on their own.
This unit test code was using malloc without a corresponding free.
When the system malloc is not being overridden by the code under
test, it might an asan/lsan allocator that notices leaks.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D91472
motivated by a refactoring in the new sparse code (yet to be merged), this avoids some lengthy code dup
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D91465
This library is only used in Flang at the moment and not tested withing LLVM.
Having it as a component is breaking llvm-config:
$ bin/llvm-config --shared-mode
llvm-config: error: component libraries and shared library
llvm-config: error: missing: [...]/lib/libLLVMFrontendOpenACC.a
This will reverted when unit-tests are provided for it.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D91470
I think the check for whether the process is connected is totally bogus
in the first place, but on the off-chance that's it's not, we should
behave the same in synchronous and asynchronous mode.
This assertion ensures the input value isn't part of the vector when
growing is required. In such cases the vector will grow and the input
value is invalidated before being read from.
This found 14 failed Tests.
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D84293
The code has a few sequence that looked like:
Ops.push_back(Ops[0]);
Ops.erase(Ops.begin());
And are equivalent to:
std::rotate(Ops.begin(), Ops.begin() + 1, Ops.end());
The latter has the advantage of never reallocating the vector, which
would be a bug in the original code as push_back would read from the
memory it deallocated.
faisalv