| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
See https://github.com/llvm/llvm-project/issues/71364 for details.
|
|
The language of side seems fairly stable.
Setting the feature test macro will ease implementation in standard
libraries.
|
|
GCC defines these macros for both userspace and kernel address
sanitizers:
$ gcc -E -dM -fsanitize=address -x c /dev/null &| string match -er
SANITIZE
#define __SANITIZE_ADDRESS__ 1
$ gcc -E -dM -fsanitize=kernel-address -x c /dev/null &| string match
-er SANITIZE
#define __SANITIZE_ADDRESS__ 1
$ gcc -E -dM -fsanitize=hwaddress -x c /dev/null &| string match -er
SANITIZE
#define __SANITIZE_HWADDRESS__ 1
$ gcc -E -dM -fsanitize=kernel-hwaddress -x c /dev/null &| string match
-er SANITIZE
#define __SANITIZE_HWADDRESS__ 1
PR #153888 added these same defines for clang but only for the userspace
address sanitizers:
$ clang -E -dM -fsanitize=address -x c /dev/null &| string match -er
SANITIZE
#define __SANITIZE_ADDRESS__ 1
$ clang -E -dM -fsanitize=kernel-address -x c /dev/null &| string match
-er SANITIZE
$ clang -E -dM -fsanitize=hwaddress -x c /dev/null &| string match -er
SANITIZE
#define __SANITIZE_HWADDRESS__ 1
$ clang -E -dM -fsanitize=kernel-hwaddress -x c /dev/null &| string
match -er SANITIZE
Match GCC's behavior so that the Linux kernel can eventually drop its
own internal defines.
|
|
available on Darwin (#153912)
For backwards compatibility reasons the `ptrauth_qualifier` and
`ptrauth_intrinsic` features need to be testable with `__has_feature()`
on Apple platforms, but for other platforms this backwards compatibility
issue does not exist.
This PR resolves these issues by making the `ptrauth_qualifier` and
`ptrauth_intrinsic` tests conditional upon a darwin target. This also
allows us to revert the ptrauth_qualifier check from an extension to a
feature test again, as is required on these platforms.
At the same time we introduce a new predefined macro `__PTRAUTH__` that
answers the same question as `__has_feature(ptrauth_qualifier)` and
`__has_feature(ptrauth_intrinsic)` as those tests are synonymous and
only exist separately for compatibility reasons.
The requirement to test for the `__PTRAUTH__` macro also resolves the
hazard presented by mixing the `ptrauth_qualifier` flag (that impacts
ABI and security policies) with `-pedantics-errors`, which makes
`__has_extension` return false for all extensions.
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
|
|
Per discussion with @ojhunt and @AaronBallman we are moving towards
predefined macros and away from __has_feature and __has_extension
for detecting sanitizers and other similar features. The rationale
is that __has_feature is only really meant for standardized features
(see the comment at the top of clang/include/clang/Basic/Features.def),
and __has_extension has the issues discovered as part of #153104.
Let's start by defining macros for ASan, HWASan and TSan, consistently
with gcc.
Reviewers: vitalybuka, ojhunt, AaronBallman, fmayer
Reviewed By: fmayer, vitalybuka
Pull Request: https://github.com/llvm/llvm-project/pull/153888
|
|
The Cygwin target is generally very similar to the MinGW target. The
default auto-import behavior, the default calling convention, the
`.dll.a` import library extension, the `__GXX_TYPEINFO_EQUALITY_INLINE`
pre-define by `g++`, and the long double configuration.
Co-authored-by: Mateusz Mikuła <oss@mateuszmikula.dev>
|
|
As we are now Sema-complete for OpenACC 3.4 (and thus have a conforming
implementation, in all modes), we can now set the _OPENACC macro
correctly.
Additionally, we remove the temporary 'override' functionality, which
was intended to allow people to experiment with this. We aren't having a
deprecation period as OpenACC support is still considered experimental.
|
|
(#148982)
This PR removes the command line parsing workaround introduced in
https://github.com/llvm/llvm-project/pull/146342 by moving
`LangOptions::ExceptionHandling` to `CodeGenOptions` that get parsed
even for IR input. Additionally, this improves layering, where the
codegen library now checks `CodeGenOptions` instead of `LangOptions` for
exception handling. (This got enabled by
https://github.com/llvm/llvm-project/pull/146422.)
|
|
Some `LangOptions` duplicate their `CodeGenOptions` counterparts. My
understanding is that this was done solely because some infrastructure
(like preprocessor initialization, serialization, module compatibility
checks, etc.) were only possible/convenient for `LangOptions`. This PR
implements the missing support for `CodeGenOptions`, which makes it
possible to remove some duplicate `LangOptions` fields and simplify the
logic. Motivated by https://github.com/llvm/llvm-project/pull/146342.
|
|
Alas reflection pushed p2719 out of C++26, so this PR changes the
diagnostics to reflect that for now type aware allocation is
functionally a clang extension.
|
|
When passing `-save-temps` to clang, the generated preprocessed output
uses gnu line markers. This unexpectedly triggers gnu-line-marker
warnings when used with `-Weverything` or `-pedantic`. Even worse,
compilation fails if `-Werror` is used.
This change suppresses gnu-line-marker warnings when invoking clang with
input from a preprocessor job and the user has not otherwise explictly
specified `-Wgnu-line-marker` somewhere on the command line. Note that
this does apply to user provided preprocessed files.
fixes #63802
|
|
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
|
|
The allocation interposition mode had a number of issues, which are
primarily addressed in the library component via
<https://github.com/ROCm/rocThrust/pull/543>. However, it is necessary
to interpose some additional symbols, which this patch does.
Furthermore, to implement this in a compatible way, we guard the new
implementation under a V1 macro, which is defined in addition to the
existing `__HIPSTDPAR_INTERPOSE_ALLOC__` one.
|
|
(#127636)
This adds
- The parsing of `trivially_relocatable_if_eligible`,
`replaceable_if_eligible` keywords
- `__builtin_trivially_relocate`, implemented in terms of memmove. In
the future this should
- Add the appropriate start/end lifetime markers that llvm does not have
(`start_lifetime_as`)
- Add support for ptrauth when that's upstreamed
- the `__builtin_is_cpp_trivially_relocatable` and
`__builtin_is_replaceable` traits
Fixes #127609
|
|
|
|
|
|
This is a basic implementation of P2719: "Type-aware allocation and
deallocation functions" described at http://wg21.link/P2719
The proposal includes some more details but the basic change in
functionality is the addition of support for an additional implicit
parameter in operators `new` and `delete` to act as a type tag. Tag is
of type `std::type_identity<T>` where T is the concrete type being
allocated. So for example, a custom type specific allocator for `int`
say can be provided by the declaration of
void *operator new(std::type_identity<int>, size_t, std::align_val_t);
void operator delete(std::type_identity<int>, void*, size_t, std::align_val_t);
However this becomes more powerful by specifying templated declarations,
for example
template <typename T> void *operator new(std::type_identity<T>, size_t, std::align_val_t);
template <typename T> void operator delete(std::type_identity<T>, void*, size_t, std::align_val_t););
Where the operators being resolved will be the concrete type being
operated over (NB. A completely unconstrained global definition as above
is not recommended as it triggers many problems similar to a general
override of the global operators).
These type aware operators can be declared as either free functions or
in class, and can be specified with or without the other implicit
parameters, with overload resolution performed according to the existing
standard parameter prioritisation, only with type parameterised
operators having higher precedence than non-type aware operators. The
only exception is destroying_delete which for reasons discussed in the
paper we do not support type-aware variants by default.
|
|
function to Triple (#126956)
I'm adding support for SPIR-V, so let's consolidate these checks.
---------
Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
|
|
Add double overloads which cast the double to a float and call the float
builtin.
Makes these double overloads conditional on hlsl version 202x or
earlier.
Add tests
Closes #128228
|
|
Per P2493R0 and SD6, `__cpp_constexpr` of value `202002L` indicates that
P1330R0 "Changing the active member of a union inside constexpr" is
implemented, which is true for Clang 9 and later.
|
|
(#127980)
Implemented in abc8812df02599fc413d9ed77b992f8236ed2af9
|
|
This flag has been deprecated since Clang 19, having been the default
since then.
It has remained because its negation was still useful to work around
backwards compatibility breaking changes from P0522.
However, in Clang 20 we have landed various changes which implemented
P3310R2 and beyond, which solve almost all of the expected issues, the
known remaining few being a bit obscure.
So this change removes the flag completely and all of its implementation
and support code.
Hopefully any remaining users can just stop using the flag. If there are
still important issues remaining, this removal will also shake the tree
and help us know.
|
|
Add support for the `-fopenmp-version=60` command line argument. It is
needed for https://github.com/llvm/llvm-project/pull/119891 (`#pragma
omp stripe`) which will be the first OpenMP 6.0 directive implemented.
Add regression tests for Clang in `-fopenmp-version=60` mode.
|
|
This adds predefined macros for integer constants to implement section 7.18.4 of ISO/IEC 9899:1999 in `<stdint.h>` in a safe way:
```
__INT8_C(c)
__INT16_C(c)
__INT32_C(c)
__INT64_C(c)
__INTMAX_C(c)
__UINT8_C(c)
__UINT16_C(c)
__UINT32_C(c)
__UINT64_C(c)
__UINTMAX_C(c)
```
Which improves compatibility with GCC and makes it trivial to implement
section 7.18.4 of ISO/IEC 9899:1999.
Clang defines `__INT<N>_C_SUFFIX__`, `__UINT<N>_C_SUFFIX__`,
`__INTAX_C_SUFFIX__` and `__UINTMAX_C_SUFFIX__`, but these macros are
useless for this purpose.
Let's say, for example, that `__INT64_C_SUFFIX__` expands to `L` or
`LL`. If the user defines them as a macros, the compiler will produce
errors if `INT64_C` is implemented in `<stdint.h>` using
`__INT64_C_SUFFIX__`:
**minimal-test.c:**
```cpp
#if defined(__clang__) & !defined(__INT64_C)
# pragma clang diagnostic push
# pragma clang diagnostic ignored "-Wreserved-identifier"
# define __PSTDC_INT_C_(literal, suffix) literal##suffix
# define __PSTDC_INT_C(literal, suffix) __PSTDC_INT_C_(literal, suffix)
# define INT64_C(literal) __PSTDC_INT_C(literal, __INT64_C_SUFFIX__)
# pragma clang diagnostic pop
#elif defined(__GNUC__)
# define INT64_C __INT64_C
#endif
typedef __INT64_TYPE__ int64_t;
#define L "Make Clang produce an error"
#define LL "Make Clang produce an error"
int main(int argc, char **argv)
{
(void)argc; (void)argv;
int64_t v = INT64_C(9223372036854775807);
(void)v;
return 0;
}
```
<img width="697" alt="imagen"
src="https://github.com/user-attachments/assets/6df97af6-7cfd-4cf9-85b7-d7c854509325"
/>
**test.c:**
```cpp
#if defined(__clang__) && !defined(__INT8_C)
# pragma clang diagnostic push
# pragma clang diagnostic ignored "-Wreserved-identifier"
# define __PSTDC_INT_C_(literal, suffix) literal##suffix
# define __PSTDC_INT_C(literal, suffix) __PSTDC_INT_C_(literal, suffix)
# define INT8_C(literal) __PSTDC_INT_C(literal, __INT8_C_SUFFIX__)
# define INT16_C(literal) __PSTDC_INT_C(literal, __INT16_C_SUFFIX__)
# define INT32_C(literal) __PSTDC_INT_C(literal, __INT32_C_SUFFIX__)
# define INT64_C(literal) __PSTDC_INT_C(literal, __INT64_C_SUFFIX__)
# define INTMAX_C(literal) __PSTDC_INT_C(literal, __INTMAX_C_SUFFIX__)
# define UINT8_C(literal) __PSTDC_INT_C(literal, __UINT8_C_SUFFIX__)
# define UINT16_C(literal) __PSTDC_INT_C(literal, __UINT16_C_SUFFIX__)
# define UINT32_C(literal) __PSTDC_INT_C(literal, __UINT32_C_SUFFIX__)
# define UINT64_C(literal) __PSTDC_INT_C(literal, __UINT64_C_SUFFIX__)
# define UINTMAX_C(literal) __PSTDC_INT_C(literal, __UINTMAX_C_SUFFIX__)
# pragma clang diagnostic pop
#else
# define INT8_C __INT8_C
# define INT16_C __INT16_C
# define INT32_C __INT32_C
# define INT64_C __INT64_C
# define INTMAX_C __INTMAX_C
# define UINT8_C __UINT8_C
# define UINT16_C __UINT16_C
# define UINT32_C __UINT32_C
# define UINT64_C __UINT64_C
# define UINTMAX_C __UINTMAX_C
#endif
typedef __INT8_TYPE__ int8_t;
typedef __INT16_TYPE__ int16_t;
typedef __INT32_TYPE__ int32_t;
typedef __INT64_TYPE__ int64_t;
typedef __INTMAX_TYPE__ intmax_t;
typedef __UINT8_TYPE__ uint8_t;
typedef __UINT16_TYPE__ uint16_t;
typedef __UINT32_TYPE__ uint32_t;
typedef __UINT64_TYPE__ uint64_t;
typedef __UINTMAX_TYPE__ uintmax_t;
#define L "Make Clang produce an error"
#define LL "Make Clang produce an error"
#define U "Make Clang produce an error"
#define UL "Make Clang produce an error"
#define ULL "Make Clang produce an error"
int main(int argc, char **argv)
{
(void)argc; (void)argv;
int8_t a = INT8_C (127);
int16_t b = INT16_C (32767);
int32_t c = INT32_C (2147483647);
int64_t d = INT64_C (9223372036854775807);
intmax_t e = INTMAX_C (9223372036854775807);
uint8_t f = UINT8_C (255);
uint16_t g = UINT16_C (65535);
uint32_t h = UINT32_C (4294967295);
uint64_t i = UINT64_C (18446744073709551615);
uintmax_t j = UINTMAX_C(18446744073709551615);
(void)a; (void)b; (void)c; (void)d; (void)e;
(void)f; (void)g; (void)h; (void)i; (void)j;
return 0;
}
```
|
|
from arm-apple-none-macho (#122427)
arm-apple-none-macho uses DarwinTargetInfo which provides several Apple
specific macros. arm64-apple-none-macho however just uses the generic
AArch64leTargetInfo and doesn't get any of those macros. It's not clear
if everything from DarwinTargetInfo is desirable for
arm64-apple-none-macho, so make an AppleMachOTargetInfo to hold the
generic Apple macros and a few other basic things.
|
|
internal-externc-isystem when nostdlibinc is used (#122035)
Embedded development often needs to use a different C standard library,
replacing the existing one normally passed as -internal-externc-isystem.
This works fine for an apple-macos target, but apple-none-macho doesn't
work because the MachO driver doesn't implement
AddClangSystemIncludeArgs to add the resource directory as
-internal-isystem like most other drivers do. Move most of the search
path logic from Darwin and DarwinClang down into an AppleMachO toolchain
between the MachO and Darwin toolchains.
Also define __MACH__ for apple-none-macho, as Swift expects all MachO
targets to have that defined.
|
|
directory after internal-externc-isystem when nostdlibinc is used (#120507)"
This reverts commit 653a54727eaa18c43447ad686c987db67f1dda74.
Breaks tests, see https://github.com/llvm/llvm-project/pull/120507#issuecomment-2575246281
|
|
internal-externc-isystem when nostdlibinc is used (#120507)
Embedded development often needs to use a different C standard library,
replacing the existing one normally passed as -internal-externc-isystem.
This works fine for an apple-macos target, but apple-none-macho doesn't
work because the MachO driver doesn't implement
AddClangSystemIncludeArgs to add the resource directory as
-internal-isystem like most other drivers do. Move most of the search
path logic from Darwin and DarwinClang down into an AppleMachO toolchain
between the MachO and Darwin toolchains.
Also define \_\_MACH__ for apple-none-macho, as Swift expects all MachO
targets to have that defined.
|
|
There are not a lot of outstanding known issues
with deducing this (besides #95112), so it
seems reasonable to claim full support.
Fixes #82780
|
|
Version of SYCL was changed according to the latest agreement:
The lower 2 digits are not formally specified, but we plan to use these
to identify the month in which we submit the specification for
ratification, which is similar to the C++ macro __cplusplus.
Since the SYCL 2020 specification was submitted for ratification in
December of 2020, the macro's value is now 202012 for SYCL 2020.
see PR for details
https://github.com/KhronosGroup/SYCL-Docs/pull/634
|
|
The standard mandates that this returns the width of the type, which is
the number of bits in the value. For bool, that's required to be `1`
explicitly.
Fixes #117348
|
|
in C++11 as an extension (#102044)
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>
|
|
The implementation follows the resolution of CWG2922
|
|
Implement P2893R3 ‘Variadic friends’ for C++26.
This closes #98587.
Co-authored-by: Younan Zhang <zyn7109@gmail.com>
|
|
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.
|
|
Currently `__FINITE_MATH_ONLY__` is set when `FiniteMathOnly`. And
`FiniteMathOnly` is set when `NoHonorInfs` && `NoHonorNans` is true. But
what happens one of the latter flags is false?
To avoid potential inconsistencies, the internal option `FiniteMathOnly`
is removed option and the macro `__FINITE_MATH_ONLY__` is set when
`NoHonorInfs` && `NoHonorNans`.
|
|
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2653.htm
Closes #97202
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
|
|
This adds the *_NORM_MAX macros to <float.h> for freestanding mode in
Clang; the values were chosen based on the behavior seen coming from GCC
and the values already produced for the *_MAX macros by Clang.
|
|
This adds a language standard mode for the latest C standard. While
WG14 is hoping for a three-year cycle, it is not clear that the next
revision of C will be in 2026 and so a flag was not created for c26
specifically.
|
|
targets (#96062)
libstdc++ requires this define to match what is predefined in GCC for
the ABI of this platform; GCC hardcodes this define for all mingw
configurations in gcc/config/i386/cygming.h.
(It also defines __GXX_MERGED_TYPEINFO_NAMES=0, but that happens to
match the defaults in libstdc++ headers, so there's no similar need to
define it in Clang.)
This fixes a Clang/libstdc++ interop issue discussed at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572.
|
|
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
https://github.com/llvm/llvm-project/commit/682d461d5a231cee54d65910e6341769419a67d7.
---------
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>
|
|
and Obj-C++ by-proxy)" (#95299)
Reverts llvm/llvm-project#68620
Introduce or expose a memory leak and UB, see llvm/llvm-project#68620
|
|
Obj-C++ by-proxy) (#68620)
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 commit adds the /Zc:\_\_STDC\_\_ argument from MSVC, which defines
\_\_STDC_\_.
This means, alongside stronger feature parity with MSVC, that things
that rely on \_\_STDC\_\_, such as autoconf, can work.
Link to MSVC documentation of this flag:
https://learn.microsoft.com/en-us/cpp/build/reference/zc-stdc?view=msvc-170
|
|
When using other specific exception options in Clang, such as
`-fseh-exceptions` or `-fsjlj-exceptions`, Clang defines a corresponding
preprocessor such as `-D__USING_SJLJ_EXCEPTIONS__`. Emscripten does that
in our own build system:
https://github.com/emscripten-core/emscripten/blob/7dcd7f40749918e141dc33397d2f4311dd80637a/tools/system_libs.py#L1577-L1578
But to make Wasm EH usable in non-Emscripten toolchain, this has to be
defined somewhere else. This PR makes Wasm EH consistent with other
exception scheme by letting it defined by Clang depending on the
exception option.
We have been using `__USING_WASM_EXCEPTIONS__` in our current library
code, but this changes it to `__WASM_EXCEPTIONS__` for its conciseness,
and I will update other parts of LLVM as follow-ups. This does not break
anything currently working, because we have not been defining anything
in Clang so far.
|
|
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p0609r3.pdf
We support this feature in all language mode.
maybe_unused applied to a binding makes the whole declaration unused.
|
|
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>
|
|
The preprocessor define `__HLSL_ENABLE_16_BIT` should be set to 1 if
native 16-bit types are enabled and not set if they are not.
Previously we were setting the value to match the HLSL active language
version, and we had no test coverage verifing the value was set and not
set as expected.
Fixes #89787
|
|
This implements support for the `= delete("message")` syntax that was
only just added to C++26
([P2573R2](https://isocpp.org/files/papers/P2573R2.html#proposal-scope)).
|
|
After discussion with a few others, and seeing the state of our concepts
support, I believe it is worth trying to see if we can update this for
Clang19. The forcing function is that libstdc++'s `<expected>` header is
guarded by this macro, so we need to update it to support that.
|
