[DOCS] Minor fixes and removals of WIP warnings

[clang] Add a new flag -fexperimental-library to enable experimental library features

Based on the discussion at [1], this patch adds a Clang flag called
-fexperimental-library that controls whether

[clang] Add a new flag -fexperimental-library to enable experimental library features

Based on the discussion at [1], this patch adds a Clang flag called
-fexperimental-library that controls whether experimental library
features are provided in libc++. In essence, it links against the
experimental static archive provided by libc++ and defines a feature
that can be picked up by libc++ to enable experimental features.

This ensures that users don't start depending on experimental
(and hence unstable) features unknowingly.

[1]: https://discourse.llvm.org/t/rfc-a-compiler-flag-to-enable-experimental-unstable-language-and-library-features

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

show more ...

[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays

Some code [0] consider that trailing arrays are flexible, whatever their size.
Support for these legacy code has b

[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays

Some code [0] consider that trailing arrays are flexible, whatever their size.
Support for these legacy code has been introduced in
f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of
__builtin_object_size and __builtin_dynamic_object_size in some legit cases.

Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is
desirable.

n = 0: current behavior, any trailing array member is a flexible array. The default.
n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member
n = 2: any trailing array member of undefined or 0 size is a flexible array member

This takes into account two specificities of clang: array bounds as macro id
disqualify FAM, as well as non standard layout.

Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836

[0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions

show more ...

[InstrProf] Add options to profile function groups

Add two options, `-fprofile-function-groups=N` and `-fprofile-selected-function-group=i` used to partition functions into `N` groups and only instr

[InstrProf] Add options to profile function groups

Add two options, `-fprofile-function-groups=N` and `-fprofile-selected-function-group=i` used to partition functions into `N` groups and only instrument the functions in group `i`. Similar options were added to xray in https://reviews.llvm.org/D87953 and the goal is the same; to reduce instrumented size overhead by spreading the overhead across multiple builds. Raw profiles from different groups can be added like normal using the `llvm-profdata merge` command.

Reviewed By: ianlevesque

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

show more ...

[SystemZ] Enable `-mtune=` option in clang.

https://reviews.llvm.org/D128910 enabled handling of
attribute "tune-cpu" in LLVM. This PR now enables
option `-mtune` in clang, which then generates the

[SystemZ] Enable `-mtune=` option in clang.

https://reviews.llvm.org/D128910 enabled handling of
attribute "tune-cpu" in LLVM. This PR now enables
option `-mtune` in clang, which then generates the
new attribute.

Reviewed By: uweigand

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

show more ...

[X86] Support -mstack-protector-guard-symbol

Reviewed By: nickdesaulniers

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

Revert "[X86] Support -mstack-protector-guard-symbol"

This reverts commit efbaad1c4a526e91b034e56386e98a9268cd87b2.
due to miss adding review info.

[X86] Support -mstack-protector-guard-symbol

[clang][NFC] Re-generate CommandLineReference.rst

Revert "[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays"

This reverts D126864 and related fixes.

This reverts commit 572b08790a69f955ae0cbb1b4a7d4a215f15dad9.
Th

Revert "[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays"

This reverts D126864 and related fixes.

This reverts commit 572b08790a69f955ae0cbb1b4a7d4a215f15dad9.
This reverts commit 886715af962de2c92fac4bd37104450345711e4a.

show more ...

[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays

Some code [0] consider that trailing arrays are flexible, whatever their size.
Support for these legacy code has b

[clang] Introduce -fstrict-flex-arrays=<n> for stricter handling of flexible arrays

Some code [0] consider that trailing arrays are flexible, whatever their size.
Support for these legacy code has been introduced in
f8f632498307d22e10fab0704548b270b15f1e1e but it prevents evaluation of
__builtin_object_size and __builtin_dynamic_object_size in some legit cases.

Introduce -fstrict-flex-arrays=<n> to have stricter conformance when it is
desirable.

n = 0: current behavior, any trailing array member is a flexible array. The default.
n = 1: any trailing array member of undefined, 0 or 1 size is a flexible array member
n = 2: any trailing array member of undefined or 0 size is a flexible array member
n = 3: any trailing array member of undefined size is a flexible array member (strict c99 conformance)

Similar patch for gcc discuss here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836

[0] https://docs.freebsd.org/en/books/developers-handbook/sockets/#sockets-essential-functions

show more ...

[docs] Re-generate ClangCommandLineReference.rst

[Clang] Introduce `--offload-link` option to perform offload device linking

The new driver uses an augmented linker wrapper to perform the device
linking phase, but to the user looks like a regular

[Clang] Introduce `--offload-link` option to perform offload device linking

The new driver uses an augmented linker wrapper to perform the device
linking phase, but to the user looks like a regular linker invocation.
Contrary to the old driver, the new driver contains all the information
necessary to produce a linked device image in the host object itself.
Currently, we infer the usage of the device linker by the user
specifying an offloading toolchain, e.g. (--offload-arch=...) or
(-fopenmp-targets=...), but this shouldn't be strictly necessary.
This patch introduces a new option `--offload-link` to tell
the driver to use the offloading linker instead. So a compilation flow
can now look like this,

```
clang foo.cu --offload-new-driver -fgpu-rdc --offload-arch=sm_70 -c
clang foo.o --offload-link -lcudart
```

I was considering if this could be merged into the `-fuse-ld` option,
but because the device linker wraps over the users linker it would
conflict with that. In the future it's possible to merge this into `lld`
completely or `gold` via a plugin and we would use this option to
enable the device linking feature. Let me know what you think for this.

Reviewed By: tra

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

show more ...

[Clang][Docs] Document `-Xoffload-linker` flag

Summary:
I added the `-Xoffload-linker` flag and did not provide additional
documentation. This patch adds it.

[docs] Re-generate ClangCommandLineReference.rst

[PowerPC] Enable CR bits support for Power8 and above.

This patch turns on support for CR bit accesses for Power8 and above. The reason
why CR bits are turned on as the default for Power8 and above

[PowerPC] Enable CR bits support for Power8 and above.

This patch turns on support for CR bit accesses for Power8 and above. The reason
why CR bits are turned on as the default for Power8 and above is that because
later architectures make use of builtins and instructions that require CR bit
accesses (such as the use of setbc in the vector string isolate predicate
and bcd builtins on Power10).

This patch also adds the clang portion to allow for turning on CR bits in the
front end if the user so desires to.

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

show more ...

[Clang][Docs] Add new offloading flags to the clang documentation

Summary:
Some previous patches introduced the `--offload-new-driver` flag, which
is a generic way to enable the new driver, and the

[Clang][Docs] Add new offloading flags to the clang documentation

Summary:
Some previous patches introduced the `--offload-new-driver` flag, which
is a generic way to enable the new driver, and the `--offload-host-only`
and `--offload-device-only` flags which allow users to compile for one
side, making it easier to inspect intermediate code for offloading
compilations. This patch just documents them in the command line
reference.

show more ...

[C++20][Modules][Driver][HU 2/N] Add fmodule-header, fmodule-header=

These command-line flags are alternates to providing the -x
c++-*-header indicators that we are building a header unit.

Act on f

[C++20][Modules][Driver][HU 2/N] Add fmodule-header, fmodule-header=

These command-line flags are alternates to providing the -x
c++-*-header indicators that we are building a header unit.

Act on fmodule-header= for headers on the c/l:

If we have x.hh -fmodule-header, then we should treat that header
as a header unit input (equivalent to -xc++-header-unit-header x.hh).

Likewise, for fmodule-header={user,system} the source should be now
recognised as a header unit input (since this can affect the job list
that we need).

It's not practical to recognise a header without any suffix so
-fmodule-header=system foo isn't going to happen. Although
-fmodule-header=system foo.hh will work OK. However we can make it
work if the user indicates that the item without a suffix is a valid
header. (so -fmodule-header=system -xc++-header vector)

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

show more ...

[Clang][Docs] Update information on the new driver now that it's default

Summary:
This patch updates some of the documentation on the new driver now that
it's the default. Also the ABI for embedding

[Clang][Docs] Update information on the new driver now that it's default

Summary:
This patch updates some of the documentation on the new driver now that
it's the default. Also the ABI for embedding these images changed.

show more ...

[OpenMP] Remove help and documentation for old flag

Summary:
The `-fopenmp-target-new-runtime` flag has not been used for awhile. It
was present in a previous release so we shouldn't remove it for
b

[OpenMP] Remove help and documentation for old flag

Summary:
The `-fopenmp-target-new-runtime` flag has not been used for awhile. It
was present in a previous release so we shouldn't remove it for
backwards compatibility, but we shouldn't have documentation or a help
message for it.

show more ...

Revert "[Clang] Add option to set alternative toolchain path"

--overlay-platform-toolchain inserts a whole new toolchain path with
higher priority than system default, which could be achieved by
com

Revert "[Clang] Add option to set alternative toolchain path"

--overlay-platform-toolchain inserts a whole new toolchain path with
higher priority than system default, which could be achieved by
composing smaller options. We need to figure out alternative solution
and what is missing among these basic options.

show more ...

[Clang] Add option to set alternative toolchain path

In some cases, we need to set alternative toolchain path other than the
default with system (headers, libraries, dynamic linker prefix, ld path,

[Clang] Add option to set alternative toolchain path

In some cases, we need to set alternative toolchain path other than the
default with system (headers, libraries, dynamic linker prefix, ld path,
etc.), e.g., to pick up newer components, but keep sysroot at the same
time (to pick up extra packages).

This change introduces a new option --overlay-platform-toolchain to set
up such alternative toolchain path.

Reviewed By: hubert.reinterpretcast

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

show more ...

Reland "[llvm][AArch64] Insert "bti j" after call to setjmp"

This reverts commit edb7ba714acba1d18a20d9f4986d2e38aee1d109.

This changes BLR_BTI to take variable_ops meaning that we can accept
a reg

Reland "[llvm][AArch64] Insert "bti j" after call to setjmp"

This reverts commit edb7ba714acba1d18a20d9f4986d2e38aee1d109.

This changes BLR_BTI to take variable_ops meaning that we can accept
a register or a label. The pattern still expects one argument so we'll
never get more than one. Then later we can check the type of the operand
to choose BL or BLR to emit.

(this is what BLR_RVMARKER does but I missed this detail of it first time around)

Also require NoSLSBLRMitigation which I missed in the first version.

show more ...

Revert "[llvm][AArch64] Insert "bti j" after call to setjmp"

This reverts commit eb5ecbbcbb6ce38e29237ab5d17156fcb2e96e74
due to failures on buildbots with expensive checks enabled.

[llvm][AArch64] Insert "bti j" after call to setjmp

Some implementations of setjmp will end with a br instead of a ret.
This means that the next instruction after a call to setjmp must be
a "bti j"

[llvm][AArch64] Insert "bti j" after call to setjmp

Some implementations of setjmp will end with a br instead of a ret.
This means that the next instruction after a call to setjmp must be
a "bti j" (j for jump) to make this work when branch target identification
is enabled.

The BTI extension was added in armv8.5-a but the bti instruction is in the
hint space. This means we can emit it for any architecture version as long
as branch target enforcement flags are passed.

The starting point for the hint number is 32 then call adds 2, jump adds 4.
Hence "hint #36" for a "bti j" (and "hint #34" for the "bti c" you see
at the start of functions).

The existing Arm command line option -mno-bti-at-return-twice has been
applied to AArch64 as well.

Support is added to SelectionDAG Isel and GlobalIsel. FastIsel will
defer to SelectionDAG.

Based on the change done for M profile Arm in https://reviews.llvm.org/D112427

Fixes #48888

Reviewed By: danielkiss

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

show more ...