This paper made empty structures and unions implementation-defined. We
have always supported this as a GNU extension, so now we're documenting
our behavior and removing the extension warning in C2y mode.
This paper made qualified function types implementation-defined. We have
always supported this as an extension, so now we're documenting our
behavior.
Note, we still warn about this by default even in C2y mode because a
qualified function type is a sign of programmer confusion.
The __builtin_counted_by_ref builtin is used on a flexible array
pointer and returns a pointer to the "counted_by" attribute's COUNT
argument, which is a field in the same non-anonymous struct as the
flexible array member. This is useful for automatically setting the
count field without needing the programmer's intervention. Otherwise
it's possible to get this anti-pattern:
ptr = alloc(<ty>, ..., COUNT);
ptr->FAM[9] = 42; /* <<< Sanitizer will complain */
ptr->count = COUNT;
To prevent this anti-pattern, the user can create an allocator that
automatically performs the assignment:
#define alloc(TY, FAM, COUNT) ({ \
TY __p = alloc(get_size(TY, COUNT)); \
if (__builtin_counted_by_ref(__p->FAM)) \
*__builtin_counted_by_ref(__p->FAM) = COUNT; \
__p; \
})
The builtin's behavior is heavily dependent upon the "counted_by"
attribute existing. It's main utility is during allocation to avoid
the above anti-pattern. If the flexible array member doesn't have that
attribute, the builtin becomes a no-op. Therefore, if the flexible
array member has a "count" field not referenced by "counted_by", it
must be set explicitly after the allocation as this builtin will
return a "nullptr" and the assignment will most likely be elided.
---------
Co-authored-by: Bill Wendling <isanbard@gmail.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
ADC and ADX use the same internal intrinsics - for testing I've taken the same approach as the generic builtin overflow tests, putting the intrinsics in a constexpr test wrapper and comparing the carry/result value pair.
I've added the addcarry/subborrow intrinsics to the clang language extension list - I'm not sure if we want to add all ISA intrinsics to the list (although we can if people think it useful?), but I felt we should at least include the baseline x86 intrinsics.
This change is part of this proposal:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294
- Add HLSL frontend for atan2
- Add clang Builtin, map to new llvm.atan2
- SemaChecking restrict to floating point and 2 args
- SemaHLSL restrict to float or half.
- Add to clang ReleaseNotes.rst and LanguageExtensions.rst
- Add half-float-only-errors2.hlsl for 2 arg intrinsics, and update half-float-only-errors.hlsl with scalar case for consistency
- Remove fmod-errors.hlsl and pow-errors.hlsl now covered in half-float-only-errors2.hlsl
Part 3 for Implement the atan2 HLSL Function #70096.
This change add the elementwise fmod builtin to support HLSL function
'fmod' in clang for #99118
Builtins.td - add the fmod builtin
CGBuiltin.cpp - lower the builtin to llvm FRem instruction
hlsl_intrinsics.h - add the fmod api
SemaChecking.cpp - add type checks for builtin
SemaHLSL.cpp - add HLSL type checks for builtin
clang/docs/LanguageExtensions.rst - add the builtin in *Elementwise
Builtins*
clang/docs/ReleaseNotes.rst - announce the builtin
When an initializer is provided to a variable, the Linux kernel relied
on the compiler to zero-initialize unspecified fields, as clarified in
https://www.spinics.net/lists/netdev/msg1007244.html.
But clang doesn't guarantee this:
1. For a union type, if an empty initializer is given, clang only
initializes bytes for the first field, left bytes for other (larger)
fields are marked as undef. Accessing those undef bytes can lead
to undefined behaviors.
2. For a union type, if an initializer explicitly sets a field, left
bytes for other (larger) fields are marked as undef.
3. When an initializer is given, clang doesn't zero initialize padding.
So this patch makes the following change:
1. In C, when an initializer is provided for a variable, zero-initialize
undef and padding fields in the initializer.
2. Document the change in LanguageExtensions.rst.
As suggested in
https://github.com/llvm/llvm-project/issues/78034#issuecomment-2183437928,
the change isn't required by C23, but it's standards conforming to do
so.
Fixes: https://github.com/llvm/llvm-project/issues/97459
This implements the logic of the `common_type` base template as a
builtin alias. If there should be no `type` member, an empty class is
returned. Otherwise a specialization of a `type_identity`-like class is
returned. The base template (i.e. `std::common_type`) as well as the
empty class and `type_identity`-like struct are given as arguments to
the builtin.
Add new elementwise popcount builtin to support HLSL function
'countbits'.
elementwise popcount only accepts integer types.
Add hlsl intrinsic 'countbits'
Closes#99094
Added a new `-Wpre-c++26-compat` warning for when this feature is used
in C++26 and a `-Wc++26-extensions` warning for when this is used in
C++11 through C++23.
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Fix list formatting, improve the wording, and fix the description when
both options (note: prefer "option" to "flag" when arguments are
supported) are specified.
Pull Request: https://github.com/llvm/llvm-project/pull/104886
Following the discussion on #101448 this defines
`__cpp_pack_indexing`. Since pack indexing is currently
supported in all language modes, the feature test macro
is also defined in all language modes.
`is_null_pointer` can be implemented very efficiently as
`__is_same(__remove_cv(T), decltype(nullptr))`. Since GCC supports both
of these builtins as well, libc++ has no interest in using
`__is_nullptr` instead. Furthermore, I could find only a single use in
the wild
(https://sourcegraph.com/search?q=context:global+__is_nullptr%28+-file:clang&patternType=keyword&sm=0).
Because of these reasons I don't think it's worth keeping this builtin
around.
This patch adds compiler support for
[P2985R0](https://wg21.link/p2985r0) "A type trait for detecting virtual
base classes".
Like we recently did with `__is_layout_compatible()` and
`__is_pointer_interconvertible_base_of()`, we support it only in C++
mode, and reject VLAs.
Resolves#98310.
This paper is about whether a copy of a va_list object which was not
produced by calling va_copy is valid to use or not. While this may work
on some targets, we explicitly document it as undefined behavior for all
targets so there's not confusion as to when it's valid or not. It's not
a burden for a user to use va_copy explicitly.
Explicitly describe how the Clang builtin works, given that it's not
exactly the same as GCC's builtin of the same name -- but is drop-in
compatible.
Fixes#95635.
The builtin causes the program to stop its execution abnormally and
shows a human-readable description of the reason for the termination
when a debugger is attached or in a symbolicated crash log.
The motivation for the builtin is explained in the following RFC:
https://discourse.llvm.org/t/rfc-adding-builtin-verbose-trap-string-literal/75845
clang's CodeGen lowers the builtin to `llvm.trap` and emits debugging
information that represents an artificial inline frame whose name
encodes the category and reason strings passed to the builtin.
This commit implements the entirety of the now-accepted [N3017
-Preprocessor
Embed](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm) and
its sister C++ paper [p1967](https://wg21.link/p1967). It implements
everything in the specification, and includes an implementation that
drastically improves the time it takes to embed data in specific
scenarios (the initialization of character type arrays). The mechanisms
used to do this are used under the "as-if" rule, and in general when the
system cannot detect it is initializing an array object in a variable
declaration, will generate EmbedExpr AST node which will be expanded by
AST consumers (CodeGen or constant expression evaluators) or expand
embed directive as a comma expression.
This reverts commit
682d461d5a.
---------
Co-authored-by: The Phantom Derpstorm <phdofthehouse@gmail.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Co-authored-by: H. Vetinari <h.vetinari@gmx.com>
The -mmacos-version-min flag is preferred over -mmacosx-version-min.
This patch updates the tests and documentation to make this clear and
also adds the missing logic to scan build to handle the new flag.
Fixes#86376.
Co-authored-by: Gabor Horvath <gaborh@apple.com>
This commit implements the entirety of the now-accepted [N3017 -
Preprocessor
Embed](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3017.htm) and
its sister C++ paper [p1967](https://wg21.link/p1967). It implements
everything in the specification, and includes an implementation that
drastically improves the time it takes to embed data in specific
scenarios (the initialization of character type arrays). The mechanisms
used to do this are used under the "as-if" rule, and in general when the
system cannot detect it is initializing an array object in a variable
declaration, will generate EmbedExpr AST node which will be expanded
by AST consumers (CodeGen or constant expression evaluators) or
expand embed directive as a comma expression.
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Co-authored-by: H. Vetinari <h.vetinari@gmx.com>
Co-authored-by: Podchishchaeva, Mariya <mariya.podchishchaeva@intel.com>
This patch implements a `__is_bitwise_cloneable` builtin in clang.
The builtin is used as a guard to check a type can be safely bitwise
copied by memcpy. It's functionally similar to
`__is_trivially_copyable`, but covers a wider range of types (e.g.
classes with virtual functions). The compiler guarantees that after
copy, the destination object has the same object representations as the
source object. And it is up to user to guarantee that program semantic
constraints are satisfied.
Context:
https://discourse.llvm.org/t/extension-for-creating-objects-via-memcpy
Using MMRAs, allow `builtin_amdgcn_fence` to emit fences that only
target one or more address spaces, instead of fencing all address spaces
at once.
This is done through a `amdgpu-as` MMRA. Currently focused on OpenCL
fences, but can very easily support more AS names and codegen on more
than just fences.
This change is an implementation of #87367's investigation on supporting
IEEE math operations as intrinsics.
Which was discussed in this RFC:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294
If you want an overarching view of how this will all connect see:
https://github.com/llvm/llvm-project/pull/90088
Changes:
- `clang/docs/LanguageExtensions.rst` - Document the new elementwise tan
builtin.
- `clang/include/clang/Basic/Builtins.td` - Implement the tan builtin.
- `clang/lib/CodeGen/CGBuiltin.cpp` - invoke the tan intrinsic on uses
of the builtin
- `clang/lib/Headers/hlsl/hlsl_intrinsics.h` - Associate the tan builtin
with the equivalent hlsl apis
- `clang/lib/Sema/SemaChecking.cpp` - Add generic sema checks as well as
HLSL specifc sema checks to the tan builtin
- `llvm/include/llvm/IR/Intrinsics.td` - Create the tan intrinsic
- `llvm/docs/LangRef.rst` - Document the tan intrinsic
commit 8d41d93e3fceb3f3af77266f5a8388fc585150a5
Author: Pol Marcet Sardà <polmarcetsarda@gmail.com>
Date: Sat Apr 20 12:19:49 2024 +0200
Address some misc comments; added a diagnostic and expanded macros in
testing.
commit 9493c0f290b558947d8b3ae8e1adf909b0fb9dcd
Author: Pol Marcet Sardà <polmarcetsarda@gmail.com>
Date: Sun Mar 31 18:18:45 2024 +0200
Following the review of sethp, I have made the following changes:
-- Added diagnostic for the undefined shuffle of -1
-- Validated support for _BitInt
-- A bunch of other minnor tweaks here and there
commit 8273abc8d56ef8225cf4dba84f66a1e54a2ef036
Author: Pol Marcet Sardà <polmarcetsarda@gmail.com>
Date: Thu Jan 4 12:31:08 2024 +0100
Fix typo in file name
commit ff68f23921966c7d9605f91a47d6b481bf1d7a7b
Author: Pol Marcet Sardà <polmarcetsarda@gmail.com>
Date: Thu Jan 4 11:26:08 2024 +0100
Address suggestions from RKSimon
commit c14783de45687c754253c0cbf8a7834c7f986d80
Author: Pol Marcet Sardà <polmarcetsarda@gmail.com>
Date: Sat Dec 30 13:59:00 2023 +0100
[clang] Constexpr for __builtin_shufflevector and __builtin_convertvector
Summary:
This patch adds constexpr support for __builtin_shufflevector
and __builtin_convertvector.
A small oddity encountered was that the arg to the intrinsics may be an
lvalue without any sort of implicit cast of any kind. I solved this
through the EvaluateVectorOrLValue function, which treats the lvalue as
if it was in an rvalue cast, which gets me the desired vector.
Co-Authored-By: Seth Pellegrino <seth@codecopse.net>
Currently, a lot of `__builtin_reduce_*` function do not support
scalable vectors, i.e., ARM SVE and RISCV V. This PR adds support for
them. The main code change is to use a different path to extract the
type from the vectors, the rest is the same and LLVM supports the reduce
functions for `vscale` vectors.
This PR adds scalable vector support for:
- `__builtin_reduce_add`
- `__builtin_reduce_mul`
- `__builtin_reduce_xor`
- `__builtin_reduce_or`
- `__builtin_reduce_and`
- `__builtin_reduce_min`
- `__builtin_reduce_max`
Note: For all except `min/max`, the element type must still be an
integer value. Adding floating point support for `add` and `mul` is
still an open TODO.
These macros are used by STL implementations to support implementation
of std::hardware_destructive_interference_size and
std::hardware_constructive_interference_size
Fixes#60174
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Currently `__is_trivially_equality_comparable` is documented to return
true if comparing the value representation is equivalent to calling the
comparison operator, which is not quite what the trait actually checks.
The traits actually checks that comparing the object representation is
equivalent, which means that there cannot be padding bytes in the type.
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>
It's useful to provide an indicator code with the trap, which the generic
__builtin_trap can't do. asm("brk #N") is an option, but following that with a
__builtin_unreachable() leads to two traps when the compiler doesn't know the
block can't return. So compiler support like this is useful.
