This matches the implementation of the gcc support for the same
feature, including checking the values set up by libgcc at runtime.
The structure looks like this:
unsigned int __cpu_vendor;
unsigned int __cpu_type;
unsigned int __cpu_subtype;
unsigned int __cpu_features[1];
with a set of enums to match various fields that are field out after
parsing the output of the cpuid instruction.
This also adds a set of errors checking for valid input (and cpu).
compiler-rt support for this and the other builtins in this family
(__builtin_cpu_init and __builtin_cpu_is) are forthcoming.
llvm-svn: 240994
If a function containing a local class is instantiated, instantiate
all of local class member, including default arguments and exception
specifications.
This change fixes PR21332 and thus implements DR1484.
Differential Revision: http://reviews.llvm.org/D9990
llvm-svn: 240974
Get rid of code-path that (according to Richard Smith) is not needed but
leads to a crasher bug when assuming a template has been fully
instantiated and thus has a definition.
llvm-svn: 240752
This patch fixes a crash caused by the following case:
template<typename T>
auto f(T x) {
auto g = [](auto ... args) {
auto h = [args...]() -> int {
return 0;
};
return h;
};
return g;
}
auto x = f(0)();
When the templated function 'f' is instantiated and the inner-most
lambda is transformed the ellipsis location on the captured variable
is lost. Then the lambda returned by 'f' is instantiated and the
tree transformer chokes on the invalid ellipsis location. The
problem is fixed by making a minor change to properly track the
ellipsis location.
This fixes PR23716.
Differential Revision: http://reviews.llvm.org/D10590
llvm-svn: 240740
In certain cases, the tree transform would introduce new TypoExprs while
trying one of the corrections, invalidating the unique_ptr in the state
reference, and also causing a TypoExpr to exist that will never be
corrected since it doesn't exist in the final corrected expression. The
simple solution to both problems is to temporarily disable typo
correction while handling potentially ambiguous typo corrections.
llvm-svn: 240734
This patch implements the functionality specified by DR948.
The changes are two fold. First, the parser was modified
to allow 'constexpr's to appear in condition declarations
(which was a hard error before). Second, Sema was modified
to cleanup maybe odr-used declarations by way of a call to
'ActOnFinishFullExpr'. As 'constexpr's were not allowed in
condition declarations before the cleanup wasn't necessary
(such declarations were always odr-used).
This fixes PR22491.
Differential Revision: http://reviews.llvm.org/D8978
llvm-svn: 240707
Summary:
This patch reduces duplication in the template argument deduction code
for handling deduction from initializer lists in a function call. This
extends the fix for PR12119 to also apply to the case where the
corresponding parameter is a trailing parameter pack.
Test Plan:
A test for deduction from nested initializer lists where the
corresponding parameter is a trailing parameter pack is added in
`clang/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp`.
Reviewers: fraggamuffin, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10681
llvm-svn: 240612
Addresses a conflict with glibc's __nonnull macro by renaming the type
nullability qualifiers as follows:
__nonnull -> _Nonnull
__nullable -> _Nullable
__null_unspecified -> _Null_unspecified
This is the major part of rdar://problem/21530726, but does not yet
provide the Darwin-specific behavior for the old names.
llvm-svn: 240596
Regular function calls (such as to cabs()) run into the same problem
with handling dependent exprs, not just builtins with custom type
checking.
Fixes PR23775.
llvm-svn: 240443
Parsing and sema analysis (without support for array sections in arguments) for 'depend' clause (used in 'task' directive, OpenMP 4.0).
llvm-svn: 240409
Currently if the variable is captured in captured region, capture record for this region stores reference to this variable for future use. But we don't need to provide the reference to the original variable if it was explicitly marked as private in the 'private' clause of the OpenMP construct, this variable is replaced by private copy.
Differential Revision: http://reviews.llvm.org/D9550
llvm-svn: 240377
Such conflicts are an accident waiting to happen, and this feature conflicts
with the desire to include existing headers into multiple modules and merge the
results. (In an ideal world, it should not be possible to export internal
linkage symbols from a module, but sadly the glibc and libstdc++ headers
provide 'static inline' functions in a few cases.)
llvm-svn: 240335
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
The same pattern was repeated a few times. Create a trivial helper method to
map the Type Specifier to an ID for the diagnostic. Flip the selection order on
one of the diagnostic messages to get the same ordering across all of the
messages. This makes the emission of the diagnostic slightly more legible by
changing the cascading ternary into a switch in a function. NFC.
llvm-svn: 240251
That is,
void cf2(CFTypeRef * __nullable p CF_RETURNS_NOT_RETAINED);
is equivalent to
void cf2(CFTypeRef __nullable * __nullable p CF_RETURNS_NOT_RETAINED);
More rdar://problem/18742441
llvm-svn: 240186
Includes a simple static analyzer check and not much else, but we'll also
be able to take advantage of this in Swift.
This feature can be tested for using __has_feature(cf_returns_on_parameters).
This commit also contains two fixes:
- Look through non-typedef sugar when deciding whether something is a CF type.
- When (cf|ns)_returns(_not)?_retained is applied to invalid properties,
refer to "property" instead of "method" in the error message.
rdar://problem/18742441
llvm-svn: 240185
Adds a new warning (under -Wnullability-completeness) that complains
about pointer, block pointer, or member pointer declarations that have
not been annotated with nullability information (directly or inferred)
within a header that contains some nullability annotations. This is
intended to be used to help maintain the completeness of nullability
information within a header that has already been audited.
Note that, for performance reasons, this warning will underrepresent
the number of non-annotated pointers in the case where more than one
pointer is seen before the first nullability type specifier, because
we're only tracking one piece of information per header. Part of
rdar://problem/18868820.
llvm-svn: 240158
Introduce the clang pragmas "assume_nonnull begin" and "assume_nonnull
end" in which we make default assumptions about the nullability of many
unannotated pointers:
- Single-level pointers are inferred to __nonnull
- NSError** in a (function or method) parameter list is inferred to
NSError * __nullable * __nullable.
- CFErrorRef * in a (function or method) parameter list is inferred
to CFErrorRef __nullable * __nullable.
- Other multi-level pointers are never inferred to anything.
Implements rdar://problem/19191042.
llvm-svn: 240156
'null_resettable' properties are those whose getters return nonnull
but whose setters take nil, to "reset" the property to some
default. Implements rdar://problem/19051334.
llvm-svn: 240155
Introduce context-sensitive, non-underscored nullability specifiers
(nonnull, nullable, null_unspecified) for Objective-C method return
types, method parameter types, and properties.
Introduce Objective-C-specific semantics, including computation of the
nullability of the result of a message send, merging of nullability
information from the @interface of a class into its @implementation,
etc .
This is the Objective-C part of rdar://problem/18868820.
llvm-svn: 240154
This generalizes the checking of null arguments to also work with
values of pointer-to-function, reference-to-function, and block
pointer type, using the nullability information within the underling
function prototype to extend non-null checking, and diagnoses returns
of 'nil' within a function with a __nonnull return type.
Note that we don't warn about nil returns from Objective-C methods,
because it's common for Objective-C methods to mimic the nil-swallowing
behavior of the receiver by checking ostensibly non-null parameters
and returning nil from otherwise non-null methods in that
case.
It also diagnoses (via a separate flag) conversions from nullable to
nonnull pointers. It's a separate flag because this warning can be noisy.
llvm-svn: 240153
Introduces the type specifiers __nonnull, __nullable, and
__null_unspecified that describe the nullability of the pointer type
to which the specifier appertains. Nullability type specifiers improve
on the existing nonnull attributes in a few ways:
- They apply to types, so one can represent a pointer to a non-null
pointer, use them in function pointer types, etc.
- As type specifiers, they are syntactically more lightweight than
__attribute__s or [[attribute]]s.
- They can express both the notion of 'should never be null' and
also 'it makes sense for this to be null', and therefore can more
easily catch errors of omission where one forgot to annotate the
nullability of a particular pointer (this will come in a subsequent
patch).
Nullability type specifiers are maintained as type sugar, and
therefore have no effect on mangling, encoding, overloading,
etc. Nonetheless, they will be used for warnings about, e.g., passing
'null' to a method that does not accept it.
This is the C/C++ part of rdar://problem/18868820.
llvm-svn: 240146
Base type of attribute((mode)) can actually be a vector type.
The patch is to distinguish between base type and base element type.
This fixes http://llvm.org/PR17453.
Differential Revision: http://reviews.llvm.org/D10058
llvm-svn: 240125
Added parsing, sema analysis and codegen for '#pragma omp taskgroup' directive (OpenMP 4.0).
The code for directive is generated the following way:
#pragma omp taskgroup
<body>
void __kmpc_taskgroup(<loc>, thread_id);
<body>
void __kmpc_end_taskgroup(<loc>, thread_id);
llvm-svn: 240011
Added codegen for combined 'omp for simd' directives, that is a combination of 'omp for' directive followed by 'omp simd' directive. Includes support for all clauses.
llvm-svn: 239990
Previously we'd complain about redefinition of default arguments when we
instantiated a class with a friend template that inherits its default argument,
because we propagate the default template arguemnt onto the friend when we
reload the AST.
llvm-svn: 239857
Previously the last iteration for simd loop-based OpenMP constructs were generated as a separate code. This feature is not required and codegen is simplified.
llvm-svn: 239810
in section 10.1, __arm_{w,r}sr{,p,64}.
This includes arm_acle.h definitions with builtins and codegen to support
these, the intrinsics are implemented by generating read/write_register calls
which get appropriately lowered in the backend based on the register string
provided. SemaChecking is also implemented to fault invalid parameters.
Differential Revision: http://reviews.llvm.org/D9697
llvm-svn: 239737
The underlying problem in PR23823 already existed before my recent change
in r239558, but that change made it worse (failing not only for undeclared
symbols, but also failed overload resolution). This makes Clang not try to
delay the lookup in SFINAE context. I assume no current code is relying on
SFINAE working with lookups that need to be delayed, because that never
seems to have worked.
Differential Revision: http://reviews.llvm.org/D10417
llvm-svn: 239639
We would get this right in the case where an explicit cast was formed
but not when we were performing an implicit conversion.
This fixes PR23828.
llvm-svn: 239625
Since we're ignoring the tune= and fpmath= attributes go ahead
and add a warning alerting people to the fact that we're going
to ignore that part of it during code generation and tie it to
the attribute warning set.
llvm-svn: 239583
Modeled after the gcc attribute of the same name, this feature
allows source level annotations to correspond to backend code
generation. In llvm particular parlance, this allows the adding
of subtarget features and changing the cpu for a particular function
based on source level hints.
This has been added into the existing support for function level
attributes without particular verification for any target outside
of whether or not the backend will support the features/cpu given
(similar to section, etc).
llvm-svn: 239579
Specifying #pragma clang loop vectorize(assume_safety) on a loop adds the
mem.parallel_loop_access metadata to each load/store operation in the loop. This
metadata tells loop access analysis (LAA) to skip memory dependency checking.
llvm-svn: 239572
This patch does two things in order to enable compilation of the problematic code in PR23810:
1. In Sema::buildOverloadedCallSet, it postpones lookup for MS mode when no
viable candidate is found in the overload set. Previously, lookup would only
be postponed here if the overload set was empty.
2. Make BuildRecoveryCallExpr call Sema::DiagnoseEmptyLookup under more circumstances.
There is a comment in DiagnoseTwoPhaseLookup that says "Don't diagnose names we find in
classes; we get much better diagnostics for these from DiagnoseEmptyLookup." The problem
was that DiagnoseEmptyLookup might not get called later, and we failed to recover.
Differential Revision: http://reviews.llvm.org/D10369
llvm-svn: 239558
If definition of a class is unknown and out-of-line definition of its
member is encountered, do not parse the member declaration.
This change fixes PR18542.
Differential Revision: http://reviews.llvm.org/D8010
llvm-svn: 239483
it doesn't work correctly when a structure is declared before pragma
and then a function with the same name declared after pragma.
Patch by Andrey Bokhanko
Differential Revision: http://reviews.llvm.org/D10187
llvm-svn: 239466
Based on previous discussion on the mailing list, clang currently lacks support
for C99 partial re-initialization behavior:
Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html
Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm
This patch attempts to fix this problem.
Given the following code snippet,
struct P1 { char x[6]; };
struct LP1 { struct P1 p1; };
struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' };
// this example is adapted from the example for "struct fred x[]" in DR-253;
// currently clang produces in l: { "\0\0x" },
// whereas gcc 4.8 produces { "fox" };
// with this fix, clang will also produce: { "fox" };
Differential Review: http://reviews.llvm.org/D5789
llvm-svn: 239446
The machinery added to permit a static_cast from void-ptr to fn-ptr
unintentionally gets triggered for c-style casts and function-style
casts. The observable effect was a diagnostic issued inappropriately.
llvm-svn: 239382
This is a follow-up to r225570 which enabled adding DLL attributes when a
class template goes from explicit instantiation declaration to explicit
instantiation definition.
llvm-svn: 239375
It is safe to add a dll attribute if the base class template previously only had
an explicit instantiation declaration, or was implicitly instantiated.
I both those cases, the members would not have been codegenned yet. In the case
of explicit instantiation declaration this is natural, and for implicit
instantiations, codegen is deferred (see r225570).
This is work towards fixing PR23770.
llvm-svn: 239373
Don't warn about not being able to propagate dll attribute to a base class template
when that base already has a different attribute.
MSVC doesn't actually try to do this; the first attribute that was propagated
takes precedence, so Clang is already doing the right thing and there's no
need to warn.
(This is a step towards fixing PR21718.)
llvm-svn: 239372
There are still problems here, but this is a better starting point.
The main part of the change is: when doing a lookup that would accept visible
or hidden declarations, prefer to produce the latest visible declaration if
there are any visible declarations, rather than always producing the latest
declaration.
Thus, when we inherit default arguments (and other properties) from a previous
declaration, we inherit them from the previous visible declaration; if the
previous declaration is hidden, we already suppress inheritance of default
arguments.
There are a couple of other changes here that fix latent bugs exposed by this
change.
llvm-svn: 239371
Summary:
This modifies Clang to reflect that under pre-C99 ISO C, decimal
constants may have type `unsigned long` even if they do not contain `u`
or `U` in their suffix (C90 subclause 6.1.3.2 paragraph 5). The same is
done for C++ without C++11 which--because of undefined behaviour--allows
for behaviour compatible with ISO C90 in the case of an unsuffixed
decimal literal and is otherwise identical to C90 in its treatment of
integer literals (C++03 subclause 2.13.1 [lex.icon] paragraph 2).
Messages are added to the `c99-compat` and `c++11-compat` groups to warn
on such literals, since they behave differently under the newer
standards.
Fixes PR 16678.
Test Plan:
A new test file is added to exercise both pre-C99/C++11 and C99/C++11-up
on decimal literals with no suffix or suffixes `l`/`L` for both 32-bit
and 64-bit `long`.
In the file, 2^31 (being `INT_MAX+1`) is tested for the expected type
using `__typeof__` and multiple declarations of the same entity. 2^63
is similarly tested when it is within the range of `unsigned long`.
Preprocessor arithmetic tests are added to ensure consistency given
that Clang (like GCC) uses greater than 32 bits for preprocessor
arithmetic even when `long` and `unsigned long` is 32 bits and a
pre-C99/C++11 mode is in effect.
Tests added:
test/Sema/PR16678.c
Reviewers: fraggamuffin, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9794
llvm-svn: 239356
input / output with memory constraint.
One generally can't get address of a bit field, so the general solution is to
error on such cases. GCC does the same.
Patch by Andrey Bokhanko
Differential Revision: http://reviews.llvm.org/D10086
llvm-svn: 239153
Summary:
This patch is part of http://llvm-reviews.chandlerc.com/D2181.
In-class initializers are appended to the CFG when CFGBuilder::addInitializer is called.
Reviewers: jordan_rose, rsmith
Reviewed By: jordan_rose
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D2370
llvm-svn: 238913
The parameter types and return type do not need to be volatile just
because the pointer type's pointee type is volatile qualified. This is
an unnecessary pessimization.
llvm-svn: 238892
The MSVC 2013 and 2015 implementation of std::atomic is specialized for
pointer types. The member functions are implemented using a static_cast
from void-ptr to function-ptr which is not allowed in the standard.
Permit this conversion if -fms-compatibility is present.
This fixes PR23733.
llvm-svn: 238877
We catch most of the various other __fp16 implicit conversions to
float, but not this one:
__fp16 a;
int i;
...
a += i;
For which we used to generate something 'fun' like:
%conv = sitofp i32 %i to float
%1 = tail call i16 @llvm.convert.to.fp16.f32(float %conv)
%add = add i16 %0, %1
Instead, when we have an __fp16 LHS and an integer RHS, we should
use float as the result type.
While there, add a bunch of missing tests for mixed
__fp16/integer expressions.
llvm-svn: 238625
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
llvm-svn: 238601
this fixes http://llvm.org/PR17424
fillAttributedTypeLoc() function is only called with AttributeLists of either
DeclarationChunk (which is used for each type in a declarator being parsed) or
DeclSpec (which captures information about declaration specifiers).
As C++11 attributes actually appertain to declarators, they are moved straight
to the declarator’s attr list in distributeFunctionTypeAttrFromDeclSpec()
function.
'Put them wherever you like' semantics is not supported for C++11 attributes
(but is allowed for GNU attributes, for example). So when we meet an attribute
while parsing the declaration, we cannot be sure if it appertains to either
DeclarationChunk or DeclSpec.
This investigation correlates with the history of changes of SemaType.cpp:
• Asserts in fillAttributedTypeLoc() were added on 3 Mar 2011 in r126986
(http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-
20110228/039638.html);
• Distributing C++11 attrs to the declarator was added on 14 Jan 2013
in r172504 (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-
20130114/071830.html).
Considering all written above I changed asserts in fillAttributedTypeLoc()
to nullptr checks.
This fixes PR17424 and related assertion on
[[gnu::fastcall]] void __stdcall foo();
Author: Alexey Frolov
Differential Revision: http://reviews.llvm.org/D9288
llvm-svn: 238550
Previously, we wouldn't call checkDLLAttribute() after the class template
specialization definition if the class template was already instantiated
by an explicit class template specialization declaration.
llvm-svn: 238266
An AtomicType might be hidden behind arbitrary levels of typedefs.
getAs<> will reliably walk through the sugar to get the underlying
AtomicType.
This fixes PR23638.
llvm-svn: 238083
The method wasn't an overrider but didn't have 'virtual' textually
written because our CXXMethodDecl was an out-of-line definition. Make
sure we use the canonical decl instead.
This fixes PR23629.
llvm-svn: 237999
Add a check for bool-like conversions for the condition expression of
conditional operators. This is similiar to the checking of condition
expressions of if statements, for-loops, while-loops, and do-while loops.
Specificially, this is to fix the problem of assert("message") not triggering
-Wstring-conversion when the assert macro uses a conditional operator.
llvm-svn: 237856
Patch fixes codegen for aggregate copying of VLAs. Currently method CodeGenFunction::EmitAggregateCopy() does not support copying of VLAs. Patch checks if the size of the type is 0, then checks if the type is actually a variable-length array. Then it calculates total length for this array and calculates total size of the array in bytes:
<total number of elements in array> * aligned_sizeof(ElementType) (if copy assignment is requested).
If simple copying is requested, size is calculated like:
<total number of elements in array> * aligned_sizeof(ElementType) - aligned_sizeof(ElementType) + sizeof(ElementType).
memcpy() is used with this calculated size of the VLA.
Differential Revision: http://reviews.llvm.org/D9851
llvm-svn: 237768
Eric Christopher