The test Sema/PR69717.cpp fails on platforms that do not support
pragma float_control. So run this test on x86 only.
(cherry picked from commit 93ae26331592f41bf2b1d10b048743d80c468385)
When instantiation function, a call to Sema::resetFPOption was used to
set the FP options associated with AST node. However this function also
cleared FP pragma stack, and it is incorrect. Template instantiation
takes place on AST representation and semantic information like the FP
pragma stack should not affect it. This was a reason for miscompilation
in some cases.
To make the Sema interface more consistent, now `resetFPOptions` does
not clear FP pragma stack anymore. It is cleared in
`FpPragmaStackSaveRAII`, which is used in parsing only.
This change must fix https://github.com/llvm/llvm-project/issues/69717
(Problems with float_control pragma stack in Clang 17.x).
(cherry picked from commit f6f625f4c6c3cbeb8cf6b889cdafc848dd4cb117)
As noticed in D158846, the Solaris driver deviates from other targets in
that it links every executable with `-lm`, but doesn't for shared
objects. For C code, this is unnecessary, while for C++ `libm` is always
needed, even for shared objects.
This patch fixes this by following the `Gnu.cpp` precedent. It adjusts
the `solaris-ld.c` test accordingly, adding some more tests.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
(cherry picked from commit 1e6b0df3503567488e7df2d574c90f8f31a001a2)
A few symbols within libclangInterpreter have got explicit dllexport
attributes, in order to make them exported (and thus visible at runtime)
in any build, not only when they are part of e.g. a DLL libclang-cpp,
but also when they are part of a plain .exe.
Due to the explicit dllexports, these symbols would sidestep the regular
MinGW logic of exporting all symbols if there are no dllexports.
Therefore, for libclang-cpp, a separate fix was made in
592e935e115ffb451eb9b782376711dab6558fe0, to pass --export-all-symbols
to the build of libclang-cpp.
If building with BUILD_SHARED_LIBS enabled, then the same issue appears
in libclangInterpreter; pass the same flag --export-all-symbols there as
well, to make sure all symbols are visible, not only the ones that are
explicitly marked as dllexport.
(cherry picked from commit 0d3eeac8c0f45410398a87f72ae38ea6ae1c3073)
When implementing thread_local as a keyword in C23, we accidentally
started using C++11 thread_local semantics when using that keyword
instead of using C11 _Thread_local semantics.
This oversight is fixed by pretending the user wrote _Thread_local
instead. This doesn't have the best behavior in terms of diagnostics,
but it does correct the semantic behavior.
Fixes https://github.com/llvm/llvm-project/issues/70068
Fixes https://github.com/llvm/llvm-project/issues/69167
When applying format changes to staged files, git-clang-format
erroneously checks out all files in the index and thus may overwrite
unstaged changes.
Fixes#65643.
(cherry picked from commit 743659be87daff4cc8861c525d4a6229d787ef14)
Don't remove the outermost parentheses surrounding a return statement
expression when inside a function/lambda that has the decltype(auto)
return type.
Fixed#67892.
(cherry picked from commit 75441a684273268ce91036aa2c770e669d39f501)
On MinGW targets, the .ctors section is always used for constructors.
When using the .ctors section, the constructors need to be emitted in
reverse order to get them execute in the right order. (Constructors with
a specific priority are sorted separately by the linker later.) In LLVM,
in CodeGen/AsmPrinter/AsmPrinter.cpp, there's code that reverses them
before writing them out, executed when using the .ctors section. This
logic is done whenever TM.Options.UseInitArray is set to false. Thus,
make sure to set UseInitArray to false for this target.
This fixes https://github.com/llvm/llvm-project/issues/55938.
(cherry picked from commit a2b8c49c1839076b540c542c024fcfe2361a3e47)
Right now, `-Wformat` for a scoped enum will suggest a cast based on the
format specifier being used. This can lead to incorrect results, e.g.
attempting to format a scoped enum with `%s` would suggest casting to
`char *` instead of fixing the specifier. Change the logic to treat the
scoped enum's underlying type as the intended type to be printed, and
suggest format specifier changes and casts based on that.
(cherry picked from commit 0b07b06effe5fdf779b75bb5ac6cf15e477cb0be)
Prior to 591c4b64b3650884c2c68eb47d755ebb62981b99, the mingw specific
linker options -mthreads, -mconsole, -mwindows and -mdll would be
tolerated also at compile time, but generating a warning about being
unused.
After that commit, they were marked as target specific, which means that
it's an error if they're unused (which would consider them used for the
wrong target). These specific options are only relevant when linking,
but we want to tolerate them at compile time too, like before.
This was fixed for -mthreads in
a79995ca6004082774a87f7a58ab6be5343364b7, while the other options didn't
seem to be commonly used during compilation.
After the 17.x release, we've got more reports about this actually being
an issue, in #64464. Therefore, apply the same fix for them; marking
them as tolerated for mingw targets during compilation, even if they're
unused. Also add a testcase for -mthreads which was already handled.
Thus, this fixes#64464.
(cherry picked from commit e39de2b8862ae43459324da84279366997265078)
Adapted from the original commit; the test in the original commit
depended on f39c399d9d15efe8309d8aa3d0ecf62205e6c474. Instead of
using -###, when we're not actually using the printed output of
-###, instead use -fdriver-only.
Previously a relative path would be used as a key for cache lookup and
if the same relative path was used from another compiler invocation with
a different working directory then the first cache entry was erroneously
returned.
(cherry picked from commit 36b37c775c285bbff9b57630e7ea9d00b918cc91)
`Lexer::getLocForEndOfToken` is documented as returning an invalid
source location when the end of the token is inside a macro expansion.
We don't want that for this particular application, so just calculate
the end location directly instead.
Before this, format fix-its would omit the closing parenthesis (thus
producing invalid code) for macros, e.g.:
```
$ cat format.cpp
extern "C" int printf(const char *, ...);
enum class Foo { Bar };
#define LOG(...) printf(__VA_ARGS__)
void f(Foo foo) { LOG("%d\n", foo); }
$ clang -fsyntax-only format.cpp
format.cpp:4:29: warning: format specifies type 'int' but the argument has type 'Foo' [-Wformat]
4 | void f(Foo f) { LOG("%d\n", f); }
| ~~ ^
| static_cast<int>(
format.cpp:3:25: note: expanded from macro 'LOG'
3 | #define LOG(...) printf(__VA_ARGS__)
| ^~~~~~~~~~~
1 warning generated.
```
We now emit a valid fix-it:
```
$ clang -fsyntax-only format.cpp
format.cpp:4:31: warning: format specifies type 'int' but the argument has type 'Foo' [-Wformat]
4 | void f(Foo foo) { LOG("%d\n", foo); }
| ~~ ^~~
| static_cast<int>( )
format.cpp:3:25: note: expanded from macro 'LOG'
3 | #define LOG(...) printf(__VA_ARGS__)
| ^~~~~~~~~~~
1 warning generated.
```
Fixes https://github.com/llvm/llvm-project/issues/63462
(cherry picked from commit 61c5ad8857a71510e4393680a1e42740da4ba6fa)
An assertion issue that arose when handling union member access with
virtual base class has been addressed. As pointed out by @zygoloid,
there is no need for further derived-to-base analysis in this instance,
so we can bail out upon encountering a virtual base class. Minor
refinement on the function name as we might not be handling a union.
Reported-By: ormris
Fixes: https://github.com/llvm/llvm-project/issues/65982
(cherry picked from commit 660876a4019b81b5a7427a3dcec5ce8c39cd1ee0)
When the caret location is lower than the lowest source range, clang is
printing wrong line numbers. The first line number should consider caret
location line even when there are source ranges provided.
Current wrong line example: https://godbolt.org/z/aj4qEjzs4
(cherry picked from commit ef5217b3c0dcbb58927fe43400b6d1faa677bf98)
As reported by mgorny at https://reviews.llvm.org/D159115#4638037, the
unsigned long long cast fails on 32-bit systems at least with GCC.
It looks like a pointer provenance/aliasing issue rather than a bug in GCC.
Acked by Vassil Vassilev on the original revision.
(cherry picked from commit 3403686b72507e3fdbcd69f21fb9235ffa0ca169)
The associated commit was reverted and backported in a93ca35, so this
release note line should also be removed.
This reverts commit 061e855767dbe0821d81a8d47158f468dd00ae5f.
`clang::runWithSufficientStackSpace` requires the address of the
initial stack bottom to prevent potential stack overflows.
In addition, add a fallback to ASTFrontendAction in case any client
forgets to call it when not through CompilerInstance::ExecuteAction,
which is rare.
Fixes https://github.com/clangd/clangd/issues/1745.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D158967
(cherry picked from commit e257c0a9190637e44e292271103a13d70bec4b03)
This patch amends D151590 to not error for unlaimed TargetSpecific
options for `-x assembler` input files. This input type causes Driver to
construct tools::ClangAs (-fintegrated-as) or other assemblers (e.g.
tools::gnutools::Assembler) Their ConstructJobs methods, unlike
Clang::ConstructJobs, claim very few options. If an option is unclaimed,
it either leads to a -Wunused-command-line-argument warning or an error
(if `TargetSpecific` is set):
```
% clang '-###' --target=aarch64 -mbranch-protection=bti -c a.s
clang: error: unsupported option '-mbranch-protection=' for target 'aarch64'
```
It seems that downgrading the diagnostic to warning is most useful as
many users use CFLAGS even for `.s` files:
```
clang --target=aarch64 -mbranch-protection=bti -S a.c
clang --target=aarch64 -mbranch-protection=bti -c a.s
```
I decide not to suppress the warning so that
-Wunused-command-line-argument lovers still get a warning, and help
projects use proper ASFLAGS/CFLAGS/etc.
Note: `-mbranch-protection=bti a.S` currently has no warning as `-x assembler-with-cpp`
instructs clangDriver to select tools::Clang and claim most options.
Revert D159010 to demonstrate that we emit a warning for -mfpmath= for
`-x assembler` input.
Modify my AIX cleanup cd18efb61d759405956dbd30e4b5f2720d8e1783 to
add an err_drv_unsupported_opt_for_target.
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D159173
(cherry picked from commit e9d454d1c195958645fb0948f8b97262e7f8b33a)
clangDriver depends on clangBasic, so clangBasic should not depend on
clangDriver, even just its header. Also remove clangBasic's dependency
on LLVMOption.
The issue can be seen through the bazel commit
d26dd681f9726ed7d43d7c0bdd8ee3cb2db69a2b which is reverted now.
Add hasFlagNoClaim and use it as we don't want to suppress
-Wunused-command-line-argument for -mexecute-only just because
-fsanitize= is specified.
An execute-only target disallows data access to code sections.
-fsanitize=function and -fsanitize=kcfi instrument indirect function
calls to load a type hash before the function label. This results in a
non-execute access to the code section and a runtime error.
To solve the issue, -fsanitize=function should not be included in any
check group (e.g. undefined) on an execute-only target. If a user passes
-fsanitize=undefined, there is no error and no warning. However, if the
user explicitly passes -fsanitize=function or -fsanitize=kcfi on an
execute-only target, an error will be emitted.
Fixes: https://github.com/llvm/llvm-project/issues/64931.
Reviewed By: MaskRay, probinson, simon_tatham
Differential Revision: https://reviews.llvm.org/D158614
A check pattern in clang/test/SemaCXX/template-64605.cpp contains template
specialization kind (the text "implicit_instantiation"). It does not need to
be checked and can be safely removed.
Presence of this text in the check pattern prevents from backporting some
commits to the release branch: https://github.com/llvm/llvm-project/issues/64605.
It has only recently been printed and the relevant commit is not present in
the release/17.x branch.
(cherry picked from commit 8859c644ede4898f90f77dcad2286de08a9ba62e)
The test clang/test/SemaCXX/template-64605.cpp uses pragma FENV_ACCESS,
which is not supported on all targets. Restrict it to x86_64 only.
(cherry picked from commit 73e5a70e676850b79f196e01e2194a2485041584)
When an expression is instantiated, TreeTransform skips ImplicitCastExpr
nodes, assuming they are recreated when the instantiated expression is
built. It breaks functions that use non-default floating-point options,
because they are kept in these ImplicitCastExprs. In this case the
recreated ImplicitCastExpr takes FP options from the current Sema state
and not from AST node.
To fix this issue the FP options in Sema object are set when a compound
statement is cloned in TreeTransform.
This change fixes https://github.com/llvm/llvm-project/issues/64605
([Regression 16 -> 17] Template instantiation ignores FENV_ACCESS being
ON for both definition and instantiation).
Differential Revision: https://reviews.llvm.org/D158158
(cherry picked from commit 0baf85c331090fbe2d2b42214ed0664d55feb0b5)
5d8aaad445
removed the warning group as the functionality is no longer a GNU
extension. However, users have asked for the warning group to be
supported so that code transitioning from Clang 16 to Clang 17 has an
easier migration path when compiling with -Werror. This patch restores
the warning group, but as an ignored warning group because the
functionality is now always considered to be a C extension rather than
a GNU extension. This allows users to do:
-Werror -pedantic -Wno-gnu-empty-intializer -Wno-c2x-extensions
to silence the diagnostics in both Clang 16 and Clang 17.
Fixes https://github.com/llvm/llvm-project/issues/64357
Differential Revision: https://reviews.llvm.org/D157503
(cherry picked from commit 151214b40d869455666ca76548a9e3ad639f79de)
From https://en.cppreference.com/w/cpp/language/decltype:
Note that if the name of an object is parenthesized, it is treated as an
ordinary lvalue expression, thus decltype(x) and decltype((x)) are often
different types.
Fixes#64786.
Differential Revision: https://reviews.llvm.org/D158155
(cherry picked from commit e3a79503a30f8c9d8fba79f3e5427bb895f320cf)
This patch fixes the reported regression caused by D146358 through adding notes about an uninitialized base class when we diagnose uninitialized constructor.
This also changes the wording from the old one in order to make it clear that the uninitialized subobject is a base class and its constructor is not called.
Wording changes:
BEFORE: `subobject of type 'Base' is not initialized`
AFTER: `constructor of base class 'Base' is not called`
Fixes https://github.com/llvm/llvm-project/issues/63496
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D153969
