[Clang] Remove 3-element vector load and store special handling (#104661)

Clang uses a long-time special handling of the case where 3 element
vector loads and stores are performed as 4 element, and

[Clang] Remove 3-element vector load and store special handling (#104661)

Clang uses a long-time special handling of the case where 3 element
vector loads and stores are performed as 4 element, and then a
shufflevector is used to extract the used elements. Odd sized vector
codegen should now work reasonably well.

This patch removes the compiler argument `-fpreserve-vec3-type` and adds
a target hook to determine if the special handling of vector type is
needed.

---------

Co-authored-by: Matt Arsenault <Matthew.Arsenault@amd.com>

show more ...

Remove support for RenderScript (#112916)

See
https://discourse.llvm.org/t/rfc-deprecate-and-eventually-remove-renderscript-support/81284
for the RFC

[HLSL] Add HLSL 202y language mode (#108437)

This change adds a new HLSL 202y language mode. Currently HLSL 202y is
planned to add `auto` and `constexpr`.

This change updates extension diagnosti

[HLSL] Add HLSL 202y language mode (#108437)

This change adds a new HLSL 202y language mode. Currently HLSL 202y is
planned to add `auto` and `constexpr`.

This change updates extension diagnostics to state that lambadas are a
"clang HLSL" extension (since we have no planned release yet to include
them), and that `auto` is a HLSL 202y extension when used in earlier
language modes.

Note: This PR does temporarily work around some differences between HLSL
2021 and 202x in Clang by changing test cases to explicitly specify
202x. A subsequent PR will update 2021's language flags to match 202x.

show more ...

Remove FiniteMathOnly and use only NoHonorINFs and NoHonorNANs. (#97342)

Currently `__FINITE_MATH_ONLY__` is set when `FiniteMathOnly`. And
`FiniteMathOnly` is set when `NoHonorInfs` && `NoHonorNa

Remove FiniteMathOnly and use only NoHonorINFs and NoHonorNANs. (#97342)

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

show more ...

[Clang] Allow raw string literals in C as an extension (#88265)

This enables raw R"" string literals in C in some language modes
and adds an option to disable or enable them explicitly as an
exten

[Clang] Allow raw string literals in C as an extension (#88265)

This enables raw R"" string literals in C in some language modes
and adds an option to disable or enable them explicitly as an
extension.

Background: GCC supports raw string literals in C in `-gnuXY` modes
starting with gnu99. This pr both enables raw string literals in gnu99
mode and later in C and adds an `-f[no-]raw-string-literals` flag to override
this behaviour. The decision not to enable raw string literals in gnu89
mode, according to the GCC devs, is intentional as that mode is supposed
to be used for ‘old code’ that they don’t want to break; we’ve decided to
match GCC’s behaviour here as well.

The `-fraw-string-literals` flag can additionally be used to enable raw string
literals in modes where they aren’t enabled by default (such as c99—as
opposed to gnu99—or even e.g. C++03); conversely, the negated flag can
be used to disable them in any gnuXY modes that *do* provide them by
default, or to override a previous flag. However, we do *not* support
disabling raw string literals (or indeed either of these two options) in
C++11 mode and later, because we don’t want to just start supporting
disabling features that are actually part of the language in the general case.

This fixes #85703.

show more ...

[C2y] Add -std=c2y and -std=gnu2y

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 20

[C2y] Add -std=c2y and -std=gnu2y

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.

show more ...

[clang] Use StringRef::operator== instead of StringRef::equals (NFC) (#91844)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber Str

[clang] Use StringRef::operator== instead of StringRef::equals (NFC) (#91844)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber StringRef::equals by a factor of
24 under clang/ in terms of their usage.

- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.

- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".

show more ...

[C23] Rename C2x -> C23; NFC

This does the rename for most internal uses of C2x, but does not rename
or reword diagnostics (those will be done in a follow-up).

I also updated standards references a

[C23] Rename C2x -> C23; NFC

This does the rename for most internal uses of C2x, but does not rename
or reword diagnostics (those will be done in a follow-up).

I also updated standards references and citations to the final wording
in the standard.

show more ...

Add C++26 compile flags.

Now that we've updated to C++23, we need to add C++26/C++2c command line
flags, as discussed in
https://discourse.llvm.org/t/rfc-lets-just-call-it-c-26-and-forget-about-the-

Add C++26 compile flags.

Now that we've updated to C++23, we need to add C++26/C++2c command line
flags, as discussed in
https://discourse.llvm.org/t/rfc-lets-just-call-it-c-26-and-forget-about-the-c-2c-business-at-least-internally/70383

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

show more ...

[clang] Use -std=c++23 instead of -std=c++2b

During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.

This updates the reference to c++2b to c++

[clang] Use -std=c++23 instead of -std=c++2b

During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.

This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.

Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.

Reviewed By: aaron.ballman

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

show more ...

[clang][deps] Ensure module invocation can be serialized

When reseting modular options, propagate the values from certain options
that have ImpliedBy relations instead of setting to the default. Als

[clang][deps] Ensure module invocation can be serialized

When reseting modular options, propagate the values from certain options
that have ImpliedBy relations instead of setting to the default. Also,
verify in clang-scan-deps that the command line produced round trips
exactly.

Ideally we would automatically derive the set of options that need this
kind of propagation, but for now there aren't very many impacted.

rdar://105148590

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

show more ...

[FPEnv] Allow CompoundStmt to keep FP options

This is a recommit of b822efc7404bf09ccfdc1ab7657475026966c3b2,
reverted in dc34d8df4c48b3a8f474360970cae8a58e6c84f0. The commit caused
fails because th

[FPEnv] Allow CompoundStmt to keep FP options

This is a recommit of b822efc7404bf09ccfdc1ab7657475026966c3b2,
reverted in dc34d8df4c48b3a8f474360970cae8a58e6c84f0. The commit caused
fails because the test ast-print-fp-pragmas.c did not specify particular
target, and it failed on targets which do not support constrained
intrinsics. The original commit message is below.

AST does not have special nodes for pragmas. Instead a pragma modifies
some state variables of Sema, which in turn results in modified
attributes of AST nodes. This technique applies to floating point
operations as well. Every AST node that can depend on FP options keeps
current set of them.

This technique works well for options like exception behavior or fast
math options. They represent instructions to the compiler how to modify
code generation for the affected nodes. However treatment of FP control
modes has problems with this technique. Modifying FP control mode
(like rounding direction) usually requires operations on hardware, like
writing to control registers. It must be done prior to the first
operation that depends on the control mode. In particular, such
operations are required for implementation of `pragma STDC FENV_ROUND`,
compiler should set up necessary rounding direction at the beginning of
compound statement where the pragma occurs. As there is no representation
for pragmas in AST, the code generation becomes a complicated task in
this case.

To solve this issue FP options are kept inside CompoundStmt. Unlike to FP
options in expressions, these does not affect any operation on FP values,
but only inform the codegen about the FP options that act in the body of
the statement. As all pragmas that modify FP environment may occurs only
at the start of compound statement or at global level, such solution
works for all relevant pragmas. The options are kept as a difference
from the options in the enclosing compound statement or default options,
it helps codegen to set only changed control modes.

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

show more ...

Revert "[FPEnv] Allow CompoundStmt to keep FP options"

On some buildbots test `ast-print-fp-pragmas.c` fails, need to investigate it.

This reverts commit 0401fd12d4aa0553347fe34d666fb236d8719173.
T

Revert "[FPEnv] Allow CompoundStmt to keep FP options"

On some buildbots test `ast-print-fp-pragmas.c` fails, need to investigate it.

This reverts commit 0401fd12d4aa0553347fe34d666fb236d8719173.
This reverts commit b822efc7404bf09ccfdc1ab7657475026966c3b2.

show more ...

[FPEnv] Allow CompoundStmt to keep FP options

AST does not have special nodes for pragmas. Instead a pragma modifies
some state variables of Sema, which in turn results in modified
attributes of AST

[FPEnv] Allow CompoundStmt to keep FP options

AST does not have special nodes for pragmas. Instead a pragma modifies
some state variables of Sema, which in turn results in modified
attributes of AST nodes. This technique applies to floating point
operations as well. Every AST node that can depend on FP options keeps
current set of them.

This technique works well for options like exception behavior or fast
math options. They represent instructions to the compiler how to modify
code generation for the affected nodes. However treatment of FP control
modes has problems with this technique. Modifying FP control mode
(like rounding direction) usually requires operations on hardware, like
writing to control registers. It must be done prior to the first
operation that depends on the control mode. In particular, such
operations are required for implementation of `pragma STDC FENV_ROUND`,
compiler should set up necessary rounding direction at the beginning of
compound statement where the pragma occurs. As there is no representation
for pragmas in AST, the code generation becomes a complicated task in
this case.

To solve this issue FP options are kept inside CompoundStmt. Unlike to FP
options in expressions, these does not affect any operation on FP values,
but only inform the codegen about the FP options that act in the body of
the statement. As all pragmas that modify FP environment may occurs only
at the start of compound statement or at global level, such solution
works for all relevant pragmas. The options are kept as a difference
from the options in the enclosing compound statement or default options,
it helps codegen to set only changed control modes.

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

show more ...

[HLSL] Enable half type for hlsl.

HLSL supports half type.
When enable-16bit-types is not set, half will be treated as float.
When enable-16bit-types is set, half will be treated like real 16bit flo

[HLSL] Enable half type for hlsl.

HLSL supports half type.
When enable-16bit-types is not set, half will be treated as float.
When enable-16bit-types is set, half will be treated like real 16bit float type and map to llvm half type.
Also change CXXABI to Microsoft to match dxc behavior.
The mangle name for half is "$f16@" when half is treat as native half type and "$halff@" when treat as float.

In AST, half is still half.
The special thing is done at clang codeGen, when NativeHalfType is false, half will translated into float.

Reviewed By: aaron.ballman

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

show more ...

[HLSL] Enable vector types for hlsl.

Vector types in hlsl is using clang ext_vector_type.
Declaration of vector types is in builtin header hlsl.h.
hlsl.h will be included by default for hlsl shader.

[HLSL] Enable vector types for hlsl.

Vector types in hlsl is using clang ext_vector_type.
Declaration of vector types is in builtin header hlsl.h.
hlsl.h will be included by default for hlsl shader.

Reviewed By: Anastasia

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

show more ...

Revert "[HLSL] Enable vector types for hlsl."

This reverts commit e576280380d3f5221cfcc14e9fabeacc8506a43c.
Breaks tests on mac/arm, see comment on https://reviews.llvm.org/D125052

Also revert foll

Revert "[HLSL] Enable vector types for hlsl."

This reverts commit e576280380d3f5221cfcc14e9fabeacc8506a43c.
Breaks tests on mac/arm, see comment on https://reviews.llvm.org/D125052

Also revert follow-up "[gn build] Port e576280380d3"
This reverts commit 1e01b1ec72031fcaceb4e77e1c5c8e34f1e862e8.

show more ...

[HLSL] Enable vector types for hlsl.

Vector types in hlsl is using clang ext_vector_type.
Declaration of vector types is in builtin header hlsl.h.
hlsl.h will be included by default for hlsl shader.

[HLSL] Enable vector types for hlsl.

Vector types in hlsl is using clang ext_vector_type.
Declaration of vector types is in builtin header hlsl.h.
hlsl.h will be included by default for hlsl shader.

Reviewed By: Anastasia

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

show more ...

[clang] Add the flag -ffile-reproducible

When Clang generates the path prefix (i.e. the path of the directory
where the file is) when generating FILE, __builtin_FILE(), and
std::source_location, Cla

[clang] Add the flag -ffile-reproducible

When Clang generates the path prefix (i.e. the path of the directory
where the file is) when generating FILE, __builtin_FILE(), and
std::source_location, Clang uses the platform-specific path separator
character of the build environment where Clang _itself_ is built. This
leads to inconsistencies in Chrome builds where Clang running on
non-Windows environments uses the forward slash (/) path separator
while Clang running on Windows builds uses the backslash (\) path
separator. To fix this, we add a flag -ffile-reproducible (and its
inverse, -fno-file-reproducible) to have Clang use the target's
platform-specific file separator character.

Additionally, the existing flags -fmacro-prefix-map and
-ffile-prefix-map now both imply -ffile-reproducible. This can be
overriden by setting -fno-file-reproducible.

[0]: https://crbug.com/1310767

Differential revision: https://reviews.llvm.org/D122766

show more ...

Change the behavior of implicit int diagnostics

C89 allowed a type specifier to be elided with the resulting type being
int, aka implicit int behavior. This feature was subsequently removed
in C99 w

Change the behavior of implicit int diagnostics

C89 allowed a type specifier to be elided with the resulting type being
int, aka implicit int behavior. This feature was subsequently removed
in C99 without a deprecation period, so implementations continued to
support the feature. Now, as with implicit function declarations, is a
good time to reevaluate the need for this support.

This patch allows -Wimplicit-int to issue warnings in C89 mode (off by
default), defaults the warning to an error in C99 through C17, and
disables support for the feature entirely in C2x. It also removes a
warning about missing declaration specifiers that really was just an
implicit int warning in disguise and other minor related cleanups.

show more ...

[clang] NFC, move CompilerInvocation::setLangDefaults to LangOptions.h

The function is moved from clangFrontend to clangBasic, which allows tools
(e.g. clang pseudoparser) which don't depend on clan

[clang] NFC, move CompilerInvocation::setLangDefaults to LangOptions.h

The function is moved from clangFrontend to clangBasic, which allows tools
(e.g. clang pseudoparser) which don't depend on clangFrontend to use.

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

show more ...

[OpenCL] Defines helper function for kernel language compatible OpenCL version

This change defines a helper function getOpenCLCompatibleVersion()
inside LangOptions class. The function contains mapp

[OpenCL] Defines helper function for kernel language compatible OpenCL version

This change defines a helper function getOpenCLCompatibleVersion()
inside LangOptions class. The function contains mapping between
C++ for OpenCL versions and their corresponding compatible OpenCL
versions. This mapping function should be updated each time a new
C++ for OpenCL language version is introduced. The helper function
is expected to simplify conditions on OpenCL C and C++ for OpenCL
versions inside compiler code.

Code refactoring performed.

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

show more ...

[OpenCL] Fix version reporting of C++ for OpenCL 2021

C++ for OpenCL version 2021 and later are expected to consist of a
major version number only. Therefore, a different constructor for
`VersionTup

[OpenCL] Fix version reporting of C++ for OpenCL 2021

C++ for OpenCL version 2021 and later are expected to consist of a
major version number only. Therefore, a different constructor for
`VersionTuple` needs to be called when reporting language version.

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

show more ...

[OpenCL] Clang diagnostics allow reporting C++ for OpenCL version.

Some Clang diagnostics could only report OpenCL C version. Because
C++ for OpenCL can be used as an alternative to OpenCL C, the te

[OpenCL] Clang diagnostics allow reporting C++ for OpenCL version.

Some Clang diagnostics could only report OpenCL C version. Because
C++ for OpenCL can be used as an alternative to OpenCL C, the text
for diagnostics should reflect that.

Desrciptions modified for these diagnostics:
`err_opencl_unknown_type_specifier`
`warn_option_invalid_ocl_version`
`err_attribute_requires_opencl_version`
`warn_opencl_attr_deprecated_ignored`
`ext_opencl_ext_vector_type_rgba_selector`

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

show more ...

Apply -fmacro-prefix-map to __builtin_FILE()

This matches the behavior of GCC.
Patch does not change remapping logic itself, so adding one simple smoke test should be enough.

Reviewed By: MaskRay

Apply -fmacro-prefix-map to __builtin_FILE()

This matches the behavior of GCC.
Patch does not change remapping logic itself, so adding one simple smoke test should be enough.

Reviewed By: MaskRay

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

show more ...