The included test case triggered a sign assertion on the result in
`Success()`. This was caused by the APSInt created for a bitcast
having its signedness bit inverted. The second APSInt constructor
argument is `isUnsigned`, so invert the result of
`isSignedIntegerType`.
Differential Revision: https://reviews.llvm.org/D95135
Added documentation for the fast builtin
function declarations with -fdeclare-opencl-builtins.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D95038
Follow-up on D95336. A bunch of these cases were found manually, the
rest made sense to be included to eliminate llvm-else-after-return
Clang-Tidy warnings.
The test ms-lookup-template-base-classes.cpp added in d972d4c749
is failing on some builtbot that don't include x86.
This patch should fix that (following the patterns in the test directory).
Currently, empty lines and comments break alignment of assignments on consecutive
lines. This makes the AlignConsecutiveAssignments option an enum that allows controlling
whether empty lines or empty lines and comments should be ignored when aligning
assignments.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks, tinloaf
Differential Revision: https://reviews.llvm.org/D93986
Currently, empty lines and comments break alignment of assignments on consecutive
lines. This makes the AlignConsecutiveAssignments option an enum that allows controlling
whether empty lines or empty lines and comments should be ignored when aligning
assignments.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks, tinloaf
Differential Revision: https://reviews.llvm.org/D93986
When `Bool{F,G}Option` were introduced, they were designed after the existing `Opt{In,Out}FFlag` in that they implied `CC1Option` for the `ChangedBy` flag.
This means less typing, but can be misleading in situations when the `ResetBy` has explicit `CC1Option` and `ChangedBy` doesn't.
This patch stops implicitly putting `CC1Option` to `ChangedBy` flag.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D95225
The prefix used to be the last (optional) argument to BoolOption. This decision was made with the expectation that only few command line options would need to pass it explicitly instead of using Bool{F,G}Option. It turns out that a considerable number of options don't conform to Bool{F,G}Option and need to provide the prefix anyways. This sometimes requires to explicitly pass `BothFlags<[]>`.
This patch makes prefix the first parameter, so it now directly precedes the spelling base string. Now 8 options dropped `BothFlags<[]>` and only two options (`pthread` and `emit_llvm_uselists`) need to pass an empty prefix.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D95221
The GNU token paste extension that removes the comma in , ## __VA_ARGS__
conflicts with C99/C++11's requirements when a variadic macro has no
named parameters: according to the standard, an invocation as FOO()
gives it a single empty argument, and concatenation of anything with an
empty argument is well-defined. For this reason, the GNU extension was
already disabled in C99 standard-conforming mode. It was not yet
disabled in C++11 standard-conforming mode.
The associated comment suggested that GCC keeps this extension enabled
in C90/C++03 standard-conforming mode, but it actually does not, so
rather than adding a check for C++ language version, this change simply
removes the check for C language version.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D91913
D94700 removed the static library so we no longer need to pass
`-llibomptarget-nvptx` to `nvlink`. Since the bitcode library is the only device
runtime for now, instead of emitting a warning when it is not found, an error
should be raised. We also set a new option `libomptarget-nvptx-bc-path` to let
user choose which bitcode library is being used.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D95161
This change adds an AssemblerInvocation class, similar to the
CompilerInvocation class. It can be used to invoke cc1as directly.
The project I'm working on wants to compile Clang and use it as a static
library. For that to work, there must be a way to invoke the assembler
programmatically, using the same arguments as you would otherwise pass
to cc1as.
Differential Revision: https://reviews.llvm.org/D63852
Insert a llvm.experimental.noalias.scope.decl intrinsic that identifies where a noalias argument was inlined.
This patch includes some refactorings from D90104.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D93040
In the PPC32 SVR4 ABI, a va_list has copies of registers from the function call.
va_arg looked in the wrong registers for (the pointer representation of) an
object in Objective-C, and for some types in C++. Fix va_arg to look in the
general-purpose registers, not the floating-point registers. Also fix va_arg
for some C++ types, like a member function pointer, that are aggregates for
the ABI.
Anthony Richardby found the problem in Objective-C. Eli Friedman suggested
part of this fix.
Fixes https://bugs.llvm.org/show_bug.cgi?id=47921
Reviewed By: efriedma, nemanjai
Differential Revision: https://reviews.llvm.org/D90329
Rather than reimplement, use a `using` declaration to bring in
`SmallVectorImpl<char>`'s assign and append implementations in
`SmallString`.
The `SmallString` versions were missing reference invalidation
assertions from `SmallVector`. This patch also fixes a bug in
`llvm::FileCollector::addFileImpl`, which was a copy/paste from
`clang::ModuleDependencyCollector::copyToRoot`, both caught by the
no-longer-skipped assertions.
As a drive-by, this also sinks the `const SmallVectorImpl&` versions of
these methods down into `SmallVectorImpl`, since I imagine they'd be
useful elsewhere.
Differential Revision: https://reviews.llvm.org/D95202
default arguments.
When a function is declared with a qualified name, its eventual semantic
DeclContext may differ from the scope specified by the qualifier if it
redeclares a function in an inline namespace. In this case, we need to
update the DeclContext to be that of the previous declaration, and we
need to do so before we decide whether to inherit default arguments from
that previous declaration, because we only inherit default arguments
from declarations in the same scope.
Add code pattersn for c++ `range for` loops and objective c `for...in` loops.
Reviewed By: kadircet
Differential Revision: https://reviews.llvm.org/D95131
Most of CGExprConstant.cpp is using the CharUnits abstraction
and is using getCharWidth() (directly of indirectly) when converting
between size of a char and size in bits. This patch is making that
abstraction more consistent by adding CharTy to the CodeGenTypeCache
(honoring getCharWidth() when mapping from char to LLVM IR types,
instead of using Int8Ty directly).
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D94979
When using getByteArrayType the requested size is calculated in
char units, but the type used for the array was hardcoded to the
Int8Ty. This patch is using getCharWIdth a bit more consistently
by using getIntNTy in combination with getCharWidth, instead
of explictly using getInt8Ty.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D94977
This patch implements codegen for __managed__ variable attribute for HIP.
Diagnostics will be added later.
Differential Revision: https://reviews.llvm.org/D94814
The class `SymbolOccurrences` can store either a single `SourceRange`
in-place or multiple `SourceRanges` on the heap. In the latter case
the number of source ranges is stored in the internal representation
of the beginning `SourceLocation` of the in-place `SourceRange`
object.
This change gets rid of such hack by placing `SourceRange` in a union
which holds either a valid `SourceRange` or an `unsigned int` (a number
of ranges).
The change also adds `static_assert`s that check that `SourceRange` and
`SourceLocation` are trivially destructible (this is required for the
current patch and for D94237 which has already been committed).
Reviewed By: MarkMurrayARM, simon_tatham
Differential Revision: https://reviews.llvm.org/D94599
This type is used as an aggregate, i.e. it has no member functions.
Starting with C++20 types with deleted default constructors are not
aggregate types anymore which means that aggregate initialization will
not work for this class anymore. This leads to a compile error in
clang::AnalyzerOptions::getDiagOpts() for example.
Also set the boolean flags to false by default to avoid undefined
behavior. Previously this was prevented by deleting the default
constructor, now we explicitly initialize them.
Differential Revision: https://reviews.llvm.org/D92221
This addresses an issue with how the PCH preable works, specifically:
1. When using a PCH/preamble the module hash changes and a different cache directory is used
2. When the preamble is used, PCH & PCM validation is disabled.
Due to combination of #1 and #2, reparsing with preamble enabled can end up loading a stale module file before a header change and using it without updating it because validation is disabled and it doesn’t check that the header has changed and the module file is out-of-date.
rdar://72611253
Differential Revision: https://reviews.llvm.org/D95159
check
This patch fixes a bug in emitARCOperationAfterCall where it inserts the
fall-back call after a bitcast instruction and then replaces the
bitcast's operand with the result of the fall-back call. The generated
IR without this patch looks like this:
msgSend.call: ; preds = %entry
%call = call i8* bitcast (i8* (i8*, i8*, ...)* @objc_msgSend
br label %msgSend.cont
msgSend.null-receiver: ; preds = %entry
call void @llvm.objc.release(i8* %4)
br label %msgSend.cont
msgSend.cont:
%8 = phi i8* [ %call, %msgSend.call ], [ null, %msgSend.null-receiver ]
%9 = bitcast i8* %10 to %0*
%10 = call i8* @llvm.objc.retain(i8* %8)
Notice that `%9 = bitcast i8* %10` to %0* is taking operand %10 which is
defined after it.
To fix the bug, this patch modifies the insert point to point to the
bitcast instruction so that the fall-back call is inserted before the
bitcast. In addition, it teaches the function to look at phi
instructions that are generated when there is a check for a null
receiver and insert the retainRV/claimRV instruction right after the
call instead of inserting a fall-back call right after the phi
instruction.
rdar://73360225
Differential Revision: https://reviews.llvm.org/D95181
CodeGenModule::EmitNullConstant() creates constants with their "in memory"
type, not their "in vregs" type. The one place where this difference matters is
when the type is _Bool, as that is an i1 when in vregs and an i8 in memory.
Fixes: rdar://73361264
If a function doesn't contain loops and does not call non-willreturn
functions, then it is willreturn. Loops are detected by checking
for backedges in the function. We don't attempt to handle finite
loops at this point.
Differential Revision: https://reviews.llvm.org/D94633
Defaulted destructor was treated inconsistently, compared to other
compiler-generated functions.
When Sema::IdentifyCUDATarget() got called on just-created dtor which didn't
have implicit __host__ __device__ attributes applied yet, it would treat it as a
host function. That happened to (sometimes) hide the error when dtor referred
to a host-only functions.
Even when we had identified defaulted dtor as a HD function, we still treated it
inconsistently during selection of usual deallocators, where we did not allow
referring to wrong-side functions, while it is allowed for other HD functions.
This change brings handling of defaulted dtors in line with other HD functions.
Differential Revision: https://reviews.llvm.org/D94732
Summary:
The custom mapper API did not previously support the mapping names added previously. This means they were not present if a user requested debugging information while using the mapper functions. This adds basic support for passing the mapped names to the runtime library.
Reviewers: jdoerfert
Differential Revision: https://reviews.llvm.org/D94806
_ExtInt gets stuck in the device-type-checking for __int128 if it is
between 65 and 128 bits inclusive. Anything larger or smaller was
permitted despite this, so this is simply enabling 65-128 bit _ExtInts.
_ExtInt is supported on all our current ABIs, but we stil use the
hasExtIntType in the target info to differentiate here so that it can be
disabled.
This reverts commit 275f30df8a.
As noted on the code review (https://reviews.llvm.org/D92892), this
change causes us to reject valid code in a few cases. Reverting so we
have more time to figure out what the right fix{es are, is} here.
This reduces template bloat, but more importantly, makes it possible to
construct one from clang-query without template types.
Differential Revision: https://reviews.llvm.org/D94879
Sven van Haastregt