[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 ...

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] Add back -fsanitize=array-bounds workaround for size-1 array after -fstrict-flex-arrays change

Before C99 introduced flexible array member, common practice uses size-1 array
to emulate FAM,

[clang] Add back -fsanitize=array-bounds workaround for size-1 array after -fstrict-flex-arrays change

Before C99 introduced flexible array member, common practice uses size-1 array
to emulate FAM, e.g. https://github.com/python/cpython/issues/94250
As a result, -fsanitize=array-bounds instrumentation skipped such structures
as a workaround (from 539e4a77bbabbc19f22b2bd24e04af2e432e599d).

D126864 accidentally dropped the workaround. Add it back with tests.

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 ...

[NFC][Alignment] Use MaybeAlign in CGCleanup/CGExpr

[clang] Honor __attribute__((no_builtin("foo"))) on functions

Support for `__attribute__((no_builtin("foo")))` was added in https://reviews.llvm.org/D68028,
but builtins were still being used even w

[clang] Honor __attribute__((no_builtin("foo"))) on functions

Support for `__attribute__((no_builtin("foo")))` was added in https://reviews.llvm.org/D68028,
but builtins were still being used even when the attribute was placed on a function.

Reviewed By: hans

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

show more ...

Treat `std::move`, `forward`, etc. as builtins.

This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`,

Treat `std::move`, `forward`, etc. as builtins.

This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`, `move_if_noexcept`, `as_const`, `addressof`, and the
libstdc++-specific function `__addressof`.

We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.

This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.

We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.

In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.

The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.

This is a re-commit of
fc3090109643af8d2da9822d0f99c84742b9c877,
a571f82a50416b767fd3cce0fb5027bb5dfec58c,
64c045e25b8471bbb572bd29159c294a82a86a2, and
de6ddaeef3aaa8a9ae3663c12cdb57d9afc0f906,
and reverts aa643f455a5362de7189eac630050d2c8aefe8f2.
This change also includes a workaround for users using libc++ 3.1 and
earlier (!!), as apparently happens on AIX, where std::move sometimes
returns by value.

Reviewed By: aaron.ballman

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

Revert "Fixup D123950 to address revert of D123345"

This reverts commit aa643f455a5362de7189eac630050d2c8aefe8f2.

show more ...

Fixup D123950 to address revert of D123345

Since D123345 got reverted Builtin::BIaddressof and Builtin::BI__addressof don't exist and cause build breaks.

Look through calls to std::addressof to compute pointer alignment.

This is sort of a followup to D37310; that basically fixed the same
issue, but then the libstdc++ implementation of <atomic> change

Look through calls to std::addressof to compute pointer alignment.

This is sort of a followup to D37310; that basically fixed the same
issue, but then the libstdc++ implementation of <atomic> changed. Re-fix
the the issue in essentially the same way: look through the addressof
operation to find the alignment of the underlying object.

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

show more ...

Fix Werror build issue from 6f20744b7ff875

Add support for ignored bitfield conditional codegen.

Currently we emit an error in just about every case of conditionals
with a 'non simple' branch if treated as an LValue. This patch adds
support

Add support for ignored bitfield conditional codegen.

Currently we emit an error in just about every case of conditionals
with a 'non simple' branch if treated as an LValue. This patch adds
support for the special case where this is an 'ignored' lvalue, which
permits the side effects from happening.

It also splits up the emit for conditional LValue in a way that should
be usable to handle simple assignment expressions in similar situations.

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

show more ...

[Clang][Fortify] drop inline decls when redeclared

When an inline builtin declaration is shadowed by an actual declaration, we must
reference the actual declaration, even if it's not the last, follo

[Clang][Fortify] drop inline decls when redeclared

When an inline builtin declaration is shadowed by an actual declaration, we must
reference the actual declaration, even if it's not the last, following GCC
behavior.

This fixes #54715

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

show more ...

[CGExpr] Perform bitcast unconditionally

The way the check is written is not compatible with opaque
pointers -- while we don't need to change the IR pointer type,
we do need to change the element ty

[CGExpr] Perform bitcast unconditionally

The way the check is written is not compatible with opaque
pointers -- while we don't need to change the IR pointer type,
we do need to change the element type stored in the Address.

show more ...

Reapply [CodeGen] Avoid deprecated Address ctor in EmitLoadOfPointer()

This requires some adjustment in caller code, because there was
a confusion regarding the meaning of the PtrTy argument: This
a

Reapply [CodeGen] Avoid deprecated Address ctor in EmitLoadOfPointer()

This requires some adjustment in caller code, because there was
a confusion regarding the meaning of the PtrTy argument: This
argument is the type of the pointer being loaded, not the addresses
being loaded from.

Reapply after fixing the specified pointer type for one call in
47eb4f7dcd845878b16a53dadd765195b9c24b6e, where the used type is
important for determining alignment.

show more ...

Revert "[CodeGen] Avoid deprecated Address ctor in EmitLoadOfPointer()"

This reverts commit 767ec883e37510a247ea5695921876ef67cf5b3f.

This results in a some incorrect alignments which are not cover

Revert "[CodeGen] Avoid deprecated Address ctor in EmitLoadOfPointer()"

This reverts commit 767ec883e37510a247ea5695921876ef67cf5b3f.

This results in a some incorrect alignments which are not covered
by existing tests.

show more ...

[CodeGen] Avoid deprecated Address ctor in EmitLoadOfPointer()

This requires some adjustment in caller code, because there was
a confusion regarding the meaning of the PtrTy argument: This
argument

[CodeGen] Avoid deprecated Address ctor in EmitLoadOfPointer()

This requires some adjustment in caller code, because there was
a confusion regarding the meaning of the PtrTy argument: This
argument is the type of the pointer being loaded, not the addresses
being loaded from.

show more ...

[CodeGen] Avoid some pointer element type accesses

[Clang] Allow "ext_vector_type" applied to Booleans

This is the `ext_vector_type` alternative to D81083.

This patch extends Clang to allow 'bool' as a valid vector element type
(attribute ext_vecto

[Clang] Allow "ext_vector_type" applied to Booleans

This is the `ext_vector_type` alternative to D81083.

This patch extends Clang to allow 'bool' as a valid vector element type
(attribute ext_vector_type) in C/C++.

This is intended as the canonical type for SIMD masks and facilitates
clean vector intrinsic declarations. Vectors of i1 are supported on IR
level and below down to many SIMD ISAs, such as AVX512, ARM SVE (fixed
vector length) and the VE target (NEC SX-Aurora TSUBASA).

The RFC on cfe-dev: https://lists.llvm.org/pipermail/cfe-dev/2020-May/065434.html

Reviewed By: erichkeane

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

show more ...

[NFC][Clang][OpaquePtr] Remove the call to Address::deprecated in
CreatePointerBitCastOrAddrSpaceCast

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

[clang] Remove Address::deprecated() from CGClass.cpp

[CodeGen] Rename deprecated Address constructor

To make uses of the deprecated constructor easier to spot, and to
ensure that no new uses are introduced, rename it to
Address::deprecated().

While d

[CodeGen] Rename deprecated Address constructor

To make uses of the deprecated constructor easier to spot, and to
ensure that no new uses are introduced, rename it to
Address::deprecated().

While doing the rename, I've filled in element types in cases
where it was relatively obvious, but we're still left with 135
calls to the deprecated constructor.

show more ...

[CGBuilder] Assert that CreateAddrSpaceCast does not change element type

Address space casts in general may change the element type, but
don't allow it in the method working on Address, so we can
pr

[CGBuilder] Assert that CreateAddrSpaceCast does not change element type

Address space casts in general may change the element type, but
don't allow it in the method working on Address, so we can
preserve the element type.

CreatePointerBitCastOrAddrSpaceCast() still needs to be addressed.

show more ...

Extend the `uwtable` attribute with unwind table kind

We have the `clang -cc1` command-line option `-funwind-tables=1|2` and
the codegen option `VALUE_CODEGENOPT(UnwindTables, 2, 0) ///< Unwind
tabl

Extend the `uwtable` attribute with unwind table kind

We have the `clang -cc1` command-line option `-funwind-tables=1|2` and
the codegen option `VALUE_CODEGENOPT(UnwindTables, 2, 0) ///< Unwind
tables (1) or asynchronous unwind tables (2)`. However, this is
encoded in LLVM IR by the presence or the absence of the `uwtable`
attribute, i.e. we lose the information whether to generate want just
some unwind tables or asynchronous unwind tables.

Asynchronous unwind tables take more space in the runtime image, I'd
estimate something like 80-90% more, as the difference is adding
roughly the same number of CFI directives as for prologues, only a bit
simpler (e.g. `.cfi_offset reg, off` vs. `.cfi_restore reg`). Or even
more, if you consider tail duplication of epilogue blocks.
Asynchronous unwind tables could also restrict code generation to
having only a finite number of frame pointer adjustments (an example
of *not* having a finite number of `SP` adjustments is on AArch64 when
untagging the stack (MTE) in some cases the compiler can modify `SP`
in a loop).
Having the CFI precise up to an instruction generally also means one
cannot bundle together CFI instructions once the prologue is done,
they need to be interspersed with ordinary instructions, which means
extra `DW_CFA_advance_loc` commands, further increasing the unwind
tables size.

That is to say, async unwind tables impose a non-negligible overhead,
yet for the most common use cases (like C++ exceptions), they are not
even needed.

This patch extends the `uwtable` attribute with an optional
value:
- `uwtable` (default to `async`)
- `uwtable(sync)`, synchronous unwind tables
- `uwtable(async)`, asynchronous (instruction precise) unwind tables

Reviewed By: MaskRay

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

show more ...

[CGBuilder] Remove CreateBitCast() method

Use CreateElementBitCast() instead, or don't work on Address
where not necessary.

[Clang][OpaquePtr] Remove deprecated Address constructor calls

Remove most calls to deprcated Address constructor in CGExpr.cpp

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