This commit fixes a bug in the handling of storage-only __fp16 vectors
where clang didn't promote __fp16 vector operands to float vectors.
Conceptually, it performs the following transformation on the AST in
CreateBuiltinBinOp and CreateBuiltinUnaryOp:
(Before)
typedef __fp16 half4 __attribute__ ((vector_size (8)));
typedef float float4 __attribute__ ((vector_size (16)));
half4 hv0, hv1, hv2, hv3;
hv0 = hv1 + hv2 + hv3;
(After)
float4 t0 = (float4)hv1 + (float4)hv2;
float4 t1 = t0 + (float4)hv3;
hv0 = (half4)t1;
Note that this commit fixes the bug for targets that set
HalfArgsAndReturns to true (ARM and ARM64). Targets using intrinsics
such as llvm.convert.to.fp16 to handle __fp16 are still broken.
rdar://problem/20625184
Differential Revision: https://reviews.llvm.org/D32520
llvm-svn: 314056
If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it is not possible to define the entity elsewhere, so any such use is
necessarily an error.
There is an exception, though: some types formally have no linkage but
nonetheless can be referenced from other translation units (for example, this
happens to anonymous structures defined within inline functions). For entities
with those types, we suppress the diagnostic except under -pedantic.
llvm-svn: 313729
Summary:
According to C99 6.3.2.1p1, structs and unions with nested
const-qualified fields (that is, const-qualified fields
declared at some recursive level of the aggregate) are not
modifiable lvalues. However, Clang permits assignments of
these lvalues.
With this patch, we both prohibit the assignment of records
with const-qualified fields and emit a best-effort diagnostic.
This fixes https://bugs.llvm.org/show_bug.cgi?id=31796 .
Committing on behalf of bevinh (Bevin Hansson).
Reviewers: rtrieu, rsmith, bjope
Reviewed By: bjope
Subscribers: Ka-Ka, rogfer01, bjope, fhahn, cfe-commits
Differential Revision: https://reviews.llvm.org/D37254
llvm-svn: 313628
https://bugs.llvm.org/show_bug.cgi?id=34266
For e.g.
struct A {
void f(int);
static void f(char);
};
struct B {
auto foo() {
return [&] (auto a) {
A::f(a); // this should not cause a capture of '*this'
};
}
};
The patch does the following:
1) It moves the check to attempt an implicit capture of '*this' by reference into the more logical location of when the call is actually built within ActOnCallExpr (as opposed to when the unresolved-member-lookup node is created).
- Reminder: A capture of '*this' by value has to always be an explicit capture.
2) It additionally checks whether the naming class of the UnresolvedMemberExpr ('A' in the example above) is related to the enclosing class ('B' above).
P.S. If you have access to ISO-C++'s CWG reflector, see this thread for some potentially related discussion: http://lists.isocpp.org/core/2017/08/2851.php
llvm-svn: 313487
Specifically, typo correction should be done before dispatching between
different kinds of binary operations like pseudo-object assignment,
overloaded binary operation, etc.
Without this change we hit an assertion
Assertion failed: (!LHSExpr->hasPlaceholderType(BuiltinType::PseudoObject)), function CheckAssignmentOperands
when in Objective-C we reference a property without `self` and there are
2 equally good typo correction candidates: ivar and a class name. In
this case LHS expression in `BuildBinOp` is
CXXDependentScopeMemberExpr
`-TypoExpr
and instead of handling Obj-C property assignment as pseudo-object
assignment, we call `CreateBuiltinBinOp` which corrects typo to
ObjCPropertyRefExpr '<pseudo-object type>'
but cannot handle pseudo-objects and asserts about it (indirectly,
through `CheckAssignmentOperands`).
rdar://problem/33102722
Reviewers: rsmith, ahatanak, majnemer
Reviewed By: ahatanak
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37322
llvm-svn: 313323
Treat typedef enum as named enums instead of anonymous enums. Anonymous enums
are ignored by the warning, so previously, typedef enums were ignored as well.
llvm-svn: 312842
This is a recommit of r312781; in some build configurations
variable names are omitted, so changed the new regression
test accordingly.
llvm-svn: 312794
This adds _Float16 as a source language type, which is a 16-bit floating point
type defined in C11 extension ISO/IEC TS 18661-3.
In follow up patches documentation and more tests will be added.
Differential Revision: https://reviews.llvm.org/D33719
llvm-svn: 312781
Block captures can have different physical locations
in memory segments depending on the use case (as a function
call or as a kernel enqueue) and in different vendor
implementations.
Therefore it's unclear how to add address space to capture
addresses uniformly. Currently it has been decided to disallow
taking addresses of captured variables until further
clarifications in the spec.
Differential Revision: https://reviews.llvm.org/D36410
llvm-svn: 312728
of class fails to map class static variable.
If the global variable is captured and it has several redeclarations,
sometimes it may lead to a compiler crash. Patch fixes this by working
only with canonical declarations.
llvm-svn: 311479
C++14 added user-defined literal support for complex numbers so that you
can write something like "complex<double> val = 2i". However, there is
an existing GNU extension supporting this syntax and interpreting the
result as a _Complex type.
This changes parsing so that such literals are interpreted in terms of
C++14's operators if an overload is present but otherwise falls back to
the original GNU extension.
(We now have more robust diagnostics for implicit conversions so the
libc++ test that caused the original revert still passes).
llvm-svn: 310478
Converting a _Complex type to a real one simply discards the imaginary part.
This can easily lead to loss of information so for safety (and GCC
compatibility) this patch disallows that when the conversion would be implicit.
The one exception is bool, which actually compares both real and imaginary
parts and so is safe.
llvm-svn: 310427
Arguments, passed to the outlined function, must have correct address
space info for proper Debug info support. Patch sets global address
space for arguments that are mapped and passed by reference.
Also, cuda-gdb does not handle reference types correctly, so reference
arguments are represented as pointers.
llvm-svn: 310387
Arguments, passed to the outlined function, must have correct address
space info for proper Debug info support. Patch sets global address
space for arguments that are mapped and passed by reference.
Also, cuda-gdb does not handle reference types correctly, so reference
arguments are represented as pointers.
llvm-svn: 310377
Arguments, passed to the outlined function, must have correct address
space info for proper Debug info support. Patch sets global address
space for arguments that are mapped and passed by reference.
Also, cuda-gdb does not handle reference types correctly, so reference
arguments are represented as pointers.
llvm-svn: 310360
Arguments, passed to the outlined function, must have correct address
space info for proper Debug info support. Patch sets global address
space for arguments that are mapped and passed by reference.
Also, cuda-gdb does not handle reference types correctly, so reference
arguments are represented as pointers.
llvm-svn: 310104
Summary:
The mis-compile is triggered by internal code, but I haven't reduced it to a small piece of code. Add a FIXME here, since a decent fix doesn't seem to be trivial.
The decent fix can be changing Decl::Init to PointerUnion<Stmt *, EvaluatedStmt *, ParamVarDecl *>, and make setUninstantiatedDefaultArg take a ParamVarDecl *, which contains the Expr * as the default argument. This way, getTemplateInstantiationArgs can take that ParamVarDecl and do the right thing.
Reviewers: rsmith
Subscribers: sanjoy, cfe-commits
Differential Revision: https://reviews.llvm.org/D36253
llvm-svn: 309908
r282968 introduced a regression due to the lack of proper testing.
Re-add lax conversion support between non ext vectors for compound
assignments and add a test for that.
rdar://problem/28639467
llvm-svn: 309722
devirtualized.
The code to detect devirtualized calls is already in IRGen, so move the
code to lib/AST and make it a shared utility between Sema and IRGen.
This commit fixes a linkage error I was seeing when compiling the
following code:
$ cat test1.cpp
struct Base {
virtual void operator()() {}
};
template<class T>
struct Derived final : Base {
void operator()() override {}
};
Derived<int> *d;
int main() {
if (d)
(*d)();
return 0;
}
rdar://problem/33195657
Differential Revision: https://reviews.llvm.org/D34301
llvm-svn: 307883
requirements in protocol/class/category declarations
The unguarded availability warnings in the protocol requirements of a protocol
/class/category declaration can be avoided. This matches the behaviour of
Swift's diagnostics. The warnings for deprecated/unavailable protocols are
preserved.
rdar://33156429
Differential Revision: https://reviews.llvm.org/D35061
llvm-svn: 307368
Bitwise complement applied to vector of floats described with
attribute `ext_vector_type` is not diagnosed as error. Attempt to
compile such construct causes assertion violation in Instruction.cpp.
With this change the complement is treated similar to the case of
vector type described with attribute `vector_size`.
Differential Revision: https://reviews.llvm.org/D33732
llvm-svn: 304963
template is valid with or without it (with different meanings).
If we see "dependent.x<...", and what follows the '<' is a valid expression,
we must parse the '<' as a comparison rather than a template angle bracket.
When we later come to instantiate, if we find that the LHS of the '<' actually
names an overload set containing function templates, produce a diagnostic
suggesting that the 'template' keyword was missed rather than producing a
mysterious diagnostic saying that the function must be called (and pointing
at what looks to already be a function call!).
llvm-svn: 304852
Summary:
This is the fix for patch https://reviews.llvm.org/D33353
@uweigand, could you please verify that everything will be good on SystemZ?
I added triple spir-unknown-unknown.
Thank you in advance!
Reviewers: uweigand
Reviewed By: uweigand
Subscribers: yaxunl, cfe-commits, bader, Anastasia, uweigand
Differential Revision: https://reviews.llvm.org/D33648
llvm-svn: 304191
This is an initial commit to allow using it with constant expressions, a follow-up commit will enable full support for it in ObjC methods.
llvm-svn: 303712
C++14 added user-defined literal support for complex numbers so that you can
write something like "complex<double> val = 2i". However, there is an existing
GNU extension supporting this syntax and interpreting the result as a _Complex
type.
This changes parsing so that such literals are interpreted in terms of C++14's
operators if an overload is present but otherwise falls back to the original
GNU extension.
llvm-svn: 303694
This fix UBSAN bots after r302935. Storing non-defined values in enum is
undefined behavior.
Other places, where "if (ScalarCast != CK_Invalid)" is used, never get to the
"if" with CK_Invalid. tryGCCVectorConvertAndSplat can get to the "if" with
CK_Invalid and it looks like expected case. So we have to use something other
than CK_Invalid, e.g. CK_NoOp.
llvm-svn: 303121
This patch teaches clang to perform implicit scalar to vector conversions
when one of the operands of a binary vector expression is a scalar which
can be converted to the element type of the vector without truncation
following GCC's implementation.
If the (constant) scalar is can be casted safely, it is implicitly casted to the
vector elements type and splatted to produce a vector of the same type.
Contributions from: Petar Jovanovic
Reviewers: bruno, vkalintiris
Differential Revision: https://reviews.llvm.org/D25866
llvm-svn: 302935
In C typos in arguments in a call of an overloadable function lead
to a failure of construction of CallExpr and following recovery does
not handle created delayed typos. This causes an assertion fail in
Sema::~Sema since Sema::DelayedTypos remains not empty.
The patch fixes that behavior by handling a call with arguments
having dependant types in the way that C++ does.
Differential Revision: https://reviews.llvm.org/D31764
Patch by Dmitry Borisenkov!
llvm-svn: 302435
Summary:
When the function is compiled with soft-float or on CPU with no FPU, we
don't need to diagnose for a call from an ISR to a regular function.
Reviewers: jroelofs, eli.friedman
Reviewed By: jroelofs
Subscribers: aemerson, rengolin, javed.absar, cfe-commits
Differential Revision: https://reviews.llvm.org/D32918
llvm-svn: 302274
blocks and lambdas
Prior to this commit Clang emitted the old "partial availability" warning for
expressions that referred to declarations that were not yet introduced in
blocks and lambdas that were not in a function/method. This commit ensures that
top-level blocks and lambdas use the new unguarded availability checks.
rdar://31835952
llvm-svn: 301409
This commit teaches Clang to recognize editor placeholders that are produced
when an IDE like Xcode inserts a code-completion result that includes a
placeholder. Now when the lexer sees a placeholder token, it emits an
'editor placeholder in source file' error and creates an identifier token
that represents the placeholder. The parser/sema can now recognize the
placeholders and can suppress the diagnostics related to the placeholders. This
ensures that live issues in an IDE like Xcode won't get spurious diagnostics
related to placeholders.
This commit also adds a new compiler option named '-fallow-editor-placeholders'
that silences the 'editor placeholder in source file' error. This is useful
for an IDE like Xcode as we don't want to display those errors in live issues.
rdar://31581400
Differential Revision: https://reviews.llvm.org/D32081
llvm-svn: 300667
This improves some error messages which would otherwise refer to
ext_vector_type types in contexts where there are no such types.
Factored out from D25866 at reviewer's request.
Reviewers: bruno
Differential Revision: https://reviews.llvm.org/D31667
llvm-svn: 299641
Summary:
I saw the same changes in the following review: https://reviews.llvm.org/D17438
I don't know in that way I could determine that atomic variable was initialized by macro ATOMIC_VAR_INIT. Anyway I added check that atomic variables can be initialize only in global scope.
I think that we can discuss this change.
Reviewers: Anastasia, cfe-commits
Reviewed By: Anastasia
Subscribers: bader, yaxunl
Differential Revision: https://reviews.llvm.org/D30643
llvm-svn: 299537
- also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17.
- update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed.
llvm-svn: 299316
an ObjC object pointer
When ARC is enabled in Objective-C++, comparisons between a pointer and
Objective-C object pointer typically result in errors like this:
"invalid operands to a binary expression". This error message can be quite
confusing as it doesn't provide a solution to the problem, unlike the non-C++
diagnostic: "implicit conversion of Objective-C pointer type 'id' to C pointer
type 'void *' requires a bridged cast" (it also provides fix-its). This commit
forces comparisons between pointers and Objective-C object pointers in ARC to
use the Objective-C semantic rules to ensure that a better diagnostic is
reported.
rdar://31103857
Differential Revision: https://reviews.llvm.org/D31177
llvm-svn: 299080
Summary: clang should produce the same errors Objective-C classes that cannot be assigned to weak pointers under both -fobjc-arc and -fobjc-weak. Check for ObjCWeak along with ObjCAutoRefCount when analyzing pointer conversions. Add an -fobjc-weak pass to the existing arc-unavailable-for-weakref test cases to verify the behavior is the same.
Reviewers: rsmith, doug.gregor, rjmccall
Reviewed By: rjmccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31006
llvm-svn: 299014
Summary: -Warc-repeated-use-of-weak should produce the same warnings with -fobjc-weak as it does with -objc-arc. Also check for ObjCWeak along with ObjCAutoRefCount when recording the use of an evaluated weak variable. Add a -fobjc-weak run to the existing arc-repeated-weak test case and adapt it slightly to work in both modes.
Reviewers: rsmith, doug.gregor, jordan_rose, rjmccall
Reviewed By: rjmccall
Subscribers: arphaman, rjmccall, cfe-commits
Differential Revision: https://reviews.llvm.org/D31005
llvm-svn: 299011
Sema holds the current FPOptions which is adjusted by 'pragma STDC
FP_CONTRACT'. This then gets propagated into expression nodes as they are
built.
This encapsulates FPOptions so that this propagation happens opaquely rather
than directly with the fp_contractable on/off bit. This allows controlled
transitioning of fp_contractable to a ternary value (off, on, fast). It will
also allow adding more fast-math flags later.
This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.
Differential Revision: https://reviews.llvm.org/D31166
llvm-svn: 298877
1. Reimplemented conditional operator so that it checks
compatibility of unqualified pointees of the 2nd and
the 3rd operands (C99, OpenCL v2.0 6.5.15).
Define QualTypes compatibility for OpenCL as following:
- corresponding types are compatible (C99 6.7.3)
- CVR-qualifiers are equal (C99 6.7.3)
- address spaces are equal (implementation defined)
2. Added generic address space to Itanium mangling.
Review: D30037
Patch by Dmitry Borisenkov!
llvm-svn: 297468
potential capture list.
Fix Sema::getCurLambda() to return the innermost lambda scope when there
is a block enclosed in the lambda. Previously, the method would return a
nullptr in such cases, which would prevent a variable captured by the
enclosed block to be added to the lambda scope's potential capture list.
rdar://problem/28412462
Differential Revision: https://reviews.llvm.org/D25556
llvm-svn: 296584
instantiation.
In preparation for converting the template stack to a more general context
stack (so we can include context notes for other kinds of context).
llvm-svn: 295686
Fix for bug 30217 - incorrect error given for logical
NOT operation with a pointer type: corrected sema check
and improved related tests.
Review: D29038
llvm-svn: 294313
This patch changes how we handle argument-dependent `diagnose_if`
attributes. In particular, we now check them in the same place that we
check for things like passing NULL to Nonnull args, etc. This is
basically better in every way than how we were handling them before. :)
This fixes PR31638, PR31639, and PR31640.
Differential Revision: https://reviews.llvm.org/D28889
llvm-svn: 293360
Modify ObjC blocks impl wrt address spaces as follows:
- keep default private address space for blocks generated
as local variables (with captures);
- add global address space for global block literals (no captures);
- make the block invoke function and enqueue_kernel prototype with
the generic AS block pointer parameter to accommodate both
private and global AS cases from above;
- add block handling into default AS because it's implemented as
a special pointer type (BlockPointer) in the frontend and therefore
it is used as a pointer everywhere. This is also needed to accommodate
both private and global AS blocks for the two cases above.
- removes ObjC RT specific symbols (NSConcreteStackBlock and
NSConcreteGlobalBlock) in the OpenCL mode.
Review: https://reviews.llvm.org/D28814
llvm-svn: 293286
This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.
We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.
llvm-svn: 293207
even in the presence of nullability qualifiers.
This commit fixes bugs in r285031 where -Wblock-capture-autoreleasing
wouldn't issue warnings when the function parameters were annotated
with nullability qualifiers. Specifically, look through the sugar and
see if there is an AttributedType of kind attr_objc_ownership to
determine whether __autoreleasing was explicitly specified or implicitly
added by the compiler.
rdar://problem/30193488
llvm-svn: 293194
The idea for this originated from a really tricky bug: ISRs on ARM don't
automatically save off the VFP regs, so if say, memcpy gets interrupted and the
ISR itself calls memcpy, the regs are left clobbered when the ISR is done.
https://reviews.llvm.org/D28820
llvm-svn: 292375
Summary:
Warn when a lambda explicitly captures something that is not used in its body.
The warning is part of -Wunused and can be enabled with -Wunused-lambda-capture.
Reviewers: rsmith, arphaman, jbcoe, aaron.ballman
Subscribers: Quuxplusone, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D28467
llvm-svn: 291905
`diagnose_if` can be used to have clang emit either warnings or errors
for function calls that meet user-specified conditions. For example:
```
constexpr int foo(int a)
__attribute__((diagnose_if(a > 10, "configurations with a > 10 are "
"expensive.", "warning")));
int f1 = foo(9);
int f2 = foo(10); // warning: configuration with a > 10 are expensive.
int f3 = foo(f2);
```
It currently only emits diagnostics in cases where the condition is
guaranteed to always be true. So, the following code will emit no
warnings:
```
constexpr int bar(int a) {
foo(a);
return 0;
}
constexpr int i = bar(10);
```
We hope to support optionally emitting diagnostics for cases like that
(and emitting runtime checks) in the future.
Release notes will appear shortly. :)
Differential Revision: https://reviews.llvm.org/D27424
llvm-svn: 291418
Add a visitor for lambda expressions to RecordExprEvaluator in ExprConstant.cpp that creates an empty APValue of Struct type to represent the closure object. Additionally, add a LambdaExpr visitor to the TemporaryExprEvaluator that forwards constant evaluation of immediately-called-lambda-expressions to the one in RecordExprEvaluator through VisitConstructExpr.
This patch supports:
constexpr auto ID = [] (auto a) { return a; };
static_assert(ID(3.14) == 3.14);
static_assert([](auto a) { return a + 1; }(10) == 11);
Lambda captures are still not supported for constexpr lambdas.
llvm-svn: 291416
This implements something like the current direction of DR1581: we use a narrow
syntactic check to determine the set of places where a constant expression
could be evaluated, and only instantiate a constexpr function or variable if
it's referenced in one of those contexts, or is odr-used.
It's not yet clear whether this is the right set of syntactic locations; we
currently consider all contexts within templates that would result in odr-uses
after instantiation, and contexts within list-initialization (narrowing
conversions take another victim...), as requiring instantiation. We could in
principle restrict the former cases more (only const integral / reference
variable initializers, and contexts in which a constant expression is required,
perhaps). However, this is sufficient to allow us to accept libstdc++ code,
which relies on GCC's behavior (which appears to be somewhat similar to this
approach).
llvm-svn: 291318
dependent context and can't be used in a constant expression.
Per C++ [temp.inst]p2, "the instantiation of a static data member does not
occur unless the static data member is used in a way that requires the
definition to exist".
This doesn't /quite/ match that, as we still instantiate static data members
that are usable in constant expressions even if the use doesn't require a
definition. A followup patch will fix that for both variables and functions.
llvm-svn: 291295
Most code paths would already bail out in this case, but certain paths,
particularly overload resolution and typo correction, would not. Carrying on
with an invalid declaration could in some cases result in crashes due to
downstream code relying on declaration invariants that are not necessarily
met for invalid declarations, and in other cases just resulted in undesirable
follow-on diagnostics.
llvm-svn: 291030
This reverts commit r290171. It triggers a bunch of warnings, because
the new enumerator isn't handled in all switches. We want a warning-free
build.
Replied on the commit with more details.
llvm-svn: 290173
Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t.
Reviewers: Anastasia
Subscribers: cfe-commits, yaxunl, bader
Differential Revision: https://reviews.llvm.org/D27569
llvm-svn: 290171
Added a map to associate types and declarations with extensions.
Refactored existing diagnostic for disabled types associated with extensions and extended it to declarations for generic situation.
Fixed some bugs for types associated with extensions.
Allow users to use pragma to declare types and functions for supported extensions, e.g.
#pragma OPENCL EXTENSION the_new_extension_name : begin
// declare types and functions associated with the extension here
#pragma OPENCL EXTENSION the_new_extension_name : end
Differential Revision: https://reviews.llvm.org/D21698
llvm-svn: 289979
At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.
Differential Revision: https://reviews.llvm.org/D26671
llvm-svn: 289647
This change makes sure single-precision floating point types are used if the
cl_fp64 extension is not supported by the target.
Also removed the check to see whether the OpenCL version is >= 1.2, as this has
been incorporated into the extension setting code.
Differential Revision: https://reviews.llvm.org/D24235
llvm-svn: 289544
latter case, a temporary array object is materialized, and can be
lifetime-extended by binding a reference to the member access. Likewise, in an
array-to-pointer decay, an rvalue array is materialized before being converted
into a pointer.
This caused IR generation to stop treating file-scope array compound literals
as having static storage duration in some cases in C++; that has been rectified
by modeling such a compound literal as an lvalue. This also improves clang's
compatibility with GCC for those cases.
llvm-svn: 288654
Summary:
We don't need a side table in ASTContext to hold CXXDefaultArgExprs. The
important part of building the CXXDefaultArgExprs was to ODR use the
default argument expressions, not to make AST nodes. Refactor the code
to only check the default argument, and remove the side table in
ASTContext which wasn't being serialized.
Fixes PR31121
Reviewers: thakis, rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27007
llvm-svn: 287774
with __unknown_anytype return type.
When the following code is compiled, Sema infers that the type of
__unknown_anytype is double:
extern __unknown_anytype func();
double *d = (double*)&func();
This triggers an assert in CodeGenFunction::EmitCallExprLValue because
it doesn't expect to see a call to a function with a non-reference
scalar return type.
This commit prevents the assert by making VisitUnaryAddrOf error out if
the address-of operator is applied to a call to a function with
__unknown_anytype return type.
rdar://problem/20287610
Differential revision: https://reviews.llvm.org/D26808
llvm-svn: 287410
This change makes sure single-precision floating point types are used if the
cl_fp64 extension is not supported by the target.
Also removed the check to see whether the OpenCL version is >= 1.2, as this has
been incorporated into the extension setting code.
Differential Revision: https://reviews.llvm.org/D24235
llvm-svn: 286815
Clang emits error message for the following code:
```
template <class F> void parallel_loop(F &&f) { f(0); }
int main() {
int x;
parallel_loop([&](auto y) {
{
x = y;
};
});
}
```
$ clang++ --std=gnu++14 clang_test.cc -o clang_test
clang_test.cc:9:7: error: reference to local variable 'x' declared in enclosing function 'main'
x = y;
^
clang_test.cc:2:48: note: in instantiation of function template specialization 'main()::(anonymous class)::operator()<int>' requested here
template <class F> void parallel_loop(F &&f) { f(0); }
^
clang_test.cc:6:3: note: in instantiation of function template specialization 'parallel_loop<(lambda at clang_test.cc:6:17)>' requested here parallel_loop([&](auto y) {
^
clang_test.cc:5:7: note: 'x' declared here
int x;
^
1 error generated.
Patch fixes this issue.
llvm-svn: 286584
The assignment to NextIsDereference is either followed by (1) another,
unrelated assignment to NextIsDereference or by (2) an early loop exit.
Found by clang's static analyzer: http://llvm.org/reports/scan-build
(While we're at it fix a typo.)
llvm-svn: 285879
the body of a function for the purposes of computing its storage
duration and deciding whether its initializer must be constant.
There are a number of problems in our current treatment of compound
literals. C specifies that a compound literal yields an l-value
referring to an object with either static or automatic storage
duration, depending on where it was written; in the latter case,
the literal object has a lifetime tied to the enclosing scope (much
like an ObjC block), not the enclosing full-expression. To get these
semantics fully correct in our current design, we would need to
collect compound literals on the ExprWithCleanups, just like we do
with ObjC blocks; we would probably also want to identify literals
like we do with materialized temporaries. But it gets stranger;
GCC adds compound literals to C++ as an extension, but makes them
r-values, which are generally assumed to have temporary storage
duration. Ignoring destructor ordering, the difference only matters
if the object's address escapes the full-expression, which for an
r-value can only happen with reference binding (which extends
temporaries) or array-to-pointer decay (which does not). GCC then
attempts to lock down on array-to-pointer decay in ad hoc ways.
Arguably a far superior language solution for C++ (and perhaps even
array r-values in C, which can occur in other ways) would be to
propagate lifetime extension through array-to-pointer decay, so
that initializing a pointer object to a decayed r-value array
extends the lifetime of the complete object containing the array.
But this would be a major change in semantics which arguably ought
to be blessed by the committee(s).
Anyway, I'm not fixing any of that in this patch; I did try, but
it got out of hand.
Fixes rdar://28949016.
llvm-svn: 285643
This is a misspelling of the intended !(x & A) negated bit test that happens in
practice every now and then.
I ran this on Chromium and all its dependencies, and it fired 0 times -- no
false or true positives, but it would've caught a bug in an in-progress change
that had to be caught by a Visual Studio warning instead.
https://reviews.llvm.org/D26035
llvm-svn: 285310
The problem with the original commit was that some of Apple's headers depended
on an incorrect behaviour, this commit adds a temporary workaround until those
headers are fixed.
llvm-svn: 285098
by blocks.
Add a new warning "-Wblock-capture-autoreleasing". The warning warns
about implicitly autoreleasing out-parameters captured by blocks which
can introduce use-after-free bugs that are hard to debug.
rdar://problem/15377548
Differential Revision: https://reviews.llvm.org/D25844
llvm-svn: 285031
This has two significant effects:
1) Direct relational comparisons between null pointer constants (0 and nullopt)
and pointers are now ill-formed. This was always the case for C, and it
appears that C++ only ever permitted by accident. For instance, cases like
nullptr < &a
are now rejected.
2) Comparisons and conditional operators between differently-cv-qualified
pointer types now work, and produce a composite type that both source
pointer types can convert to (when possible). For instance, comparison
between 'int **' and 'const int **' is now valid, and uses an intermediate
type of 'const int *const *'.
Clang previously supported #2 as an extension.
We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.
This is a re-commit of r284800.
llvm-svn: 284890
This has two significant effects:
1) Direct relational comparisons between null pointer constants (0 and nullopt)
and pointers are now ill-formed. This was always the case for C, and it
appears that C++ only ever permitted by accident. For instance, cases like
nullptr < &a
are now rejected.
2) Comparisons and conditional operators between differently-cv-qualified
pointer types now work, and produce a composite type that both source
pointer types can convert to (when possible). For instance, comparison
between 'int **' and 'const int **' is now valid, and uses an intermediate
type of 'const int *const *'.
Clang previously supported #2 as an extension.
We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.
llvm-svn: 284800
Gcc prints error if elements of left and right parts of a shift have different
sizes. This patch is provided the GCC compatibility.
Patch by Vladimir Yakovlev.
Differential Revision: https://reviews.llvm.org/D24669
llvm-svn: 284579
not instantiate exception specifications of functions if they were only used in
unevaluated contexts (other than 'noexcept' expressions).
In C++17 onwards, this becomes essential since the exception specification is
now part of the function's type.
Note that this means that constructs like the following no longer work:
struct A {
static T f() noexcept(...);
decltype(f()) *p;
};
... because the decltype expression now needs the exception specification of
'f', which has not yet been parsed.
llvm-svn: 284549
This commit combines a couple of redundant functions that do availability
attribute context checking into a more correct/simpler one.
Differential revision: https://reviews.llvm.org/D25283
llvm-svn: 284265
Summary:
Move CheckCUDACall from ActOnCallExpr and BuildDeclRefExpr to
DiagnoseUseOfDecl. This lets us catch some edge cases we were missing,
specifically around class operators.
This necessitates a few other changes:
- Avoid emitting duplicate deferred diags in CheckCUDACall.
Previously we'd carefully placed our call to CheckCUDACall such that
it would only ever run once for a particular callsite. But now this
isn't the case.
- Emit deferred diagnostics from a template
specialization/instantiation's primary template, in addition to from
the specialization/instantiation itself. DiagnoseUseOfDecl ends up
putting the deferred diagnostics on the template, rather than the
specialization, so we need to check both.
Reviewers: rsmith
Subscribers: cfe-commits, tra
Differential Revision: https://reviews.llvm.org/D24573
llvm-svn: 283637
CheckSingleAssignmentConstraints. These no longer produce ExprError() when they
have not emitted an error, and reliably inform the caller when they *have*
emitted an error.
This fixes some serious issues where we would fail to emit any diagnostic for
invalid code and then attempt to emit code for an invalid AST, and conversely
some issues where we would emit two diagnostics for the same problem.
llvm-svn: 283508
Looks like the smart quote was copy/pasted from the C++ standard.
The smart quote was not encoded as valid UTF-8 (?), even though vim was
detecting the file as UTF-8. This broke the clang-format Python script,
which tried to read the file using the same encoding as vim detected.
llvm-svn: 283487
Treating large 0x*LL literals as signed instead of unsigned is not a
conforming language extension, so move it out of -fms-extensions.
Came up in PR30605
llvm-svn: 283227
Support lax convertions on compound assignment expressions like:
typedef __attribute__((vector_size(8))) double float64x1_t;
typedef __attribute__((vector_size(16))) double float64x2_t;
float64x1_t vget_low_f64(float64x2_t __p0);
double c = 3.0;
float64x2_t v = {0.0, 1.0};
c += vget_low_f64(v);
This restores one more valid behavior pre r266366, and is a incremental
follow up from work committed in r274646.
While here, make the check more strict, add FIXMEs, clean up variable
names to match what they can actually be and update testcases to reflect
that. We now reject:
typedef float float2 __attribute__ ((vector_size (8)));
double d;
f2 += d;
which doesn't fit as a direct bitcast anyway.
Differential Revision: https://reviews.llvm.org/D24472
rdar://problem/28033929
llvm-svn: 282968
Summary:
This lets people link against LLVM and their own version of the UTF
library.
I determined this only affects llvm, clang, lld, and lldb by running
$ git grep -wl 'UTF[0-9]\+\|\bConvertUTF\bisLegalUTF\|getNumBytesFor' | cut -f 1 -d '/' | sort | uniq
clang
lld
lldb
llvm
Tested with
ninja lldb
ninja check-clang check-llvm check-lld
(ninja check-lldb doesn't complete for me with or without this patch.)
Reviewers: rnk
Subscribers: klimek, beanz, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D24996
llvm-svn: 282822
r278501 inadvertently introduced a bug in which it disallowed shifting
scalar operands by vector operands when not compiling for OpenCL. This
commit fixes it.
Patch by Vladimir Yakovlev.
Differential Revision: https://reviews.llvm.org/D24467
llvm-svn: 281669
We also need to add ObjCTypeParamTypeLoc. ObjCTypeParamType supports the
representation of "T <protocol>" where T is a type parameter. Before this,
we use TypedefType to represent the type parameter for ObjC.
ObjCTypeParamType has "ObjCTypeParamDecl *OTPDecl" and it extends from
ObjCProtocolQualifiers. It is a non-canonical type and is canonicalized
to the underlying type with the protocol qualifiers.
rdar://24619481
rdar://25060179
Differential Revision: http://reviews.llvm.org/D23079
llvm-svn: 281355
within the instantiation of that same specialization. This could previously
happen for eagerly-instantiated function templates, variable templates,
exception specifications, default arguments, and a handful of other cases.
We still have an issue here for default template arguments that recursively
make use of themselves and likewise for substitution into the type of a
non-type template parameter, but in those cases we're producing a different
entity each time, so they should instead be caught by the instantiation depth
limit. However, currently we will typically run out of stack before we reach
it. :(
llvm-svn: 280190
This commit adds a traversal of the AST after Sema of a function that diagnoses
unguarded references to declarations that are partially available (based on
availability attributes). This traversal is only done when we would otherwise
emit -Wpartial-availability.
This commit is part of a feature I proposed here:
http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html
Differential revision: https://reviews.llvm.org/D23003
llvm-svn: 278826
Summary:
Some function calls in CUDA are allowed to appear in
semantically-correct programs but are an error if they're ever
codegen'ed. Specifically, a host+device function may call a host
function, but it's an error if such a function is ever codegen'ed in
device mode (and vice versa).
Previously, clang made no attempt to catch these errors. For the most
part, they would be caught by ptxas, and reported as "call to unknown
function 'foo'".
Now we catch these errors and report them the same as we report other
illegal calls (e.g. a call from a host function to a device function).
This has a small change in error-message behavior for calls that were
previously disallowed (e.g. calls from a host to a device function).
Previously, we'd catch disallowed calls fairly early, before doing
additional semantic checking e.g. of the call's arguments. Now we catch
these illegal calls at the very end of our semantic checks, so we'll
only emit a "illegal CUDA call" error if the call is otherwise
well-formed.
Reviewers: tra, rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23242
llvm-svn: 278759
This fixes an error in type checking of shift of vector values.
Patch by Vladimir Yakovlev.
Differential Revision: https://reviews.llvm.org/D21678
llvm-svn: 278501
Taking the address of a packed member is dangerous since the reduced
alignment of the pointee is lost. This can lead to memory alignment
faults in some architectures if the pointer value is dereferenced.
This change adds a new warning to clang emitted when taking the address
of a packed member. A packed member is either a field/data member
declared as attribute((packed)) or belonging to a struct/class
declared as such. The associated flag is -Waddress-of-packed-member.
Conversions (either implicit or via a valid casting) to pointer types
with lower or equal alignment requirements (e.g. void* or char*)
will silence the warning.
Differential Revision: https://reviews.llvm.org/D20561
llvm-svn: 278483
Summary:
I want to reuse "CheckCUDAFoo" in a later patch. Also, I think
IsAllowedCUDACall gets the point across more clearly.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23238
llvm-svn: 278193
This means that a function marked with an availability attribute can safely
refer to a declaration that is greater than the deployment target, but less then
or equal to the context availability without -Wpartial-availability firing.
Differential revision: https://reviews.llvm.org/D22697
llvm-svn: 277058
Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type.
This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer.
Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions.
This patch is partially based on Alexey Sotkin's work in Khronos Clang (3d4eec6162).
Differential Revision: https://reviews.llvm.org/D21567
llvm-svn: 277024
on the nullabilities of its operands.
This commit is a follow-up to r276076 and enables
computeConditionalNullability to compute the merged nullability when
the operands are objective-c pointers.
rdar://problem/22074116
llvm-svn: 276696
decomposition declarations.
There are a couple of things in the wording that seem strange here:
decomposition declarations are permitted at namespace scope (which we partially
support here) and they are permitted as the declaration in a template (which we
reject).
llvm-svn: 276492
rewriteBuiltinFunctionDecl can encounter errors when performing
DefaultFunctionArrayLvalueConversion. These errors were not handled
which led to a null pointer dereference.
This fixes PR28651.
llvm-svn: 276352
OpenMP 4.5 removed the restriction that array section lower bound must be non negative.
This change is to allow negative values for array section based on pointers.
For array section based on array type there is still a restriction: "The array section must be a subset of the original array."
Patch by David S.
Differential Revision: https://reviews.llvm.org/D22481
llvm-svn: 276177
nullabilities of its operands.
This patch defines a function to compute the nullability of conditional
expressions, which enables Sema to precisely detect implicit conversions
of nullable conditional expressions to nonnull pointers.
rdar://problem/25166556
Differential Revision: https://reviews.llvm.org/D22392
llvm-svn: 276076
Give incompatible function pointer warning its own diagnostic group
but still leave it as a subgroup of incompatible-pointer-types. This is in
preparation to promote -Wincompatible-function-pointer-types to error on
darwin.
Differential Revision: https://reviews.llvm.org/D22248
rdar://problem/12907612
llvm-svn: 275907
This patch adds a new AST node: ObjCAvailabilityCheckExpr, and teaches the
Parser and Sema to generate it. This node represents an availability check of
the form:
@available(macos 10.10, *);
Which will eventually compile to a runtime check of the host's OS version. This
is the first patch of the feature I proposed here:
http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html
Differential Revision: https://reviews.llvm.org/D22171
llvm-svn: 275654
This patch implements PR#22821.
Taking the address of a packed member is dangerous since the reduced
alignment of the pointee is lost. This can lead to memory alignment
faults in some architectures if the pointer value is dereferenced.
This change adds a new warning to clang emitted when taking the address
of a packed member. A packed member is either a field/data member
declared as attribute((packed)) or belonging to a struct/class
declared as such. The associated flag is -Waddress-of-packed-member.
Conversions (either implicit or via a valid casting) to pointer types
with lower or equal alignment requirements (e.g. void* or char*)
silence the warning.
This change also adds a new error diagnostic when the user attempts to
bind a reference to a packed member, regardless of the alignment.
Differential Revision: https://reviews.llvm.org/D20561
llvm-svn: 275417
- Changes diagnostics for Blocks to be implicitly
const qualified OpenCL v2.0 s6.12.5.
- Added and unified diagnostics of some OpenCL special types:
blocks, images, samplers, pipes. These types are intended for use
with the OpenCL builtin functions only and, therefore, most regular
uses are not allowed including assignments, arithmetic operations,
pointer dereferencing, etc.
Review: http://reviews.llvm.org/D21989
llvm-svn: 275061
Before r266366, clang used to support constructs like:
typedef __attribute__((vector_size(8))) double float64x1_t;
typedef __attribute__((vector_size(16))) double float64x2_t;
float64x1_t vget_low_f64(float64x2_t __p0);
double y = 3.0 + vget_low_f64(v);
But it would reject:
double y = vget_low_f64(v) + 3.0;
It also always rejected assignments:
double y = vget_low_f64(v);
This patch: (a) revivies the behavior of `3.0 + vget_low_f64(v)` prior to
r266366, (b) add support for `vget_low_f64(v) + 3.0` and (c) add support for
assignments.
These vector semantics have never really been tied up but it seems
odd that we used to support some binop froms but do not support
assignment. If we did support scalar for the purposes of arithmetic, we
should probably be able to reinterpret as scalar for the purposes of
assignment too.
Differential Revision: http://reviews.llvm.org/D21700
rdar://problem/26093791
llvm-svn: 274646
When we have template arguments, we have a function and a pattern, the variable
in init-capture belongs to the pattern decl when checking if the lhs of
"max = current" is modifiable:
auto find = [max = init](auto current) {
max = current;
};
In function isReferenceToNonConstCapture, we handle the case where the decl
context for the variable is not part of the current context.
Instead of crashing, we emit an error message:
cannot assign to a variable captured by copy in a non-mutable lambda
rdar://26997922
llvm-svn: 274392
constructor would be; this is effectively required by P0136R1. This has the
effect of exposing the validity of the base class initialization steps to
SFINAE checks.
llvm-svn: 274088
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
llvm-svn: 274049
-Wfor-loop-analysis warnings for a for-loop with a condition variable. In such
a case, the loop condition variable is modified on each iteration of the loop
by definition.
Original commit message:
Rearrange condition handling so that semantic checks on a condition variable
are performed before the other substatements of the construct are parsed,
rather than deferring them until the end. This allows better error recovery
from semantic errors in the condition, improves diagnostic order, and is a
prerequisite for C++17 constexpr if.
llvm-svn: 273600
are performed before the other substatements of the construct are parsed,
rather than deferring them until the end. This allows better error recovery
from semantic errors in the condition, improves diagnostic order, and is a
prerequisite for C++17 constexpr if.
llvm-svn: 273548
classes.
MSVC actively uses unqualified lookup in dependent bases, lookup at the
instantiation point (non-dependent names may be resolved on things
declared later) etc. and all this stuff is the main cause of
incompatibility between clang and MSVC.
Clang tries to emulate MSVC behavior but it may fail in many cases.
clang could store lexed tokens for member functions definitions within
ClassTemplateDecl for later parsing during template instantiation.
It will allow resolving many possible issues with lookup in dependent
base classes and removing many already existing MSVC-specific
hacks/workarounds from the clang code.
llvm-svn: 272774
If definition of default function argument uses itself, clang crashed,
because corresponding function parameter is not associated with the default
argument yet. With this fix clang emits appropriate error message.
This change fixes PR28105.
Differential Revision: http://reviews.llvm.org/D21301
llvm-svn: 272623
This patch implements PR#22821.
Taking the address of a packed member is dangerous since the reduced
alignment of the pointee is lost. This can lead to memory alignment
faults in some architectures if the pointer value is dereferenced.
This change adds a new warning to clang emitted when taking the address
of a packed member. A packed member is either a field/data member
declared as attribute((packed)) or belonging to a struct/class
declared as such. The associated flag is -Waddress-of-packed-member
Differential Revision: http://reviews.llvm.org/D20561
llvm-svn: 272552
These ExprWithCleanups are added for holding a RunCleanupsScope not
for destructor calls; rather, they are for lifetime marks. This requires
ExprWithCleanups to keep a bit to indicate whether it have cleanups with
side effects (e.g. dtor calls).
Differential Revision: http://reviews.llvm.org/D20498
llvm-svn: 272296
Given the following C++:
```
void foo();
void foo() __attribute__((enable_if(false, "")));
bool bar() {
auto P = foo;
return P == foo;
}
```
We'll currently happily (and correctly) resolve `foo` to the `foo`
overload without `enable_if` when assigning to `P`. However, we'll
complain about an ambiguous overload on the `P == foo` line, because
`Sema::CheckPlaceholderExpr` doesn't recognize that there's only one
`foo` that could possibly work here.
This patch teaches `Sema::CheckPlaceholderExpr` how to properly deal
with such cases.
Grepping for other callers of things like
`Sema::ResolveAndFixSingleFunctionTemplateSpecialization`, it *looks*
like this is the last place that needed to be fixed up. If I'm wrong,
I'll see if there's something we can do that beats what amounts to
whack-a-mole with bugs.
llvm-svn: 272080
For better performance and to unify code with offloading part we pass
scalar firstprivate values by value, instead of by reference. It will
remove some extra copying operations.
llvm-svn: 269751
This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).
It also fixes PR27367 and PR27666.
Differential Revision: http://reviews.llvm.org/D20103
llvm-svn: 269220
This patch corresponds to reviews:
http://reviews.llvm.org/D15120http://reviews.llvm.org/D19125
It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.
If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.
llvm-svn: 268898
If the address of a field is taken as a pointer to member, we should
not warn that the field is not used.
Normaly, yse of fields are done from MemberExpr, but in case of pointer to
member, it is in a DeclRefExpr
Differential Revision: http://reviews.llvm.org/D20054
llvm-svn: 268895
This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).
It also fixes PR27367.
Differential Revision: http://reviews.llvm.org/D19654
llvm-svn: 268727
declared before it is used. Because we don't use normal name lookup to find
these, the normal code to filter out non-visible names from name lookup results
does not apply.
llvm-svn: 268585
Usually these parameters are used solely to initialize the field in the
initializer list, and there is no real shadowing confusion.
There is a new warning under -Wshadow called
-Wshadow-field-in-constructor-modified. It attempts to find
modifications of such constructor parameters that probably intended to
modify the field.
It has some false negatives, though, so there is another warning group,
-Wshadow-field-in-constructor, which always warns on this special case.
For users who just want the old behavior and don't care about these fine
grained groups, we have a new warning group called -Wshadow-all that
activates everything.
Fixes PR16088.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18271
llvm-svn: 267957
The Decl::isUsed has a value for every decl. In non-module builds it is very
difficult (but possible) to break this invariant but when we walk up the redecl
chain we find the neccessary information.
When deserializing the decls from a module it is much more difficult to update
correctly this invariant. The patch centralizes the information whether a decl
is used in the canonical decl marking the entire entity as being used.
Fixes https://llvm.org/bugs/show_bug.cgi?id=27401
Patch by Cristina Cristescu and me.
Thanks to Richard Smith who helped to debug and understand the issue!
Reviewed by Richard Smith.
llvm-svn: 267691
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
llvm-svn: 266460
This patch implements __unaligned as a type qualifier; before that, it was
modeled as an attribute. Proper mangling of __unaligned is implemented as well.
Some OpenCL code/tests are tangenially affected, as they relied on existing
number and sizes of type qualifiers.
Differential Revision: http://reviews.llvm.org/D18596
llvm-svn: 266415
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
llvm-svn: 266186
Putting OpenCLImageTypes.def to clangAST library violates layering requirement: "It's not OK for a Basic/ header to include an AST/ header".
This fixes the modules build.
Differential revision: http://reviews.llvm.org/D18954
Reviewers: Richard Smith, Vassil Vassilev.
llvm-svn: 266180
I. Current implementation of images is not conformant to spec in the following points:
1. It makes no distinction with respect to access qualifiers and therefore allows to use images with different access type interchangeably. The following code would compile just fine:
void write_image(write_only image2d_t img);
kernel void foo(read_only image2d_t img) { write_image(img); } // Accepted code
which is disallowed according to s6.13.14.
2. It discards access qualifier on generated code, which leads to generated code for the above example:
call void @write_image(%opencl.image2d_t* %img);
In OpenCL2.0 however we can have different calls into write_image with read_only and wite_only images.
Also generally following compiler steps have no easy way to take different path depending on the image access: linking to the right implementation of image types, performing IR opts and backend codegen differently.
3. Image types are language keywords and can't be redeclared s6.1.9, which can happen currently as they are just typedef names.
4. Default access qualifier read_only is to be added if not provided explicitly.
II. This patch corrects the above points as follows:
1. All images are encapsulated into a separate .def file that is inserted in different points where image handling is required. This avoid a lot of code repetition as all images are handled the same way in the code with no distinction of their exact type.
2. The Cartesian product of image types and image access qualifiers is added to the builtin types. This simplifies a lot handling of access type mismatch as no operations are allowed by default on distinct Builtin types. Also spec intended access qualifier as special type qualifier that are combined with an image type to form a distinct type (see statement above - images can't be created w/o access qualifiers).
3. Improves testing of images in Clang.
Author: Anastasia Stulova
Reviewers: bader, mgrang.
Subscribers: pxli168, pekka.jaaskelainen, yaxunl.
Differential Revision: http://reviews.llvm.org/D17821
llvm-svn: 265783
Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0
(4.5 support will be added in separate patch).
The declare target directive specifies that variables, functions (C, C++
and Fortran), and subroutines (Fortran) are mapped to a device. The declare
target directive is a declarative directive. In Clang declare target is
implemented as implicit attribute for the declaration.
The syntax of the declare target directive is as follows:
#pragma omp declare target
declarations-definition-seq
#pragma omp end declare target
Based on patch from Michael Wong http://reviews.llvm.org/D15321
llvm-svn: 265530
In some cases, when we encounter a direct function call with an
incorrect number of arguments, we'll emit a diagnostic, and pretend that
the call to the function was valid. For example, in C:
int foo();
int a = foo(1);
Prior to this patch, we'd get an ICE if foo had an enable_if attribute,
because CheckEnableIf assumes that the number of arguments it gets
passed is valid for the function it's passed. Now, we check that the
number of args looks valid prior to checking enable_if conditions.
This fix was not done inside of CheckEnableIf because the problem
presently can only occur in one caller of CheckEnableIf (ActOnCallExpr).
Additionally, checking inside of CheckEnableIf would make us emit
multiple diagnostics for the same error (one "enable_if failed", one
"you gave this function the wrong number of arguments"), which seems
worse than just complaining about the latter.
llvm-svn: 264975
use. In order for this to fire, the function needed to be a templated function
marked 'constexpr' and declared but not defined. This weird pattern appears in
libstdc++'s alloc_traits.h.
llvm-svn: 264471
Yi Kong