| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expression is a discarded-value expression.
Summary:
We used to get this wrong in three ways:
1) During parsing, an expression-statement followed by the }) ending a
statement expression was always treated as producing the value of the
statement expression. That's wrong for ({ if (1) expr; })
2) During template instantiation, various kinds of statement (most
statements not appearing directly in a compound-statement) were not
treated as discarded-value expressions, resulting in missing volatile
loads (etc).
3) In all contexts, an expression-statement with attributes was not
treated as producing the value of the statement expression, eg
({ [[attr]] expr; }).
Also fix incorrect enforcement of OpenMP rule that directives can "only
be placed in the program at a position where ignoring or deleting the
directive would result in a program with correct syntax". In particular,
a label (be it goto, case, or default) should not affect whether
directives are permitted.
Reviewers: aaron.ballman, rjmccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57984
llvm-svn: 354090
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We were warning on valid ObjC property reference exprs, and passing
in the wrong arguments to DiagnoseFloatingImpCast (leading to a badly
worded diagnostic).
rdar://47644670
Differential revision: https://reviews.llvm.org/D58145
llvm-svn: 354074
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
D54902 removed CallExpr::setNumArgs in preparation of tail-allocating the
arguments of CallExpr. It did this by allocating storage for
max(number of arguments, number of parameters in the prototype). The
temporarily nulled arguments however causes issues in BuildResolvedCallExpr
when typo correction is done just after the creation of the call expression.
This was unfortunately missed by the tests /:
To fix this, delay setting the number of arguments to
max(number of arguments, number of parameters in the prototype) until we are
ready for it. It would be nice to have this encapsulated in CallExpr but this
is the best I can come up with under the constraint that we cannot add
anything the CallExpr.
Fixes PR40286.
Differential Revision: https://reviews.llvm.org/D57948
Reviewed By: aaron.ballman
llvm-svn: 354035
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This makes it consistent with `memcmp` and `__builtin_bcmp`.
Also see the discussion in https://reviews.llvm.org/D56593.
Reviewers: jyknight
Subscribers: kristina, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58120
llvm-svn: 354023
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When this was rewritten in D43737, the logic changed to better explore infinite loops. The check for a reachable exit block was deleted which accidentally introduced false positives in case the exit node was unreachable.
We were testing for cases like this, but @steven_wu provided an additional test case that I've included in the regression tests for this patch.
Reviewers: steven_wu, rtrieu
Reviewed By: steven_wu, rtrieu
Subscribers: cfe-commits, steven_wu
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58122
llvm-svn: 353984
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to an init method
This fixes a regression that was caused by r335084, which reversed
the order that attributes are applied. objc_method_family can change
whether a method is an init method, so the order that these
attributes are applied matters. The commit fixes this by delaying the
init check until after all attributes have been applied.
rdar://47829358
Differential revision: https://reviews.llvm.org/D58152
llvm-svn: 353976
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: See the added test for a repro.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58111
llvm-svn: 353840
|
| |
|
|
| |
llvm-svn: 353839
|
| |
|
|
|
|
| |
Amends r353837 which renamed the diagnostics to conflict.
llvm-svn: 353838
|
| |
|
|
| |
llvm-svn: 353837
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This attribute applies to declarations of C stdlib functions
(sprintf, memcpy...) that have known fortified variants
(__sprintf_chk, __memcpy_chk, ...). When applied, clang will emit
calls to the fortified variant functions instead of calls to the
defaults.
In GCC, this is done by adding gnu_inline-style wrapper functions,
but that doesn't work for us for variadic functions because we don't
support __builtin_va_arg_pack (and have no intention to).
This attribute takes two arguments, the first is 'type' argument
passed through to __builtin_object_size, and the second is a flag
argument that gets passed through to the variadic checking variants.
rdar://47905754
Differential revision: https://reviews.llvm.org/D57918
llvm-svn: 353765
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Basically the same issue as string init, except it didn't really have
any visible consequences before I removed the implicit lvalue-to-rvalue
conversion from CodeGen.
While I'm here, a couple minor drive-by cleanups: IgnoreParens never
returns a ConstantExpr, and there was a potential crash with string init
involving a ChooseExpr.
The analyzer test change maybe indicates we could simplify the analyzer
code a little with this fix? Apparently a hack was added to support
lvalues in initializers in r315750, but I'm not really familiar with the
relevant code.
Fixes regression reported in the kernel build at
https://bugs.llvm.org/show_bug.cgi?id=40430#c6 .
Differential Revision: https://reviews.llvm.org/D58069
llvm-svn: 353762
|
| |
|
|
| |
llvm-svn: 353705
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows substantially simplifying the expression evaluation code,
because we don't have to special-case lvalues which are actually string
literal initialization.
This currently throws away an optimization where we would avoid creating
an array APValue for string literal initialization. If we really want
to optimize this case, we should fix APValue so it can store simple
arrays more efficiently, like llvm::ConstantDataArray. This shouldn't
affect the memory usage for other string literals. (Not sure if this is
a blocker; I don't think string literal init is common enough for this
to be a serious issue, but I could be wrong.)
The change to test/CodeGenObjC/encode-test.m is a weird side-effect of
these changes: we currently don't constant-evaluate arrays in C, so the
strlen call shouldn't be folded, but lvalue string init managed to get
around that check. I this this is fine.
Fixes https://bugs.llvm.org/show_bug.cgi?id=40430 .
llvm-svn: 353569
|
| |
|
|
|
|
|
|
|
|
| |
Fixed diagnostic emission for the exceptions support in case of the
compilation of OpenMP code for the devices. From now on, it uses delayed
diagnostics mechanism, previously used for CUDA only. It allow to
diagnose not allowed used of exceptions only in functions that are going
to be codegen'ed.
llvm-svn: 353542
|
| |
|
|
|
|
|
| |
This reverts commit r353540. Erroneously committed, need to fix the
message and description.
llvm-svn: 353541
|
| |
|
|
|
|
|
|
|
| |
It is important to delay the emission of the diagnostic messages for the
functions unless it is proved that the function is going to be used on
the device side. It is required to support compilation with some of the
target-specific system headers.
llvm-svn: 353540
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a bug where clang doesn’t reject union fields of
non-trivial C struct types. For example:
```
// This struct is non-trivial under ARC.
struct S0 {
id x;
};
union U0 {
struct S0 s0; // clang should reject this.
struct S0 s1; // clang should reject this.
};
void test(union U0 a) {
// Previously, both 'a.s0.x' and 'a.s1.x' were released in this
// function.
}
```
rdar://problem/46677858
Differential Revision: https://reviews.llvm.org/D55659
llvm-svn: 353459
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Deferred diagnostic interface is going to be used for OpenMP device
compilation. Generalized previously existed deferred diagnostic
interface for CUDA to be used with OpenMP and, possibly, other models.
Reviewers: rjmccall, tra
Subscribers: caomhin, cfe-commits, kkwli0
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57908
llvm-svn: 353456
|
| |
|
|
|
|
|
|
|
|
| |
Valid OpenCL C code should still compile in C++ mode.
This change enables extensions and OpenCL types.
Differential Revision: https://reviews.llvm.org/D57824
llvm-svn: 353431
|
| |
|
|
| |
llvm-svn: 353320
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
has Class type
rdar://47713266
Differential revision: https://reviews.llvm.org/D57712
llvm-svn: 353115
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Structured blocks"
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
|
| |
|
|
| |
llvm-svn: 352842
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit r350920 as it is not clear whether we should force a
class to be returned in registers when copy and move constructors are
both deleted.
For more background, see the following discussion:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190128/259907.html
llvm-svn: 352822
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This reverts commit 352740: broke swift build
llvm-svn: 352748
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This time with a fix to make gcc 4.8 happy.
llvm-svn: 352486
|
| |
|
|
|
|
| |
This breaks GCC 4.8.4. Reported by email by Hans Wennborg.
llvm-svn: 352403
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|