The fix is to issue error messages if there are more than one
teams construct inside a target constructs.
#pragma omp target
{
#pragma omp teams
{ ... }
#pragma omp teams
{ ... }
}
llvm-svn: 353186
edge cases.
Currently, EmitCall emits a call instruction with a function type
derived from the pointee-type of the callee. This *should* be the same
as the type created from the CallInfo parameter, but in some cases an
incorrect CallInfo was being passed.
All of these fixes were discovered by the addition of the assert in
EmitCall which verifies that the passed-in CallInfo matches the
Callee's function type.
As far as I know, these issues caused no bugs at the moment, as the
correct types were ultimately being emitted. But, some would become
problematic when pointee types are removed.
List of fixes:
* arrangeCXXConstructorCall was passing an incorrect value for the
number of Required args, when calling an inheriting constructor
where the inherited constructor is variadic. (The inheriting
constructor doesn't actually get passed any of the user's args, but
the code was calculating it as if it did).
* arrangeFreeFunctionLikeCall was not including the count of the
pass_object_size arguments in the count of required args.
* OpenCL uses other address spaces for the "this" pointer. However,
commonEmitCXXMemberOrOperatorCall was not annotating the address
space on the "this" argument of the call.
* Destructor calls were being created with EmitCXXMemberOrOperatorCall
instead of EmitCXXDestructorCall in a few places. This was a problem
because the calling convention sometimes has destructors returning
"this" rather than void, and the latter function knows about that,
and sets up the types properly (through calling
arrangeCXXStructorDeclaration), while the former does not.
* generateObjCGetterBody: the 'objc_getProperty' function returns type
'id', but was being called as if it returned the particular
property's type. (That is of course the *dynamic* return type, and
there's a downcast immediately after.)
* OpenMP user-defined reduction functions (#pragma omp declare
reduction) can be called with a subclass of the declared type. In
such case, the call was being setup as if the function had been
actually declared to take the subtype, rather than the base type.
Differential Revision: https://reviews.llvm.org/D57664
llvm-svn: 353181
When we attempt to add an addr space qual to a type already
qualified by an addr space ICE is triggered. Before creating
a type with new address space, remove the old addr space.
Fixing PR38614!
Differential Revision: https://reviews.llvm.org/D57524
llvm-svn: 353160
A non-lazy class will be initialized eagerly when the Objective-C runtime is
loaded. This is required for certain system classes which have instances allocated in
non-standard ways, such as the classes for blocks and constant strings.
Adding this attribute is essentially equivalent to providing a trivial
+load method but avoids the (fairly small) load-time overheads associated
with defining and calling such a method.
Differential Revision: https://reviews.llvm.org/D56555
llvm-svn: 353116
ownership qualifications in C++ unions under ARC.
An ObjC pointer member with non-trivial ownership qualifications causes
all of the defaulted special functions of the enclosing union to be
defined as deleted, except when the member has an in-class initializer,
the default constructor isn't defined as deleted.
rdar://problem/34213306
Differential Revision: https://reviews.llvm.org/D57438
llvm-svn: 352949
Further reviews (D57594, D57615) have revealed that this was not reviewed,
and that the differential's description was not read during the review,
thus rendering this commit invalid.
This reverts commit r352882.
llvm-svn: 352933
This is similar to import_module, but sets the import field name
instead.
By default, the import field name is the same as the C/asm/.o symbol
name. However, there are situations where it's useful to have it be
different. For example, suppose I have a wasm API with a module named
"pwsix" and a field named "read". There's no risk of namespace
collisions with user code at the wasm level because the generic name
"read" is qualified by the module name "pwsix". However in the C/asm/.o
namespaces, the module name is not used, so if I have a global function
named "read", it is intruding on the user's namespace.
With the import_field module, I can declare my function (in libc) to be
"__read", and then set the wasm import module to be "pwsix" and the wasm
import field to be "read". So at the C/asm/.o levels, my symbol is
outside the user namespace.
Differential Revision: https://reviews.llvm.org/D57602
llvm-svn: 352930
I recently ran into this code:
```
\#include <iostream>
void foo(const std::string &s, const std::string& = "");
\#include <string>
void test() { foo(""); }
```
The diagnostic produced said it can't bind char[1] to std::string
const&. It didn't mention std::string is incomplete. The user had to
infer that.
This patch causes the diagnostic to now say "incomplete type".
llvm-svn: 352927
This patch implements parsing and sema for "omp declare mapper"
directive. User defined mapper, i.e., declare mapper directive, is a new
feature in OpenMP 5.0. It is introduced to extend existing map clauses
for the purpose of simplifying the copy of complex data structures
between host and device (i.e., deep copy). An example is shown below:
struct S { int len; int *d; };
#pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper.
Contributed-by: Lingda Li <lildmh@gmail.com>
Differential Revision: https://reviews.llvm.org/D56326
llvm-svn: 352906
Summary:
I'm working on a clang-tidy check, much like existing [[ http://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html | bugprone-exception-escape ]],
to detect when an exception might escape out of an OpenMP construct it isn't supposed to escape from.
For that i will be using the `nothrow` bit of `CapturedDecl`s.
While that bit is already correctly set for some constructs, e.g. `#pragma omp parallel`: https://godbolt.org/z/2La7pv
it isn't set for the `#pragma omp sections`, or `#pragma omp section`: https://godbolt.org/z/qZ-EbP
If i'm reading [[ https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf | `OpenMP Application Programming Interface Version 5.0 November 2018` ]] correctly,
they should be, as per `2.8.1 sections Construct`, starting with page 86:
* The sections construct is a non-iterative worksharing construct that contains a set of **structured blocks**
that are to be distributed among and executed by the threads in a team. Each **structured block** is executed
once by one of the threads in the team in the context of its implicit task.
* The syntax of the sections construct is as follows:
#pragma omp sections [clause[ [,] clause] ... ] new-line
{
[#pragma omp section new-line]
**structured-block**
...
* Description
Each **structured block** in the sections construct is preceded by a section directive except
possibly **the first block**, for which a preceding section directive is optional.
* Restrictions
• The code enclosed in a sections construct must be a **structured block**.
* A throw executed inside a sections region must cause execution to resume within the same
section of the sections region, and the same thread that threw the exception must catch it.
Reviewers: ABataev, #openmp
Reviewed By: ABataev
Subscribers: guansong, openmp-commits, cfe-commits
Tags: #clang, #openmp
Differential Revision: https://reviews.llvm.org/D57585
llvm-svn: 352882
Summary:
Given the following test program:
```
class C {
public:
int A(int a, int& b);
};
int C::A(const int a, int b) {
return a * b;
}
```
Clang would produce an error message that correctly diagnosed the
redeclaration of `C::A` to not match the original declaration (the
parameters to the two declarations do not match -- the original takes an
`int &` as its 2nd parameter, but the redeclaration takes an `int`). However,
it also produced a note diagnostic that inaccurately pointed to the
first parameter, claiming that `const int` in the redeclaration did not
match the unqualified `int` in the original. The diagnostic is
misleading because it has nothing to do with why the program does not
compile.
The logic for checking for a function overload, in
`Sema::FunctionParamTypesAreEqual`, discards cv-qualifiers before
checking whether the types are equal. Do the same when producing the
overload diagnostic.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cpplearner, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57032
llvm-svn: 352831
Instead of calling CUDA runtime to arrange function arguments,
the new API constructs arguments in a local array and the kernels
are launched with __cudaLaunchKernel().
The old API has been deprecated and is expected to go away
in the next CUDA release.
Differential Revision: https://reviews.llvm.org/D57488
llvm-svn: 352799
Preferred types are used by code completion for ranking. This commit
considerably increases the number of points in code where those types
are propagated.
In order to avoid complicating signatures of Parser's methods, a
preferred type is kept as a member variable in the parser and updated
during parsing.
Differential revision: https://reviews.llvm.org/D56723
llvm-svn: 352788
Summary:
As PR17480 describes, clang does not support the used attribute
for member functions of class templates. This means that if the member
function is not used, its definition is never instantiated. This patch
changes clang to emit the definition if it has the used attribute.
Test Plan: Added a testcase
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D56928
llvm-svn: 352740
This builtin has the same UI as __builtin_object_size, but has the
potential to be evaluated dynamically. It is meant to be used as a
drop-in replacement for libraries that use __builtin_object_size when
a dynamic checking mode is enabled. For instance,
__builtin_object_size fails to provide any extra checking in the
following function:
void f(size_t alloc) {
char* p = malloc(alloc);
strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0))
}
This is an overflow if alloc < 7, but because LLVM can't fold the
object size intrinsic statically, it folds __builtin_object_size to
-1. With __builtin_dynamic_object_size, alloc is passed through to
__builtin___strcpy_chk.
rdar://32212419
Differential revision: https://reviews.llvm.org/D56760
llvm-svn: 352665
When creating the prototype of implicit assignment operators the
returned reference to the class should be qualified with the same
addr space as 'this' (i.e. __generic in OpenCL).
Differential Revision: https://reviews.llvm.org/D57101
llvm-svn: 352617
Summary:
We use the existing diag::note_locked_here to tell the user where we saw
the first locking.
Reviewers: aaron.ballman, delesley
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56967
llvm-svn: 352549
We don't need to use the predetermined data-sharing attributes for the
loop counters if the user explicitly specified correct data-sharing
attributes for such variables.
llvm-svn: 352543
Re-enable format string warnings on printf.
The warnings are still incomplete. Apparently it is undefined to use a
vector specifier without a length modifier, which is not currently
warned on. Additionally, type warnings appear to not be working with
the hh modifier, and aren't warning on all of the special restrictions
from c99 printf.
llvm-svn: 352540
This reverts r348083. This was based on a misreading of the spec
for printf specifiers.
Also revert r343653, as without a subsequent patch, a correctly
specified format for a vector will incorrectly warn.
Fixes bug 40491.
llvm-svn: 352539
According to the report, better to keep the original strict compare
operation as the loop condition with unsigned loop counters to make the
loop countable. This allows further loop transformations.
llvm-svn: 352526
r352221 caused regressions in CUDA/HIP since device function may use _Float16 whereas host does not support it.
In this case host compilation should not diagnose usage of _Float16 in device functions or variables.
For now just do not diagnose _Float16 for CUDA/HIP. In the future we should have more precise check.
Differential Revision: https://reviews.llvm.org/D57369
llvm-svn: 352488
Summary:
As discussed in https://reviews.llvm.org/D57112#inline-506781,
'flush' clause does not exist in the OpenMP spec, it can not be
specified, and `OMPFlushClause` class is just a helper class.
Therefore `OPENMP_CLAUSE()` in `clang/Basic/OpenMPKinds.def`
should not contain 'flush' "clause".
I have simply removed the `OPENMP_CLAUSE(flush, OMPFlushClause)`
from `clang/Basic/OpenMPKinds.def`, grepped for `OPENMP_CLAUSE`
and added `OPENMP_CLAUSE(flush, OMPFlushClause)` back to the **every**
place where `OPENMP_CLAUSE` is defined and `clang/Basic/OpenMPKinds.def`
is then included.
So as-is, this patch is a NFC. Possibly, some of these
`OPENMP_CLAUSE(flush, OMPFlushClause)` should be dropped,
i don't really know.
Test plan: `ninja check-clang`
Reviewers: ABataev
Reviewed By: ABataev
Subscribers: guansong, arphaman, cfe-commits
Tags: #openmp
Differential Revision: https://reviews.llvm.org/D57280
llvm-svn: 352390
Introduce a new class GenericSelectionExpr::Association which bundle together
an association expression and its TypeSourceInfo.
An iterator GenericSelectionExpr::AssociationIterator is additionally added to
make it possible to iterate over ranges of Associations. This iterator is a
kind of proxy iterator which abstract over how exactly the expressions and the
TypeSourceInfos are stored.
Differential Revision: https://reviews.llvm.org/D57106
Reviewed By: aaron.ballman
Reviewers: aaron.ballman, steveire, dblaikie, mclow.lists
llvm-svn: 352369
Summary:
Trying to use structure binding with a structure that doesn't implement
std::tuple_size, should unpack the data members. When the struct is a
template though, clang might hit an assertion (if the type has not been
completed before), because CXXRecordDecl::DefinitionData is nullptr.
This commit fixes the problem by completing the type while trying to
decompose the structured binding.
The ICE happens in real world code, for example, when trying to iterate
a protobuf generated map with a range-based for loop and structure
bindings (because google::protobuf::MapPair is a template and doesn't
support std::tuple_size).
Reported-by: nicholas.sun@nlsun.com
Patch by Daniele Di Proietto
Reviewers: #clang, rsmith
Reviewed By: #clang, rsmith
Subscribers: cpplearner, Rakete1111, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56974
llvm-svn: 352323
Store the controlling expression, the association expressions and the
corresponding TypeSourceInfos as trailing objects.
Additionally use the bit-fields of Stmt to store one SourceLocation,
saving one additional pointer. This saves 3 pointers in total per
GenericSelectionExpr.
Differential Revision: https://reviews.llvm.org/D57104
Reviewed By: aaron.ballman
Reviewers: aaron.ballman, steveire
llvm-svn: 352276
Fix a bug where we would compare array sizes with incompatible
element types, and look through explicit casts.
rdar://44800168
Differential revision: https://reviews.llvm.org/D57064
llvm-svn: 352239
As Discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129543.html
There are problems exposing the _Float16 type on architectures that
haven't defined the ABI/ISel for the type yet, so we're temporarily
disabling the type and making it opt-in.
Differential Revision: https://reviews.llvm.org/D57188
Change-Id: I5db7366dedf1deb9485adb8948b1deb7e612a736
llvm-svn: 352221
declaration in MSVCCompat mode
Microsoft compiler permits the use of 'static' storage specifier outside
of a class definition if it's on an out-of-line member function template
declaration.
This patch allows 'static' storage specifier on an out-of-line member
function template declaration with a warning in Clang (To be compatible
with Microsoft).
Intel C/C++ compiler allows the 'static' keyword with a warning in
Microsoft mode. GCC allows this with -fpermissive.
Patch By: Manna
Differential Revision: https://reviews.llvm.org/D56473
Change-Id: I97b2d9e9d57cecbcd545d17e2523142a85ca2702
llvm-svn: 352219
This adds a C/C++ attribute which corresponds to the LLVM IR wasm-import-module
attribute. It allows code to specify an explicit import module.
Differential Revision: https://reviews.llvm.org/D57160
llvm-svn: 352106
attributes from declaration over attributes from '#pragma clang attribute'
Before this commit users had an issue when using #pragma clang attribute with
availability attributes:
The explicit attribute that's specified next to the declaration is not
guaranteed to be preferred over the attribute specified in the pragma.
This commit fixes this by introducing a priority field to the availability
attribute to control how they're merged. Attributes with higher priority are
applied over attributes with lower priority for the same platform. The
implicitly inferred attributes are given the lower priority. This ensures that:
- explicit attributes are preferred over all other attributes.
- implicitly inferred attributes that are inferred from an explicit attribute
are discarded if there's an explicit attribute or an attribute specified
using a #pragma for the same platform.
- implicitly inferred attributes that are inferred from an attribute in the
#pragma are not used if there's an explicit, explicit #pragma, or an
implicit attribute inferred from an explicit attribute for the declaration.
This is the resulting ranking:
`platform availability > platform availability from pragma > inferred availability > inferred availability from pragma`
rdar://46390243
Differential Revision: https://reviews.llvm.org/D56892
llvm-svn: 352084
When attempting to correct a misspelled pseudo destructor call as in:
struct Foo;
void foo(Foo *p) {
p.~Foo();
}
a call is made in canRecoverDotPseudoDestructorCallsOnPointerObjects
to LookupDestructor without checking that the record has a definition.
This causes an assertion later in LookupSpecialMember which assumes that
the record has a definition.
Patch By Roman Zhikharevich!
Differential Revision: https://reviews.llvm.org/D57111
Reviewed By: riccibruno
llvm-svn: 352047
This is a fix for https://reviews.llvm.org/D51229 where we pass the
address_space qualified type as the modified type of an AttributedType. This
change now instead wraps the AttributedType with either the address_space
qualifier or a DependentAddressSpaceType.
Differential Revision: https://reviews.llvm.org/D55447
llvm-svn: 351997
before adding a delayed diagnostic to DelayedDiagnostics.
This fixes an assertion failure in Sema::DelayedDiagnostics::add that
was caused by the changes made in r141037.
rdar://problem/42782323
llvm-svn: 351911
Methods can now be qualified with address spaces to prevent
undesirable conversions to generic or to provide custom
implementation to be used if the object is located in certain
memory segments.
This commit extends parsing and standard C++ overloading to
work for an address space of a method (i.e. implicit 'this'
parameter).
Differential Revision: https://reviews.llvm.org/D55850
llvm-svn: 351747
As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectation of
std::is_trivially_copyable which makes the memcpy optimization invalid.
This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable.
Unfortunately std::is_trivially_copyable is not portable across compiler / STL
versions. So a portable version is provided too.
Note that the following specialization were invalid:
std::pair<T0, T1>
llvm::Optional<T>
Tests have been added to assert that former specialization are respected by the
standard usage of llvm::is_trivially_copyable, and that when a decent version
of std::is_trivially_copyable is available, llvm::is_trivially_copyable is
compared to std::is_trivially_copyable.
As of this patch, llvm::Optional is no longer considered trivially copyable,
even if T is. This is to be fixed in a later patch, as it has impact on a
long-running bug (see r347004)
Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296.
Differential Revision: https://reviews.llvm.org/D54472
llvm-svn: 351701
Patrick Lyster