#
978e0839 |
| 29-Jan-2025 |
Zahira Ammarguellat <zahira.ammarguellat@intel.com> |
[OpenMP] Allow OMP6.0 features. (#122108)
Add support for the `-fopenmp-version=60` command line argument. It is
needed for https://github.com/llvm/llvm-project/pull/119891 (`#pragma
omp stripe`)
[OpenMP] Allow OMP6.0 features. (#122108)
Add support for the `-fopenmp-version=60` command line argument. It is
needed for https://github.com/llvm/llvm-project/pull/119891 (`#pragma
omp stripe`) which will be the first OpenMP 6.0 directive implemented.
Add regression tests for Clang in `-fopenmp-version=60` mode.
show more ...
|
Revision tags: llvmorg-21-init |
|
#
60927405 |
| 29-Jan-2025 |
Akira Hatanaka <ahatanak@gmail.com> |
Don't use CLANG_VERSION_MAJOR to check that the value passed to -fclang-abi-compat= is valid (#123998)
Use LLVM_VERSION_MAJOR instead as the maximum allowed value. This change
is needed to fix regr
Don't use CLANG_VERSION_MAJOR to check that the value passed to -fclang-abi-compat= is valid (#123998)
Use LLVM_VERSION_MAJOR instead as the maximum allowed value. This change
is needed to fix regression tests that fail when vendors set
CLANG_VERSION_MAJOR to a value that is lower than LLVM_VERSION_MAJOR
when building the compiler.
For example, clang/test/CodeGenCXX/mangle-concept.cpp fails with the
following error if -DCLANG_VERSION_MAJOR=17 is passed to cmake:
invalid value '19' in '-fclang-abi-compat=19'
show more ...
|
#
1295aa2e |
| 28-Jan-2025 |
Nikita Popov <npopov@redhat.com> |
[Clang] Add -fwrapv-pointer flag (#122486)
GCC supports three flags related to overflow behavior:
* `-fwrapv`: Makes signed integer overflow well-defined.
* `-fwrapv-pointer`: Makes pointer over
[Clang] Add -fwrapv-pointer flag (#122486)
GCC supports three flags related to overflow behavior:
* `-fwrapv`: Makes signed integer overflow well-defined.
* `-fwrapv-pointer`: Makes pointer overflow well-defined.
* `-fno-strict-overflow`: Implies `-fwrapv -fwrapv-pointer`, making both
signed integer overflow and pointer overflow well-defined.
Clang currently only supports `-fno-strict-overflow` and `-fwrapv`, but
not `-fwrapv-pointer`.
This PR proposes to introduce `-fwrapv-pointer` and adjust the semantics
of `-fwrapv` to match GCC.
This allows signed integer overflow and pointer overflow to be
controlled independently, while `-fno-strict-overflow` still exists to
control both at the same time (and that option is consistent across GCC
and Clang).
show more ...
|
#
cd5694ec |
| 23-Jan-2025 |
Chandler Carruth <chandlerc@gmail.com> |
[StrTable] Switch the option parser to `llvm::StringTable` (#123308)
Now that we have a dedicated abstraction for string tables, switch the
option parser library's string table over to it rather th
[StrTable] Switch the option parser to `llvm::StringTable` (#123308)
Now that we have a dedicated abstraction for string tables, switch the
option parser library's string table over to it rather than using a raw
`const char*`. Also try to use the `StringTable::Offset` type rather
than a raw `unsigned` where we can to avoid accidental increments or
other issues.
This is based on review feedback for the initial switch of options to a
string table. Happy to tweak or adjust if desired here.
show more ...
|
Revision tags: llvmorg-19.1.7 |
|
#
1907a29d |
| 13-Jan-2025 |
Tom Honermann <tom.honermann@intel.com> |
[Clang][NFC] Indentation fixes and unneeded semicolon removal. (#122794)
|
#
76fac9c0 |
| 10-Jan-2025 |
Thurston Dang <thurston@google.com> |
[sanitizer] Parse weighted sanitizer args and -fsanitize-skip-hot-cutoff (#121619)
This adds a function to parse weighted sanitizer flags (e.g.,
`-fsanitize-blah=undefined=0.5,null=0.3`) and adds t
[sanitizer] Parse weighted sanitizer args and -fsanitize-skip-hot-cutoff (#121619)
This adds a function to parse weighted sanitizer flags (e.g.,
`-fsanitize-blah=undefined=0.5,null=0.3`) and adds the plumbing to apply
that to a new flag, `-fsanitize-skip-hot-cutoff`.
`-fsanitize-skip-hot-cutoff` currently has no effect; future work will
use it to generalize ubsan-guard-checks (originally introduced in
5f9ed2ff8364ff3e4fac410472f421299dafa793).
---------
Co-authored-by: Vitaly Buka <vitalybuka@google.com>
show more ...
|
#
5f6b7145 |
| 07-Jan-2025 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer][NFC] Simplify PositiveAnalyzerOption handling (#121910)
This simplifies #120239
Addresses my comment at:
https://github.com/llvm/llvm-project/pull/120239#issuecomment-2574600543
CPP-
[analyzer][NFC] Simplify PositiveAnalyzerOption handling (#121910)
This simplifies #120239
Addresses my comment at:
https://github.com/llvm/llvm-project/pull/120239#issuecomment-2574600543
CPP-5920
show more ...
|
#
55391f85 |
| 06-Jan-2025 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer] Retry UNDEF Z3 queries 2 times by default (#120239)
If we have a refutation Z3 query timed out (UNDEF), allow a couple of
retries to improve stability of the query. By default allow 2 re
[analyzer] Retry UNDEF Z3 queries 2 times by default (#120239)
If we have a refutation Z3 query timed out (UNDEF), allow a couple of
retries to improve stability of the query. By default allow 2 retries,
which will give us in maximum of 3 solve attempts per query.
Retries should help mitigating flaky Z3 queries.
See the details in the following RFC:
https://discourse.llvm.org/t/analyzer-rfc-retry-z3-crosscheck-queries-on-timeout/83711
Note that with each attempt, we spend more time per query.
Currently, we have a 15 seconds timeout per query - which are also in
effect for the retry attempts.
---
Why should this help?
In short, retrying queries should bring stability because if a query
runs long
it's more likely that it did so due to some runtime anomaly than it's on
the edge of succeeding. This is because most queries run quick, and the
queries that run long, usually run long by a fair amount.
Consequently, retries should improve the stability of the outcome of the
Z3 query.
In general, the retries shouldn't increase the overall analysis time
because it's really rare we hit the 0.1% of the cases when we would do
retries. But keep in mind that the retry attempts can add up if many
retries are allowed, or the individual query timeout is large.
CPP-5920
show more ...
|
#
82fecab8 |
| 03-Jan-2025 |
Fangrui Song <i@maskray.me> |
[gcov] Bump default version to 11.1
The gcov version is set to 11.1 (compatible with gcov 9) even if `-Xclang -coverage-version=` specified version is less than 11.1.
Therefore, we can drop produce
[gcov] Bump default version to 11.1
The gcov version is set to 11.1 (compatible with gcov 9) even if `-Xclang -coverage-version=` specified version is less than 11.1.
Therefore, we can drop producer support for version < 11.1.
show more ...
|
#
cd19f3f7 |
| 02-Jan-2025 |
Nick Sarnie <nick.sarnie@intel.com> |
[Driver][clang-linker-wrapper] Add initial support for OpenMP offloading to generic SPIR-V (#120145)
This is the first of a series of patches to add support for OpenMP
offloading to SPIR-V through
[Driver][clang-linker-wrapper] Add initial support for OpenMP offloading to generic SPIR-V (#120145)
This is the first of a series of patches to add support for OpenMP
offloading to SPIR-V through liboffload with the first intended target
being Intel GPUs. This patch implements the basic driver and
`clang-linker-wrapper` work for JIT mode. There are still many missing
pieces, so this is not yet usable.
We introduce `spirv64-intel-unknown` as the only currently supported
triple. The user-facing argument to enable offloading will be `-fopenmp
-fopenmp-targets=spirv64-intel`
Add a new `SPIRVOpenMPToolChain` toolchain based on the existing general
SPIR-V toolchain which will call all the required SPIR-V tools (and
eventually the SPIR-V backend) as well as add the corresponding device
RTL as an argument to the linker.
We can't get through the front end consistently yet, so it's difficult
to add any LIT tests that execute any tools, but front end changes are
planned very shortly, and then we can add those tests.
---------
Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
show more ...
|
#
ffff7bb5 |
| 19-Dec-2024 |
Thurston Dang <thurston@google.com> |
Reapply "[ubsan] Add -fsanitize-merge (and -fno-sanitize-merge) (#120…464)" (#120511)
This reverts commit 2691b964150c77a9e6967423383ad14a7693095e. This
reapply fixes the buildbot breakage of the o
Reapply "[ubsan] Add -fsanitize-merge (and -fno-sanitize-merge) (#120…464)" (#120511)
This reverts commit 2691b964150c77a9e6967423383ad14a7693095e. This
reapply fixes the buildbot breakage of the original patch, by updating
clang/test/CodeGen/ubsan-trap-debugloc.c to specify -fsanitize-merge
(the default, which is merge, is applied by the driver but not
clang_cc1).
This reapply also expands clang/test/CodeGen/ubsan-trap-merge.c.
----
Original commit message:
'-mllvm -ubsan-unique-traps'
(https://github.com/llvm/llvm-project/pull/65972) applies to all UBSan
checks. This patch introduces -fsanitize-merge (defaults to on,
maintaining the status quo behavior) and -fno-sanitize-merge (equivalent
to '-mllvm -ubsan-unique-traps'), with the option to selectively
applying non-merged handlers to a subset of UBSan checks (e.g.,
-fno-sanitize-merge=bool,enum).
N.B. we do not use "trap" in the argument name since
https://github.com/llvm/llvm-project/pull/119302 has generalized
-ubsan-unique-traps to work for non-trap modes (min-rt and regular rt).
This patch does not remove the -ubsan-unique-traps flag; that will
override -f(no-)sanitize-merge.
show more ...
|
#
2691b964 |
| 18-Dec-2024 |
Thurston Dang <thurston@google.com> |
Revert "[ubsan] Add -fsanitize-merge (and -fno-sanitize-merge) (#120464)"
This reverts commit 7eaf4708098c216bf432fc7e0bc79c3771e793a4.
Reason: buildbot breakage (e.g., https://lab.llvm.org/buildbo
Revert "[ubsan] Add -fsanitize-merge (and -fno-sanitize-merge) (#120464)"
This reverts commit 7eaf4708098c216bf432fc7e0bc79c3771e793a4.
Reason: buildbot breakage (e.g., https://lab.llvm.org/buildbot/#/builders/144/builds/14299/steps/6/logs/FAIL__Clang__ubsan-trap-debugloc_c)
show more ...
|
#
7eaf4708 |
| 18-Dec-2024 |
Thurston Dang <thurston@google.com> |
[ubsan] Add -fsanitize-merge (and -fno-sanitize-merge) (#120464)
'-mllvm -ubsan-unique-traps'
(https://github.com/llvm/llvm-project/pull/65972) applies to all UBSan
checks. This patch introduces -
[ubsan] Add -fsanitize-merge (and -fno-sanitize-merge) (#120464)
'-mllvm -ubsan-unique-traps'
(https://github.com/llvm/llvm-project/pull/65972) applies to all UBSan
checks. This patch introduces -fsanitize-merge (defaults to on,
maintaining the status quo behavior) and -fno-sanitize-merge (equivalent
to '-mllvm -ubsan-unique-traps'), with the option to selectively
applying non-merged handlers to a subset of UBSan checks (e.g.,
-fno-sanitize-merge=bool,enum).
N.B. we do not use "trap" in the argument name since
https://github.com/llvm/llvm-project/pull/119302 has generalized
-ubsan-unique-traps to work for non-trap modes (min-rt and regular rt).
This patch does not remove the -ubsan-unique-traps flag; that will
override -f(no-)sanitize-merge.
show more ...
|
#
bdf72706 |
| 17-Dec-2024 |
wanglei <wanglei@loongson.cn> |
[Offload] Add support for loongarch64 to host plugin
This adds support for the loongarch64 architecture to the offload host plugin.
Similar to #115773
To fix some test issues, I've had to add the
[Offload] Add support for loongarch64 to host plugin
This adds support for the loongarch64 architecture to the offload host plugin.
Similar to #115773
To fix some test issues, I've had to add the LoongArch64 target to:
- CompilerInvocation::ParseLangArgs - linkDevice in ClangLinuxWrapper.cpp - OMPContext::OMPContext (to set the device_kind_cpu trait)
Reviewed By: jhuber6
Pull Request: https://github.com/llvm/llvm-project/pull/120173
show more ...
|
Revision tags: llvmorg-19.1.6 |
|
#
dd647e3e |
| 11-Dec-2024 |
Chandler Carruth <chandlerc@gmail.com> |
Rework the `Option` library to reduce dynamic relocations (#119198)
Apologies for the large change, I looked for ways to break this up and
all of the ones I saw added real complexity. This change f
Rework the `Option` library to reduce dynamic relocations (#119198)
Apologies for the large change, I looked for ways to break this up and
all of the ones I saw added real complexity. This change focuses on the
option's prefixed names and the array of prefixes. These are present in
every option and the dominant source of dynamic relocations for PIE or
PIC users of LLVM and Clang tooling. In some cases, 100s or 1000s of
them for the Clang driver which has a huge number of options.
This PR addresses this by building a string table and a prefixes table
that can be referenced with indices rather than pointers that require
dynamic relocations. This removes almost 7k dynmaic relocations from the
`clang` binary, roughly 8% of the remaining dynmaic relocations outside
of vtables. For busy-boxing use cases where many different option tables
are linked into the same binary, the savings add up a bit more.
The string table is a straightforward mechanism, but the prefixes
required some subtlety. They are encoded in a Pascal-string fashion with
a size followed by a sequence of offsets. This works relatively well for
the small realistic prefixes arrays in use.
Lots of code has to change in order to land this though: both all the
option library code has to be updated to use the string table and
prefixes table, and all the users of the options library have to be
updated to correctly instantiate the objects.
Some follow-up patches in the works to provide an abstraction for this
style of code, and to start using the same technique for some of the
other strings here now that the infrastructure is in place.
show more ...
|
#
41cde465 |
| 05-Dec-2024 |
Daniil Kovalev <dkovalev@accesssoftek.com> |
[PAC][Driver] Add `-faarch64-jump-table-hardening` flag (#113149)
The flag is placed together with pointer authentication flags since they
serve the same security purpose of protecting against atta
[PAC][Driver] Add `-faarch64-jump-table-hardening` flag (#113149)
The flag is placed together with pointer authentication flags since they
serve the same security purpose of protecting against attacks on control
flow. The flag is not ABI-affecting and might be enabled separately if
needed, but it's also intended to be enabled as part of pauth-enabled
environments (e.g. pauthtest).
See also codegen implementation #97666.
show more ...
|
Revision tags: llvmorg-19.1.5, llvmorg-19.1.4 |
|
#
3b162f73 |
| 19-Nov-2024 |
Daniil Kovalev <dkovalev@accesssoftek.com> |
[PAC][clang] Add signed GOT cc1 flag (#96160)
Add `-fptrauth-elf-got` clang cc1 flag and set `ptrauth_elf_got`
preprocessor feature and `PointerAuthELFGOT` LangOption correspondingly.
No additiona
[PAC][clang] Add signed GOT cc1 flag (#96160)
Add `-fptrauth-elf-got` clang cc1 flag and set `ptrauth_elf_got`
preprocessor feature and `PointerAuthELFGOT` LangOption correspondingly.
No additional checks like ensuring OS binary format is ELF are
performed: it should be done on clang driver level when a pauth-enabled
environment implying signed GOT enabled is requested.
If the cc1 flag is passed, "ptrauth-elf-got" IR module flag is set.
show more ...
|
#
5845688e |
| 13-Nov-2024 |
Kadir Cetinkaya <kadircet@google.com> |
Reapply "[clang] Introduce diagnostics suppression mappings (#112517)"
This reverts commit 5f140ba54794fe6ca379362b133eb27780e363d7.
|
#
5f140ba5 |
| 12-Nov-2024 |
Kadir Cetinkaya <kadircet@google.com> |
Revert "[clang] Introduce diagnostics suppression mappings (#112517)"
This reverts commit 12e3ed8de8c6063b15916b3faf67c8c9cd17df1f. This reverts commit 41e3919ded78d8870f7c95e9181c7f7e29aa3cc4.
The
Revert "[clang] Introduce diagnostics suppression mappings (#112517)"
This reverts commit 12e3ed8de8c6063b15916b3faf67c8c9cd17df1f. This reverts commit 41e3919ded78d8870f7c95e9181c7f7e29aa3cc4.
There are some buildbot breakages in https://lab.llvm.org/buildbot/#/builders/18/builds/6832.
show more ...
|
#
41e3919d |
| 12-Nov-2024 |
kadir çetinkaya <kadircet@google.com> |
[clang] Introduce diagnostics suppression mappings (#112517)
This implements
https://discourse.llvm.org/t/rfc-add-support-for-controlling-diagnostics-severities-at-file-level-granularity-through-
[clang] Introduce diagnostics suppression mappings (#112517)
This implements
https://discourse.llvm.org/t/rfc-add-support-for-controlling-diagnostics-severities-at-file-level-granularity-through-command-line/81292.
Users now can suppress warnings for certain headers by providing a
mapping with globs, a sample file looks like:
```
[unused]
src:*
src:*clang/*=emit
```
This will suppress warnings from `-Wunused` group in all files that
aren't under `clang/` directory. This mapping file can be passed to
clang via `--warning-suppression-mappings=foo.txt`.
At a high level, mapping file is stored in DiagnosticOptions and then
processed with rest of the warning flags when creating a
DiagnosticsEngine. This is a functor that uses SpecialCaseLists
underneath to match against globs coming from the mappings file.
This implies processing warning options now performs IO, relevant
interfaces are updated to take in a VFS, falling back to RealFileSystem
when one is not available.
show more ...
|
#
19b4f17d |
| 31-Oct-2024 |
Jan Svoboda <jan_svoboda@apple.com> |
[clang][lex] Remove `-index-header-map` (#114459)
This PR removes the `-index-header-map` functionality from Clang. AFAIK
this was only used internally at Apple and is now dead code. The main
moti
[clang][lex] Remove `-index-header-map` (#114459)
This PR removes the `-index-header-map` functionality from Clang. AFAIK
this was only used internally at Apple and is now dead code. The main
motivation behind this change is to enable the removal of
`HeaderFileInfo::Framework` member and reducing the size of that data
structure.
rdar://84036149
show more ...
|
Revision tags: llvmorg-19.1.3 |
|
#
af7c58b7 |
| 28-Oct-2024 |
Aaron Ballman <aaron@aaronballman.com> |
Remove support for RenderScript (#112916)
See
https://discourse.llvm.org/t/rfc-deprecate-and-eventually-remove-renderscript-support/81284
for the RFC
|
Revision tags: llvmorg-19.1.2 |
|
#
d8f22514 |
| 04-Oct-2024 |
Joseph Huber <huberjn@outlook.com> |
[Clang] Automatically enable `-fconvergent-functions` on GPU targets (#111076)
Summary: This patch causes us to respect the `-fconvergent-functions` and `-fno-convergent-functions` options correctly
[Clang] Automatically enable `-fconvergent-functions` on GPU targets (#111076)
Summary: This patch causes us to respect the `-fconvergent-functions` and `-fno-convergent-functions` options correctly. GPU targets should have this set all the time, but we now offer `-fno-convergent-functions` to opt-out if you want to test broken behavior. This munged about with a lot of the old weird logic, but I don't think it makes any real changes.
show more ...
|
Revision tags: llvmorg-19.1.1 |
|
#
7883b028 |
| 29-Sep-2024 |
tcwzxx <tcwzxx@gmail.com> |
[ItaniumMangle] Add substitutions for record types when mangling vtables (#109970)
Fix #108015
The `mangleNameOrStandardSubstitution` function does not add the RD type
into the substitution, wh
[ItaniumMangle] Add substitutions for record types when mangling vtables (#109970)
Fix #108015
The `mangleNameOrStandardSubstitution` function does not add the RD type
into the substitution, which causes the mangling of the \<base type\> to
be incorrect.
Rename `mangleNameOrStandardSubstitution` to `mangleCXXRecordDecl` and add `Record` as a substitution
show more ...
|
#
9f33eb86 |
| 26-Sep-2024 |
Ming-Yi Lai <ming-yi.lai@mediatek.com> |
[clang][RISCV] Introduce command line options for RISC-V Zicfilp CFI
This patch enables the following command line flags for RISC-V targets:
+ `-fcf-protection=branch` turns on forward-edge contr
[clang][RISCV] Introduce command line options for RISC-V Zicfilp CFI
This patch enables the following command line flags for RISC-V targets:
+ `-fcf-protection=branch` turns on forward-edge control-flow integrity conditioning
+ `-mcf-branch-label-scheme=unlabeled|func-sig` selects the label scheme used in the forward-edge CFI conditioning
show more ...
|