History log of /llvm-project/clang/lib/Frontend/CompilerInvocation.cpp (Results 51 – 75 of 1971)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-18.1.5
# 359ab3ae 29-Apr-2024 Nathan Lanza <nathanlanza@gmail.com>

[CIR] Add options to emit ClangIR and enable the ClangIR pipeline

Introduce just the option definitions and support for their existance at
a few different points in the frontend. This will be follow

[CIR] Add options to emit ClangIR and enable the ClangIR pipeline

Introduce just the option definitions and support for their existance at
a few different points in the frontend. This will be followed soon by
functionality that uses it.

Reviewers: bcardosolopes, jansvoboda11, AaronBallman, erichkeane, MaskRay

Reviewed By: erichkeane

Pull Request: https://github.com/llvm/llvm-project/pull/89030

show more ...


# 64cc3fad 19-Apr-2024 cor3ntin <corentinjabot@gmail.com>

[Clang] Fix the mangling of lambdas (#89204)

Lambdas used in the initializer of a local class were not mangling the
name of the member.

Fixes #88906


# e772a268 18-Apr-2024 Orlando Cazalet-Hyams <orlando.hyams@sony.com>

[Clang] Emit DW_TAG_template_alias for template aliases (#87623)

Fix issue https://github.com/llvm/llvm-project/issues/54624

Add front end flags -gtemplate-alias (also a cc1 flag) and -gno-templa

[Clang] Emit DW_TAG_template_alias for template aliases (#87623)

Fix issue https://github.com/llvm/llvm-project/issues/54624

Add front end flags -gtemplate-alias (also a cc1 flag) and -gno-template-alias
to enable/disable usage of the feature. It's enabled by default in the front
end for SCE debugger tuning only.

GCC emits DW_TAG_typedef for template aliases (as does Clang with this feature
disabled), and GDB and LLDB appear not to support DW_TAG_template_alias.

The -Xclang option -gsimple-template-names=mangled is treated the same as
=full, which is not a regression from current behaviour for template
aliases.

The current implementation omits defaulted arguments and as a consequence
also omits empty parameter packs that come after defaulted arguments. Again,
this isn't a regression as the DW_TAG_typedef name doesn't contain defaulted
arguments.

LLVM support added in https://github.com/llvm/llvm-project/pull/88943

Added template-alias.cpp - Check the metadata construction & interaction with
-gsimple-template-names.
Added variadic-template-alias.cpp - Check template parameter packs work.
Added defaulted-template-alias.cpp - Check defaulted args (don't) work.
Modified debug-options.c - Check Clang generates correct cc1 flags.

show more ...


Revision tags: llvmorg-18.1.4
# aff197ff 05-Apr-2024 David Spickett <david.spickett@linaro.org>

Reland "[flang][clang] Add Visibility specific help text for options (#81869)"

This reverts commit 67d20412b448533c77f54ac7a1e5d0775d273729.

This includes fixes for clanginstallapi.


# 67d20412 05-Apr-2024 David Spickett <david.spickett@linaro.org>

Revert "[flang][clang] Add Visibility specific help text for options (#81869)"

This reverts commit 7e958f64efea6cb824e96ace51e021afbc150922.

Failing on multiple bots.


# 7e958f64 05-Apr-2024 David Spickett <david.spickett@linaro.org>

[flang][clang] Add Visibility specific help text for options (#81869)

And use it to print the correct default OpenMP version for flang and
flang -fc1.

This change adds an optional `HelpTextsForV

[flang][clang] Add Visibility specific help text for options (#81869)

And use it to print the correct default OpenMP version for flang and
flang -fc1.

This change adds an optional `HelpTextsForVariants` to options. This
allows you to change the help text that gets shown in documentation and
`--help` based on the program its being generated for.

As `OptTable` needs to be constexpr compatible, I have used a std::array
of help text variants. Each entry is:
(list of visibilities) - > help text string

So for the OpenMP version we have (flang, fc1) -> "OpenMP version for
flang is...".

So you can have multiple visibilities use the same string. The number of
entries is currently set to 1, and the number of visibilities per entry
is 2, because that's the maximum we need for now. The code is written so
we can increase these numbers later, and the unused elements will be initialised.

I have not applied this to group descriptions just because I don't know
of one that needs changing. It could easily be enabled for those too if
needed. There are minor changes to them just to get it all to compile.

This approach of storing many help strings per option in the 1 driver
library seemed preferable to making a whole new library for Flang (even
if that would mostly be including stuff from Clang).

show more ...


Revision tags: llvmorg-18.1.3
# 3d469c0e 02-Apr-2024 aniplcc <aniplccode@gmail.com>

[HLSL] Enable -fconvergent-functions by default (#86571)

Fixes #86506


# 6f10dccb 28-Mar-2024 Joshua Batista <jbatista@microsoft.com>

[HLSL] Add validation for the -enable-16bit-types option (#85340)

Previously, the clang compiler with the dxc driver would accept the
-enable-16bit-types flag without checking to see if the require

[HLSL] Add validation for the -enable-16bit-types option (#85340)

Previously, the clang compiler with the dxc driver would accept the
-enable-16bit-types flag without checking to see if the required
conditions are met for proper processing of the flag.
Specifically, -enable-16bit-types requires a shader model of at least
6.2 and an HLSL version of at least 2021.
This PR adds a validation check for these other options having the
required values, and emits an error if these constraints are not met.
Fixes #57876

---------

Co-authored-by: Damyan Pepper <damyanp@microsoft.com>
Co-authored-by: Chris B <cbieneman@microsoft.com>

show more ...


# e66b670f 21-Mar-2024 Nathan Lanza <nathanlanza@gmail.com>

[CIR][Basic][NFC] Add the CIR language to the Language enum

Add the CIR language to the Language enum and the standard usages of it.

commit-id:fd12b2c2

Reviewers: bcardosolopes, AaronBallman, eric

[CIR][Basic][NFC] Add the CIR language to the Language enum

Add the CIR language to the Language enum and the standard usages of it.

commit-id:fd12b2c2

Reviewers: bcardosolopes, AaronBallman, erichkeane

Reviewed By: AaronBallman, bcardosolopes

Pull Request: https://github.com/llvm/llvm-project/pull/86072

show more ...


Revision tags: llvmorg-18.1.2
# 12a65463 19-Mar-2024 Evan Wilde <etceterawilde@gmail.com>

Add support for sysroot-relative system header search paths (#82084)

Clang supported header searchpaths of the form `-I =/path`, relative to
the sysroot if one is passed, but did not implement that

Add support for sysroot-relative system header search paths (#82084)

Clang supported header searchpaths of the form `-I =/path`, relative to
the sysroot if one is passed, but did not implement that behavior for
`-iquote`, `-isystem`, or `-idirafter`.

This implements the `=` portion of the behavior implemented by GCC for
these flags described in
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html.

show more ...


# 0481f049 15-Mar-2024 Ahmed Bougacha <ahmed@bougacha.org>

[AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (#65996)

This defines the basic set of pointer authentication clang builtins
(provided in a new header, ptrauth.h), with diagnostic

[AArch64][PAC] Support ptrauth builtins and -fptrauth-intrinsics. (#65996)

This defines the basic set of pointer authentication clang builtins
(provided in a new header, ptrauth.h), with diagnostics and IRGen
support. The availability of the builtins is gated on a new flag,
`-fptrauth-intrinsics`.

Note that this only includes the basic intrinsics, and notably excludes
`ptrauth_sign_constant`, `ptrauth_type_discriminator`, and
`ptrauth_string_discriminator`, which need extra logic to be fully
supported.

This also introduces clang/docs/PointerAuthentication.rst, which
describes the ptrauth model in general, in addition to these builtins.

Co-Authored-By: Akira Hatanaka <ahatanaka@apple.com>
Co-Authored-By: John McCall <rjmccall@apple.com>

show more ...


Revision tags: llvmorg-18.1.1
# c9062e8f 06-Mar-2024 Ulrich Weigand <ulrich.weigand@de.ibm.com>

Reapply [libomptarget] Build plugins-nextgen for SystemZ (#83978)

The plugin was not getting built as the build_generic_elf64 macro
assumes the LLVM triple processor name matches the CMake processor

Reapply [libomptarget] Build plugins-nextgen for SystemZ (#83978)

The plugin was not getting built as the build_generic_elf64 macro
assumes the LLVM triple processor name matches the CMake processor name,
which is unfortunately not the case for SystemZ.

Fix this by providing two separate arguments instead.

Actually building the plugin exposed a number of other issues causing
various test failures. Specifically, I've had to add the SystemZ target
to
- CompilerInvocation::ParseLangArgs
- linkDevice in ClangLinuxWrapper.cpp
- OMPContext::OMPContext (to set the device_kind_cpu trait)
- LIBOMPTARGET_ALL_TARGETS in libomptarget/CMakeLists.txt
- a check_plugin_target call in libomptarget/src/CMakeLists.txt

Finally, I've had to set a number of test cases to UNSUPPORTED on
s390x-ibm-linux-gnu; all these tests were already marked as UNSUPPORTED
for x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu and are failing on
s390x for what seem to be the same reason.

In addition, this also requires support for BE ELF files in
plugins-nextgen: https://github.com/llvm/llvm-project/pull/85246

show more ...


# da00c60d 08-Mar-2024 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

[C++20] [Modules] Introduce reduced BMI (#75894)

Close https://github.com/llvm/llvm-project/issues/71034

See

https://discourse.llvm.org/t/rfc-c-20-modules-introduce-thin-bmi-and-decls-hash/747

[C++20] [Modules] Introduce reduced BMI (#75894)

Close https://github.com/llvm/llvm-project/issues/71034

See

https://discourse.llvm.org/t/rfc-c-20-modules-introduce-thin-bmi-and-decls-hash/74755

This patch introduces reduced BMI, which doesn't contain the definitions
of functions and variables if its definitions won't contribute to the
ABI.

Testing is a big part of the patch. We want to make sure the reduced BMI
contains the same behavior with the existing and relatively stable
fatBMI. This is pretty helpful for further reduction.

The user interfaces part it left to following patches to ease the
reviewing.

show more ...


# 70677c81 06-Mar-2024 Ulrich Weigand <ulrich.weigand@de.ibm.com>

Revert "[libomptarget] Build plugins-nextgen for SystemZ (#83978)"

This reverts commit 3ecd38c8e1d34b1e4639a1de9f0cb56c7957cbd2.


# 3ecd38c8 06-Mar-2024 Ulrich Weigand <ulrich.weigand@de.ibm.com>

[libomptarget] Build plugins-nextgen for SystemZ (#83978)

The plugin was not getting built as the build_generic_elf64 macro
assumes the LLVM triple processor name matches the CMake processor name,

[libomptarget] Build plugins-nextgen for SystemZ (#83978)

The plugin was not getting built as the build_generic_elf64 macro
assumes the LLVM triple processor name matches the CMake processor name,
which is unfortunately not the case for SystemZ.

Fix this by providing two separate arguments instead.

Actually building the plugin exposed a number of other issues causing
various test failures. Specifically, I've had to add the SystemZ target
to
- CompilerInvocation::ParseLangArgs
- linkDevice in ClangLinuxWrapper.cpp
- OMPContext::OMPContext (to set the device_kind_cpu trait)
- LIBOMPTARGET_ALL_TARGETS in libomptarget/CMakeLists.txt
- a check_plugin_target call in libomptarget/src/CMakeLists.txt

Finally, I've had to set a number of test cases to UNSUPPORTED on
s390x-ibm-linux-gnu; all these tests were already marked as UNSUPPORTED
for x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu and are failing on
s390x for what seem to be the same reason.

In addition, this also requires support for BE ELF files in
plugins-nextgen: https://github.com/llvm/llvm-project/pull/83976

show more ...


# 164c0985 02-Mar-2024 Jan Svoboda <jan_svoboda@apple.com>

[clang][deps] Implement move-conversion for `CowCompilerInvocation` (follow-up)


# 5b058709 01-Mar-2024 Felix (Ting Wang) <Ting.Wang.SH@ibm.com>

[PowerPC] Support local-dynamic TLS relocation on AIX (#66316)

Supports TLS local-dynamic on AIX, generates below sequence of code:

```
.tc foo[TC],foo[TL]@ld # Variable offset, ld relocation sp

[PowerPC] Support local-dynamic TLS relocation on AIX (#66316)

Supports TLS local-dynamic on AIX, generates below sequence of code:

```
.tc foo[TC],foo[TL]@ld # Variable offset, ld relocation specifier
.tc mh[TC],mh[TC]@ml # Module handle for the caller
lwz 3,mh[TC]\(2\) $$ For 64-bit: ld 3,mh[TC]\(2\)
bla .__tls_get_mod # Modifies r0,r3,r4,r5,r11,lr,cr0
#r3 = &TLS for module
lwz 4,foo[TC]\(2\) $$ For 64-bit: ld 4,foo[TC]\(2\)
add 5,3,4 # Compute &foo
.rename mh[TC], "\_$TLSML" # Symbol for the module handle must have the name "_$TLSML"
```

---------

Co-authored-by: tingwang <tingwang@tingwangs-MBP.lan>
Co-authored-by: tingwang <tingwang@tingwangs-MacBook-Pro.local>

show more ...


Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4
# 0a518db9 21-Feb-2024 Cyndy Ishida <cyndy_ishida@apple.com>

[InstallAPI] Set InstallAPI as a standalone tool instead of CC1 action (#82293)

Installapi has important distinctions when compared to the clang driver,
so much that, it doesn't make much sense to

[InstallAPI] Set InstallAPI as a standalone tool instead of CC1 action (#82293)

Installapi has important distinctions when compared to the clang driver,
so much that, it doesn't make much sense to try to integrate into it.

This patch partially reverts the CC1 action & driver support to replace
with its own driver as a clang tool.

For distribution, we could use `LLVM_TOOL_LLVM_DRIVER_BUILD` mechanism
for integrating the functionality into clang such that the toolchain
size is less impacted.

show more ...


Revision tags: llvmorg-18.1.0-rc3
# 09e98950 14-Feb-2024 Cyndy Ishida <cyndy_ishida@apple.com>

[clang][InstallAPI] Introduce basic driver to write out tbd files (#81571)

This introduces a basic outline of installapi as a clang driver option.
It captures relevant information as cc1 args, whic

[clang][InstallAPI] Introduce basic driver to write out tbd files (#81571)

This introduces a basic outline of installapi as a clang driver option.
It captures relevant information as cc1 args, which are common arguments
already passed to the linker to encode into TBD file outputs. This is
effectively an upstream for what already exists as `tapi installapi` in
Xcode toolchains, but directly in Clang. This patch does not handle any
AST traversing on input yet.

InstallAPI is broadly an operation that takes a series of header files
that represent a single dynamic library and generates a TBD file out of
it which represents all the linkable symbols and necessary attributes
for statically linking in clients. It is the linkable object in all
Apple SDKs and when building dylibs in Xcode. `clang -installapi` also
will support verification where it compares all the information recorded
for the TBD files against the already built binary, to catch possible
mismatches like when a declaration is missing a definition for an
exported symbol.

show more ...


Revision tags: llvmorg-18.1.0-rc2
# 7847e445 30-Jan-2024 Michael Spencer <bigcheesegs@gmail.com>

[clang][DependencyScanner] Remove unused -ivfsoverlay files (#73734)

`-ivfsoverlay` files are unused when building most modules. Enable
removing them by,
* adding a way to visit the filesystem tre

[clang][DependencyScanner] Remove unused -ivfsoverlay files (#73734)

`-ivfsoverlay` files are unused when building most modules. Enable
removing them by,
* adding a way to visit the filesystem tree with extensible RTTI to
access each `RedirectingFileSystem`.
* Adding tracking to `RedirectingFileSystem` to record when it
actually redirects a file access.
* Storing this information in each PCM.

Usage tracking is only enabled when iterating over the source manager
and affecting modulemaps. Here each path is stated to cause an access.
During scanning these stats all hit the cache.

show more ...


Revision tags: llvmorg-18.1.0-rc1, llvmorg-19-init
# 9d476e1e 23-Jan-2024 Paul Kirth <paulkirth@google.com>

[clang][FatLTO] Avoid UnifiedLTO until it can support WPD/CFI (#79061)

Currently, the UnifiedLTO pipeline seems to have trouble with several
LTO features, like SplitLTO units, which means we cannot

[clang][FatLTO] Avoid UnifiedLTO until it can support WPD/CFI (#79061)

Currently, the UnifiedLTO pipeline seems to have trouble with several
LTO features, like SplitLTO units, which means we cannot use important
optimizations like Whole Program Devirtualization or security hardening
instrumentation like CFI.

This patch reverts FatLTO to using distinct pipelines for Full LTO and
ThinLTO. It still avoids module cloning, since that was error prone.

show more ...


# 997ffce4 21-Jan-2024 Aaron Ballman <aaron@aaronballman.com>

[C23] Implement N2490, Remove trigraphs??!

This follows the same implementation logic as with C++ and is
compatible with the GCC behavior in C.

Trigraphs are enabled by default in -std=c* conforman

[C23] Implement N2490, Remove trigraphs??!

This follows the same implementation logic as with C++ and is
compatible with the GCC behavior in C.

Trigraphs are enabled by default in -std=c* conformance modes before
C23, but are disabled in GNU and Microsoft modes as well as in C23 or
later.

show more ...


# 85114360 20-Jan-2024 Kazu Hirata <kazu@google.com>

[Frontend] Use SmallString::operator std::string (NFC)


# c21f48e5 18-Jan-2024 Natalie Chouinard <sudonatalie@google.com>

[HLSL][SPIR-V] Add Vulkan to target triple (#76749)

Add support for specifying the logical SPIR-V target environment in the
triple as Vulkan. When compiling HLSL, this replaces the DirectX Shader

[HLSL][SPIR-V] Add Vulkan to target triple (#76749)

Add support for specifying the logical SPIR-V target environment in the
triple as Vulkan. When compiling HLSL, this replaces the DirectX Shader
Model with a Vulkan environment instead.

Currently, the only supported combinations of SPIR-V version and Vulkan
environment are:
- Vulkan 1.2 and SPIR-V 1.5
- Vulkan 1.3 and SPIR-V 1.6

Fixes #70051

show more ...


# f3dcc235 13-Dec-2023 Kazu Hirata <kazu@google.com>

[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}:

[clang] Use StringRef::{starts,ends}_with (NFC) (#75149)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...


12345678910>>...79