Revert "Add support for floating-point option `ffp-eval-method` and for"

This reverts commit 32b73bc6ab8234b670c34d5ef999300e072cc706.

This breaks builds on macOS in some configurations, because
__

Revert "Add support for floating-point option `ffp-eval-method` and for"

This reverts commit 32b73bc6ab8234b670c34d5ef999300e072cc706.

This breaks builds on macOS in some configurations, because
__FLT_EVAL_METHOD__ is set to an unexpected value.

E.g.
https://green.lab.llvm.org/green/job/clang-stage1-RA/28282/consoleFull#129538464349ba4694-19c4-4d7e-bec5-911270d8a58c

More details available in the review thread
https://reviews.llvm.org/D109239

show more ...

Add support for floating-point option `ffp-eval-method` and for
`pragma clang fp eval_method`.

https://reviews.llvm.org/D109239

Revert "Add support for floating-point option `ffp-eval-method` and for"

This reverts commit 4bafe65c2b2f1ce745894a509a6d80c87fb1c335.
Breaks at least Misc/warning-flags.c, see comments on
https://r

Revert "Add support for floating-point option `ffp-eval-method` and for"

This reverts commit 4bafe65c2b2f1ce745894a509a6d80c87fb1c335.
Breaks at least Misc/warning-flags.c, see comments on
https://reviews.llvm.org/D109239

show more ...

Add support for floating-point option `ffp-eval-method` and for
`pragma clang fp eval_method`.

[C++2b] Implement multidimentional subscript operator

Implement P2128R6 in C++23 mode.

Unlike GCC's implementation, this doesn't try to recover when a user
meant to use a comma expression.

Because

[C++2b] Implement multidimentional subscript operator

Implement P2128R6 in C++23 mode.

Unlike GCC's implementation, this doesn't try to recover when a user
meant to use a comma expression.

Because the syntax changes meaning in C++23, the patch is *NOT*
implemented as an extension. Instead, declaring an array with not
exactly 1 parameter is an error in older languages modes. There is an
off-by-default extension warning in C++23 mode.

Unlike the standard, we supports default arguments;

Ie, we assume, based on conversations in WG21, that the proposed
resolution to CWG2507 will be accepted.

We allow arrays OpenMP sections and C++23 multidimensional array to
coexist:

[a , b] multi dimensional array
[a : b] open mp section
[a, b: c] // error

The rest of the patch is relatively straight forward: we take care to
support an arbitrary number of arguments everywhere.

show more ...

Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied

fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of
86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This
hopef

Revert fad7e491a0770ac4336934030ac67d77e7af5520 with fixes applied

fad7e491a0770ac4336934030ac67d77e7af5520 was a revert of
86797fdb6f51d32f285e48b6d3e0fc5b8b852734 due to build failures. This
hopefully fixes them.

show more ...

Revert "Add BITINT_MAXWIDTH support"

This reverts commit 86797fdb6f51d32f285e48b6d3e0fc5b8b852734.

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

Add BITINT_MAXWIDTH support

Part of the _BitInt feature in C2x
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf) is a new
macro in limits.h named BITINT_MAXWIDTH that can be used to determ

Add BITINT_MAXWIDTH support

Part of the _BitInt feature in C2x
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf) is a new
macro in limits.h named BITINT_MAXWIDTH that can be used to determine
the maximum width of a bit-precise integer type. This macro must expand
to a value that is at least as large as ULLONG_WIDTH.

This adds an implementation-defined macro named __BITINT_MAXWIDTH__ to
specify that value, which is used by limits.h for the standard macro.

This also limits the maximum bit width to 128 bits because backends do
not currently support all mathematical operations (such as division) on
wider types yet. This maximum is expected to be increased in the future.

show more ...

Support the *_WIDTH macros in limits.h and stdint.h

This completes the implementation of
WG14 N2412 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf),
which standardizes C on a twos comple

Support the *_WIDTH macros in limits.h and stdint.h

This completes the implementation of
WG14 N2412 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf),
which standardizes C on a twos complement representation for integer
types. The only work that remained there was to define the correct
macros in the standard headers, which this patch does.

show more ...

set __NO_MATH_ERRNO__ if -fno-math-errno

This causes modern glibc to unset math_errhandling MATH_ERRNO. gcc 12
also sets some other macros, but most of them are associated with
flags ignored by clan

set __NO_MATH_ERRNO__ if -fno-math-errno

This causes modern glibc to unset math_errhandling MATH_ERRNO. gcc 12
also sets some other macros, but most of them are associated with
flags ignored by clang, so without library examples, it is difficult to
determine whether they should be set. I think setting this one macro is
OK for now.

show more ...

[CUDA][HIP] Add pre-defined macro `__CLANG_RDC__`

nvcc defines __CUDACC_RDC__ for both host and
device compilation when -rdc=true is specified
(https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc

[CUDA][HIP] Add pre-defined macro `__CLANG_RDC__`

nvcc defines __CUDACC_RDC__ for both host and
device compilation when -rdc=true is specified
(https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#nvcc-identification-macro)

This patch defines __CLANG_RDC__ when -fgpu-rdc
is specified for CUDA/HIP.

Reviewed by: Artem Belevich

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

show more ...

[HIP] Add HIP scope atomic operations

Add an AtomicScopeModel for HIP and support for OpenCL builtins
that are missing in HIP.

Patch by: Michael Liao

Revised by: Anshil Ghandi

Reviewed by: Yaxun

[HIP] Add HIP scope atomic operations

Add an AtomicScopeModel for HIP and support for OpenCL builtins
that are missing in HIP.

Patch by: Michael Liao

Revised by: Anshil Ghandi

Reviewed by: Yaxun Liu

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

show more ...

[OpenMP] Add version macro support for 5.1 and 5.2

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

[SPIR-V] Add SPIR-V triple and clang target info.

Add new triple and target info for ‘spirv32’ and ‘spirv64’ and,
thus, enabling clang (LLVM IR) code emission to SPIR-V target.

The target for SPIR-

[SPIR-V] Add SPIR-V triple and clang target info.

Add new triple and target info for ‘spirv32’ and ‘spirv64’ and,
thus, enabling clang (LLVM IR) code emission to SPIR-V target.

The target for SPIR-V is mostly reused from SPIR by derivation
from a common base class since IR output for SPIR-V is mostly
the same as SPIR. Some refactoring are made accordingly.

Added and updated tests for parts that are different between
SPIR and SPIR-V.

Patch by linjamaki (Henry Linjamäki)!

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

show more ...

[Coroutines] [Frontend] Lookup in std namespace first

Now in libcxx and clang, all the coroutine components are defined in
std::experimental namespace.
And now the coroutine TS is merged into C++20.

[Coroutines] [Frontend] Lookup in std namespace first

Now in libcxx and clang, all the coroutine components are defined in
std::experimental namespace.
And now the coroutine TS is merged into C++20. So in the working draft
like N4892, we could find the coroutine components is defined in std
namespace instead of std::experimental namespace.
And the coroutine support in clang seems to be relatively stable. So I
think it may be suitable to move the coroutine component into the
experiment namespace now.

This patch would make clang lookup coroutine_traits in std namespace
first. For the compatibility consideration, clang would lookup in
std::experimental namespace if it can't find definitions in std
namespace. So the existing codes wouldn't be break after update
compiler.

And in case the compiler found std::coroutine_traits and
std::experimental::coroutine_traits at the same time, it would emit an
error for it.

The support for looking up std::experimental::coroutine_traits would be
removed in Clang16.

Reviewed By: lxfind, Quuxplusone

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

show more ...

Bump the value of __STDC_VERSION__ in -std=c2x mode

Previously, we reported the same value as for C17, now we report 202000L, which
is the same value currently used by GCC.

Once C23 ships, this val

Bump the value of __STDC_VERSION__ in -std=c2x mode

Previously, we reported the same value as for C17, now we report 202000L, which
is the same value currently used by GCC.

Once C23 ships, this value will be bumped to the correct date.

show more ...

Implement if consteval (P1938)

Modify the IfStmt node to suppoort constant evaluated expressions.

Add a new ExpressionEvaluationContext::ImmediateFunctionContext to
keep track of immediate function

Implement if consteval (P1938)

Modify the IfStmt node to suppoort constant evaluated expressions.

Add a new ExpressionEvaluationContext::ImmediateFunctionContext to
keep track of immediate function contexts.

This proved easier/better/probably more efficient than walking the AST
backward as it allows diagnosing nested if consteval statements.

show more ...

Revert "[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly"
The intent of this patch is to add support of -fp-model=[source|double|extended] to a

Revert "[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly"
The intent of this patch is to add support of -fp-model=[source|double|extended] to allow
the compiler to use a wider type for intermediate floating point calculations. As a side
effect to that, the value of FLT_EVAL_METHOD is changed according to the pragma
float_control.
Unfortunately some issue was uncovered with this change in preprocessing. See details in
https://reviews.llvm.org/D93769 . We are therefore reverting this patch until we find a way
to reconcile the value of FLT_EVAL_METHOD, the pragma and the -E flow.

This reverts commit 66ddac22e2a7f268e91c26d694112970dfa607ae.

show more ...

[OpenCL] C++ for OpenCL version 2021 introduced to command line.

Introduces language standard `lang_openclcpp2021` and allows
`clc++2021` as a version flag for `-cl-std` in command line.
Defines mac

[OpenCL] C++ for OpenCL version 2021 introduced to command line.

Introduces language standard `lang_openclcpp2021` and allows
`clc++2021` as a version flag for `-cl-std` in command line.
Defines macros related to C++ for OpenCL version 2021.

C++ for OpenCL version 2021 has been proposed in an RFC:
https://lists.llvm.org/pipermail/cfe-dev/2021-August/068593.html

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

show more ...

[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly

The Intel compiler ICC supports the option "-fp-model=(source|double|extended)"
which causes

[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly

The Intel compiler ICC supports the option "-fp-model=(source|double|extended)"
which causes the compiler to use a wider type for intermediate floating point
calculations. Also supported is a way to embed this effect in the source
program with #pragma float_control(source|double|extended).
This patch extends pragma float_control syntax, and also adds support
for a new floating point option "-ffp-eval-method=(source|double|extended)".
source: intermediate results use source precision
double: intermediate results use double precision
extended: intermediate results use extended precision

Reviewed By: Aaron Ballman

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

show more ...

[clang] P2266 implicit moves STL workaround

This patch replaces the workaround for simpler implicit moves
implemented in D105518.

The Microsoft STL currently has some issues with P2266.

Where befo

[clang] P2266 implicit moves STL workaround

This patch replaces the workaround for simpler implicit moves
implemented in D105518.

The Microsoft STL currently has some issues with P2266.

Where before, with -fms-compatibility, we would disable simpler
implicit moves globally, with this change, we disable it only
when the returned expression is in a context contained by
std namespace and is located within a system header.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: aaron.ballman, mibintc

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

show more ...

Revert "[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly"

This reverts commit ce8024e8ff76e7be8b9ffa1a39d1dc9310bf74c7.
There are a couple bui

Revert "[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly"

This reverts commit ce8024e8ff76e7be8b9ffa1a39d1dc9310bf74c7.
There are a couple buildbot problems

show more ...

[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly

The Intel compiler ICC supports the option "-fp-model=(source|double|extended)"
which causes

[CLANG][PATCH][FPEnv] Add support for option -ffp-eval-method and extend #pragma float_control similarly

The Intel compiler ICC supports the option "-fp-model=(source|double|extended)"
which causes the compiler to use a wider type for intermediate floating point
calculations. Also supported is a way to embed this effect in the source
program with #pragma float_control(source|double|extended).
This patch extends pragma float_control syntax, and also adds support
for a new floating point option "-ffp-eval-method=(source|double|extended)".
source: intermediate results use source precision
double: intermediate results use double precision
extended: intermediate results use extended precision

Reviewed By: Aaron Ballman

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

show more ...

[clang] disable P2266 simpler implicit moves under -fms-compatibility

The Microsoft STL currently has some issues with P2266.
We disable it for now in that mode, but we might come back later with a

[clang] disable P2266 simpler implicit moves under -fms-compatibility

The Microsoft STL currently has some issues with P2266.
We disable it for now in that mode, but we might come back later with a
more targetted approach.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: aaron.ballman

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

show more ...

[clang] add C++ feature test macro for P2266 simpler implicit move

The feature was implemented in D99005, but we forgot to add the test
macro.

Reviewed By: Quuxplusone

Differential Revision: https

[clang] add C++ feature test macro for P2266 simpler implicit move

The feature was implemented in D99005, but we forgot to add the test
macro.

Reviewed By: Quuxplusone

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

show more ...