History log of /llvm-project/clang/lib/Frontend/CompilerInvocation.cpp (Results 1 – 25 of 1971)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


12345678910>>...79