| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.
This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.
Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.
The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.
Function templates and virtual functions are NOT yet supported (not supported
in GCC either).
Additionally, constructors/destructors are disallowed, but the former is
planned.
llvm-svn: 322028
|
|
|
|
|
|
|
|
|
|
| |
This is not quite NFC: we don't perform the usual arithmetic conversions unless
we have an operand of arithmetic or enumeration type any more. This matches the
standard rule, but actually has no effect other than to marginally improve our
diagnostics for the non-arithmetic, non-enumeration cases (by not performing
integral promotions on one operand if the other is a pointer).
llvm-svn: 322024
|
|
|
|
|
|
|
| |
The important check is that we're not within a template *instantiation*, which
we check separately.
llvm-svn: 321977
|
|
|
|
|
|
|
|
| |
Check whether we are comparing the same entity, not merely the same
declaration, and don't assume that weak declarations resolve to distinct
entities.
llvm-svn: 321976
|
|
|
|
|
|
|
|
| |
compare checking.
In passing, improve vector compare diagnostic to match scalar compare diagnostic.
llvm-svn: 321972
|
|
|
|
|
|
|
|
|
|
| |
redecl chain for an imported declaration, make sure to check the IDNS of prior
imported decls.
Otherwise we can end up finding an invisible friend declaration and incorrectly
believing that it should be visible.
llvm-svn: 321916
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-noexcept pointer in C++17
As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/
#!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non-
noexcept pointer is undefined behavior?", such a call should not be UB.
However, Clang currently warns about it.
This change removes exception specifications from the function types recorded
for -fsanitize=function, both in the functions themselves and at the call sites.
That means that calling a non-noexcept function through a noexcept pointer will
also not be flagged as UB. In the review of this change, that was deemed
acceptable, at least for now. (See the "TODO" in compiler-rt
test/ubsan/TestCases/TypeCheck/Function/function.cpp.)
To remove exception specifications from types, the existing internal
ASTContext::getFunctionTypeWithExceptionSpec was made public, and some places
otherwise unrelated to this change have been adapted to call it, too.
This is the cfe part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40720
llvm-svn: 321859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
each kind.
Attribute instantiation would previously default to instantiating each kind of
attribute only once. This was overridden by a flag whose intended purpose was
to permit attributes from a prior declaration to be inherited onto a new
declaration even if that new declaration had its own copy of the attribute.
This is the wrong behavior: when instantiating attributes from a template, we
should always instantiate all the attributes that were written on that
template.
This patch renames the flag in the Attr class (and TableGen sources) to more
clearly identify what it's actually for, and removes the usage of the flag from
template instantiation. I also removed the flag from AlignedAttr, which was
only added to work around the incorrect suppression of duplicate attribute
instantiation.
llvm-svn: 321834
|
|
|
|
|
|
|
|
| |
Patch fixes incorrect capturing of the expressions in clauses with
expressions that must be captured for the combined constructs. Incorrect
capturing may lead to compiler crash during codegen phase.
llvm-svn: 321820
|
|
|
|
|
|
|
|
|
|
| |
during template argument deduction.
We already did this when the injected-class-name was in P, but missed the case
where it was in A. This (probably) can't happen except in implicit deduction
guides.
llvm-svn: 321779
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a warning
This commit separates out the warn_nsconsumed_attribute_mismatch and
warn_nsreturns_retained_attribute_mismatch diagnostic into a warning and error.
This is needed to avoid a module import regression introduced by r313717 that
turned these errors into warnings and started promoting them only when needed,
which caused an error when importing a module as it had different warning
settings.
rdar://36265651
llvm-svn: 321775
|
|
|
|
|
|
|
|
|
|
|
| |
an inline namespace, update its semantic DeclContext to match.
We would previously get the semantic DeclContext wrong (pointing to the named
scope rather than the inline namespace within it), resulting in wrong lookup
results and linkage-related problems if the inline namespace was an anonymous
namespace.
llvm-svn: 321770
|
|
|
|
|
|
|
|
|
|
| |
distribute parallel for' on host
https://reviews.llvm.org/D41709
This patch includes code generation and testing for offloading when target device is host.
llvm-svn: 321759
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function to function pointer.
Previously, we would:
* compute the type of the conversion function and static invoker as a
side-effect of template argument deduction for a conversion
* re-compute the type as part of deduced return type deduction when building
the conversion function itself
Neither of these turns out to be quite correct. There are other ways to reach a
declaration of the conversion function than in a conversion (such as an
explicit call or friend declaration), and performing auto deduction causes the
function type to be rebuilt in the context of the lambda closure type (which is
different from the context in which it originally appeared, resulting in
spurious substitution failures for constructs that are valid in one context but
not the other, such as the use of an enclosing class's "this" pointer).
This patch switches us to use a different strategy: as before, we use the
declared type of the operator() to form the type of the conversion function and
invoker, but we now populate that type as part of return type deduction for the
conversion function. And the invoker is now treated as simply being an
implementation detail of building the conversion function, and isn't given
special treatment by template argument deduction for the conversion function
any more.
llvm-svn: 321683
|
|
|
|
|
|
|
|
| |
system header.
The way to fix an undefined-template warning is to add lines to the header file that defines the template pattern. We should suppress the warnings when the template pattern is in a system header because we don't expect users to edit those.
llvm-svn: 321665
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rdar://problem/33251668
Reviewers: arphaman, ahatanak
Reviewed By: arphaman
Subscribers: ptitei, cfe-commits
Differential Revision: https://reviews.llvm.org/D41528
llvm-svn: 321660
|
|
|
|
|
|
|
|
|
|
|
|
| |
- reverts r321622, r321625, and r321626.
- the use of bit-fields is still resulting in warnings - even though we can use static-asserts to harden the code and ensure the bit-fields are wide enough. The bots still complain of warnings being seen.
- to silence the warnings requires specifying the bit-fields with the underlying enum type (as opposed to the enum type itself), which then requires lots of unnecessary static casts of each enumerator within DeclSpec to the underlying-type, which even though could be seen as implementation details, it does hamper readability - and given the additional litterings, makes me question the value of the change.
So in short - I give up (for now at least).
Sorry about the noise.
llvm-svn: 321628
|
|
|
|
|
|
|
|
|
|
| |
tools/clang/lib/Sema/DeclSpec.cpp: In member function 'void clang::DeclSpec::Finish(clang::Sema&, const clang::PrintingPolicy&)':
tools/clang/lib/Sema/DeclSpec.cpp:1116:8: error: could not convert 'clang::DeclSpec::TSW_unspecified' from 'const TSW {aka const clang::TypeSpecifierWidth}' to 'int'
tools/clang/lib/Sema/DeclSpec.cpp:1117:8: error: could not convert 'clang::DeclSpec::TSW_short' from 'const TSW {aka const clang::TypeSpecifierWidth}' to 'int'
tools/clang/lib/Sema/DeclSpec.cpp:1118:8: error: could not convert 'clang::DeclSpec::TSW_longlong' from 'const TSW {aka const clang::TypeSpecifierWidth}' to 'int'
tools/clang/lib/Sema/DeclSpec.cpp:1128:8: error: could not convert 'clang::DeclSpec::TSW_long' from 'const TSW {aka const clang::TypeSpecifierWidth}' to 'int'
llvm-svn: 321626
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r321622
- bots were complaining that the bit-field width was less than the width of the underlying type (note, underlying types of enums can not be bit-fields)
- add static_asserts for TSS and TSW to ensure that the bit-fields can hold all the enumerators - and add comments next to the last enumerator warning not to reorder.
See https://reviews.llvm.org/rC321622 for the patch that introduced the warnings.
llvm-svn: 321625
|
|
|
|
|
|
|
|
|
|
|
|
| |
TypeSpecifierType into scoped enums with underlying types.
- Since these enums are used as bit-fields - for the bit-fields to be interpreted as unsigned, the underlying type must be specified as unsigned.
Previous failed attempt - wherein I did not specify an underlying type - was the sum of:
https://reviews.llvm.org/rC321614
https://reviews.llvm.org/rC321615
llvm-svn: 321622
|
|
|
|
|
|
|
|
| |
- the enum changes to TypeSpecifierType are breaking some tests - and will require a more careful integration.
Sorry about rushing these changes - thought I could sneak them in prior to heading out for new years ;)
llvm-svn: 321616
|
|
|
|
|
|
|
|
| |
TypeSpecifierType into scoped enums.
llvm-svn: 321614
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Re-submission of D39937 with fixed tests.)
Adjust wording for const-qualification mismatch to be a little more clear.
Also add another diagnostic for a ref qualifier mismatch, which previously produced a useless error (this error path is simply very old; see rL119336):
Before:
error: cannot initialize object parameter of type 'X0' with an expression of type 'X0'
After:
error: 'this' argument to member function 'rvalue' is an lvalue, but function has rvalue ref-qualifier
Reviewers: aaron.ballman
Reviewed By: aaron.ballman
Subscribers: lebedev.ri, cfe-commits
Differential Revision: https://reviews.llvm.org/D41646
llvm-svn: 321609
|
|
|
|
|
|
|
|
| |
member functions
A few tests need to be fixed
llvm-svn: 321593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adjust wording for const-qualification mismatch to be a little more clear.
Also add another diagnostic for a ref qualifier mismatch, which previously produced a useless error (this error path is simply very old; see rL119336):
Before:
error: cannot initialize object parameter of type 'X0' with an expression of type 'X0'
After:
error: 'this' argument to member function 'rvalue' is an lvalue, but function has rvalue ref-qualifier
Reviewers: rsmith, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: lebedev.ri, aaron.ballman, cfe-commits
Differential Revision: https://reviews.llvm.org/D39937
llvm-svn: 321592
|
|
|
|
|
|
| |
UnqualifiedIdKind.
llvm-svn: 321574
|
|
|
|
|
|
| |
Note, we don't do any bitwise manipulations when using them.
llvm-svn: 321546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previsouly clang tried instantiating member initializers even if ctor
body was skipped, this caused spurious errors (see the test).
Reviewers: sepavloff, klimek
Reviewed By: sepavloff
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41492
llvm-svn: 321520
|
|
|
|
|
|
| |
Added codegen for `depend` clauses on `target enter|exit data` directives.
llvm-svn: 321495
|
|
|
|
| |
llvm-svn: 321494
|
|
|
|
|
|
| |
Added codegen for `depend` clauses on `target data update` directives.
llvm-svn: 321493
|
|
|
|
|
|
| |
Saves a pointer on every CompoundStmt.
llvm-svn: 321429
|
|
|
|
|
|
|
|
| |
NamedDecl (vs Decl)
This patch addresses a FIXME and has the template-parameter processing functions return a more derived common type NamedDecl (as opposed to a type needlessly higher up in the inheritance hierarchy : Decl).
llvm-svn: 321409
|
|
|
|
|
|
| |
fallthrough. Fixes GCC and Clang warnings about this.
llvm-svn: 321392
|
|
|
|
|
|
|
|
| |
If the clause is applied to the combined construct and has captured
expression, try to capture this expression by value rather than by
reference.
llvm-svn: 321386
|
|
|
|
| |
llvm-svn: 321346
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The standard correctly forbids various decl-specifiers that dont make sense on non-type template parameters - such as the extern in:
template<extern int> struct X;
This patch implements those restrictions (in a fashion similar to the corresponding checks on function parameters within ActOnParamDeclarator).
Credit goes to miyuki (Mikhail Maltsev) for drawing attention to this issue, authoring the initial versions of this patch, and supporting the effort to re-engineer it slightly. Thank you!
For details of how this patch evolved please see: https://reviews.llvm.org/D40705
llvm-svn: 321339
|
|
|
|
|
|
|
|
| |
accept bit 2 which is supposed to indicate the prefetched addresses will be written to
Add the appropriate _MM_HINT_ET0/ET1 defines to match gcc.
llvm-svn: 321325
|
|
|
|
|
|
|
|
| |
This is a slightly odd construct (it's more common to see "A (::B)()") but can
happen in friend declarations, and the parens are not redundant as they prevent
the :: binding to the left.
llvm-svn: 321318
|
|
|
|
|
|
|
| |
The parentheses here are not redundant as they affect the binding of the
'::' token.
llvm-svn: 321304
|
|
|
|
|
|
| |
Otherwise it will serve as a deduction guide for the wrong class template.
llvm-svn: 321297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Looking through the code, I saw a FIXME on IFunc to switch it
to a target specific attribute. In looking through it, i saw that
the no-longer-appropriately-named TargetArch didn't support ObjectFormat
checking.
This patch changes the name of TargetArch to TargetSpecific
(since it checks much more than just Arch), makes "Arch" optional, adds
support for ObjectFormat, better documents the TargetSpecific type, and
changes IFunc over to a TargetSpecificAttr.
Differential Revision: https://reviews.llvm.org/D41303
llvm-svn: 321201
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Fixed an assert in Sema::InstantiateFunctionDefinition and added
support for instantiating a function template with skipped body.
- Properly call setHasSkippedBody for FunctionTemplateDecl passed to
Sema::ActOnSkippedFunctionBody.
Reviewers: sepavloff, bkramer
Reviewed By: sepavloff
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D41237
llvm-svn: 321174
|
|
|
|
| |
llvm-svn: 321116
|
|
|
|
| |
llvm-svn: 321115
|
|
|
|
|
|
| |
Convert most uses to range-for loops. No functionality change intended.
llvm-svn: 320954
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In D41064, I proposed adding `#pragma clang diagnostic ignored
"-Wuser-defined-literals"` to some of libc++'s headers, since these
warnings are now triggered by clang's new `-std=gnu++14` default:
```
$ cat test.cpp
#include <string>
$ clang -std=c++14 -Wsystem-headers -Wall -Wextra -c test.cpp
In file included from test.cpp:1:
In file included from /usr/include/c++/v1/string:470:
/usr/include/c++/v1/string_view:763:29: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view<char> operator "" sv(const char *__str, size_t __len)
^
/usr/include/c++/v1/string_view:769:32: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view<wchar_t> operator "" sv(const wchar_t *__str, size_t __len)
^
/usr/include/c++/v1/string_view:775:33: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view<char16_t> operator "" sv(const char16_t *__str, size_t __len)
^
/usr/include/c++/v1/string_view:781:33: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view<char32_t> operator "" sv(const char32_t *__str, size_t __len)
^
In file included from test.cpp:1:
/usr/include/c++/v1/string:4012:24: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string<char> operator "" s( const char *__str, size_t __len )
^
/usr/include/c++/v1/string:4018:27: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string<wchar_t> operator "" s( const wchar_t *__str, size_t __len )
^
/usr/include/c++/v1/string:4024:28: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string<char16_t> operator "" s( const char16_t *__str, size_t __len )
^
/usr/include/c++/v1/string:4030:28: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string<char32_t> operator "" s( const char32_t *__str, size_t __len )
^
8 warnings generated.
```
Both @aaron.ballman and @mclow.lists felt that adding this workaround to
the libc++ headers was the wrong way, and it should be fixed in clang
instead.
Here is a proposal to do just that. I verified that this suppresses the
warning, even when -Wsystem-headers is used, and that the warning is
still emitted for a declaration outside of system headers.
Reviewers: aaron.ballman, mclow.lists, rsmith
Reviewed By: aaron.ballman
Subscribers: mclow.lists, aaron.ballman, andrew, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D41080
llvm-svn: 320755
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are many more expr types that can be a capability expr, like
CXXThisExpr, CallExpr, MemberExpr. Instead of enumerating all of them,
just check typeHasCapability for any type given.
Also add & and * operators to allowed unary operators.
Differential Revision: https://reviews.llvm.org/D41224
llvm-svn: 320753
|
|
|
|
|
|
|
|
|
|
| |
update the type from the definition even if we didn't instantiate a definition.
We may have instantiated the definition in an earlier stage of semantic
analysis, after creating the DeclRefExpr but before we reach a point where a
complete expression type is required.
llvm-svn: 320709
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.
All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.
llvm-svn: 320707
|