Commit Graph

3247 Commits

Author SHA1 Message Date
Richard Smith 72315d02c4 Treat `std::move`, `forward`, etc. as builtins.
This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`, `move_if_noexcept`, `as_const`, `addressof`, and the
libstdc++-specific function `__addressof`.

We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.

This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.

We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.

In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.

The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.

This is a re-commit of
  fc30901096,
  a571f82a50,
  64c045e25b, and
  de6ddaeef3,
and reverts aa643f455a.
This change also includes a workaround for users using libc++ 3.1 and
earlier (!!), as apparently happens on AIX, where std::move sometimes
returns by value.

Reviewed By: aaron.ballman

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

Revert "Fixup D123950 to address revert of D123345"

This reverts commit aa643f455a.
2022-04-20 17:58:31 -07:00
David Tenty 98d911e01f Revert "Treat `std::move`, `forward`, etc. as builtins."
This reverts commit b27430f9f4 as the
    parent https://reviews.llvm.org/D123345 breaks the AIX CI:

    https://lab.llvm.org/buildbot/#/builders/214/builds/819
2022-04-20 19:14:37 -04:00
Fangrui Song c79e6007ed Revert D119136 "[clang] Implement Change scope of lambda trailing-return-type" and its follow-up
This reverts commit 69dd89fdcb.
This reverts commit 04000c2f92.

The current states breaks libstdc++ usage (https://reviews.llvm.org/D119136#3455423).
The fixup has been reverted as it caused other valid code to be disallowed.
I think we should start from the clean state by reverting all relevant commits.
2022-04-20 10:57:12 -07:00
Fangrui Song 0f5dbfd29a Revert D123909 "[Clang] Use of decltype(capture) in parameter-declaration-clause"
This reverts commit daa6d7b250.

It breaks valid code like https://reviews.llvm.org/D123909#3461716
2022-04-20 10:32:41 -07:00
Aaron Ballman 9955f14aaf [C2x] Disallow functions without prototypes/functions with identifier lists
WG14 has elected to remove support for K&R C functions in C2x. The
feature was introduced into C89 already deprecated, so after this long
of a deprecation period, the committee has made an empty parameter list
mean the same thing in C as it means in C++: the function accepts no
arguments exactly as if the function were written with (void) as the
parameter list.

This patch implements WG14 N2841 No function declarators without
prototypes (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2841.htm)
and WG14 N2432 Remove support for function definitions with identifier
lists (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2432.pdf).

It also adds The -fno-knr-functions command line option to opt into
this behavior in other language modes.

Differential Revision: https://reviews.llvm.org/D123955
2022-04-20 13:28:15 -04:00
Jun Zhang 9c069374ce
Reland "[Clang][Sema] Fix invalid redefinition error in if/switch/for statement"
This reverts commit 9f075c3d84.
The broken build has alreasy been fixed in D124012, so reland it now.
Signed-off-by: Jun Zhang <jun@junz.org>
2022-04-21 01:18:58 +08:00
Jun Zhang 9f075c3d84
Revert "[Clang][Sema] Fix invalid redefinition error in if/switch/for statement"
This reverts commit be0905a333.
This patch broke build addressed in https://github.com/llvm/llvm-project/issues/54968
Signed-off-by: Jun Zhang <jun@junz.org>
2022-04-20 23:45:44 +08:00
Aaron Ballman 7d644e1215 [C11/C2x] Change the behavior of the implicit function declaration warning
C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never previously
declared. The resulting function would be globally declared as
extern int func(); -- a function without a prototype which accepts zero
or more arguments.

C99 removed support for this questionable feature due to severe
security concerns. However, there was no deprecation period; C89 had
the feature, C99 didn't. So Clang (and GCC) both supported the
functionality as an extension in C99 and later modes.

C2x no longer supports that function signature as it now requires all
functions to have a prototype, and given the known security issues with
the feature, continuing to support it as an extension is not tenable.

This patch changes the diagnostic behavior for the
-Wimplicit-function-declaration warning group depending on the language
mode in effect. We continue to warn by default in C89 mode (due to the
feature being dangerous to use). However, because this feature will not
be supported in C2x mode, we've diagnosed it as being invalid for so
long, the security concerns with the feature, and the trivial
workaround for users (declare the function), we now default the
extension warning to an error in C99-C17 mode. This still gives users
an easy workaround if they are extensively using the extension in those
modes (they can disable the warning or use -Wno-error to downgrade the
error), but the new diagnostic makes it more clear that this feature is
not supported and should be avoided. In C2x mode, we no longer allow an
implicit function to be defined and treat the situation the same as any
other lookup failure.

Differential Revision: https://reviews.llvm.org/D122983
2022-04-20 11:30:12 -04:00
Paul Kirth bac6cd5bf8 [misexpect] Re-implement MisExpect Diagnostics
Reimplements MisExpect diagnostics from D66324 to reconstruct its
original checking methodology only using MD_prof branch_weights
metadata.

New checks rely on 2 invariants:

1) For frontend instrumentation, MD_prof branch_weights will always be
   populated before llvm.expect intrinsics are lowered.

2) for IR and sample profiling, llvm.expect intrinsics will always be
   lowered before branch_weights are populated from the IR profiles.

These invariants allow the checking to assume how the existing branch
weights are populated depending on the profiling method used, and emit
the correct diagnostics. If these invariants are ever invalidated, the
MisExpect related checks would need to be updated, potentially by
re-introducing MD_misexpect metadata, and ensuring it always will be
transformed the same way as branch_weights in other optimization passes.

Frontend based profiling is now enabled without using LLVM Args, by
introducing a new CodeGen option, and checking if the -Wmisexpect flag
has been passed on the command line.

Reviewed By: tejohnson

Differential Revision: https://reviews.llvm.org/D115907
2022-04-19 21:23:48 +00:00
Tom Ritter 82f3ed9904 [analyzer] Expose Taint.h to plugins
Reviewed By: NoQ, xazax.hun, steakhal

Differential Revision: https://reviews.llvm.org/D123155
2022-04-19 16:55:01 +02:00
David Spickett 218b5c8394 [clang][AArch64] Remove BTI after setjmp from release notes
This is now going into 14.0.2 as
571c7d8f6dae1a8797ae3271c0c09fc648b1940b so will not be
new in clang-15.
2022-04-19 13:49:55 +00:00
Joseph Huber 0f8b8d79af [OpenMP][Docs] Remove old 14.0 release information
Summary:
This patch removes the OpenMP sections in the release notes. These will
be filled once the release is close and implementations are finalized.
2022-04-19 08:45:51 -04:00
Roy Jacobson 76410040b9 Revert "[Concepts] Fix overload resolution bug with constrained candidates"
This reverts commit 454d1df942.
2022-04-19 07:51:21 -04:00
Roy Jacobson 454d1df942 [Concepts] Fix overload resolution bug with constrained candidates
When doing overload resolution, we have to check that candidates' parameter types are equal before trying to find a better candidate through checking which candidate is more constrained.
This revision adds this missing check and makes us diagnose those cases as ambiguous calls when the types are not equal.

Fixes GitHub issue https://github.com/llvm/llvm-project/issues/53640

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D123182
2022-04-19 04:45:28 -04:00
Timm Bäder 33ec653055 [clang][lexer] Allow u8 character literal prefixes in C2x
Implement N2418 for C2x.

Differential Revision: https://reviews.llvm.org/D119221
2022-04-19 09:57:51 +02:00
Joseph Huber 15e62062c0 [Clang][Docs] Update information on the new driver now that it's default
Summary:
This patch updates some of the documentation on the new driver now that
it's the default. Also the ABI for embedding these images changed.
2022-04-18 15:05:09 -04:00
Corentin Jabot daa6d7b250 [Clang] Use of decltype(capture) in parameter-declaration-clause
Partially implement the proposed resolution to CWG2569.

D119136 broke some libstdc++ code, as P2036R3, implemented as a DR to
C++11 made ill-formed some previously valid and innocuous code.

We resolve this issue to allow decltype(x) - but not decltype((x)
to appear in the parameter list of a lambda that capture x by copy.

Unlike CWG2569, we do not extend that special treatment to
sizeof/noexcept yet, as the resolution has not been approved yet
and keeping the review small allows a quicker fix of impacted code.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D123909
2022-04-18 15:58:25 +02:00
Richard Smith b27430f9f4 Treat `std::move`, `forward`, etc. as builtins.
This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`, `move_if_noexcept`, `as_const`, `addressof`, and the
libstdc++-specific function `__addressof`.

We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.

This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.

We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.

In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.

The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.

This is a re-commit of
  fc30901096,
  a571f82a50, and
  64c045e25b
which were reverted in
  e75d8b7037
due to a crasher bug where CodeGen would emit a builtin glvalue as an
rvalue if it constant-folds.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D123345
2022-04-17 13:26:16 -07:00
Vitaly Buka e75d8b7037 Revert "Treat `std::move`, `forward`, and `move_if_noexcept` as builtins."
Revert "Extend support for std::move etc to also cover std::as_const and"
Revert "Update test to handle opaque pointers flag flip."

It crashes on libcxx tests https://lab.llvm.org/buildbot/#/builders/85/builds/8174

This reverts commit fc30901096.
This reverts commit a571f82a50.
This reverts commit 64c045e25b.
2022-04-16 00:27:51 -07:00
Richard Smith 64c045e25b Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.
We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.

This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.

We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.

In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.

The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D123345
2022-04-15 14:09:45 -07:00
Corentin Jabot 04000c2f92 [clang] Implement Change scope of lambda trailing-return-type
Implement P2036R3.

Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.

Up until now, the entire lambda declaration up to the start of the body would be parsed in the parent scope, such that capture would not be available to look up.

The scoping is changed to have an outer lambda scope, followed by the lambda prototype and body.

The lambda scope is necessary because there may be a template scope between the start of the lambda (to which we want to attach the captured variable) and the prototype scope.

We also need to introduce a declaration context to attach the captured variable to (and several parts of clang assume captures are handled from the call operator context), before we know the type of the call operator.

The order of operations is as follow:

* Parse the init capture in the lambda's parent scope

* Introduce a lambda scope

* Create the lambda class and call operator

* Add the init captures to the call operator context and the lambda scope. But the variables are not capured yet (because we don't know their type).
Instead, explicit  captures are stored in a temporary map that conserves the order of capture (for the purpose of having a stable order in the ast dumps).

* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.

* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context, we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).

* The lambda qualifiers are parsed, at this point We can switch (for the second time) inside the lambda context, unset the flag indicating that we have not parsed the lambda qualifiers,
record the lambda is mutable and capture the explicit variables.

* We can parse the rest of the lambda type, transform the lambda and call operator's types and also transform the call operator to a template function decl where necessary.

At this point, both captures and parameters can be injected in the body's scope. When trying to capture an implicit variable, if we are before the qualifiers of a lambda, we need to remember that the variables are still in the parent's context (rather than in the call operator's).

Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu

Differential Revision: https://reviews.llvm.org/D119136
2022-04-15 16:50:52 +02:00
Jun Zhang be0905a333
[Clang][Sema] Fix invalid redefinition error in if/switch/for statement
Clang should no longer incorrectly diagnose a variable declaration inside of a
lambda expression that shares the name of a variable in a containing
if/while/for/switch init statement as a redeclaration.

After this patch, clang is supposed to accept code below:

void foo() {
  for (int x = [] { int x = 0; return x; }(); ;) ;
}

Fixes https://github.com/llvm/llvm-project/issues/54913

Differential Revision: https://reviews.llvm.org/D123840
2022-04-15 21:54:39 +08:00
Aaron Ballman 33d3fc4466 [C89/C2x] Diagnose calls to a function without a prototype but passes arguments
This catches places where a function without a prototype is
accidentally used, potentially passing an incorrect number of
arguments, and is a follow-up to the work done in
https://reviews.llvm.org/D122895 and described in the RFC
(https://discourse.llvm.org/t/rfc-enabling-wstrict-prototypes-by-default-in-c).
The diagnostic is grouped under the new -Wdeprecated-non-prototypes
warning group and is enabled by default.

The diagnostic is disabled if the function being called was implicitly
declared (the user already gets an on-by-default warning about the
creation of the implicit function declaration, so no need to warn them
twice on the same line). Additionally, the diagnostic is disabled if
the declaration of the function without a prototype was in a location
where the user explicitly disabled deprecation warnings for functions
without prototypes (this allows the provider of the API a way to
disable the diagnostic at call sites because the lack of prototype is
intentional).
2022-04-15 09:08:54 -04:00
Richard Smith 836e610d93 Revert "[clang] Implement Change scope of lambda trailing-return-type"
This reverts commit c729d5be78.

This change breaks thread safety annotations on lambdas.
2022-04-13 21:34:08 -07:00
Corentin Jabot c729d5be78 [clang] Implement Change scope of lambda trailing-return-type
Implement P2036R3.

Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.

Up until now, the entire lambda declaration up to the start
of the body would  be parsed in the parent scope, such that
captures would not be available to look up.

The scoping is changed to have an outer lambda scope,
followed by the lambda prototype and body.

The lambda scope is necessary because there may be a template scope
between the start of the lambda (to which we want to attach
the captured variable) and the prototype scope.

We also need to introduce a declaration context to attach the captured
variable to (and several parts of clang assume captures are handled from
the call operator context), before we know the type of the call operator.

The order of operations is as follow:

* Parse the init capture in the lambda's parent scope
* Introduce a lambda scope
* Create the lambda class and call operator
* Add the init captures to the call operator context and the lambda scope.
  But the variables are not capured yet (because we don't know their type).
  Instead, explicit  captures are stored in a temporary map that
  conserves the order of capture (for the purpose of having a stable order in the ast dumps).

* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.

* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context,
  we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).

* The lambda qualifiers are parsed, at this point,
  we can switch (for the second time) inside the lambda context,
  unset the flag indicating that we have not parsed the lambda qualifiers,
  record the lambda is mutable and capture the explicit variables.

* We can parse the rest of the lambda type, transform the lambda and call operator's types and also
  transform the call operator to a template function decl where necessary.

At this point, both captures and parameters can be injected in the body's scope.
When trying to capture an implicit variable, if we are before the qualifiers of a lambda,
we need to remember that the variables are still in the parent's context (rather than in the call operator's).

This is a recommit of adff142dc2 after a fix in d8d793f29b

Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu

Differential Revision: https://reviews.llvm.org/D119136
2022-04-13 23:07:39 +02:00
Mehdi Amini 26eec9e9db Revert "[clang] Implement Change scope of lambda trailing-return-type"
This reverts commit adff142dc2.
This broke clang bootstrap: it made existing C++ code in LLVM invalid:

llvm/include/llvm/CodeGen/LiveInterval.h:630:53: error: captured variable 'Idx' cannot appear here
              [=](std::remove_reference_t<decltype(*Idx)> V,
                                                    ^
2022-04-13 19:35:13 +00:00
Corentin Jabot adff142dc2 [clang] Implement Change scope of lambda trailing-return-type
Implement P2036R3.

Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.

Up until now, the entire lambda declaration up to the start of the body would be parsed in the parent scope, such that capture would not be available to look up.

The scoping is changed to have an outer lambda scope, followed by the lambda prototype and body.

The lambda scope is necessary because there may be a template scope between the start of the lambda (to which we want to attach the captured variable) and the prototype scope.

We also need to introduce a declaration context to attach the captured variable to (and several parts of clang assume captures are handled from the call operator context), before we know the type of the call operator.

The order of operations is as follow:

* Parse the init capture in the lambda's parent scope

* Introduce a lambda scope

* Create the lambda class and call operator

* Add the init captures to the call operator context and the lambda scope. But the variables are not capured yet (because we don't know their type).
Instead, explicit  captures are stored in a temporary map that conserves the order of capture (for the purpose of having a stable order in the ast dumps).

* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.

* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context, we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).

* The lambda qualifiers are parsed, at this point We can switch (for the second time) inside the lambda context, unset the flag indicating that we have not parsed the lambda qualifiers,
record the lambda is mutable and capture the explicit variables.

* We can parse the rest of the lambda type, transform the lambda and call operator's types and also transform the call operator to a template function decl where necessary.

At this point, both captures and parameters can be injected in the body's scope. When trying to capture an implicit variable, if we are before the qualifiers of a lambda, we need to remember that the variables are still in the parent's context (rather than in the call operator's).

Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu

Differential Revision: https://reviews.llvm.org/D119136
2022-04-13 20:00:03 +02:00
Aaron Ballman 385e7df330 Correctly diagnose prototype redeclaration errors in C
We did not implement C99 6.7.5.3p15 fully in that we missed the rule
for compatible function types where a prior declaration has a prototype
and a subsequent definition (not just declaration) has an empty
identifier list or an identifier list with a mismatch in parameter
arity. This addresses that situation by issuing an error on code like:

void f(int);
void f() {} // type conflicts with previous declaration

(Note: we already diagnose the other type conflict situations
appropriately, this was the only situation we hadn't covered that I
could find.)
2022-04-13 08:21:31 -04:00
Jun Zhang f9c2f821d7
[Clang] Fix unknown type attributes diagnosed twice with [[]] spelling
Don't warn on unknown type attributes in Parser::ProhibitCXX11Attributes
for most cases, but left the diagnostic to the later checks.
module declaration and module import declaration are special cases.

Fixes https://github.com/llvm/llvm-project/issues/54817

Differential Revision: https://reviews.llvm.org/D123447
2022-04-12 21:11:51 +08:00
PoYao Chang 50b1faf5c1 [Clang] CWG 1394: Incomplete types as parameters of deleted functions
According to CWG 1394 and C++20 [dcl.fct.def.general]p2,
Clang should not diagnose incomplete types if function body is "= delete;".
For example:
```
struct Incomplete;
Incomplete f(Incomplete) = delete; // well-formed
```

Also close https://github.com/llvm/llvm-project/issues/52802

Differential Revision: https://reviews.llvm.org/D122981
2022-04-12 11:10:10 +08:00
Fangrui Song 8eb6741fa0 [docs] Remove outdated -fexperimental-new-pass-manager for profile data remapping support 2022-04-11 13:49:06 -07:00
Patryk Wychowaniec d16a631c12 [AVR] Merge AVRRelaxMemOperations into AVRExpandPseudoInsts
This commit contains a refactoring that merges AVRRelaxMemOperations
into AVRExpandPseudoInsts, so that we have a single place in code that
expands the STDWPtrQRr opcode.

Seizing the day, I've also fixed a couple of potential bugs with our
previous implementation (e.g. when the destination register was killed,
the previous implementation would try to .addDef() that killed
register, crashing LLVM in the process - that's fixed now, as proved by
the test).

Reviewed By: benshi001

Differential Revision: https://reviews.llvm.org/D122533
2022-04-11 02:42:13 +00:00
Connor Kuehl 7aa8c38a9e [randstruct] Add randomize structure layout support
The Randstruct feature is a compile-time hardening technique that
randomizes the field layout for designated structures of a code base.
Admittedly, this is mostly useful for closed-source releases of code,
since the randomization seed would need to be available for public and
open source applications.

Why implement it? This patch set enhances Clang’s feature parity with
that of GCC which already has the Randstruct feature. It's used by the
Linux kernel in certain structures to help thwart attacks that depend on
structure layouts in memory.

This patch set is a from-scratch reimplementation of the Randstruct
feature that was originally ported to GCC. The patches for the GCC
implementation can be found here:

  https://www.openwall.com/lists/kernel-hardening/2017/04/06/14

Link: https://lists.llvm.org/pipermail/cfe-dev/2019-March/061607.html
Co-authored-by: Cole Nixon <nixontcole@gmail.com>
Co-authored-by: Connor Kuehl <cipkuehl@gmail.com>
Co-authored-by: James Foster <jafosterja@gmail.com>
Co-authored-by: Jeff Takahashi <jeffrey.takahashi@gmail.com>
Co-authored-by: Jordan Cantrell <jordan.cantrell@mail.com>
Co-authored-by: Nikk Forbus <nicholas.forbus@gmail.com>
Co-authored-by: Tim Pugh <nwtpugh@gmail.com>
Co-authored-by: Bill Wendling <isanbard@gmail.com>
Signed-off-by: Bill Wendling <isanbard@gmail.com>

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D121556
2022-04-09 13:15:36 -07:00
owenca f67e3f6e8c [clang-format] Add execute permission to dump_format_help.py 2022-04-09 07:58:33 -07:00
Fangrui Song ca68038d12 Reland "[Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON""
(With C++ exceptions, `clang++ --target=mips64{,el}-linux-gnu -fpie -pie
-fuse-ld=lld` has link errors (lld does not implement some strange R_MIPS_64
.eh_frame handling in GNU ld). However, sanitizer-x86_64-linux-qemu used this to
build ScudoUnitTests. Pined ScudoUnitTests to -no-pie.)

Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.

Differential Revision: https://reviews.llvm.org/D120305
2022-04-08 23:40:18 -07:00
Fangrui Song a58d0af058 Revert D121556 "[randstruct] Add randomize structure layout support"
This reverts commit 3f0587d0c6.

Not all tests pass after a few rounds of fixes.

I spot one failure that std::shuffle (potentially different results with
different STL implementations) was misused and replaced it with llvm::shuffle,
but there appears to be another failure in a Windows build.

The latest failure is reported on https://reviews.llvm.org/D121556#3440383
2022-04-08 18:37:26 -07:00
Aaron Ballman 11da1b53d8 [C89/C2x] Improve diagnostics around strict prototypes in C
Functions without prototypes in C (also known as K&R C functions) were
introduced into C89 as a deprecated feature and C2x is now reclaiming
that syntax space with different semantics. However, Clang's
-Wstrict-prototypes diagnostic is off-by-default (even in pedantic
mode) and does not suffice to warn users about issues in their code.

This patch changes the behavior of -Wstrict-prototypes to only diagnose
declarations and definitions which are not going to change behavior in
C2x mode, and enables the diagnostic in -pedantic mode. The diagnostic
is now specifically about the fact that the feature is deprecated.

It also adds -Wdeprecated-non-prototype, which is grouped under
-Wstrict-prototypes and diagnoses declarations or definitions which
will change behavior in C2x mode. This diagnostic is enabled by default
because the risk is higher for the user to continue to use the
deprecated feature.

Differential Revision: https://reviews.llvm.org/D122895
2022-04-08 16:19:58 -04:00
Connor Kuehl 3f0587d0c6 [randstruct] Add randomize structure layout support
The Randstruct feature is a compile-time hardening technique that
randomizes the field layout for designated structures of a code base.
Admittedly, this is mostly useful for closed-source releases of code,
since the randomization seed would need to be available for public and
open source applications.

Why implement it? This patch set enhances Clang’s feature parity with
that of GCC which already has the Randstruct feature. It's used by the
Linux kernel in certain structures to help thwart attacks that depend on
structure layouts in memory.

This patch set is a from-scratch reimplementation of the Randstruct
feature that was originally ported to GCC. The patches for the GCC
implementation can be found here:

  https://www.openwall.com/lists/kernel-hardening/2017/04/06/14

Link: https://lists.llvm.org/pipermail/cfe-dev/2019-March/061607.html
Co-authored-by: Cole Nixon <nixontcole@gmail.com>
Co-authored-by: Connor Kuehl <cipkuehl@gmail.com>
Co-authored-by: James Foster <jafosterja@gmail.com>
Co-authored-by: Jeff Takahashi <jeffrey.takahashi@gmail.com>
Co-authored-by: Jordan Cantrell <jordan.cantrell@mail.com>
Co-authored-by: Nikk Forbus <nicholas.forbus@gmail.com>
Co-authored-by: Tim Pugh <nwtpugh@gmail.com>
Co-authored-by: Bill Wendling <isanbard@gmail.com>
Signed-off-by: Bill Wendling <isanbard@gmail.com>

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D121556
2022-04-08 12:48:30 -07:00
Chris Bieneman 9e3678e161 [Clang] [Docs] Add HLSLSupport page
This document is a first-stab at addressing some of the questions about
HLSL support in Clang.

Differential Revision: https://reviews.llvm.org/D123278
2022-04-08 12:17:45 -05:00
Joseph Huber ae377575b2 [OpenMP] Remove help and documentation for old flag
Summary:
The `-fopenmp-target-new-runtime` flag has not been used for awhile. It
was present in a previous release so we shouldn't remove it for
backwards compatibility, but we shouldn't have documentation or a help
message for it.
2022-04-08 10:16:33 -04:00
Nico Weber e22a60b1c8 Revert "Reland "[Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON"""
This reverts commit 2aca33baf1.
Broke tests on several bots, see comments on https://reviews.llvm.org/D120305
2022-04-07 10:07:07 -04:00
Fangrui Song 2aca33baf1 Reland "[Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON""
(The upgrade of the ppc64le bot and D121257 have fixed compiler-rt failures. Tested by nemanjai.)

Default the option introduced in D113372 to ON to match all(?) major Linux
distros. This matches GCC and improves consistency with Android and linux-musl
which always default to PIE.
Note: CLANG_DEFAULT_PIE_ON_LINUX may be removed in the future.

Differential Revision: https://reviews.llvm.org/D120305
2022-04-06 20:19:07 -07:00
Krystian Kuzniarek 1cd4346409 [clang-format][docs] Fix incorrect 'clang-format 11' option markers
Differential Revision: https://reviews.llvm.org/D122064
2022-04-06 18:38:30 -07:00
Nathan Sidwell 482fad4a3f [clang][DOC] Document module mangler changes
Note that the mangling has changed and the demangler's learnt a new
trick.  Obviously dependent upon the mangler and demangler patches.

Reviewed By: bruno

Differential Revision: https://reviews.llvm.org/D123141
2022-04-06 11:13:32 -07:00
Jun Zhang 8a4d388c7f
[Clang][Sema] Prohibit statement expression in the default argument
As statement expression makes no sense in the default argument,
this patch tries to disable it in the all cases.

Please note that the statement expression is a GNU extension, which
means that Clang should be consistent with GCC. However, there's no
response from GCC devs since we have raised the issue for several weeks.
In this case, I think we can disallow statement expressions as a default
parameter in general for now, and relax the restriction if GCC folks
decide to retain the feature for functions but not lambdas in the
future.

Related discussion: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104765

Fixes https://github.com/llvm/llvm-project/issues/53488

Differential Revision: https://reviews.llvm.org/D119609
2022-04-06 09:28:20 +08:00
Corentin Jabot 84f0a36b14 [Clang] Do not warn on unused lifetime-extending vars with side effects...
const auto & var = ObjectWithSideEffects();

Fixes https://github.com/llvm/llvm-project/issues/54489

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D122661
2022-04-05 21:03:02 +02:00
Jorge Gorbe Moya fc7573f29c Revert "[misexpect] Re-implement MisExpect Diagnostics"
This reverts commit 46774df307.
2022-03-31 14:54:41 -07:00
Paul Kirth 46774df307 [misexpect] Re-implement MisExpect Diagnostics
Reimplements MisExpect diagnostics from D66324 to reconstruct its
original checking methodology only using MD_prof branch_weights
metadata.

New checks rely on 2 invariants:

1) For frontend instrumentation, MD_prof branch_weights will always be
   populated before llvm.expect intrinsics are lowered.

2) for IR and sample profiling, llvm.expect intrinsics will always be
   lowered before branch_weights are populated from the IR profiles.

These invariants allow the checking to assume how the existing branch
weights are populated depending on the profiling method used, and emit
the correct diagnostics. If these invariants are ever invalidated, the
MisExpect related checks would need to be updated, potentially by
re-introducing MD_misexpect metadata, and ensuring it always will be
transformed the same way as branch_weights in other optimization passes.

Frontend based profiling is now enabled without using LLVM Args, by
introducing a new CodeGen option, and checking if the -Wmisexpect flag
has been passed on the command line.

Reviewed By: tejohnson

Differential Revision: https://reviews.llvm.org/D115907
2022-03-31 17:38:21 +00:00
Qiu Chaofan e1b85430e9 Revert "[Clang] Add option to set alternative toolchain path"
--overlay-platform-toolchain inserts a whole new toolchain path with
higher priority than system default, which could be achieved by
composing smaller options. We need to figure out alternative solution
and what is missing among these basic options.
2022-03-31 15:58:01 +08:00
wangyihan 907d3acefc [Clang][CodeGen]Beautify dump format, add indent for nested struct and struct members
Beautify dump format, add indent for nested struct and struct members, also fix test cases in dump-struct-builtin.c
for example:
struct:
```
  struct A {
    int a;
    struct B {
      int b;
      struct C {
        struct D {
          int d;
          union E {
            int x;
            int y;
          } e;
        } d;
        int c;
      } c;
    } b;
  };
```
Before:
```
struct A {
int a = 0
struct B {
    int b = 0
struct C {
struct D {
            int d = 0
union E {
                int x = 0
                int y = 0
                }
            }
        int c = 0
        }
    }
}
```
After:
```
struct A {
    int a = 0
    struct B {
        int b = 0
        struct C {
            struct D {
                int d = 0
                union E {
                    int x = 0
                    int y = 0
                }
            }
            int c = 0
        }
    }
}
```

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D122704
2022-03-31 07:38:37 +08:00