[SPIR-V] Add SPIR-V logical triple.

Clang implements SPIR-V with both Physical32 and Physical64 addressing
models. This commit adds a new triple value for the Logical
addressing model.

Differential

[SPIR-V] Add SPIR-V logical triple.

Clang implements SPIR-V with both Physical32 and Physical64 addressing
models. This commit adds a new triple value for the Logical
addressing model.

Differential Revision: https://reviews.llvm.org/D155978

show more ...

[clang] Introduce copy-on-write `CompilerInvocation` (#65412)

This PR introduces new copy-on-write `CompilerInvocation` class
(`CowCompilerInvocation`), which will be used by the dependency scanner

[clang] Introduce copy-on-write `CompilerInvocation` (#65412)

This PR introduces new copy-on-write `CompilerInvocation` class
(`CowCompilerInvocation`), which will be used by the dependency scanner
to reduce the number of copies performed when generating command lines
for discovered modules.

show more ...

[clang] Make the entire `CompilerInvocation` ref-counted (#65647)

This enables making the whole `CompilerInvocation` more efficient
through copy-on-write.

[clang] NFCI: Change returned AnalyzerOptions smart pointer to reference

[clang] NFCI: Change returned LanguageOptions pointer to reference

[Clang] Enable AIX initial-exec TLS mode

Reviewed By: shchenz

Differential Revision: https://reviews.llvm.org/D156076

[Driver] Refactor to use llvm Option's new Visibility flags

This is a big refactor of the clang driver's option handling to use
the Visibility flags introduced in https://reviews.llvm.org/D157149.
T

[Driver] Refactor to use llvm Option's new Visibility flags

This is a big refactor of the clang driver's option handling to use
the Visibility flags introduced in https://reviews.llvm.org/D157149.
There are a few distinct parts, but they can't really be split into
separate commits and still be made to compile.

1. We split out some of the flags in ClangFlags to ClangVisibility.
Note that this does not include any subtractive flags.

2. We update the Flag definitions and OptIn/OptOut constructs in
Options.td by hand.

3. We introduce and use a script, update_options_td_flags, to ease
migration of flag definitions in Options.td, and we run that on
Options.td. I intend to remove this later, but I'm committing it so
that downstream forks can use the script to simplify merging.

4. We update calls to OptTable in the clang driver, cc1as, flang, and
clangd to use the visibility APIs instead of Include/Exclude flags.

5. We deprecate the Include/Exclude APIs and add a release note.

*if you are running into conflicts with this change:*

Note that https://reviews.llvm.org/D157150 may also be the culprit and
if so it should be handled first.

The script in `clang/utils/update_options_td_flags.py` can help. Take
the downstream side of all conflicts and then run the following:

```
% cd clang/include/clang/Driver
% ../../../utils/update_options_td_flags.py Options.td > Options.td.new
% mv Options.td.new Options.td
```

This will hopefully be sufficient, please take a look at the diff.

Differential Revision: https://reviews.llvm.org/D157151

show more ...

Reapply "[Option] Add "Visibility" field and clone the OptTable APIs to use it"

This reverts commit 4e3b89483a6922d3f48670bb1c50a37f342918c6, with
fixes for places I'd missed updating in lld and lld

Reapply "[Option] Add "Visibility" field and clone the OptTable APIs to use it"

This reverts commit 4e3b89483a6922d3f48670bb1c50a37f342918c6, with
fixes for places I'd missed updating in lld and lldb. I've also
renamed OptionVisibility::Default to "DefaultVis" to avoid ambiguity
since the undecorated name has to be available anywhere Options.inc is
included.

Original message follows:

This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and adds
variants of the OptTable APIs that use Visibility mask instead of
Include/Exclude flags.

We need to do this to clean up a bunch of complexity in the clang
driver's option handling - there's a whole slew of flags like
CoreOption, NoDriverOption, and FlangOnlyOption there today to try to
handle all of the permutations of flags that the various drivers need,
but it really doesn't scale well, as can be seen by things like the
somewhat recently introduced CLDXCOption.

Instead, we'll provide an additive model for visibility that's
separate from the other flags. For things like "HelpHidden", which is
used as a "subtractive" modifier for option visibility, we leave that
in "Flags" and handle it as a special case.

Note that we don't actually update the users of the Include/Exclude
APIs here or change the flags that exist in clang at all - that will
come in a follow up that refactors clang's Options.td to use the
increased flexibility this change allows.

Differential Revision: https://reviews.llvm.org/D157149

show more ...

Revert "[Option] Add "Visibility" field and clone the OptTable APIs to use it"

this is failing on bots, reverting to investigate.

This reverts commit a16104e6da6f36f3d72dbf53d10ba56495a0d65a.

[Option] Add "Visibility" field and clone the OptTable APIs to use it

This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and a

[Option] Add "Visibility" field and clone the OptTable APIs to use it

This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and adds
variants of the OptTable APIs that use Visibility mask instead of
Include/Exclude flags.

We need to do this to clean up a bunch of complexity in the clang
driver's option handling - there's a whole slew of flags like
CoreOption, NoDriverOption, and FlangOnlyOption there today to try to
handle all of the permutations of flags that the various drivers need,
but it really doesn't scale well, as can be seen by things like the
somewhat recently introduced CLDXCOption.

Instead, we'll provide an additive model for visibility that's
separate from the other flags. For things like "HelpHidden", which is
used as a "subtractive" modifier for option visibility, we leave that
in "Flags" and handle it as a special case.

Note that we don't actually update the users of the Include/Exclude
APIs here or change the flags that exist in clang at all - that will
come in a follow up that refactors clang's Options.td to use the
increased flexibility this change allows.

Differential Revision: https://reviews.llvm.org/D157149

show more ...

[clang] NFC: Use compile-time option spelling when generating command line

When generating command lines, use the option spelling generated by TableGen (`StringLiteral`) instead of constructing it a

[clang] NFC: Use compile-time option spelling when generating command line

When generating command lines, use the option spelling generated by TableGen (`StringLiteral`) instead of constructing it at runtime. This saves some needless allocations.

Depends on D157029.

Reviewed By: benlangmuir, MaskRay

Differential Revision: https://reviews.llvm.org/D157054

show more ...

[llvm] Construct option's prefixed name at compile-time

Some Clang command-line handling code could benefit from the option's prefixed name being a `StringLiteral`. This patch changes the `llvm::opt

[llvm] Construct option's prefixed name at compile-time

Some Clang command-line handling code could benefit from the option's prefixed name being a `StringLiteral`. This patch changes the `llvm::opt` TableGen backend to generate and emit that into the .inc file.

Depends on D157028.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D157029

show more ...

Revert "Anonymous unions should be transparent wrt `[[clang::trivial_abi]]`."

This reverts commit bddaa35177861545fc329123e55b6a3b34549507.
Reverting as requested at https://reviews.llvm.org/D155895

Revert "Anonymous unions should be transparent wrt `[[clang::trivial_abi]]`."

This reverts commit bddaa35177861545fc329123e55b6a3b34549507.
Reverting as requested at https://reviews.llvm.org/D155895#4566945
(for breaking tests on Windows).

show more ...

Anonymous unions should be transparent wrt `[[clang::trivial_abi]]`.

Anonymous unions should be transparent wrt `[[clang::trivial_abi]]`.

Consider the test input below:

```
struct [[clang::trivi

Anonymous unions should be transparent wrt `[[clang::trivial_abi]]`.

Anonymous unions should be transparent wrt `[[clang::trivial_abi]]`.

Consider the test input below:

```
struct [[clang::trivial_abi]] Trivial {
Trivial() {}
Trivial(Trivial&& other) {}
Trivial& operator=(Trivial&& other) { return *this; }
~Trivial() {}
};
static_assert(__is_trivially_relocatable(Trivial), "");

struct [[clang::trivial_abi]] S2 {
S2(S2&& other) {}
S2& operator=(S2&& other) { return *this; }
~S2() {}
union { Trivial field; };
};
static_assert(__is_trivially_relocatable(S2), "");
```

Before the fix Clang would warn that 'trivial_abi' is disallowed on 'S2'
because it has a field of a non-trivial class type (the type of the
anonymous union is non-trivial, because it doesn't have the
`[[clang::trivial_abi]]` attribute applied to it). Consequently, before
the fix the `static_assert` about `__is_trivially_relocatable` would
fail.

Note that `[[clang::trivial_abi]]` cannot be applied to the anonymous
union, because Clang warns that 'trivial_abi' is disallowed on '(unnamed
union at ...)' because its copy constructors and move constructors are
all deleted. Also note that it is impossible to provide copy nor move
constructors for anonymous unions and structs.

Reviewed By: gribozavr2

Differential Revision: https://reviews.llvm.org/D155895

show more ...

[clang] NFC: Avoid double allocation when generating command line

This patch makes use of the infrastructure established in D157046 to avoid needless allocations via `StringSaver`.

Depends on D1570

[clang] NFC: Avoid double allocation when generating command line

This patch makes use of the infrastructure established in D157046 to avoid needless allocations via `StringSaver`.

Depends on D157046.

Reviewed By: benlangmuir

Differential Revision: https://reviews.llvm.org/D157048

show more ...

[clang] Abstract away string allocation in command line generation

This patch abstracts away the string allocation and vector push-back from command line generation. Instead, **all** generated argum

[clang] Abstract away string allocation in command line generation

This patch abstracts away the string allocation and vector push-back from command line generation. Instead, **all** generated arguments are passed into `ArgumentConsumer`, which may choose to do the string allocation and vector push-back, or something else entirely.

Reviewed By: benlangmuir

Differential Revision: https://reviews.llvm.org/D157046

show more ...

[clang][cli] Accept option spelling as `Twine`

This will make it possible to accept the spelling as `StringLiteral` in D157029 and avoid some unnecessary allocations in a later patch.

Reviewed By:

[clang][cli] Accept option spelling as `Twine`

This will make it possible to accept the spelling as `StringLiteral` in D157029 and avoid some unnecessary allocations in a later patch.

Reviewed By: benlangmuir

Differential Revision: https://reviews.llvm.org/D157035

show more ...

[clang] Support Unified LTO Bitcode Frontend

The unified LTO pipeline creates a single LTO bitcode structure that can
be used by Thin or Full LTO. This means that the LTO mode can be chosen
at link

[clang] Support Unified LTO Bitcode Frontend

The unified LTO pipeline creates a single LTO bitcode structure that can
be used by Thin or Full LTO. This means that the LTO mode can be chosen
at link time and that all LTO bitcode produced by the pipeline is
compatible, from an optimization perspective. This makes the behavior of
LTO a bit more predictable by normalizing the set of LTO features
supported by each LTO bitcode file.

Example usage:

# Compile and link. Select regular LTO at link time.
clang -flto -funified-lto -fuse-ld=lld foo.c

# Compile and link. Select ThinLTO at link time.
clang -flto=thin -funified-lto -fuse-ld=lld foo.c

# Link separately, using ThinLTO.
clang -c -flto -funified-lto foo.c # -flto={full,thin} are identical in
terms of compilation actions
clang -flto=thin -fuse-ld=lld foo.o # pass --lto=thin to ld.lld

# Link separately, using regular LTO.
clang -c -flto -funified-lto foo.c
clang -flto -fuse-ld=lld foo.o # pass --lto=full to ld.lld

The RFC discussing the details and rational for this change is here:
https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode-frontend/61774

show more ...

[OpenMP][OMPIRBuilder] Rename IsEmbedded and IsTargetCodegen flags

This patch renames the `OpenMPIRBuilderConfig` flags to reduce confusion over
their meaning. `IsTargetCodegen` becomes `IsGPU`, whe

[OpenMP][OMPIRBuilder] Rename IsEmbedded and IsTargetCodegen flags

This patch renames the `OpenMPIRBuilderConfig` flags to reduce confusion over
their meaning. `IsTargetCodegen` becomes `IsGPU`, whereas `IsEmbedded` becomes
`IsTargetDevice`. The `-fopenmp-is-device` compiler option is also renamed to
`-fopenmp-is-target-device` and the `omp.is_device` MLIR attribute is renamed
to `omp.is_target_device`. Getters and setters of all these renamed properties
are also updated accordingly. Many unit tests have been updated to use the new
names, but an alias for the `-fopenmp-is-device` option is created so that
external programs do not stop working after the name change.

`IsGPU` is set when the target triple is AMDGCN or NVIDIA PTX, and it is only
valid if `IsTargetDevice` is specified as well. `IsTargetDevice` is set by the
`-fopenmp-is-target-device` compiler frontend option, which is only added to
the OpenMP device invocation for offloading-enabled programs.

Differential Revision: https://reviews.llvm.org/D154591

show more ...

[analyzer] Remove deprecated analyzer-config options

The `consider-single-element-arrays-as-flexible-array-members` analyzer
option was deprecated in clang-16, and now removed from clang-17 as
promi

[analyzer] Remove deprecated analyzer-config options

The `consider-single-element-arrays-as-flexible-array-members` analyzer
option was deprecated in clang-16, and now removed from clang-17 as
promised in
https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html#static-analyzer

This shouldn't change observable behavior.

Differential Revision: https://reviews.llvm.org/D154481

show more ...

[AIX][TLS] Relax front end diagnostics to accept the local-exec TLS model

This patch relaxes the front end AIX diagnostics added in D102070 to accept the
local-exec TLS model, as we plan to support

[AIX][TLS] Relax front end diagnostics to accept the local-exec TLS model

This patch relaxes the front end AIX diagnostics added in D102070 to accept the
local-exec TLS model, as we plan to support this model in a series of future patches.

The diagnostics are relaxed when local-exec is used as a compiler option to
`-ftls-model=*` and in the `__attribute__((tls_model("local-exec")))` attribute.

Differential Revision: https://reviews.llvm.org/D149596

show more ...

[OpenMP] Update the default version of OpenMP to 5.1

The default version of OpenMP is updated from 5.0 to 5.1 which means if -fopenmp is specified but -fopenmp-version is not specified with clang, t

[OpenMP] Update the default version of OpenMP to 5.1

The default version of OpenMP is updated from 5.0 to 5.1 which means if -fopenmp is specified but -fopenmp-version is not specified with clang, the default version of OpenMP is taken to be 5.1. After modifying the Frontend for that, various LIT tests were updated. This patch contains all such changes. At a high level, these are the patterns of changes observed in LIT tests -

# RUN lines which mentioned `-fopenmp-version=50` need to kept only if the IR for version 5.0 and 5.1 are different. Otherwise only one RUN line with no version info(i.e. default version) needs to be there.

# Test cases of this sort already had the RUN lines with respect to the older default version 5.0 and the version 5.1. Only swapping the version specification flag `-fopenmp-version` from newer version RUN line to older version RUN line is required.

# Diagnostics: Remove the 5.0 version specific RUN lines if there was no difference in the Diagnostics messages with respect to the default 5.1.

# Diagnostics: In case there was any difference in diagnostics messages between 5.0 and 5.1, mention version specific messages in tests.

# If the test contained version specific ifdef's e.g. "#ifdef OMP5" but there were no RUN lines for any other version than 5.X, then bring the code guarded by ifdef's outside and remove the ifdef's.

# Some tests had RUN lines for both 5.0 and 5.1 versions, but it is found that the IR for 5.0 is not different from the 5.1, therefore such RUN lines are redundant. So, such duplicated lines are removed.

# To generate CHECK lines automatically, use the script llvm/utils/update_cc_test_checks.py

Reviewed By: saiislam, ABataev

Differential Revision: https://reviews.llvm.org/D129635

(cherry picked from commit 9dd2999907dc791136a75238a6000f69bf67cf4e)

show more ...

Add support for the NO_COLOR environment variable

Clang currently supports disabling color diagnostic output via
-fno-color-diagnostics. However, there is a somewhat long-standing push
to support us

Add support for the NO_COLOR environment variable

Clang currently supports disabling color diagnostic output via
-fno-color-diagnostics. However, there is a somewhat long-standing push
to support use of an environment variable to override color output so
that users can set up their terminal such that most color output is
disabled (largely for accessibility reasons).

There are two competing de facto standards to accomplish this:
NO_COLOR (https://no-color.org/) and
CLICOLOR/CLICOLOR_FORCE (http://bixense.com/clicolors/).

This patch adds support for NO_COLOR as that appears to be the more
commonly supported feature, at least when comparing issues and pull
requests:
https://github.com/search?q=NO_COLOR&type=issues (2.2k issues, 35k pull requests)
https://github.com/search?q=CLICOLOR&type=issues (1k issues, 3k pull requests)

It's also the more straightforward and thoroughly-specified of the two
options. If NO_COLOR is present as an environment variable (regardless
of value), color output is suppressed unless the command line specifies
use of color output (command line takes precedence over the environment
variable).

Differential Revision: https://reviews.llvm.org/D152285

show more ...

print user provide value in tabstop diagnostic

github issue: https://github.com/llvm/llvm-project/issues/62912

Reviewed By: jansvoboda11

Differential Revision: https://reviews.llvm.org/D151429

[gcov] Simplify cc1 options and remove CodeGenOptions EmitCovNotes/EmitCovArcs

After a07b135ce0c0111bd83450b5dc29ef0381cdbc39, we always pass
-coverage-notes-file/-coverage-data-file for driver opti

[gcov] Simplify cc1 options and remove CodeGenOptions EmitCovNotes/EmitCovArcs

After a07b135ce0c0111bd83450b5dc29ef0381cdbc39, we always pass
-coverage-notes-file/-coverage-data-file for driver options
-ftest-coverage/-fprofile-arcs/--coverage. As a bonus, we can make the following
simplification to cc1 options:

* `-ftest-coverage -coverage-notes-file a.gcno` => `-coverage-notes-file a.gcno`
* `-fprofile-arcs -coverage-data-file a.gcda` => `-coverage-data-file a.gcda`

and remove EmitCovNotes/EmitCovArcs.

show more ...