This reverts commit e476f968bc8e438a0435d10934f148de570db8eb.
It has introduced a failure tracked by https://github.com/llvm/llvm-project/issues/150601
One libcxx test fail if libcxx is build with no exceptions and no RTTI:
- libcxx/utilities/expected/expected.expected/value.observers.verify.cpp
This patch moves `LazyDetector` and target specific (Cuda, Hip, SYCL)
installation detectors to clang's include directory. It was problematic
for downstream to use headers from clang's lib dir. The use of lib
headers could lead to subtle errors, as some of the symbols there are
annotated with `LLVM_LIBRARY_VISIBILITY`. For instance
[`ROCMToolChain::getCommonDeviceLibNames`](https://github.com/jchlanda/llvm-project/blob/jakub/installation_detectors/clang/lib/Driver/ToolChains/AMDGPU.h#L147)
is c++ public, but because of the annotation it ends up as ELF hidden
symbol, which causes errors when accessed from another shared library.
This PR adds support for `-ffine-grained-bitfield-accesses`. I reused
the tests from classic CodeGen, available here:
[c2c881fcc8/clang/test/CodeGenCXX/finegrain-bitfield-access.cpp)
We produce almost exactly the same codegen, except when returning a
variable: we emit an extra variable to hold the return value, whereas
classic CodeGen does not. Also, the GEP instructions use slightly
different syntax compared to classic CodeGen.
This patch removes getVirtualFile because it has been deprecated for
more than 10 months since:
commit b1aea98cfa357e23f4bb52232da5f41781f23bff
Author: Jan Svoboda <jan_svoboda@apple.com>
Date: Wed Sep 25 10:36:44 2024 -0700
I'm not aware of any downstream use AFAICT.
This patch adds the `cir.ffs` operation which corresponds to the
`__builtin_ffs` family of builtin functions.
This operation was not included in the previous PRs because the call to
`__builtin_ffs` would be transformed into a library call to `ffs`. At
the time of authoring this patch, this behavior has been changed and now
we can properly lower calls to `__builtin_ffs` to `cir.ffs`.
Depending on the particular version of the AArch32 architecture,
load/store exclusive operations might be available for various subset of
8, 16, 32, and 64-bit quantities. Sema knew nothing about this and was
accepting all four sizes, leading to a compiler crash at isel time if
you used a size not available on the target architecture.
Now the Sema checking stage emits a more sensible diagnostic, pointing
at the location in the code.
In order to allow Sema to query the set of supported sizes, I've moved
the enum of LDREX_x sizes out of its Arm-specific header into
`TargetInfo.h`.
Also, in order to allow the diagnostic to specify the correct list of
supported sizes, I've filled it with `%select{}`. (The alternative was
to make separate error messages for each different list of sizes.)
Preprocessing the preprocessor output again interacts poorly with some
flag combinations when we perform a separate preprocessing stage. In our
case, `-no-integrated-cpp -dD` triggered this issue; but I guess that
other flags could also trigger problems (`-save-temps` instead of
`-no-integrated-cpp`).
Full context (which is quite weird I'll admit):
* To cache OpenCL kernel compilation results, we use the
`-no-integrated-cpp` for the driver to generate a separate preprocessing
command (`clang -E`) before the rest of the compilation.
* Some OpenCL C language features are implemented as macro definitions
(in `opencl-c-base.h`). The semantic analysis queries the preprocessor
to check if these are defined or not, for example, when we checks if a
builtin is available when using `-fdeclare-opencl-builtins`.
* To preserve these `#define` directives, on the preprocessor's output,
we use `-dD`. However, other `#define` directives are also maintained
besides OpenCL ones; which triggers the issue shown in this PR.
A better fix for our particular case could have been to move the
language features implemented as macros into some sort of a flag to be
used together with `-fdeclare-opencl-builtins`.
But I also thought that not preprocessing preprocessor outputs seemed
like something desirable. I hope to work on this on a follow up.
Clang's current implementation only works on array types, but GCC (which
is where we got this attribute) supports it on pointers as well as
arrays.
Fixes#150951
This commit converts the class DereferenceChecker to the checker family
framework and simplifies some parts of the implementation.
This commit is almost NFC, the only technically "functional" change is
that it removes the hidden modeling checker `DereferenceModeling` which
was only relevant as an implementation detail of the old checker
registration procedure.
Tracked at https://github.com/llvm/llvm-project/issues/112294
This patch implements from [basic.link]p14 to [basic.link]p18 partially.
The explicitly missing parts are:
- Anything related to specializations.
- Decide if a pointer is associated with a TU-local value at compile
time.
- [basic.link]p15.1.2 to decide if a type is TU-local.
- Diagnose if TU-local functions from other TU are collected to the
overload set. See [basic.link]p19, the call to 'h(N::A{});' in
translation unit #2
There should be other implicitly missing parts as the wording uses
"names" briefly several times. But to implement this precisely, we have
to visit the whole AST, including Decls, Expression and Types, which may
be harder to implement and be more time-consuming for compilation time.
So I choose to implement the common parts.
It won't be too bad to miss some cases since we DIDN'T do any such
checks in the past 3 years. Any new check is an improvement. Given
modules have been basically available since clang15 without such checks,
it will be user unfriendly if we give a hard error now. And there are
a lot of cases which violating the rule actually just fine. So I decide
to emit it as warnings instead of hard errors.
This patch adds the `#cir.poison` attribute which represents a poison
value. This patch also updates various operation folders to let them
propagate poison values from their inputs to their outputs.
This patch adds a human readable trap category and message to UBSan
traps. The category and message are encoded in a fake frame in the debug
info where the function is a fake inline function where the name encodes
the trap category and message. This is the same mechanism used by
Clang’s `__builtin_verbose_trap()`.
This change allows consumers of binaries built with trapping UBSan to
more easily identify the reason for trapping. In particular LLDB already
has a frame recognizer that recognizes the fake function names emitted
in debug info by this patch. A patch testing this behavior in LLDB will
be added in a separately.
The human readable trap messages are based on the messages currently
emitted by the userspace runtime for UBSan in compiler-rt. Note the
wording is not identical because the userspace UBSan runtime has access
to dynamic information that is not available during Clang’s codegen.
Test cases for each UBSan trap kind are included.
This complements the [`-fsanitize-annotate-debug-info`
feature](https://github.com/llvm/llvm-project/pull/141997). While
`-fsanitize-annotate-debug-info` attempts to annotate all UBSan-added
instructions, this feature (`-fsanitize-debug-trap-reasons`) only
annotates the final trap instruction using SanitizerHandler information.
This work is part of a GSoc 2025 project.
Tests if the runtime type of the function pointer matches the static
type. If this returns false, calling the function pointer will trap.
Uses `@llvm.wasm.ref.test.func` added in #147486.
Also adds a "gc" wasm feature to gate the use of the ref.test
instruction.
These two both allow arrays as their variable references, but it is a
common thing to use sub-arrays as a way to get a pointer to act as an
array with other compilers. This patch adds these, with an
extension-warning.
…Type
PR #118288 fixed a re-entrancy issue with the usage of `FoldingSet` and
`AutoType`. The following test case (reduced with `creduce` by
@Fznamznon):
```
template <typename C, typename S1, int rbits>
typename C::A Bar(const S1& x, const C& c = C()) {
using T = typename C::A;
T result;
using PreC = typename C::template boop<T::p + rbits>;
using ExactC = typename C::template bap<PreC::p + 2>;
using D = typename ExactC::A;
return result;
}
```
shows a similar non-deterministic recursion with the use of `FoldingSet`
but with `DependentTemplateSepcializationType`. A nearly identical fix
is needed here too.
This patch adds folders for the bit manipulation operations, namely:
`clrsb`, `clz`, `ctz`, `parity`, `popcount`, `bitreverse`, `byte_swap`,
and `rotate`.
report_fatal_error is not a good way to report diagnostics to the users, so this switches to using actual diagnostic reporting mechanisms instead.
Fixes#147187
This change adds basic handling for normal cleanups. This is a very
minimal implemention. In particular, it uses a naive substitute for the
rich cleanup and EH stack handling that is present in classic codegen
and the CIR incubator. This is intended as a temporary implementation to
allow incremental progress. It is not expected to scale well enough to
be used in a production environment. It will be replaced with the full
EHScopeStack handling when such an implementation is needed.
Atomic Control Options are used to specify architectural characteristics
to help lowering of atomic operations. The options used are:
`-f[no-]atomic-remote-memory`, `-f[no-]atomic-fine-grained-memory`,
`-f[no-]atomic-ignore-denormal-mode`.
Legacy option `-m[no-]unsafe-fp-atomics` is aliased to
`-f[no-]ignore-denormal-mode`.
More details can be found in
https://github.com/llvm/llvm-project/pull/102569. This PR implements the
frontend support for these options with OpenMP atomic in flang.
Backend changes are available in the draft PR:
https://github.com/llvm/llvm-project/pull/143769 which will be raised
after this merged.
This patch upstreams support for creating arrays of classes that require
calling a constructor.
* Adds the ArrayCtor operation
* New lowering pass for lowering ArrayCtor to a loop
---------
Co-authored-by: Andy Kaylor <akaylor@nvidia.com>
Co-authored-by: Henrich Lauko <xlauko@mail.muni.cz>
Running an external test suite (UDel) showed that our expression
comparison for the 'cache' rule checking was overly strict in the
presence of irrelevant parens/casts/etc. This patch ensures we skip
them when checking.
This also changes the diagnostic to say 'sub-expression' instead of
variable, which is more correct.
This makes the bug in PR #125556 which was fixed by
dc87a14efb381d960c8fbf988221f31216d7f5fd into a compile-time error.
...and fix a newly-discovered instance of this issue, triggered by a
`llvm::MapVector<AccessSpecifier, ...>` in
clang-tools-extra/clangd/refactor/tweaks/OverridePureVirtuals.cpp.
This commit provides a brief documentation for the checker
optin.portability.UnixAPI.
Unfortunately the name of this checker is meaninglessly vague and its
functionality is very closely related to unix.Malloc, so it should be
eventually "rebranded" to a more user-friendly presentation.
If the need_device_addr adjust-op modifier is present, each list item
that appears in the clause must refer to an argument in the declaration
of the function variant that has a reference type.
Reference:
OpenMP 6.0 [Sec 9.6.2, page 332, line 31-33, adjust_args clause,
Restrictions]
Previously, the unsigned NEON intrinsic variants of 'vqshrun_high_n' and
'vqrshrun_high_n' were using signed integer types for their first
argument and return values.
These should be unsigned according to developer.arm.com, however.
Adjust the test cases accordingly.
This PR adds the `ExpiredLoansAnalysis` class to track which loans have expired. The analysis uses a dataflow lattice (`ExpiredLattice`) to maintain the set of expired loans at each program point.
This is a very light weight dataflow analysis and is expected to reach fixed point in ~2 iterations.
In principle, this does not need a dataflow analysis but is used for convenience in favour of lean code.
FMV priority is the returned value of a polymorphic function. On RISC-V
and X86 targets a 32-bit value is enough. On AArch64 we currently need
64 bits and we will soon exceed that. APInt seems to be a suitable
replacement for uint64_t, presumably with minimal compile time overhead.
It allows bit manipulation, comparison and variable bit width.
This patch provides a single point for handling the logic behind
choosing common bitcode libraries. The intention is that the users of
ROCm installation detector will not have to rewrite options handling
code each time the bitcode libraries are queried. This is not too
distant from detectors for other architecture that encapsulate the
similar decision making process, providing cleaner interface. The only
flag left in `getCommonBitcodeLibs` (main point of entry) is
`NeedsASanRT`, this is deliberate, as in order to calculate it we need
to consult `ToolChain`.
As reported in #138173, enabling `-ftime-report` adds pass timing info
to the stats file if `-stats-file` is specified. This was determined to
be WAI. However, if one intentionally wants to put timer information in
the stats file, using `-ftime-report` may lead to a lot of logspam (that
can't be removed by directing stderr to `/dev/null` as that would also
redirect compiler errors). To address this, this PR adds a flag
`-stats-file-timers` that adds timer data to the stats file without
outputting to stderr.
Add a language option flag for experimental lifetime safety analysis in C++.
This change provides a language option to control the experimental lifetime safety analysis feature, making it more explicit and easier to enable/disable. Previously, the feature was controlled indirectly through a diagnostic warning flag, which we do not want to accidentally enable with `-Weverything` (atm)!
### Changes:
- Added a new language option `EnableLifetimeSafety` in `LangOptions.def` for experimental lifetime safety analysis in C++
- Added corresponding driver options `-fexperimental-lifetime-safety` and `-fno-experimental-lifetime-safety` in `Options.td`
- Modified `AnalysisBasedWarnings.cpp` to use the new language option flag instead of checking if a specific diagnostic is ignored
- Updated a test case to use the new flag instead of relying on the warning flag alone
