Summary:
A previous patch removed the use of the `OK` private variable in CUDA
which resulted in usused variable warnings. this was fixed in
f886f7e8ef but did not change the
constructor to accurately represent its removal. This patch removes it
from the interface entirely.
leaking in ARC mode
When ARC (automatic reference count) is enabled, (objective-c) block
objects are automatically retained and released thus they do not leak.
Without ARC, they still can leak from an expiring stack frame like
other stack variables.
With this commit, the static analyzer now puts a block object in an
"unknown" region if ARC is enabled because it is up to the
implementation to choose whether to put the object on stack initially
(then move to heap when needed) or in heap directly under ARC.
Therefore, the `StackAddrEscapeChecker` has no need to know
specifically about ARC at all and it will not report errors on objects
in "unknown" regions.
Reviewed By: NoQ (Artem Dergachev)
Differential Revision: https://reviews.llvm.org/D131009
Enables Clang to emit diagnostics in SARIF format when
`-fdiagnostics-format=sarif`. Adds a new DiagnosticConsumer named
SARIFDiagnosticPrinter and a new DiagnosticRenderer named SARIFDiagnostic
to constuct and emit a SARIF object containing the run's basic diagnostic info.
Reviewed By: cjdb, denik, aaron.ballman
Differential Revision: https://reviews.llvm.org/D131632
Recently OpenMP has transitioned to using the "new" driver which
primarily merges the device and host linking phases into a single
wrapper that handles both at the same time. This replaced a few tools
that were only used for OpenMP offloading, such as the
`clang-offload-wrapper` and `clang-nvlink-wrapper`. The new driver
carries some marked benefits compared to the old driver that is now
being deprecated. Things like device-side LTO, static library
support, and more compatible tooling. As such, we should be able to
completely deprecate the old driver, at least for OpenMP. The old driver
support will still exist for CUDA and HIP, although both of these can
currently be compiled on Linux with `--offload-new-driver` to use the new
method.
Note that this does not deprecate the `clang-offload-bundler`, although
it is unused by OpenMP now, it is still used by the HIP toolchain both
as their device binary format and object format.
When I proposed deprecating this code I heard some vendors voice
concernes about needing to update their code in their fork. They should
be able to just revert this commit if it lands.
Reviewed By: jdoerfert, MaskRay, ye-luo
Differential Revision: https://reviews.llvm.org/D130020
We run into a duplicate symbol error when instrumenting the rtti_proxies
generated as part of the relative vtables ABI with hwasan:
```
ld.lld: error: duplicate symbol: typeinfo for icu_71::UObject
(.rtti_proxy)
>>> defined at brkiter.cpp
>>>
arm64-hwasan-shared/obj/third_party/icu/source/common/libicuuc.brkiter.cpp.o:(typeinfo
for icu_71::UObject (.rtti_proxy))
>>> defined at locavailable.cpp
>>>
arm64-hwasan-shared/obj/third_party/icu/source/common/libicuuc.locavailable.cpp.o:(.data.rel.ro..L_ZTIN6icu_717UObjectE.rtti_proxy.hwasan+0xE00000000000000)
```
The issue here is that the hwasan alias carries over the visibility and
linkage of the original proxy, so we have duplicate external symbols
that participate in linking. Similar to D132425 we can just disable
hwasan for the proxies for now.
Differential Revision: https://reviews.llvm.org/D132691
Full context in
https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=107017.
Instrumenting hwasan with globals results in a linker error under the
relative vtables abi:
```
ld.lld: error:
libunwind.cpp:(.rodata..L_ZTVN9libunwind12UnwindCursorINS_17LocalAddressSpaceENS_15Registers_arm64EEE.hwasan+0x8):
relocation R_AARCH64_PLT32 out of range: 6845471433603167792 is not in
[-2147483648, 2147483647]; references
libunwind::AbstractUnwindCursor::~AbstractUnwindCursor()
>>> defined in
libunwind/src/CMakeFiles/unwind_shared.dir/libunwind.cpp.obj
```
This is because the tag is included in the vtable address when
calculating the offset between the vtable and virtual function. A
temporary solution until we can resolve this is to just disable hwasan
instrumentation on relative vtables specifically, which can be done in
the frontend.
Differential Revision: https://reviews.llvm.org/D132425
In Sema::LookupTemplateName(...) seeks to assert that the ObjectType is complete
or being defined. If the type is incomplete it will attempt to unconditionally
cast it to a TagType and not all incomplete types are a TagType. For example the
type could be void or it could be an IncompleteArray.
This change adds an additional check to confirm it is a TagType before attempting
to check if it is incomplete or being defined
Differential Revision: https://reviews.llvm.org/D132712
Put DXIL validation version into separate NamedMetadata to avoid update ModuleFlags.
Currently DXIL validation version is saved in ModuleFlags in clang codeGen.
Then in DirectX backend, the data will be extracted from ModuleFlags and cause rebuild of ModuleFlags.
This patch will build NamedMetadata for DXIL validation version and remove the code to rebuild ModuleFlags.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D130207
Clang crashes when encountering an `if consteval` statement.
This is the minimum fix not to crash.
The fix is consistent with the current behavior of if constexpr,
which does generate coverage data for the discarded branches.
This is of course not correct and a better solution is
needed for both if constexpr and if consteval.
See https://github.com/llvm/llvm-project/issues/54419.
Fixes#57377
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D132723
This addresses an accidental change in behavior from
41667a8b9b to get the bots back to green.
However, I think there's an issue with LLDB assuming it's valid to
enable support for keywords in language modes that don't support the
keyword (as other parts of Clang are not expecting to be able to do
that).
This should fix (and others):
https://lab.llvm.org/buildbot/#/builders/68/builds/38374
The patch diagnoses an identifier as a future keyword if it exists in a
future language mode, such as:
int restrict;
in C modes earlier than C99. We now give a warning to the user that
such an identifier is a future keyword. Handles keywords from C as well
as C++.
Differential Revision: https://reviews.llvm.org/D131683
The commit breaks the compiler when a function is used as a function
parameter (hm... for a function from the standard C library?):
```
static float strtof(char *, char *) {}
void a() { strtof(a, 0); }
```
This reverts commit 879f5118fc.
Closing https://github.com/llvm/llvm-project/issues/57339
The root cause for this issue is an pre-mature optimization to eliminate
the index for the final suspend point since we feel like we can judge
if a coroutine is suspended at the final suspend by if resume_fn_addr is
null. However this is not true if the coroutine exists via an exception
in promise.unhandled_exception(). According to
[dcl.fct.def.coroutine]p14:
> If the evaluation of the expression promise.unhandled_exception()
> exits via an exception, the coroutine is considered suspended at the
> final suspend point.
But from the perspective of the implementation, we can't set the coro
index to the final suspend point directly since it breaks the states.
To fix the issue, we block the optimization if we find there is any
unwind coro end, which indicates that it is possible that the coroutine
exists via an exception from promise.unhandled_exception().
Test Plan: folly
This patch implements P0848 in Clang.
During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constraints for all the SMFs and compare the constraints to compute the eligibility. We defer the computation of the type's [copy-]trivial bits from addedMember to the eligibility computation, like we did for destructors in D126194. `canPassInRegisters` is modified as well to better respect the ineligibility of functions.
Note: Because of the non-implementation of DR1734 and DR1496, I treat deleted member functions as 'eligible' for the purpose of [copy-]triviallity. This is unfortunate, but I couldn't think of a way to make this make sense otherwise.
Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman
Differential Revision: https://reviews.llvm.org/D128619
Semantic parameters aren't passed as actual parameters, instead they are
populated from intrinsics which are generally lowered to reads from
dedicated hardware registers.
This change modifies clang CodeGen to emit the intrinsic calls and
populate the parameter's LValue with the result of the intrinsic call
for SV_GroupIndex.
The result of this is to make the actual passed argument ignored, which
will make it easy to clean up later in an IR pass.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D131203
The linker is supposed to detect when an object with /kernel is linked
with another object which is not compiled with /kernel. The linker
detects this by checking bit 30 in @feat.00.
* Factor module map and module file path functions out
* Use a secondary mapping to lookup module deps by ID instead of the
preprocessor module map.
* Sink DirectPrebuiltModularDeps into MDC.
Differential Revision: https://reviews.llvm.org/D132617
clang/lib/Basic/Targets/X86.h:293:8: warning: 'shouldEmitFloat16WithExcessPrecision' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
bool shouldEmitFloat16WithExcessPrecision() const {
^
clang/include/clang/Basic/TargetInfo.h:915:16: note: overridden virtual function is here
virtual bool shouldEmitFloat16WithExcessPrecision() const { return false; }
^
Prior to this patch when the analyzer encountered a non-POD 0 length array,
it still invoked the constructor for 1 element, which lead to false positives.
This patch makes sure that we no longer construct any elements when we see a
0 length array.
Differential Revision: https://reviews.llvm.org/D131501
The ArgumentPromotion pass uses Mem2Reg promotion at the end to cutting
down generated `alloca` instructions as well as meaningless `store`s and
this behavior can leave unused (dead) arguments. To eliminate the dead
arguments and therefore let the DeadCodeElimination remove becoming dead
inserted `GEP`s as well as `load`s and `cast`s in the callers, the
DeadArgumentElimination pass should be run after the ArgumentPromotion
one.
Differential Revision: https://reviews.llvm.org/D128830
The invocation is only ever used to serialize cc1 arguments from, so
instead serialize the arguments inside the dep scanner to simplify the
interface.
Differential Revision: https://reviews.llvm.org/D132616
ToolInvocation is useful even if you already have a -cc1 invocation,
since it provides a standard way to setup diagnostics, parse arguments,
and handoff to a ToolAction. So teach it to support -cc1 commands by
skipping the driver bits.
Differential Revision: https://reviews.llvm.org/D132615
The KCFI sanitizer, enabled with `-fsanitize=kcfi`, implements a
forward-edge control flow integrity scheme for indirect calls. It
uses a !kcfi_type metadata node to attach a type identifier for each
function and injects verification code before indirect calls.
Unlike the current CFI schemes implemented in LLVM, KCFI does not
require LTO, does not alter function references to point to a jump
table, and never breaks function address equality. KCFI is intended
to be used in low-level code, such as operating system kernels,
where the existing schemes can cause undue complications because
of the aforementioned properties. However, unlike the existing
schemes, KCFI is limited to validating only function pointers and is
not compatible with executable-only memory.
KCFI does not provide runtime support, but always traps when a
type mismatch is encountered. Users of the scheme are expected
to handle the trap. With `-fsanitize=kcfi`, Clang emits a `kcfi`
operand bundle to indirect calls, and LLVM lowers this to a
known architecture-specific sequence of instructions for each
callsite to make runtime patching easier for users who require this
functionality.
A KCFI type identifier is a 32-bit constant produced by taking the
lower half of xxHash64 from a C++ mangled typename. If a program
contains indirect calls to assembly functions, they must be
manually annotated with the expected type identifiers to prevent
errors. To make this easier, Clang generates a weak SHN_ABS
`__kcfi_typeid_<function>` symbol for each address-taken function
declaration, which can be used to annotate functions in assembly
as long as at least one C translation unit linked into the program
takes the function address. For example on AArch64, we might have
the following code:
```
.c:
int f(void);
int (*p)(void) = f;
p();
.s:
.4byte __kcfi_typeid_f
.global f
f:
...
```
Note that X86 uses a different preamble format for compatibility
with Linux kernel tooling. See the comments in
`X86AsmPrinter::emitKCFITypeId` for details.
As users of KCFI may need to locate trap locations for binary
validation and error handling, LLVM can additionally emit the
locations of traps to a `.kcfi_traps` section.
Similarly to other sanitizers, KCFI checking can be disabled for a
function with a `no_sanitize("kcfi")` function attribute.
Relands 67504c9549 with a fix for
32-bit builds.
Reviewed By: nickdesaulniers, kees, joaomoreira, MaskRay
Differential Revision: https://reviews.llvm.org/D119296
This patch adds a formatter for `std::coroutine_handle`, both for libc++
and libstdc++. For the type-erased `coroutine_handle<>`, it shows the
`resume` and `destroy` function pointers. For a non-type-erased
`coroutine_handle<promise_type>` it also shows the `promise` value.
With this change, executing the `v t` command on the example from
https://clang.llvm.org/docs/DebuggingCoroutines.html now outputs
```
(task) t = {
handle = coro frame = 0x55555555b2a0 {
resume = 0x0000555555555a10 (a.out`coro_task(int, int) at llvm-example.cpp:36)
destroy = 0x0000555555556090 (a.out`coro_task(int, int) at llvm-example.cpp:36)
}
}
```
instead of just
```
(task) t = {
handle = {
__handle_ = 0x55555555b2a0
}
}
```
Note, how the symbols for the `resume` and `destroy` function pointer
reveal which coroutine is stored inside the `std::coroutine_handle`.
A follow-up commit will use this fact to infer the coroutine's promise
type and the representation of its internal coroutine state based on
the `resume` and `destroy` pointers.
The same formatter is used for both libc++ and libstdc++. It would
also work for MSVC's standard library, however it is not registered
for MSVC, given that lldb does not provide pretty printers for other
MSVC types, either.
The formatter is in a newly added `Coroutines.{h,cpp}` file because there
does not seem to be an already existing place where we could share
formatters across libc++ and libstdc++. Also, I expect this code to grow
as we improve debugging experience for coroutines further.
**Testing**
* Added API test
Differential Revision: https://reviews.llvm.org/D132415
When Clang encounters `@import M.Private` during implicit build, it precompiles module `M` and looks through its submodules. If the `Private` submodule is not found, Clang assumes `@import M_Private`. In the dependency scanner, we don't capture the dependency on `M`, since it's not imported. It's an affecting module, though: compilation of the import statement will fail when implicit modules are disabled and `M` is not precompiled and explicitly provided. This patch fixes that.
Depends on D132430.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D132502
HLSL entry function parameters must have parameter annotations. This
allows appropriate intrinsic values to be populated into parameters
during code generation.
This does not handle entry function return values, which will be
handled in a subsequent commit because we don't currently support any
annotations that are valid for function returns.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D131625
The KCFI sanitizer, enabled with `-fsanitize=kcfi`, implements a
forward-edge control flow integrity scheme for indirect calls. It
uses a !kcfi_type metadata node to attach a type identifier for each
function and injects verification code before indirect calls.
Unlike the current CFI schemes implemented in LLVM, KCFI does not
require LTO, does not alter function references to point to a jump
table, and never breaks function address equality. KCFI is intended
to be used in low-level code, such as operating system kernels,
where the existing schemes can cause undue complications because
of the aforementioned properties. However, unlike the existing
schemes, KCFI is limited to validating only function pointers and is
not compatible with executable-only memory.
KCFI does not provide runtime support, but always traps when a
type mismatch is encountered. Users of the scheme are expected
to handle the trap. With `-fsanitize=kcfi`, Clang emits a `kcfi`
operand bundle to indirect calls, and LLVM lowers this to a
known architecture-specific sequence of instructions for each
callsite to make runtime patching easier for users who require this
functionality.
A KCFI type identifier is a 32-bit constant produced by taking the
lower half of xxHash64 from a C++ mangled typename. If a program
contains indirect calls to assembly functions, they must be
manually annotated with the expected type identifiers to prevent
errors. To make this easier, Clang generates a weak SHN_ABS
`__kcfi_typeid_<function>` symbol for each address-taken function
declaration, which can be used to annotate functions in assembly
as long as at least one C translation unit linked into the program
takes the function address. For example on AArch64, we might have
the following code:
```
.c:
int f(void);
int (*p)(void) = f;
p();
.s:
.4byte __kcfi_typeid_f
.global f
f:
...
```
Note that X86 uses a different preamble format for compatibility
with Linux kernel tooling. See the comments in
`X86AsmPrinter::emitKCFITypeId` for details.
As users of KCFI may need to locate trap locations for binary
validation and error handling, LLVM can additionally emit the
locations of traps to a `.kcfi_traps` section.
Similarly to other sanitizers, KCFI checking can be disabled for a
function with a `no_sanitize("kcfi")` function attribute.
Reviewed By: nickdesaulniers, kees, joaomoreira, MaskRay
Differential Revision: https://reviews.llvm.org/D119296
When compiling a module, its semantics and Clang's behavior are affected by other modules. These modules are typically the **imported** ones. However, during implicit build, some modules end up being compiled and read without being actually imported. This patch starts tracking such modules and serializing them into `.pcm` files. This enables the dependency scanner to construct explicit compilations that mimic implicit build.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D132430
We're seeing the following warnings with --rtlib=compiler-rt:
lld-link: warning: ignoring unknown argument '--as-needed'
lld-link: warning: ignoring unknown argument '-lunwind'
lld-link: warning: ignoring unknown argument '--no-as-needed'
MSVC doesn't use the unwind library, so just omit it.
Differential Revision: https://reviews.llvm.org/D132440
A simple sed doing these substitutions:
- `${LLVM_BINARY_DIR}/(\$\{CMAKE_CFG_INTDIR}/)?lib(${LLVM_LIBDIR_SUFFIX})?\>` -> `${LLVM_LIBRARY_DIR}`
- `${LLVM_BINARY_DIR}/(\$\{CMAKE_CFG_INTDIR}/)?bin\>` -> `${LLVM_TOOLS_BINARY_DIR}`
where `\>` means "word boundary".
The only manual modifications were reverting changes in
- `compiler-rt/cmake/Modules/CompilerRTUtils.cmake
- `runtimes/CMakeLists.txt`
because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing.
This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D132316
The new driver supports device-only compilation for the offloading
device. The way this is handlded is a little different from the old
offloading driver. The old driver would put all the outputs in the final
action list akin to a linker job. The new driver however generated these
in the middle of the host's job so we instead put them all in a single
offloading action. However, we only handled these kinds of offloading
actions correctly when there was only a single input. When we had
multiple inputs we would instead attempt to get the host job, which
didn't exist, and crash.
This patch simply adds some extra logic to generate the jobs for all
dependencies if there is not host action.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D132248
For the time being, we are still building libc++ and libc++abi's headers
during stage 2 builds. Encode that in the cache file so that CI jobs don't
have to manually specify LLVM_ENABLE_RUNTIMES when doing a stage 2 build.
Normally, passing -rtlib=platform overrides any earlier -rtlib
options, and overrides any hardcoded CLANG_DEFAULT_RTLIB option.
However, some targets, MSVC and Darwin, have custom logic for
disallowing specific -rtlib= option values; amend these checks for
allowing the -rtlib=platform option.
Differential Revision: https://reviews.llvm.org/D132444
The ArgumentPromotion pass uses Mem2Reg promotion at the end to cutting
down generated `alloca` instructions as well as meaningless `store`s and
this behavior can leave unused (dead) arguments. To eliminate the dead
arguments and therefore let the DeadCodeElimination remove becoming dead
inserted `GEP`s as well as `load`s and `cast`s in the callers, the
DeadArgumentElimination pass should be run after the ArgumentPromotion
one.
Differential Revision: https://reviews.llvm.org/D128830
This removes -O1 from the SVE ACLE intrinsics tests and replaces it with
-O0 and "opt -mem2reg -instcombine -tailcallelim". Instrcombine and
TailCallElim are only added to keep the differences smaller and can be
removed in a followup patches. The only remaining differences in the
tests are tbaa nodes not being emitted under -O0, and the removable of
some tailcall flags.
We're seeing the following warnings with --rtlib=compiler-rt:
lld-link: warning: ignoring unknown argument '--as-needed'
lld-link: warning: ignoring unknown argument '-lunwind'
lld-link: warning: ignoring unknown argument '--no-as-needed'
MSVC doesn't use the unwind library, so just omit it.
Differential Revision: https://reviews.llvm.org/D132440
The constructors of non-POD array elements are evaluated under
certain conditions. This patch makes sure that in such cases
we also evaluate the destructors.
Differential Revision: https://reviews.llvm.org/D130737
We build libcxx using LLVM_ENABLE_RUNTIMES during Stage2, which requires
cxx-headers to be part of LLVM_RUNTIME_DISTRIBUTION_COMPONENTS instead
of LLVM_DISTRIBUTION_COMPONENTS.
rdar://99028431
Differential Revision: https://reviews.llvm.org/D132488
"this" parameter of lambda if undef, notnull and differentiable.
So we need to pass something consistent.
Any alloca will work. It will be eliminated as unused later by optimizer.
Otherwise we generate code which Msan is expected to catch.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D132275
To support using Control Flow Guard with mingw-w64, Clang needs to
accept `__declspec(guard(nocf))` also for the GNU target. Since mingw
has `#define __declspec(a) __attribute__((a))` as built-in, the simplest
solution is to accept `__attribute__((guard(nocf)))` to be compatible with
MSVC and Clang's msvc target.
As a side effect, this also adds `[[clang::guard(nocf)]]` for C++.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D132302
The OpenMP device runtime needs to support the OpenMP standard. However
constructs like nested parallelism are very uncommon in real application
yet lead to complexity in the runtime that is sometimes difficult to
optimize out. As a stop-gap for performance we should supply an argument
that selectively disables this feature. This patch adds the
`-fopenmp-assume-no-nested-parallelism` argument which explicitly
disables the usee of nested parallelism in OpenMP.
Reviewed By: carlo.bertolli
Differential Revision: https://reviews.llvm.org/D132074
This patch implements P0848 in Clang.
During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constraints for all the SMFs and compare the constraints to compute the eligibility. We defer the computation of the type's [copy-]trivial bits from addedMember to the eligibility computation, like we did for destructors in D126194. `canPassInRegisters` is modified as well to better respect the ineligibility of functions.
Note: Because of the non-implementation of DR1734 and DR1496, I treat deleted member functions as 'eligible' for the purpose of [copy-]triviallity. This is unfortunate, but I couldn't think of a way to make this make sense otherwise.
Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman
Differential Revision: https://reviews.llvm.org/D128619
This is to clarify that the macro __FLT_EVAL_METHOD__ is not pre-
defined like other preprocessor macros. It will not appear when
preprocessor macros are dumped.
Differential Revision: https://reviews.llvm.org/D124033
Since the patch missed release 15.x and will be included in release 16.x. Also, simplify related tests.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D132414
As proposed in D126215 (ffe7950ebc),
I'm dropping the `-analyzer-store` and
`-analyzer-opt-analyze-nested-blocks` clang frontend flags.
I'm also dropping the corresponding commandline handlers of `scanbuild`.
This behavior is planned to be part of `clang-16`.
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D132289
Dead store detection automatically checks that an expression is a
CXXConstructor and skips it because of potential side effects. In C++17,
with guaranteed copy elision, this check can fail because we actually
receive the implicit cast of a CXXConstructor.
Most checks in the dead store analysis were already stripping all casts
and parenthesis and those that weren't were either forgotten (like the
constructor) or would not suffer from it, so this patch proposes to
factorize the stripping.
It has an impact on where the dead store warning is reported in the case
of an explicit cast, from
auto a = static_cast<B>(A());
^~~~~~~~~~~~~~~~~~~
to
auto a = static_cast<B>(A());
^~~
which we think is an improvement.
Patch By: frederic-tingaud-sonarsource
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D126534
Move copying compiler arguments to a vector<string> and modifying
common module-related options into CompilerInvocation in preparation for
using some of them in more places and to avoid duplicating this code
accidentally in the future.
Differential Revision: https://reviews.llvm.org/D132419
Summary:
The buildbots are giving failures on the explicit move operations here.
Previously I had problems where not perfomring an explicit move would
cause problems with older compilers so we'll see if this works as
expected.
MSVC allows interpreting volatile loads and stores, when combined with
/volatile:iso, as having acquire/release semantics. MSVC also exposes a
define, _ISO_VOLATILE, which allows users to enquire if this feature is
enabled or disabled.
Putting "simulator" in the `-target` flag requires putting it in the
"environment" part of the triple, which is the 4th `-`-separated component.
Some places in the tests currently use "iossimulator" which puts it in the
OS field. The triple parsing code in llvm::Triple uses startswith("ios")
in parseOS(), so that successfully sets the OS to "iOS", and all these
triples use an intel arch, and iOS + intel triple implicitly make the
driver convert the environment to "simulator", so this happened to work --
but it led to the somewhat strange "simulator-simulator" in the diag
in the test.
No behavior change.
Differential Revision: https://reviews.llvm.org/D132399
I added this recently, but it looks like several tests very intentionally
check that `-mios-version-min=foo --target=x86_64-apple-ios` does simulator
builds. So we can't easily remove this hack, even though it makes little
sense in an arm mac world. (Here, you _have_ to say
`-mios-simulator-version-min=` or `--target=arm64-apple-ios-simulator`.)
The tests that check this:
Clang :: Driver/darwin-ld.c
Clang :: Driver/darwin-simulator-macro.c
Clang :: Driver/darwin-version.c
No behavior change.
Differential Revision: https://reviews.llvm.org/D132400
This commit reverts the following commits:
- 952f90b72b
- e6a0800532 (D132298)
- 176db3b3ab (D132324)
These commits caused CI instability and need to be reverted in order
to figure things out again. See the discussion in https://llvm.org/D132324
for more information.
Summary:
Some older compilers cannot automatically elide the returned vector of
unique pointers, causing build errors. This patch explicitly moves the
returned value instead which should solve the problem.
We use the `clang-offload-packager` too bundle many files into a single
binary format containing metadata. This is used for offloading
compilation which may contain multiple device binaries of different
types and architectures in a single file. We use this special binary
format to store these files along with some necessary metadata around
them. We use this format because of the difficulty of determining the
filesize of the various binary inputs that will be passed to the
offloading toolchain rather than engineering a solution for each input.
Previously we only support packaing many files into a single binary.
This patch adds support for doing the reverse by using the same
`--image=` syntax. To unpackage a binary we now present an input file
instead of an output.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D129507
Previously when I wrote this document, I felt the completed scripts was
lengthy, redundant and not easy to read. So I didn't add complete
examples in the previous commit.
However, in the recent discussion with @avogelsgesang, I found people
may not know how to use debugging scripts to improve their debugging
efficiency. So now, I feel like it is helpful to put the examples even
if they are a little bit long.
Test Plan: make docs-clang-html
Reviewed By: avogelsgesang
Differential Revision: https://reviews.llvm.org/D132451
A FriendDecl node can have a friend record type that owns a RecordDecl
object. This object is different than the one got from TypeSourceInfo
object of the FriendDecl. When building a ParentMapContext this owned
tag decaration has to be encountered to have the parent set for it.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D131685
With the initial support added, clang can compile `helloworld` C
to executable file for loongarch64. For example:
```
$ cat hello.c
int main() {
printf("Hello, world!\n");
return 0;
}
$ clang --target=loongarch64-unknown-linux-gnu --gcc-toolchain=xxx --sysroot=xxx hello.c
```
The output a.out can run within qemu or native machine. For example:
```
$ file ./a.out
./a.out: ELF 64-bit LSB pie executable, LoongArch, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-loongarch-lp64d.so.1, for GNU/Linux 5.19.0, with debug_info, not stripped
$ ./a.out
Hello, world!
```
Currently gcc toolchain and sysroot can be found here:
https://github.com/loongson/build-tools/releases/download/2022.08.11/loongarch64-clfs-5.1-cross-tools-gcc-glibc.tar.xz
Reference: https://github.com/loongson/LoongArch-Documentation
The last commit hash (main branch) is:
99016636af64d02dee05e39974d4c1e55875c45b
Note loongarch32 is not fully tested because there is no reference
gcc toolchain yet.
Differential Revision: https://reviews.llvm.org/D130255
For bootstrap builds (CLANG_ENABLE_BOOTSTRAP=ON) allow
arguments to be passed to the native tool used in CMake
for the stage2 step.
Can be used to pass extra arguments for enhanced versions
of build tools, e.g. distributed build options.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D131665
Since we have enabled the support for `_Float16` on SSE2, we can relax
the limitation for AVX512FP16 now. This helps for user to use AVX512FP16
mixed with unsupported versions, e.g., multiversioning.
Also fix lit fails due to missing const modifier. Found during this change.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D132342
This patch introduces new option `-eager-load-pcm` to `clang-scan-deps`, which controls whether the resulting command-lines will load PCM files eagerly (at the start of compilation) or lazily (when handling import directive). This patch also switches the default from eager to lazy.
To reduce the potential for churn in LIT tests in the future, this patch also removes redundant checks of command-line arguments and introduces new test `modules-dep-args.c` as a substitute.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D132066
libc++ prior to LLVM 15 has a bug in it due to it excluding
`remove_reference_t` when `__remove_reference` is available as a
compiler built-in. This went unnoticed until D116203 because it wasn't
available in any compiler.
To work around this, we're renaming `__remove_reference` to
`__remove_reference_t`.
TEST=Tested locally, tested using emscripten
Fixes https://github.com/llvm/llvm-project/issues/55804
The lexing order is already bookkept in DelayedCXXInitPosition but we
were not using it based on the wrong assumption that inline variable is
unordered. This patch fixes it by ordering entries in llvm.global_ctors
by orders in DelayedCXXInitPosition.
for llvm.global_ctors entries without a lexing order, ordering them by
the insertion order.
(This *mostly* orders the template instantiation in
https://reviews.llvm.org/D126341 intuitively, minus one tweak for which I'll
submit a separate patch.)
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D127233
This keeps clang compatible with MSVC defines for the FP environment.
These defines are used by the CRT and other libraries to interrogate
what to expect. Perhaps most importantly, they feed into the definition
of float_t and double_t which may result in ODR violations between MSVC
and clang.
They were mapped as follows:
- /fp:except to --ftrapping-math
- /fp:except- to --fno-trapping-math
- /fp:strict to --fno-fast-math
- /fp:precise to --fno-fast-math
Let's map them as follows:
- /fp:except to --ffp-exception-behavior=strict
- /fp:except- to --ffp-exception-behavior=ignore
- /fp:strict to --ffp-model=strict
- /fp:precise to --ffp-model=ignore
I believe the changes to /fp:except are technically a no-op but it makes
the mapping a lot clearer. The changes for /fp:strict and /fp:precise are not
no-ops, they now match MSVC's behavior.
While we are here, also add support for /fp:contract by mapping it to
-ffp-contract=on.
This patch does the following:
- Consumes the PIC flags (fPIC/fPIE/fropi/frwpi etc) in flang-new.
tools::ParsePICArgs() in ToolChains/CommonArgs.cpp is used for this.
- Adds FC1Option to "-mrelocation-model", "-pic-level", and "-pic-is-pie"
command line options.
- Adds the above options to flang/Frontend/CodeGenOptions' data structure.
- Sets the relocation model in the target machine, and
- Sets module flags for the respective PIC/PIE type in LLVM IR.
I have tried my best to replicate how clang does things.
Differential Revision: https://reviews.llvm.org/D131533
Change-Id: I68fe64910be28147dc5617826641cea71b92d94d
In preparation for allowing the prefer_type list in the append_args clause,
use the OMPInteropInfo in the attribute for 'declare variant'.
This requires adding a new Argument kind to the attribute code. This change
adds a specific attribute to pass an array of OMPInteropInfo. It implements
new tablegen needed to handle the interop-type part of the structure. When
prefer_type is added, more work will be needed to dump, instantiate, and
serialize the PreferTypes field in OMPInteropInfo.
Differential Revision: https://reviews.llvm.org/D132270
Before this patch, open-source clang would consider
`-target x86_64-apple-darwin -mios-simulator-version-min=11.0` as
targeting the iOS simulator, due to the mios flag informing it
that we want to target iOS, and logic in the driver then realizing
that x86 iOS builds must be the simulator.
However, for `-target arm64-apple-darwin -mios-simulator-version-min=11.0`
that didn't work and clang thought that it's building for actual iOS,
and not for the simulator.
Due to this, building compiler-rt for arm64 iossim would lead to
all .o files in RTSanitizerCommonSymbolizer.iossim.dir being built
for iOS instead of for iOS simulator, and clang would ask ld64 to
link for iOS, but using the iPhoneSimulator sysroot. This would then
lead to many warnings from ld64 looking like:
ld: warning: building for iOS, but linking in .tbd file
(.../iPhoneSimulator.sdk/usr/lib/libc++abi.tbd) built for iOS Simulator
Worse, with ld64.lld, this diagnostic is currently an error instead
of a warning.
This patch makes it so that the presence of -mios-simulator-version-min=
now informs clang that we're building for simulator. That way, all the
.o files are built for simulator, the linker is informed that we're
building for simulator, and everything Just Works.
(Xcode's clang already behaves like this, so this makes open-source clang
match Xcode clang.)
We can now likely remove the hack to treat non-mac darwin x86 as
simulator, but doing that feels slightly risky, so I'm leaving that
for a follow-up patch.
(This patch is made necessary by the existence of arm64 macs.)
Differential Revision: https://reviews.llvm.org/D132258
It was originally left off thinking the paper only impacts the C
standard library, but Clang supports diagnostics for incorrect use of
a format specifier, so this paper has some frontend impacts as well.
This patch makes it possible for lambdas, implicit copy/move ctors
and structured bindings to handle non-POD multidimensional arrays.
Differential Revision: https://reviews.llvm.org/D131840
Prior to this patch we handled lambda captures based on their
initializer expression, which resulted in pattern matching. With
C++17 copy elision the initializer expression can be anything,
and this approach proved to be fragile and a source of crashes.
This patch removes pattern matching and only checks whether the
object is under construction or not.
Differential Revision: https://reviews.llvm.org/D131944
Adds
* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__remove_all_extents`
* `__remove_extent`
* `__remove_const`
* `__remove_volatile`
* `__remove_cv`
* `__remove_pointer`
* `__remove_reference`
* `__remove_cvref`
These are all compiler built-in equivalents of the unary type traits
found in [[meta.trans]][1]. The compiler already has all of the
information it needs to answer these transformations, so we can skip
needing to make partial specialisations in standard library
implementations (we already do this for a lot of the query traits). This
will hopefully improve compile times, as we won't need use as much
memory in such a base part of the standard library.
[1]: http://wg21.link/meta.trans
Co-authored-by: zoecarver
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D116203
This has been officially deprecated since D112724, meaning the
deprecation warning is present in released 14 and 15.
This makes me think that now, shortly after the 15 release is branched,
is a good time to pull the trigger.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D132324
This adds a check for exported inline functions, that there is a definition in
the definition domain (which, in practice, can only be the module purview but
before any PMF starts) since the PMF definition domain cannot contain exports.
This is:
[dcl.inline]/7
If an inline function or variable that is attached to a named module is declared in
a definition domain, it shall be defined in that domain.
The patch also amends diagnostic output by excluding the PMF sub-module from the
set considered as sources of missing decls. There is no point in telling the user
that the import of a PMF object is missing - since such objects are never reachable
to an importer. We still show the definition (as unreachable), to help point out
this.
Differential Revision: https://reviews.llvm.org/D128328
Use this instead of `*_LIBDIR_SUFFIX`, from which it is computed.
This gets us ready for D130586, in which `*_LIBDIR_SUFFIX` is
deprecated.
Differential Revision: https://reviews.llvm.org/D132300
Adds a builtin that serves as an optimization hint to apply specific optimized
DAG mutations during scheduling. This also disables any other mutations or
clustering that may interfere with the desired pipeline. The first optimization
strategy that is added here is designed to improve the performance of small gemm
kernels on gfx90a.
Reviewed By: jrbyrnes
Differential Revision: https://reviews.llvm.org/D132079
Currently ExtractAPI only emits availability information for the
current platform. This makes it easy for clients to get all availability
information for a given symbol in one invocation as opposed to having to invoke
clang once per-platform and then merge the symbol-graphs.
Differential Revision: https://reviews.llvm.org/D130918
This reverts commit d483730d8c.
This allegedly breaks a significant part of facebooks internal build.
Reverting while we wait for them to provide a reproducer of this from
@wlei.
The hard float ABIs have a rule that if a flattened struct contains
either a single fp value, or an int+fp, or fp+fp then it may be passed
in a pair of registers (if sufficient GPRs+FPRs are available).
detectFPCCEligibleStruct and the helper it calls,
detectFPCCEligibleStructHelper examine the type of the argument/return
value to determine if it complies with the requirements for this ABI
rule.
As reported in bug #57084, this logic produces incorrect results for C++
structs that inherit from other structs. This is because only the fields
of the struct were examined, but enumerating RD->fields misses any
fields in inherited C++ structs. This patch corrects that issue by
adding appropriate logic to enumerate any included base structs.
Differential Revision: https://reviews.llvm.org/D131677
This patch adds a ProgramPointTag to the EpsilonPoint created
before we replay a call without inlining.
Differential Revision: https://reviews.llvm.org/D132246
The patch mainly focuses on the no warnings for -Wtautological-compare.
It work fine for the positive numbers but doesn't for the negative
numbers. This is because the warning explicitly checks for an
IntegerLiteral AST node, but -1 is represented by a UnaryOperator with
an IntegerLiteral sub-Expr.
Fixes#42918
Differential Revision: https://reviews.llvm.org/D130510
Implement negating and inverting values. Also implement
IntegralToBoolean casts so the operations are easier to test.
Differential Revision: https://reviews.llvm.org/D132098
Certain idioms are ignored by -Wunused in header files only.
The current "is a header" check assumes that if headers are the main file, we're
building a PCH or a module or something. However in tools we may be parsing the
header in its own right, but still want to treat it as a header.
Fixes https://github.com/clangd/vscode-clangd/issues/360
Differential Revision: https://reviews.llvm.org/D129642
This patch replaces svget, svset and svcreate aarch64 intrinsics for tuple
types with the generic llvm-ir intrinsics extract/insert vector
Differential Revision: https://reviews.llvm.org/D131547
Fix for the problem with displaying options `-fsyntax-only` in clang and flang-new in help
Fix https://github.com/llvm/llvm-project/issues/57033
Before:
``` $ clang -help | grep syntax
-objcmt-migrate-property-dot-syntax
Enable migration of setter/getter messages to property-dot syntax
```
After:
```
$ clang -help | grep syntax
-fsyntax-only Run the preprocessor, parser and semantic analysis stages
-objcmt-migrate-property-dot-syntax
Enable migration of setter/getter messages to property-dot syntax
```
Reviewed By: vzakhari, awarzynski, MaskRay, alexiprof
Differential Revision: https://reviews.llvm.org/D131808
The commit of af2d11b1d5 missed a case where
the value of a suggested module needed to be reset to nullptr. Fixed thus
and added a testcase to cover the circumstance.
Instead of complaining about default initialization, tell users that
constexpr variables need to be initialized by a constant expression.
Differential Revision: https://reviews.llvm.org/D131662
Owing to the large number of instantiations of this function, this small
change has a small but meaningful difference on the total size of
(especially a debug) build of clang at -O0:
```
FILE SIZE VM SIZE
-------------- --------------
+0.9% +96.9Ki +0.9% +96.9Ki .data.rel.ro
+0.7% +96.7Ki +0.7% +96.7Ki .rela.dyn
+0.0% +18.3Ki +0.0% +18.3Ki .rodata
+0.0% +324 [ = ] 0 [2 Others]
-0.2% -392 -0.2% -392 .gnu.version
-0.0% -441 [ = ] 0 .debug_abbrev
-0.1% -980 -0.1% -980 .gnu.hash
-0.2% -1.53Ki -0.2% -1.53Ki .hash
-0.2% -4.59Ki -0.2% -4.59Ki .dynsym
-0.1% -10.5Ki [ = ] 0 .debug_rnglists
-0.6% -59.0Ki -0.6% -59.0Ki .dynstr
-0.2% -191Ki [ = ] 0 .debug_str_offsets
-3.0% -233Ki -3.0% -233Ki .eh_frame_hdr
-0.7% -244Ki [ = ] 0 .debug_addr
-2.9% -699Ki [ = ] 0 .symtab
-0.6% -884Ki [ = ] 0 .debug_line
-3.0% -932Ki -3.0% -932Ki .eh_frame
-1.0% -1.48Mi -1.0% -1.48Mi .text
-0.6% -2.75Mi [ = ] 0 .debug_info
-7.3% -8.61Mi [ = ] 0 .strtab
-7.3% -17.2Mi [ = ] 0 .debug_str
-2.4% -33.0Mi -0.9% -2.47Mi TOTAL
```
If anyone's got other ideas for how to reduce this further - it's not
especially important, I just came across it while investigating a debug
info size regression, but thought it was interesting enough to poke
around at.
Currently, record arguments are always passed by reference by allocating
space for record values in the caller. This is less efficient for
small records which may take one or two registers. For example,
for x86_64 and aarch64, for a record size up to 16 bytes, the record
values can be passed by values directly on the registers.
This patch added BPF support of record argument with direct values
for up to 16 byte record size. If record size is 0, that record
will not take any register, which is the same behavior for x86_64
and aarch64. If the record size is greater than 16 bytes, the
record argument will be passed by reference.
Differential Revision: https://reviews.llvm.org/D132144
The 'init' clause allows an interop-modifier of prefer_type(list) and
and interop-types 'target' and 'targetsync'.
The 'append_args' clause uses an append-op that also includes
interop-types ('target' and 'targetsync') and will allow
a prefer_type list in the next OpenMP version.
This change adds a helper struct OMPInteropInfo and uses it in the parsing
of both the 'init' and 'append_args' clauses.
One OMPInteropInfo object represents the info in a single 'init' clause.
Since 'append_args' allows a variable number of interop items it will
require an array of OMPInteropInfo objects once that is supported.
Differential Revision: https://reviews.llvm.org/D132171
Using Max for both "PIC Level" and "PIE Level" is inconsistent. PIC imposes less
restriction while PIE imposes more restriction. The result generally
picks the more restrictive behavior: Min for PIC.
This choice matches `ld -r`: a non-pic object and a pic object merge into a
result which should be treated as non-pic.
To allow linking "PIC Level" using Error/Max from old bitcode files, upgrade
Error/Max to Min.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D130531
The previous implementation translated from names like sifive-7-series
to sifive-7-rv32 or sifive-7-rv64. This also required sifive-7-rv32
and sifive-7-rv64 to be valid CPU names. As those are not real
CPUs it doesn't make sense to accept them in -mcpu.
This patch does away with the translation and adds sifive-7-series
directly to RISCV.td. Removing sifive-7-rv32 and sifive-7-rv64.
sifive-7-series is only allowed in -mtune.
I've also added "rocket" to RISCV.td but have not removed rocket-rv32
or rocket-rv64.
To prevent -mcpu=sifive-7-series or -mcpu=rocket being used with llc,
I've added a Feature32Bit to all rv32 CPUs. And made it an error to
have an rv32 triple without Feature32Bit. sifive-7-series and rocket
do not have Feature32Bit or Feature64Bit set so the user would need
to provide -mattr=+32bit or -mattr=+64bit along with the -mcpu to
avoid the error.
SiFive no longer names their newer products with 3, 5, or 7 series.
Instead we have p200 series, x200 series, p500 series, and p600 series.
Following the previous behavior would require a sifive-p500-rv32 and
sifive-p500-rv64 in order to support -mtune=sifive-p500-series. There
is currently no p500 product, but it could start getting confusing if
there was in the future.
I'm open to hearing alternatives for how to achieve my main goal
of removing sifive-7-rv32/rv64 as a CPU name.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D131708
The DXC driver tests don't really belong mixed in with the toolchain
tests. This pulls them out to their own file and moves the
SimpleDiagnosticConsumer into a header so it can be used by both DXC and
toolchain tests.
fast-forwarded.
This patch adds OMPIRBuilder support for the safelen clause for the
simd directive.
Reviewed By: shraiysh, Meinersbur
Differential Revision: https://reviews.llvm.org/D131526
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
Add the clang option -finline-max-stacksize=<N> to suppress inlining
of functions whose stack size exceeds the given value.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D131986
This patch fixes a crash when trying to emit a constant compound literal.
For C++ Clang evaluates either casts or binary operations at translation time,
but doesn't pass on the InConstantContext information that was inferred when
parsing the statement. Because of this, strict FP evaluation (-ftrapping-math)
which shouldn't be in effect yet, then causes checkFloatingpointResult to return
false, which in tryEmitGlobalCompoundLiteral will trigger an assert that the
compound literal wasn't constant.
The discussion here around 'manifestly constant evaluated contexts' was very
helpful to me when trying to understand what LLVM's position is on what
evaluation context should be in effect, together with the explanatory text in
that patch itself:
https://reviews.llvm.org/D87528
Reviewed By: rjmccall, DavidSpickett
Differential Revision: https://reviews.llvm.org/D131555
We deferred the evaluation of dependent immediate invocations in https://reviews.llvm.org/D119375 until instantiation.
We should also not consider them referenced from a non-consteval context.
Fixes: https://github.com/llvm/llvm-project/issues/55601
```
template<typename T>
class Bar {
consteval static T x() { return 5; }
public:
Bar() : a(x()) {}
private:
int a;
};
Bar<int> g();
```
Is now accepted by clang. Previously it errored with: `cannot take address of consteval function 'x' outside of an immediate invocation Bar() : a(x()) {}`
Differential Revision: https://reviews.llvm.org/D132031
This implements support for using libc++ headers in MSVC toolchain.
We only support libc++ headers that are part of the toolchain, and
not headers installed elsewhere on the system.
Differential Revision: https://reviews.llvm.org/D101479
The restrictions added in D131704 were not sufficient to avoid all non-constant
expression contexts. In particular constant initialization cases.
We need to check EvaluatingDecl to detect if the variable we are initializing is
constexpr or not.
At this point it looks like this is the remaining case affecting various projects
with this diagnostic.
Differential Revision: https://reviews.llvm.org/D131874
In D131869 we noticed that we jump through some hoops because we parse the
tolerance option used in MisExpect.cpp into a 64-bit integer. This is
unnecessary, since the value can only be in the range [0, 100).
This patch changes the underlying type to be 32-bit from where it is
parsed in Clang through to it's use in LLVM.
Reviewed By: jloser
Differential Revision: https://reviews.llvm.org/D131935
This reverts commit 258c3aee54.
This should fix the libc++ issue that caused the revert, by re-designing
slightly how we determined when we should evaluate the constraints.
Additionally, many of the other components to the original patch (the
NFC parts) were committed separately to shrink the size of this patch
for review.
Differential Revision: https://reviews.llvm.org/D126907
If directory for config files was specified in project configuration
using parameters CLANG_CONFIG_FILE_SYSTEM_DIR or CLANG_CONFIG_FILE_USER_DIR,
it was not overriden by command-line option `--config-system-dir=` or
`--config-user-dir=` that specified empty path.
This change corrects the behavior. It fixes the issue
https://github.com/llvm/llvm-project/issues/56836 ([clang] [test]
test/Driver/config-file-errs.c fails if CLANG_CONFIG_FILE_SYSTEM_DIR is
specified).
The https://reviews.llvm.org/D53014 added CMAKE_BUILD_TYPE to
the list of BOOTSTRAP_DEFAULT_PASSTHROUGH variables.
The downside is that both stage-1 and stage-2 configurations
are the same. So it is not possible to build different stage
configurations.
This patch allow explicit bootstrap options to override any
passthrough ones.
For instance, the following settings would build:
stage-1 (Release) and stage-2(Debug)
-DCMAKE_BUILD_TYPE=Release -DBOOTSTRAP_CMAKE_BUILD_TYPE=Debug
Reviewed By: @beanz
Differential Revision: https://reviews.llvm.org/D131755
Seems this complicated lldb sufficiently for some cases that it hasn't
been worth supporting/fixing there - and it so far hasn't provided any
new use cases/value for debug info consumers, so let's remove it until
someone has a use case for it.
(side note: the original implementation of this still had a bug (I
should've caught it in review) that we still didn't produce
auto-returning function declarations in types where the function wasn't
instantiatied (that requires a fix to remove the `if
getContainedAutoType` condition in
`CGDebugInfo::CollectCXXMemberFunctions` - without that, auto returning
functions were still being handled the same as member function templates
and special member functions - never added to the member list, only
attached to the type via the declaration chain from the definition)
Further discussion about this in D123319
This reverts commit 5ff992bca208a0e37ca6338fc735aec6aa848b72: [DEBUG-INFO] Change how we handle auto return types for lambda operator() to be consistent with gcc
This reverts commit c83602fdf51b2692e3bacb06bf861f20f74e987f: [DWARF5][clang]: Added support for DebugInfo generation for auto return type for C++ member functions.
Differential Revision: https://reviews.llvm.org/D131933
Currently bpf supports calling kernel functions (x86_64, arm64, etc.)
in bpf programs. Tejun discovered a problem where the x86_64 func
return value (a unsigned char type) is stored in 8-bit subregister %al
and the other 56-bits in %rax might be garbage. But based on current
bpf ABI, the bpf program assumes the whole %rax holds the correct value
as the callee is supposed to do necessary sign/zero extension.
This mismatch between bpf and x86_64 caused the incorrect results.
To resolve this problem, this patch forced caller to do needed
sign/zero extension for 8/16-bit return values as well. Note that
32-bit return values already had sign/zero extension even without
this patch.
For example, for the test case attached to this patch:
$ cat t.c
_Bool bar_bool(void);
unsigned char bar_char(void);
short bar_short(void);
int bar_int(void);
int foo_bool(void) {
if (bar_bool() != 1) return 0; else return 1;
}
int foo_char(void) {
if (bar_char() != 10) return 0; else return 1;
}
int foo_short(void) {
if (bar_short() != 10) return 0; else return 1;
}
int foo_int(void) {
if (bar_int() != 10) return 0; else return 1;
}
Without this patch, generated call insns in IR looks like:
%call = call zeroext i1 @bar_bool()
%call = call zeroext i8 @bar_char()
%call = call signext i16 @bar_short()
%call = call i32 @bar_int()
So it is assumed that zero extension has been done for return values of
bar_bool()and bar_char(). Sign extension has been done for the return
value of bar_short(). The return value of bar_int() does not have any
assumption so caller needs to do necessary shifting to get correct
32bit values.
With this patch, generated call insns in IR looks like:
%call = call i1 @bar_bool()
%call = call i8 @bar_char()
%call = call i16 @bar_short()
%call = call i32 @bar_int()
There are no assumptions for return values of the above four function calls,
so necessary shifting is necessary for all of them.
The following is the objdump file difference for function foo_char().
Without this patch:
0000000000000010 <foo_char>:
2: 85 10 00 00 ff ff ff ff call -1
3: bf 01 00 00 00 00 00 00 r1 = r0
4: b7 00 00 00 01 00 00 00 r0 = 1
5: 15 01 01 00 0a 00 00 00 if r1 == 10 goto +1 <LBB1_2>
6: b7 00 00 00 00 00 00 00 r0 = 0
0000000000000038 <LBB1_2>:
7: 95 00 00 00 00 00 00 00 exit
With this patch:
0000000000000018 <foo_char>:
3: 85 10 00 00 ff ff ff ff call -1
4: bf 01 00 00 00 00 00 00 r1 = r0
5: 57 01 00 00 ff 00 00 00 r1 &= 255
6: b7 00 00 00 01 00 00 00 r0 = 1
7: 15 01 01 00 0a 00 00 00 if r1 == 10 goto +1 <LBB1_2>
8: b7 00 00 00 00 00 00 00 r0 = 0
0000000000000048 <LBB1_2>:
9: 95 00 00 00 00 00 00 00 exit
The zero extension of the return 'char' value is done here.
Differential Revision: https://reviews.llvm.org/D131598
Add initial support for NonNull attribute.
(https://github.com/llvm/llvm-project/issues/57113)
Test plan:
verify that for
__thread int x;
int main() {
int* y = &x;
return *y;
}
(with this patch) clang -O -fsanitize=null -S -emit-llvm -o -
doesn't emit a null-pointer check
Differential revision: https://reviews.llvm.org/D131872
When aliasing a static array, the aliasee is going to be a GEP which
points to the value. We should strip pointer casts before forming the
reference. This was occluded by the use of opaque pointers.
This problem has existed since the introduction of the debug info
generation for aliases in b1ea0191a4. The
test case would assert due to the invalid cast with or without
`-no-opaque-pointers` at that revision.
Fixes: #57179
Instead of delaying the generation of command-lines to after all
dependencies are reported, compute them immediately. This is partly in
preparation for splitting the TU driver command into its constituent cc1
and other jobs, but it also just simplifies working with the compiler
invocation for modules if they are not "without paths".
Also change the computation of the default output path in
clang-scan-deps to scrape the implicit module cache from the
command-line rather than get it from the dependency, since that is now
unavailable at the time we make the callback.
Differential Revision: https://reviews.llvm.org/D131934
I accidentally broke friend destructor declarations in D130936.
Modify it to skip performing the destructor name check if we have a dependent friend declaration.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D131541
Currently we treat initializers with init_seg(compiler/lib) as similar
to any other init_seg, they simply have a global variable in the proper
section (".CRT$XCC" for compiler/".CRT$XCL" for lib) and are added to
llvm.used. However, this doesn't match with how LLVM sees normal (or
init_seg(user)) initializers via llvm.global_ctors. This
causes issues like incorrect init_seg(compiler) vs init_seg(user)
ordering due to GlobalOpt evaluating constructors, and the
ability to remove init_seg(compiler/lib) initializers at all.
Currently we use 'A' for priorities less than 200. Use 200 for
init_seg(compiler) (".CRT$XCC") and 400 for init_seg(lib) (".CRT$XCL"),
which do not append the priority to the section name. Priorities
between 200 and 400 use ".CRT$XCC${Priority}". This allows for
some wiggle room for people/future extensions that want to add
initializers between compiler and lib.
Fixes#56922
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D131910
I introduced a patch to handle unqualified templated base class
initialization in MSVC compatibility mode:
https://reviews.llvm.org/rGc894e85fc64dd8d83b460de81080fff93c5ca334
We identified a problem with this patch in the case where the base class
is partially specialized, which can lead to triggering an assertion in
the case of a mix between types and values.
The minimal test case is:
template <typename Type, int TSize> class Vec {};
template <int TDim> class Index : public Vec<int, TDim> {
Index() : Vec() {}
};
template class Index<0>;
The detailed problem is that I was using the
`InjectedClassNameSpecialization`, to which the class template arguments
were then applied in order. But in the process, we were losing all the
partial specializations of the base class and creating an index mismatch
between the expected and passed arguments.
Patch By: frederic-tingaud-sonarsource
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D130709
Newer SDKs don't even provide libstdc++ headers, so it's effectively
never valid to build for libstdc++ unless the user explicitly asks
for it (in which case they will need to provide include paths and more).
This is a re-application of c5ccb78ade which had been reverted in
33171df9cc because it broke the Fuchsia CI bots. The issue was that
the test was XPASSing because it didn't fail anymore when the
CLANG_DEFAULT_CXX_LIB was set to libc++, which seems to be done for
Fuchsia. Instead, the test only fails if CLANG_DEFAULT_CXX_LIB is
set to libstdc++.
As a fly-by fix, also adjust the triple used by various tests to
something that is supported. Those tests were shown to fail on
internal bots.
Differential Revision: https://reviews.llvm.org/D131274
This fixes some fallout from D131282. Currently, add_tablegen() will add the tablegen target to LLVM_EXPORTS and associates the install with LLVMExports. For non-standalone builds, this means that you end up with mlir-tblgen and clang-tblgen in LLVMExports.
However, these projects should instead be using MLIR_EXPORTS/MLIRTargets and CLANG_EXPORTS/ClangTargets. To fix this, add an extra EXPORT option and make use of get_target_export_arg() to create the correct export argument.
Reviewed By: ashay-github
Differential Revision: https://reviews.llvm.org/D131565
- Modify TokenAnnotator to work fine with java-style array declarations.
- Add test for aligning of java declarations.
Fixes#55931.
Differential Revision: https://reviews.llvm.org/D129628
This patch adds a `Depth` field (default value 2) to `ContextSensitiveOptions`, allowing context-sensitive analysis of functions that call other functions. This also requires replacing the `DeclCtx` field on `Environment` with a `CallString` field that contains a vector of decl contexts, to ensure that the analysis doesn't try to analyze recursive or mutually recursive calls (which would result in a crash, due to the way we handle `StorageLocation`s).
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D131809
The point of a constexpr if statement is to determine which branch to
take at compile time, so warning on unreachable code is meaningless in
these situations.
Fixes#57123.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D131818
When expanding undeclared function parameters, we should initialize
the original number of expansions, if known, before trying to expand
them, otherwise a length mismatch with an outer pack might not be
diagnosed.
Fixes PR56094.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D131802
DR692 handles two cases: pack expansion (for class/var template) and function parameter pack. The former needs DR1432 as a fix, and the latter needs DR1395 as a fix. However, DR1432 has not yet made a wording change. so I made a tentative fix for DR1432 with the same spirit as DR1395.
Reviewed By: aaron.ballman, erichkeane, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D128745
DiagnoseNullConversion is needlessly calling isNullPointerConstant which
is an expensive routine due to its calls to a constant evaluator --
which we don't need.
Building the Linux Kernel (x86_64) with this fix has improved build
times by ~2.1%. This is mainly due to the following methods no longer
needing to be called anywhere near as often:
1) ExprConstant::CheckICE (reduced CPU cycles by ~90%)
2) IntExprEvaluator::VisitBinaryOperator (reduced CPU cycles by ~50%)
Reviewed By: rtrieu, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D131532
This patch fixes:
clang/lib/Sema/SemaType.cpp:9469:3: error: default label in switch
which covers all enumeration values
[-Werror,-Wcovered-switch-default]
Adds
* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__remove_all_extents`
* `__remove_extent`
* `__remove_const`
* `__remove_volatile`
* `__remove_cv`
* `__remove_pointer`
* `__remove_reference`
* `__remove_cvref`
These are all compiler built-in equivalents of the unary type traits
found in [[meta.trans]][1]. The compiler already has all of the
information it needs to answer these transformations, so we can skip
needing to make partial specialisations in standard library
implementations (we already do this for a lot of the query traits). This
will hopefully improve compile times, as we won't need use as much
memory in such a base part of the standard library.
[1]: http://wg21.link/meta.trans
Co-authored-by: zoecarver
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D116203
Found during clang 15 RC1 testing due to the new diagnostic added by @royjacobson since clang 14. Uncertain if this fix meets the bar to also be applied to the release branch.
If accepted, I'll need someone with commit access to submit on my behalf.
Reviewed By: royjacobson, aaron.ballman, erichkeane
Differential Revision: https://reviews.llvm.org/D131730
Currently, the field just emit map info for this pointer variable. It is
failed at run time. For the fields, the PartialStruct is created and it
needs call to emitCombinedEntry which create the base that covers all
the pieces.
The change is to generate map info as regular fields.
Differential Revision: https://reviews.llvm.org/D129608
In Android API < 30 there is no HWAsan instrumentation support for globals
so the test fails if API < 30 or if the target triple does not specify the API version.
Add -triple=aarch64-linux-android31 to enable global instrumentation. This is the
same triple as is used in the RUN line for -fsanitize=memtag-globals.
Differential Revision: https://reviews.llvm.org/D131806
Change-Id: I300703bd126b10e3c52505e23c78c5a48acb0309
Inside `ExprEngine::VisitLambdaExpr()` we wasn't prepared for a
copy elided initialized capture's `InitExpr`. This patch teaches
the analyzer how to handle such situation.
Differential Revision: https://reviews.llvm.org/D131784
This patch restructures `DataflowAnalysisOptions` and `TransferOptions` to use `llvm::Optional`, in preparation for adding more sub-options to the `ContextSensitiveOptions` struct introduced here.
Reviewed By: sgatev, xazax.hun
Differential Revision: https://reviews.llvm.org/D131779
Before this patch type traits are checked in Parser, so use type traits
directly did not cause assertion faults. However if type traits are initialized
from a template, we didn't perform arity checks before evaluating. This
patch moves arity checks from Parser to Sema, and performing arity
checks in Sema actions, so type traits get checked corretly.
Crash input:
```
template<class... Ts> bool b = __is_constructible(Ts...);
bool x = b<>;
```
After this patch:
```
clang/test/SemaCXX/type-trait-eval-crash-issue-57008.cpp:5:32: error: type trait requires 1 or more arguments; have 0 arguments
template<class... Ts> bool b = __is_constructible(Ts...);
^~~~~~~~~~~~~~~~~~
clang/test/SemaCXX/type-trait-eval-crash-issue-57008.cpp:6:10: note: in instantiation of variable template specialization 'b<>' requested here
bool x = b<>;
^
1 error generated.
```
See https://godbolt.org/z/q39W78hsK.
Fixes https://github.com/llvm/llvm-project/issues/57008
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D131423
This fixes compilation errors in the following code with
latest libc++ and libstdc++:
```cpp
int main() {
std::tuple<std::string> s;
std::tuple<std::string_view> sv;
s < sv;
}
```
See https://gcc.godbolt.org/z/vGvEhxWvh for the error.
This used to happen because repeated template instantiations during
C++20 constraint satisfaction will cause a call to `RebuildCXXRewrittenBinaryOperator`
with `PerformADL` set to false, see 59351fe340/clang/lib/Sema/TreeTransform.h (L2737)
Committing urgently to unbreak breakages we see in our configurations.
The change seems relatively safe and the right thing to do.
However, I will follow-up with tests and investigation on whether we
need to do this extra semantic checking in the first place next week.
STLForwardCompat.h defines several utilities and type traits to mimic that of
the ones in the C++17 standard library. Now that LLVM is built with the C++17
standards mode, remove use of these equivalents in favor of the ones from the
standard library.
Differential Revision: https://reviews.llvm.org/D131717
arm_sve.h defines and uses __ai macro which needs to be undefined (as it is
already in arm_neon.h).
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D131580
Followup patch for D128083
Previously, using a non-consteval constructor from an consteval constructor would code generates the consteval constructor.
Example
```
template <typename T>
struct S {
T i;
consteval S() = default;
};
struct Foo {
Foo() {}
};
void func() {
S<Foo> three; // incorrectly accepted by clang.
}
```
This happened because clang erroneously disregards `consteval` specifier for a `consteval explicitly defaulted special member functions in a class template` if it has dependent data members without a `consteval default constructor`.
According to
```
C++14 [dcl.constexpr]p6 (CWG DR647/CWG DR1358):
If the instantiated template specialization of a constexpr function
template or member function of a class template would fail to satisfy
the requirements for a constexpr function or constexpr constructor, that
specialization is still a constexpr function or constexpr constructor,
even though a call to such a function cannot appear in a constant
expression.
```
Therefore the `consteval defaulted constructor of a class template` should be considered `consteval` even if the data members' default constructors are not consteval.
Keeping this constructor `consteval` allows complaining while processing the call to data member constructors.
(Same applies for other special member functions).
This works fine even when we have more than one default constructors since we process the constructors after the templates are instantiated.
This does not address initialization issues raised in
[2602](https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2602) and compiler divergence seen in https://godbolt.org/z/va9EMvvMe
Fixes: https://github.com/llvm/llvm-project/issues/51593
Differential Revision: https://reviews.llvm.org/D131479
Closing https://github.com/llvm/llvm-project/issues/56329
The problem happens when we try to simplify the suspend points. We might
break the assumption that the final suspend lives in the last slot of
Shape.CoroSuspends. This patch tries to main the assumption and fixes
the problem.
Closing https://github.com/llvm/llvm-project/issues/56826.
The root cause for pr56826 is: when we collect the template args for the
friend, we need to judge if the friend lives in file context. However,
if the friend lives in ExportDecl lexically, the judgement here is
invalid.
The solution is easy. We should judge the non transparent context and
the ExportDecl is transparent context. So the solution should be good.
A main concern may be the patch doesn't handle all the places of the
same defect. I think it might not be bad since the patch itself should
be innocent.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D131651
The `File` might point to an invalid `FileID` when the AST is broken. That leads to clang/clangd crashes while processing comments. The relevant part of the crash is below
```
#4 0x00007f1d7fbf95bc std::_Rb_tree<unsigned int, std::pair<unsigned int const, clang::RawComment*>, std::_Select1st<std::pair<unsigned int const, clang::RawComment*>>, std::less<unsigned int>, std::allocator<std::pair<unsigned int const
, clang::RawComment*>>>::_M_lower_bound(std::_Rb_tree_node<std::pair<unsigned int const, clang::RawComment*>> const*, std::_Rb_tree_node_base const*, unsigned int const&) const /usr/include/c++/8/bits/stl_tree.h:1911:2
#5 0x00007f1d7fbf95bc std::_Rb_tree<unsigned int, std::pair<unsigned int const, clang::RawComment*>, std::_Select1st<std::pair<unsigned int const, clang::RawComment*>>, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, clang::RawComment*>>>::lower_bound(unsigned int const&) const /usr/include/c++/8/bits/stl_tree.h:1214:56
#6 0x00007f1d7fbf95bc std::map<unsigned int, clang::RawComment*, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, clang::RawComment*>>>::lower_bound(unsigned int const&) const /usr/include/c++/8/bits/stl_map.h:1264:36
#7 0x00007f1d7fbf95bc clang::ASTContext::getRawCommentForDeclNoCacheImpl(clang::Decl const*, clang::SourceLocation, std::map<unsigned int, clang::RawComment*, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, clang::RawComment*>>> const&) const /home/ivanmurashko/local/llvm-project/clang/lib/AST/ASTContext.cpp:226:57
```
The corresponding LIT test that reproduces the crash was also added
Same issue is described at https://bugs.llvm.org/show_bug.cgi?id=49707
Reviewed By: gribozavr2
Differential Revision: https://reviews.llvm.org/D131675
Ok it looks like this is a bit more subtle, I broke the llvm-test-suite file
paq8p.cpp again. We need both conditions to be true Info.EvalMode ==
EvalInfo::EM_ConstantExpression && Info.InConstantContext. We need to be in a
context that requires a constant value but also in a constant expression context.
Differential Revision: https://reviews.llvm.org/D131704
In D131528 using Info.EvalMode == EvalInfo::EM_ConstantExpression is not strict
enough to restrict the diagnostic to only constant expression contexts. It is
sometimes set in cases where we are still determining if we are in a constant
expression context.
Using InConstantContext will tighten the restriction.
Differential Revision: https://reviews.llvm.org/D131704
Clang currently crashes when lowering a consteval list initialization
of a temporary. This is partially working around an issue in the
template instantiation code (TreeTransform::TransformCXXTemporaryObjectExpr())
that does not yet know how to handle list initialization of temporaries
in all cases. However, it's also helping reduce fragility by ensuring
we always have a valid QualType when trying to emit a constant
expression during IR generation.
Fixes#55871
Differential Revision: https://reviews.llvm.org/D131194
Instead of having separate implementations for RV32 and RV64,
use the triple to control the Is64Bit parameter.
Do the same for isValidTuneCPUName, fillValidCPUList, and
fillValidTuneCPUList.
Previously a diagnostic was given if the expression was not strictly a
DeclRef. Now also allow use of data members inside member functions.
Differential Revision: https://reviews.llvm.org/D131222
As mentioned on D128934 - we weren't including the CPUID bit handling for the RDPRU instruction
AMD's APMv3 (24594) lists it as CPUID Fn8000_0008_EBX Bit#4
This encapsulates 3 changes:
- `DotDumpVisitor` now aggregates strings instead of *bytes* for both
`python2` and `python3`. This difference caused crashes when it tried
to write out the content as *strings*, similarly described at D71746.
- `graphviz.pipe()` expects the input in *bytes* instead of unicode
strings. And it results in *bytes*. Due to string concatenations and
similar operations, I'm using unicode string as the default, and
converting to *bytes* on demand.
- `write_temp_file()` now appends the `egraph-` prefix and more
importantly, it will create the temp file in the **current working
directory** instead of in the *temp*. This change makes `Firefox` be
able to open the file even if the `security.sandbox.content.level` is
set to the (default) most restricting `4`.
See https://support.mozilla.org/si/questions/1259285
An artifact of the bad byte handling was previously in the `HTML`
produced by the script that it displayed the `b'` string at the top left
corner. Now it won't anymore :)
I've tested that the following command works on `Ubuntu 22.04`:
```
exploded-graph-rewriter my-egraph.dot
```
Both `python2` and `python3` works as expected.
PS: I'm not adding tests, as the current test infra does not support
testing HTML outputs for this script.
Check the `clang/test/Analysis/exploded-graph-rewriter/lit.local.cfg`.
We always pass the `--dump-dot-only` flag to the script.
Along with that, the default invocation will not only create this HTML
report but also try to open it. In addition to this, I'm not sure if the
buildbots have `graphviz` installed and also if this package is installed
on `pip`.
Unless we change some of these, we cannot test this change.
Given that D71746 had no tests, I'm not too worried about this either.
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D131553
The __ARM_FEATURE_SVE_VECTOR_OPERATORS macro should be changed to
indicate that this feature is now supported on VLA vectors as well as
VLS vectors. There is a complementary PR to the ACLE spec here
https://github.com/ARM-software/acle/pull/213
Reviewed By: peterwaller-arm
Differential Revision: https://reviews.llvm.org/D131573
Previously the table in LanguageExtensions said that sizeof worked on
SVE types but this is only correct for fixed-length vectors so a
clarification has been added.
This patch modifies `Environment`'s `pushCall` method to pass over arguments that are missing storage locations, instead of crashing.
Reviewed By: gribozavr2
Differential Revision: https://reviews.llvm.org/D131600
This patch adds the ability to context-sensitively analyze constructor bodies, by changing `pushCall` to allow both `CallExpr` and `CXXConstructExpr`, and extracting the main context-sensitive logic out of `VisitCallExpr` into a new `transferInlineCall` method which is now also called at the end of `VisitCXXConstructExpr`.
Reviewed By: ymandel, sgatev, xazax.hun
Differential Revision: https://reviews.llvm.org/D131438
This should help address a build failure found after
09117b2189
../tools/clang/lib/Sema/SemaDeclCXX.cpp: In member function void clang::Sema::DiagnoseStaticAssertDetails(const clang::Expr*):
../tools/clang/lib/Sema/SemaDeclCXX.cpp:16666:19: error: declaration of const clang::Expr* clang::Sema::DiagnoseStaticAssertDetails(const clang::Expr*)::<unnamed struct>::Expr changes meaning of Expr [-fpermissive]
16666 | const Expr *Expr;
| ^~~~
In file included from ../tools/clang/include/clang/AST/DeclCXX.h:22,
from ../tools/clang/include/clang/AST/ASTLambda.h:18,
from ../tools/clang/lib/Sema/SemaDeclCXX.cpp:15:
../tools/clang/include/clang/AST/Expr.h:109:7: note: Expr declared here as class clang::Expr
109 | class Expr : public ValueStmt {
| ^~~~
At the moment, Clang only considers errno when deciding if a builtin
is const. This ignores the fact that some library functions may raise
floating point exceptions, which may modify global state, e.g. when
updating FP status registers.
To model the fact that some library functions/builtins may raise
floating point exceptions, this patch adds a new 'g' modifier for
builtins. If a builtin is marked with 'g', it cannot be considered
const, unless FP exceptions are ignored.
So far I've not added CHECK lines for all calls in math-libcalls.c. I'll
do that once we agree on the overall direction.
A consequence seems to be that we fail to select some of the constrained
math builtins now, but I am not entirely sure what's going on there.
Reviewed By: john.brawn
Differential Revision: https://reviews.llvm.org/D129231
This fixes the following warnings produced by GCC 9:
In file included from ../tools/clang/include/clang/Sema/ExternalSemaSource.h:15,
from ../tools/clang/include/clang/Sema/HLSLExternalSemaSource.h:17,
from ../tools/clang/lib/Sema/HLSLExternalSemaSource.cpp:12:
../tools/clang/include/clang/AST/ExternalASTSource.h:211:16: warning: ‘virtual void clang::ExternalASTSource::CompleteType(clang::ObjCInterfaceDecl*)’ was hidden [-Woverloaded-virtual]
211 | virtual void CompleteType(ObjCInterfaceDecl *Class);
| ^~~~~~~~~~~~
In file included from ../tools/clang/lib/Sema/HLSLExternalSemaSource.cpp:12:
../tools/clang/include/clang/Sema/HLSLExternalSemaSource.h:49:8: warning: by virtual void clang::HLSLExternalSemaSource::CompleteType(clang::TagDecl*)’ [-Woverloaded-virtual]
49 | void CompleteType(TagDecl *Tag) override;
| ^~~~~~~~~~~~
Differential Revision: https://reviews.llvm.org/D130969
For failed static assertions, try to take the expression apart and print
useful information about why it failed. In particular, look at binary
operators and print the compile-time evaluated value of the LHS/RHS.
Differential Revision: https://reviews.llvm.org/D130894
Right now we can only add a single warning, notes are not possible.
Apparently some provisions were made to allow notes, but they were never
propagated all the way to the diagnostics.
Differential Revision: https://reviews.llvm.org/D128807
When --staged (or --cached) use the index for formatting as well, not just
for the line numbers to format. Without this change git-clang-format gets
the changed line numbers based on the index, but then formats these lines on
the working tree version of the file.
This is a problem when the working tree and index differ. One common case
would be (and is the motivation behind this patch) when applying the
suggested changes git-clang-format --staged, then forgetting to add the
applied changes. When git-clang-format --staged --diff is used in a
pre-commit hook in this scenario, then the hook would allow committing the
improperly formatted changes, as the file is correctly formatted in the work
tree.
Fixes#56797.
Differential Revision: https://reviews.llvm.org/D130108
When clang includes a PCH, it tolerates some amount of differences
between the defines used when creating and when including the PCH
- this seems to be intentionally allowed in
c379c07240 (and later extended in
b636875196).
When using a PCH (or when picking a PCH out of a directory containing
multiple candidates) Clang used to accept the header if there were
defines on the command line when creating the PCH that are missing
when using the PCH, or vice versa, defines only set when using the
PCH.
The only cases where Clang explicitly rejected the use of a PCH
is if there was an explicit conflict between the options, e.g.
-DFOO=1 vs -DFOO=2, or -DFOO vs -UFOO.
The latter commit added a FIXME that we really should check whether
mismatched defines actually were used somewhere in the PCH, so that
the define would affect the outcome. This FIXME has stood unaddressed
since 2012.
This differs from GCC, which rejects PCH files if the defines differ
at all.
When explicitly including a single PCH file, the relaxed policy
of allowing minor differences is harmless for correct use cases
(but may fail to diagnose mismtaches), and potentially allow using
PCHs in wider cases (where the user intentionally know that the
differences in defines are harmless for the PCH).
However, for GCC style PCH directories, with a directory containing
multiple PCH variants and the compiler should pick the correct match
out of them, Clang's relaxed logic was problematic. The directory
could contain two otherwise identical PCHs, but one built with -DFOO
and one without. When attempting to include a PCH and iterating over
the candidates in the directory, Clang would essentially pick the
first one out of the two, even if there existed a better, exact
match in the directory.
Keep the relaxed checking when specificlly including one named
PCH file, but require strict matches when trying to pick the right
candidate out of a GCC style directory with alternatives.
This fixes https://github.com/lhmouse/mcfgthread/issues/63.
Differential Revision: https://reviews.llvm.org/D126676
Since D129389 (and downstream PR https://github.com/apple/llvm-project/pull/4965), the dependency scanner is responsible for generating full command-lines, including the modules paths. This patch removes the flag that was making this an opt-in behavior in clang-scan-deps.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D131420
In D131307 we allowed the diagnostic to be turned into a warning for a
transition period.
This had the side effect of triggering the warning in contexts not required to
be constant expression. This change will restrict the diagnostic to constant
expression contexts. This should reduce the fallout of this diagnostic.
Differential Revision: https://reviews.llvm.org/D131528
Implicitly converting between incompatible function pointers in C is
currently a default-on warning (it is an error in C++). However, this
is very poor security posture. A mismatch in parameters or return
types, or a mismatch in calling conventions, etc can lead to
exploitable security vulnerabilities. Rather than allow this unsafe
practice with a warning, this patch strengthens the warning to be an
error (while still allowing users the ability to disable the error or
the warning entirely to ease migration). Users should either ensure the
signatures are correctly compatible or they should use an explicit cast
if they believe that's more reasonable.
Differential Revision: https://reviews.llvm.org/D131351
This patch modifies `Environment`'s `pushCall` method to pass over arguments that are missing storage locations, instead of crashing.
Reviewed By: gribozavr2
Differential Revision: https://reviews.llvm.org/D131600
Summary: Cover `ConstraintAssignor::assign(EquivalenceClass, RangeSet)` function with more regression tests.
Differential Revision: https://reviews.llvm.org/D131514
Refactor baremetal driver code to reduce the bespoke
additions and base class overrides.
This lets us use the per target runtimes like other clang
targets. E.g. clang -target armv7m-cros-none-eabi will now
be able to use the runtimes installed at
<resource_dir>/lib/armv7m-cros-none-eabi instead of the hardcoded
path <resource_dir>/lib/baremetal.
The older code paths should still continue to work as before if
<resource_dir>/lib/<tuple> does not exist.
Reviewed By: MaskRay, barannikov88
Differential Revision: https://reviews.llvm.org/D131225
There is a fix for the search procedure at `SourceManager::getFileIDLoaded`. It might return an invalid (not loaded) entry. That might cause clang/clangd crashes. At my case the scenario was the following:
- `SourceManager::getFileIDLoaded` returned an invalid file id for a non loaded entry and incorrectly set `SourceManager::LastFileIDLookup` to the value
- `getSLocEntry` returned `SourceManager::FakeSLocEntryForRecovery` introduced at [D89748](https://reviews.llvm.org/D89748).
- The result entry is not tested at `SourceManager::isOffsetInFileID`and as result the call `return SLocOffset < getSLocEntryByID(FID.ID+1).getOffset();` returned `true` value because `FID.ID+1` pointed to a non-fake entry
- The tested offset was marked as one that belonged to the fake `SLockEntry`
Such behaviour might cause a weird clangd crash when preamble contains some header files that were removed just after the preamble created. Unfortunately it's not so easy to reproduce the crash in the form of a LIT test thus I provided the fix only.
Test Plan:
```
ninja check-clang
```
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D130847
Previously the language extension documentation didn't mention SVE and
was incomplete in listing the C/C++ operators supported on NEON. This
corrects the documentation to be in line with the implementation.
This patch adds the ability to context-sensitively analyze constructor bodies, by changing `pushCall` to allow both `CallExpr` and `CXXConstructExpr`, and extracting the main context-sensitive logic out of `VisitCallExpr` into a new `transferInlineCall` method which is now also called at the end of `VisitCXXConstructExpr`.
Reviewed By: ymandel, sgatev, xazax.hun
Differential Revision: https://reviews.llvm.org/D131438
Given that we provide an EditGenerator edit(ASTEdit), we can't ever be
sure that the user won't give us an empty replacement.
Differential Revision: https://reviews.llvm.org/D128887
A one-bit signed bit-field can only hold the values 0 and -1; this
corrects the diagnostic behavior accordingly.
Fixes#53253
Differential Revision: https://reviews.llvm.org/D131255
As was observed in https://reviews.llvm.org/D123627#3707635, it's
confusing that a user can write:
```
float rintf(void) {}
```
and get a warning, but writing:
```
float rintf() {}
```
gives an error. This patch changes the behavior so that both are
warnings, so that users who have functions which conflict with a
builtin identifier can still use that identifier as they wish.
Differential Revision: https://reviews.llvm.org/D131499
Earlier, if the QualType was sugared, then we would error out
as it was not a pointer type, for example,
typedef int *int_star;
int_star __ptr32 p;
Now, if ptr32 is given we apply it if the raw Canonical Type
(i.e., the desugared type) is a PointerType, instead of only
checking whether the sugared type is a pointer type.
As before, we still disallow ptr32 usage if the pointer is used
as a pointer to a member.
Differential Revision: https://reviews.llvm.org/D130123
ASTImporter used to crash in some cases when a function is imported with
`auto` return type and the return type has references into the function.
The handling of such cases is improved and crash should not occur any more
but it is not fully verified, there are very many different types of
cases to care for.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D130705
MapEntryOptionalStorage is an underlying storage class for
OptionalStorage<clang::DirectoryEntryRef>.
This patch deprecates:
OptionalStorage<clang::DirectoryEntryRef>::hasValue
OptionalStorage<clang::DirectoryEntryRef>::getValue
as there is no known users of these two methods.
Differential Revision: https://reviews.llvm.org/D131368
Driver options taking a value typically use `=` as the separator, instead of a
space. Unfortunately many older driver options do not stick with the rule, but I
find -Xclang used a lot and will be convenient if -Xclang= exists.
For build systems using a string array instead of a string to indicate compiler options,
`["-Xclang=-foo"]` is more convenient than `["-Xclang", "-foo"]`.
If a tool wants to filter out -Xclang=-foo, it is trivial for the `=` form, but
complex for the space separated form.
Reviewed By: jhuber6
Differential Revision: https://reviews.llvm.org/D131455
In D130058 we diagnose the undefined behavior of setting the value outside the
range of the enumerations values for an enum without a fixed underlying type.
Based on feedback we will provide users to the ability to downgrade this
diagnostic to a waring to allow for a transition period. We expect to turn this
diagnostic to an error in the next release.
Differential Revision: https://reviews.llvm.org/D131307
Sharing the FileManager across implicit module builds currently leaks
paths looked up in an importer into the built module itself. This can
cause non-deterministic results across scans. It is especially bad for
modules since the path can be saved into the pcm file itself, leading to
stateful behaviour if the cache is shared.
This should not impact the number of real filesystem accesses in the
scanner, since it is already caching in the
DependencyScanningWorkerFilesystem.
Note: this change does not affect whether or not the FileManager is
shared across TUs in the scanner, which is a separate issue.
Differential Revision: https://reviews.llvm.org/D131412
The header from 62e0681afb does something with
LLVM_FALLTHROUGH. Now that llvm-project has switched to C++17 and
LLVM_FALLTHROUGH uses have been migrated to [[fallthrough]], the header is
unneeded.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D131422
WG14 N3047 is the last C working draft before the document goes out
for committee ballot, so this should be the last of the C2x compiler
features to be added.
Along with the new documentation this also re-organizes the HLSL docs
to a subdirectory. The hope is to continue to expand this documentation
as the HLSL implementation advances.
Differential Revision: https://reviews.llvm.org/D130794
Prior to this patch, the `add_tablegen()` macro in
llvm/cmake/modules/TableGen.cmake added the install rule only if
`project` matched `LLVM` or `MLIR`. This patch adds an optional
`DESTINATION` argument, which, if non-empty, decides whether (and where)
to install the tablegen tool, thus eliminating the need for
project-specific overrides. This patch also updates all other
invocations of the `add_tablegen()` macro.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D131282
Swift calling conventions stands out in the way that they are lowered in
mostly target-independent manner, with very few customization points.
As such, swift-related methods of ABIInfo do not reference the rest of
ABIInfo and vice versa.
This change follows interface segregation principle; it removes
dependency of SwiftABIInfo on ABIInfo. Targets must now implement
SwiftABIInfo separately if they support Swift calling conventions.
Almost all targets implemented `shouldPassIndirectly` the same way. This
de-facto default implementation has been moved into the base class.
`isSwiftErrorInRegister` used to be virtual, now it is not. It didn't
accept any arguments which could have an effect on the returned value.
This is now a static property of the target ABI.
Reviewed By: rusyaev-roman, inclyc
Differential Revision: https://reviews.llvm.org/D130394
Currently if an OpenMP program uses `linear` clause, and is compiled with
optimization, `llvm.lifetime.end` for variables listed in `linear` clause are
emitted too early such that there could still be uses after that. Let's take the
following code as example:
```
// loop.c
int j;
int *u;
void loop(int n) {
int i;
for (i = 0; i < n; ++i) {
++j;
u = &j;
}
}
```
We compile using the command:
```
clang -cc1 -fopenmp-simd -O3 -x c -triple x86_64-apple-darwin10 -emit-llvm loop.c -o loop.ll
```
The following IR (simplified) will be generated:
```
@j = local_unnamed_addr global i32 0, align 4
@u = local_unnamed_addr global ptr null, align 8
define void @loop(i32 noundef %n) local_unnamed_addr {
entry:
%j = alloca i32, align 4
%cmp = icmp sgt i32 %n, 0
br i1 %cmp, label %simd.if.then, label %simd.if.end
simd.if.then: ; preds = %entry
call void @llvm.lifetime.start.p0(i64 4, ptr nonnull %j)
store ptr %j, ptr @u, align 8
call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
%0 = load i32, ptr %j, align 4
store i32 %0, ptr @j, align 4
br label %simd.if.end
simd.if.end: ; preds = %simd.if.then, %entry
ret void
}
```
The most important part is:
```
call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
%0 = load i32, ptr %j, align 4
store i32 %0, ptr @j, align 4
```
`%j` is still loaded after `@llvm.lifetime.end.p0(i64 4, ptr nonnull %j)`. This
could cause the backend incorrectly optimizes the code and further generates
incorrect code. The root cause is, when we emit a construct that could have
`linear` clause, it usually has the following pattern:
```
EmitOMPLinearClauseInit(S)
{
OMPPrivateScope LoopScope(*this);
...
EmitOMPLinearClause(S, LoopScope);
...
(void)LoopScope.Privatize();
...
}
EmitOMPLinearClauseFinal(S, [](CodeGenFunction &) { return nullptr; });
```
Variables that need to be privatized are added into `LoopScope`, which also
serves as a RAII object. When `LoopScope` is destructed and if optimization is
enabled, a `@llvm.lifetime.end` is also emitted for each privatized variable.
However, the writing back to original variables in `linear` clause happens after
the scope in `EmitOMPLinearClauseFinal`, causing the issue we see above.
A quick "fix" seems to be, moving `EmitOMPLinearClauseFinal` inside the scope.
However, it doesn't work. That's because the local variable map has been updated
by `LoopScope` such that a variable declaration is mapped to the privatized
variable, instead of the actual one. In that way, the following code will be
generated:
```
%0 = load i32, ptr %j, align 4
store i32 %0, ptr %j, align 4
call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
```
Well, now the life time is correct, but apparently the writing back is broken.
In this patch, a new function `OMPPrivateScope::restoreMap` is added and called
before calling `EmitOMPLinearClauseFinal`. This can make sure that
`EmitOMPLinearClauseFinal` can find the orignal varaibls to write back.
Fixes#56913.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D131272
This has been deprecated for a while, since D51714 in 2018.
Remove it in favor of using CMake's find_package() function.
Reviewed By: phosek, mgorny
Differential Revision: https://reviews.llvm.org/D128777
Also make the soft toolchain requirements hard. This allows
us to use C++17 features in LLVM now.
If we find patterns with C++17 that improve readability
it should be recommended in the coding standards.
Reviewed By: jhenderson, cor3ntin, MaskRay
Differential Revision: https://reviews.llvm.org/D130689
In the case of static compilation the file system is pretty much read-only
and taking a snapshot of it usually is sufficient. In the interactive C++
case the compilation is longer and people can create and include files, etc.
In that case we often do not want to open files or cache failures unless is
absolutely necessary.
This patch extends the original API call by forwarding some optional flags,
so we can continue use it in the previous way with no breakage.
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D131241
When not set output, set default output to stdout.
When set output with -Fo and no -fcgl, set -emit-obj to generate dx container.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D130858
When performing device only compilation, there was an issue where
`cubin` outputs were being renamed to `cubin` despite the user's name.
This is required in a normal compilation flow as the Nvidia tools only
understand specific filenames instead of checking magic bytes for some
unknown reason. We do not want to perform this transformation when the
user is performing device only compilation.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D131278
Use of `ORIGINAL_PCH_DIR` record has been superseeded by making PCH/PCM files with relocatable paths at write time.
Removing this record is useful for producing an output-path-independent PCH file and enable sharing of the same PCH file even
when it was intended for a different output path.
Differential Revision: https://reviews.llvm.org/D131124
Sharing the FileManager between the importer and the module build should
only be an optimization. Add a cc1 option -fno-modules-share-filemanager
to allow us to test this. Fix the path to modulemap files, which
previously depended on the shared FileManager when using path mapped to
an external file in a VFS.
Differential Revision: https://reviews.llvm.org/D131076
In 6a79e2ff19 we changed Filemanager::getEntryRef() to return the
redirecting FileEntryRef instead of looking through the redirection.
This commit fixes the case when looking up a cached file path to also
return the redirecting FileEntryRef. This mainly affects the behaviour
of calling getNameAsRequested() on the resulting entry ref.
Differential Revision: https://reviews.llvm.org/D131273
Support for functions wmempcpy, wmemmove, wmemcmp is added to the checker.
The same tests are copied that exist for the non-wide versions, with
non-wide functions and character types changed to the wide version.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D130470
Closing https://github.com/llvm/llvm-project/issues/56919
It is meaningless to preserve the lifetime markers for the spilled
allocas in the coroutine frames and it would block some optimizations
too.
Consider:
A == 5 && A != 5
IfA is 5, the old collectConjunctionTerms() would call itself again for
the LHS (which it ignores), then the RHS (which it also ignores) and
then just return without ever adding anything to the Terms array.
Differential Revision: https://reviews.llvm.org/D131070
In D130807 we added the `skipprofile` attribute. This commit
changes the format so we can either `forbid` or `skip` profiling
functions by adding the `noprofile` or `skipprofile` attributes,
respectively. The behavior of the original format remains
unchanged.
Also, add the `skipprofile` attribute when using
`-fprofile-function-groups`.
This was originally landed as https://reviews.llvm.org/D130808 but was
reverted due to a Windows test failure.
Differential Revision: https://reviews.llvm.org/D131195
-E option will set entry function for hlsl.
The format is -E entry_name.
To avoid conflict with existing option with name 'E', add an extra prefix '--'.
A new field HLSLEntry is added to TargetOption.
To share code with HLSLShaderAttr, entry function will be add HLSLShaderAttr attribute too.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D124751
The order has to be a constant and should be enforced by the builtin
definition. The fallthrough behavior would have been broken anyway.
There's still an existing issue/assert if you try to use garbage for the
ordering. The IRGen should be broken, but we also hit another assert
before that.
Fixes issue 56832
This patch adds the ability to context-sensitively analyze method bodies, by moving `ThisPointeeLoc` from `DataflowAnalysisContext` to `Environment`, and adding code in `pushCall` to set it.
Reviewed By: ymandel, sgatev, xazax.hun
Differential Revision: https://reviews.llvm.org/D131170
This patch adds a `ReturnLoc` field to the `Environment`, serving a similar to the `ThisPointeeLoc` field in the `DataflowAnalysisContext`. It then uses that (along with a new `VisitReturnStmt` method in `TransferVisitor`) to handle non-`void`-returning functions in context-sensitive analysis.
Reviewed By: ymandel, sgatev
Differential Revision: https://reviews.llvm.org/D130600
We would like to make the ACLE NEON and SVE intrinsics more useable by
gating them on the target, not by ifdef preprocessor macros. In order to
do this the types they use need to be available. This patches makes
__bf16 always available under AArch64 not just when the bf16
architecture feature is present. This bringing it in-line with GCC. In
subsequent patches the NEON bfloat16x8_t and SVE svbfloat16_t types
(along with bfloat16_t used in arm_sve.h) will be made unconditional
too.
The operations valid on the types are still very limited. They can be
used as a storage type, but the intrinsics used for convertions are
still behind an ifdef guard in arm_neon.h/arm_bf16.h.
Differential Revision: https://reviews.llvm.org/D130973
Close#56885: WG14 N2630 added %b to fprintf/fscanf and recommended %B for
fprintf. This patch teaches -Wformat %b for the printf/scanf family of functions
and %B for the printf family of functions.
glibc 2.35 and latest Android bionic added %b/%B printf support. From
https://www.openwall.com/lists/libc-coord/2022/07/ no scanf support is available
yet.
Like GCC, we don't test library support.
GCC 12 -Wformat -pedantic emits a warning:
> warning: ISO C17 does not support the ‘%b’ gnu_printf format [-Wformat=]
The behavior is not ported.
Note: `freebsd_kernel_printf` uses %b differently.
Reviewed By: aaron.ballman, dim, enh
Differential Revision: https://reviews.llvm.org/D131057
`transferBlock` and `computeBlockInputState` only read the
`BlockStates` vector for the predecessor block(s), and do not need to
mutate any of the contents. Only `runTypeErasedDataflowAnalysis`
writes into the `vector`, so simply down to an `ArrayRef`.
In D130807 we added the `skipprofile` attribute. This commit
changes the format so we can either `forbid` or `skip` profiling
functions by adding the `noprofile` or `skipprofile` attributes,
respectively. The behavior of the original format remains
unchanged.
Also, add the `skipprofile` attribute when using
`-fprofile-function-groups`.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D130808
This reverts commit d959324e1e.
The target_include_directories in the clang-fuzzer CMake files
are set to PRIVATE instead of PUBLIC to prevent the clang buildbots
from breaking when symlinking clang into llvm.
The expression evaluator fuzzer itself has been modified to prevent a
bug that occurs when running it without a target.
As discussed in [0], this diff adds the `skipprofile` attribute to
prevent the function from being profiled while allowing profiled
functions to be inlined into it. The `noprofile` attribute remains
unchanged.
The `noprofile` attribute is used for functions where it is
dangerous to add instrumentation to while the `skipprofile` attribute is
used to reduce code size or performance overhead.
[0] https://discourse.llvm.org/t/why-does-the-noprofile-attribute-restrict-inlining/64108
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D130807
Follow-up to D129097.
It is no longer a requirement that the `QualType` passed to to
`DataflowAnalysisContext::getStableStorageLocation()` is not null. A
null type pass as an argument is only applicable as the pointee type
of a `std::nullptr_t` pointer.
Differential Revision: https://reviews.llvm.org/D131109
This patch enhances clang's ability to check compile-time determinable
string literals as format strings, and can give FixIt hints at literals
(unlike gcc). Issue https://github.com/llvm/llvm-project/issues/55805
mentiond two compile-time string cases. And this patch partially fixes
one.
```
constexpr const char* foo() {
return "%s %d";
}
int main() {
printf(foo(), "abc", "def");
return 0;
}
```
This patch enables clang check format string for this:
```
<source>:4:24: warning: format specifies type 'int' but the argument has type 'const char *' [-Wformat]
printf(foo(), "abc", "def");
~~~~~ ^~~~~
<source>:2:42: note: format string is defined here
constexpr const char *foo() { return "%s %d"; }
^~
%s
1 warning generated.
```
Reviewed By: aaron.ballman
Signed-off-by: YingChi Long <me@inclyc.cn>
Differential Revision: https://reviews.llvm.org/D130906
On targets with non-default program address space (e.g., Harvard
architectures), clang crashes when emitting Objective-C method metadata,
because the address of the method IMP cannot be bitcast to i8*. It similarly
crashes at messenger callsite with a failed bitcast.
Define the _imp field instead as i8 addrspace(1)* (or whatever the target's
program address space is). And in getMessageSendInfo(), create signatureType by
specifying the program address space.
Add a regression test using the AVR target. Test failed previously and passes
now. Checked codegen of the test for x86_64-apple-darwin19.6.0 and saw no
difference, as expected.
Reviewed By: rjmccall, dylanmckay
Differential Revision: https://reviews.llvm.org/D112113
This completes the implementation of P1091R3 and P1381R1.
This patch allow the capture of structured bindings
both for C++20+ and C++17, with extension/compat warning.
In addition, capturing an anonymous union member,
a bitfield, or a structured binding thereof now has a
better diagnostic.
We only support structured bindings - as opposed to other kinds
of structured statements/blocks. We still emit an error for those.
In addition, support for structured bindings capture is entirely disabled in
OpenMP mode as this needs more investigation - a specific diagnostic indicate the feature is not yet supported there.
Note that the rest of P1091R3 (static/thread_local structured bindings) was already implemented.
at the request of @shafik, i can confirm the correct behavior of lldb wit this change.
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/54300
Fixes https://github.com/llvm/llvm-project/issues/52720
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122768
Joseph Huber