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.
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.
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.
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.
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.
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.
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.
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
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>
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`.
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.
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
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>
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:
7dcd7f4074/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.
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
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.
This adds predefined formatting macros in C23 mode for printing unsigned
integers in binary format (e.g, __UINT_FAST64_FMTB__). These are used to
implement the PRIb (et al) macros in inttypes.h
Fixes https://github.com/llvm/llvm-project/issues/81896
This defines the builtin macros specified in `7.18a.3 Precision macros`
of ISO/IEC TR 18037:2008. These are the `__*__` versions of them and the
formal definitions in stdfix.h can use them.
* Set `__cpp_auto_cast`, as per
https://github.com/cplusplus/CWG/issues/281
* Support `__has_extension(cxx_generalized_nttp)` in C++20 as the
feature isn't stable enough for a feature test macro
* Support `__has_extension(cxx_explicit_this_parameter)` in c++23 as the
feature isn't stable enough for a feature test macro
This PR exposes four PGO functions
- `__llvm_profile_set_filename`
- `__llvm_profile_reset_counters`,
- `__llvm_profile_dump`
- `__llvm_orderfile_dump`
to user programs through the new header `instr_prof_interface.h` under
`compiler-rt/include/profile`. This way, the user can include the header
`profile/instr_prof_interface.h` to introduce these four names to their
programs.
Additionally, this PR defines macro `__LLVM_INSTR_PROFILE_GENERATE` when
the program is compiled with profile generation, and defines macro
`__LLVM_INSTR_PROFILE_USE` when the program is compiled with profile
use. `__LLVM_INSTR_PROFILE_GENERATE` together with
`instr_prof_interface.h` define the PGO functions only when the program
is compiled with profile generation. When profile generation is off,
these PGO functions are defined away and leave no trace in the user's
program.
Background:
https://discourse.llvm.org/t/pgo-are-the-llvm-profile-functions-stable-c-apis-across-llvm-releases/75832
