| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
rules
Differential revision: https://reviews.llvm.org/D50418
llvm-svn: 339375
|
|
|
|
|
|
|
|
| |
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50348
llvm-svn: 339374
|
|
|
|
|
|
|
|
| |
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50346
llvm-svn: 339372
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a part of attempting to clean up the way attributes are
printed, this patch adds an operator << to the diagnostics/
partialdiagnostics so that ParsedAttr can be sent directly.
This patch also rewrites a large amount* of the times when
ParsedAttr was printed using its IdentifierInfo object instead
of being printed itself.
*"a large amount" == "All I could find".
llvm-svn: 339344
|
|
|
|
|
|
| |
incomplete class template.
llvm-svn: 339210
|
|
|
|
|
|
|
|
|
|
|
| |
The dependent auto was getting stripped away while rebuilding the template
parameter type, so substitute it in.
rdar://41852459
Differential revision: https://reviews.llvm.org/D50088
llvm-svn: 339198
|
|
|
|
|
|
|
| |
No functional change intended, except that we will now produce more
"declared here" notes.
llvm-svn: 339187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Compiling the following causes clang to crash
```
char *cmp(__attribute__((address_space(1))) char *x, __attribute__((address_space(2))) char *y) {
return x < y ? x : y;
}
```
with the message: "wrong cast for pointers in different address
spaces(must be an address space cast)!"
This is because during IR emission, the source and dest type for a
bitcast should not have differing address spaces.
This fix prints an error since the code shouldn't compile in the first place.
Differential Revision: https://reviews.llvm.org/D50278
llvm-svn: 339167
|
|
|
|
|
|
|
|
|
| |
declare target.
According to OpenMP 5.0, variables captured in lambdas in declare target
regions must be considered as implicitly declare target.
llvm-svn: 339152
|
|
|
|
|
|
|
|
|
|
| |
This patch proposes an abstract type that represents fixed point numbers, similar to APInt or APSInt that was discussed in https://reviews.llvm.org/D48456#inline-425585. This type holds a value, scale, and saturation and is meant to perform intermediate calculations on constant fixed point values.
Currently this class is used as a way for handling the conversions between fixed point numbers with different sizes and radixes. For example, if I'm casting from a signed _Accum to a saturated unsigned short _Accum, I will need to check the value of the signed _Accum to see if it fits into the short _Accum which involves getting and comparing against the max/min values of the short _Accum. The FixedPointNumber class currently handles the radix shifting and extension when converting to a signed _Accum.
Differential Revision: https://reviews.llvm.org/D48661
llvm-svn: 339028
|
|
|
|
|
|
|
|
| |
Looks like the only reason we use a unique_ptr here is so that we can
conditionally construct a LogicalErrorHandler. It's a small type, and
Optional can do the same thing with 100% fewer heap allocations.
llvm-svn: 338962
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Libc++ needs to know when aligned allocation is supported by clang, but is
otherwise unavailable at link time. Otherwise, libc++ will incorrectly end up
generating calls to `__builtin_operator_new`/`__builtin_operator_delete` with
alignment arguments.
This patch implements the following changes:
* The `__cpp_aligned_new` feature test macro to no longer be defined when
aligned allocation is otherwise enabled but unavailable.
* The Darwin driver no longer passes `-faligned-alloc-unavailable` when the
user manually specifies `-faligned-allocation` or `-fno-aligned-allocation`.
* Instead of a warning Clang now generates a hard error when an aligned
allocation or deallocation function is referenced but unavailable.
Patch by Eric Fiselier.
Reviewers: rsmith, vsapsai, erik.pilkington, ahatanak, dexonsmith
Reviewed By: rsmith
Subscribers: Quuxplusone, cfe-commits
Differential Revision: https://reviews.llvm.org/D45015
llvm-svn: 338934
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D45712
llvm-svn: 338931
|
|
|
|
|
|
|
|
|
|
|
|
| |
Explicit cast of a void pointer to a pointer type in different address space is
incorrectly classified as bitcast, which causes invalid bitcast in codegen.
The patch fixes that by checking the address space of the source and destination
type and set the correct cast kind.
Differential Revision: https://reviews.llvm.org/D50003
llvm-svn: 338805
|
|
|
|
|
|
| |
This avoids to recast `Record` multiple times.
llvm-svn: 338801
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recommit of r335084 after revert in r335516.
... instead of prepending it at the beginning (the original behavior
since implemented in r122535 2010-12-23). This builds up an
AttributeList in the the order in which the attributes appear in the
source.
The reverse order caused nodes for attributes in the AST (e.g. LoopHint)
to be in the reverse order, and therefore printed in the wrong order in
-ast-dump. Some TODO comments mention this. The order was explicitly
reversed for enable_if attribute overload resolution and name mangling,
which is not necessary anymore with this patch.
The change unfortunately has some secondary effect, especially on
diagnostic output. In the simplest cases, the CHECK lines or expected
diagnostic were changed to the the new output. If the kind of
error/warning changed, the attributes' order was changed instead.
This unfortunately causes some 'previous occurrence here' hints to be
textually after the main marker. This typically happens when attributes
are merged, but are incompatible to each other. Interchanging the role
of the the main and note SourceLocation will also cause the case where
two different declaration's attributes (in contrast to multiple
attributes of the same declaration) are merged to be reverse. There is
no easy fix because sometimes previous attributes are merged into a new
declaration's attribute list, sometimes new attributes are added to a
previous declaration's attribute list. Since 'previous occurrence here'
pointing to locations after the main marker is not rare, I left the
markers as-is; it is only relevant when the attributes are declared in
the same declaration anyway.
Differential Revision: https://reviews.llvm.org/D48100
llvm-svn: 338800
|
|
|
|
|
|
|
|
|
| |
This is the same fix as in r338478, for another occurrance of the
same pattern from r338464.
See gcc.gnu.org/PR86769 for details of the bug.
llvm-svn: 338749
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
C++11 onwards specs the non-member functions atomic_load and atomic_load_explicit as taking the atomic<T> by const (potentially volatile) pointer. C11, in its infinite wisdom, decided to drop the const, and C17 will fix this with DR459 (the current draft forgot to fix B.16, but that’s not the normative part).
clang’s lib/Headers/stdatomic.h implements these as #define to the __c11_* equivalent, which are builtins with custom typecheck. Fix the typecheck.
D47613 takes care of the libc++ side.
Discussion: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058129.html
<rdar://problem/27426936>
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D47618
llvm-svn: 338743
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way address space declarations for builtins currently work
is nearly useless. The code assumes the address spaces used for
builtins is a confusingly named "target address space" from user
code using __attribute__((address_space(N))) that matches
the builtin declaration. There's no way to use this to declare
a builtin that returns a language specific address space.
The terminology used is highly cofusing since it has nothing
to do with the the address space selected by the target to use
for a language address space.
This feature is essentially unused as-is. AMDGPU and NVPTX
are the only in-tree targets attempting to use this. The AMDGPU
builtins certainly do not behave as intended (i.e. all of the
builtins returning pointers can never compile because the numbered
address space never matches the expected named address space).
The NVPTX builtins are missing tests for some, and the others
seem to rely on an implicit addrspacecast.
Change the used address space for builtins based on a target
hook to allow using a language address space for a builtin.
This allows the same builtin declaration to be used for multiple
languages with similarly purposed address spaces (e.g. the same
AMDGPU builtin can be used in OpenCL and CUDA even though the
constant address spaces are arbitarily different).
This breaks the possibility of using arbitrary numbered
address spaces alongside the named address spaces for builtins.
If this is an issue we probably need to introduce another builtin
declaration character to distinguish language address spaces from
so-called "target address spaces".
llvm-svn: 338707
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into DeclContext
This patch follows https://reviews.llvm.org/D49729,
https://reviews.llvm.org/D49732 and
https://reviews.llvm.org/D49733.
Move the bits from ObjCMethodDecl and ObjCContainerDecl
into DeclContext.
Differential Revision: https://reviews.llvm.org/D49734
Patch By: bricci
llvm-svn: 338641
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the unroll_and_jam pragma, to go with the recently
added unroll and jam pass. The name of the pragma is the same as is used
in the Intel compiler, and most of the code works the same as for unroll.
#pragma clang loop unroll_and_jam has been separated into a different
patch. This part adds #pragma unroll_and_jam with an optional count, and
#pragma no_unroll_and_jam to disable the transform.
Differential Revision: https://reviews.llvm.org/D47267
llvm-svn: 338566
|
|
|
|
|
|
| |
See gcc.gnu.org/PR86769 for details of the bug.
llvm-svn: 338478
|
|
|
|
| |
llvm-svn: 338473
|
|
|
|
|
|
| |
warnings.
llvm-svn: 338467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for a new attribute, [[clang::lifetimebound]], that
indicates that the lifetime of a function result is related to one of the
function arguments. When walking an initializer to make sure that the lifetime
of the initial value is at least as long as the lifetime of the initialized
object, we step through parameters (including the implicit object parameter of
a non-static member function) that are marked with this attribute.
There's nowhere to write an attribute on the implicit object parameter, so in
lieu of that, it may be applied to a function type (where it appears
immediately after the cv-qualifiers and ref-qualifier, which is as close to a
declaration of the implicit object parameter as we have). I'm currently
modeling this in the AST as the attribute appertaining to the function type.
Differential Revision: https://reviews.llvm.org/D49922
llvm-svn: 338464
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Size_t, intptr_t, uintptr_t and ptrdiff_t cannot be used as kernel
arguments, according to OpenCL Specification s6.9k:
The size in bytes of these types are implementation-defined and in
addition can also be different for the OpenCL device and the host
processor making it difficult to allocate buffer objects to be passed
as arguments to a kernel declared as pointer to these types.
Patch by: Andrew Savonichev
Reviewers: Anastasia, yaxunl
Subscribers: yaxunl, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D49725
llvm-svn: 338432
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
OpenCL specification forbids use of several types as kernel arguments.
This patch improves existing diagnostic to look through arrays.
Patch by: Andrew Savonichev
Reviewers: Anastasia, yaxunl
Subscribers: yaxunl, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D49723
llvm-svn: 338427
|
|
|
|
|
|
| |
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}
llvm-svn: 338291
|
|
|
|
|
|
|
|
|
| |
Started crashing in r337453. See the added test case for the crash repro.
The fix reverts part of r337453 that causes the crash and does
not actually break anything when reverted.
llvm-svn: 338255
|
|
|
|
|
|
| |
an initializer is self-referential.
llvm-svn: 338230
|
|
|
|
|
|
|
|
|
|
|
| |
non-escaping parameter but the implementation's method takes an escaping
parameter.
rdar://problem/39548196
Differential Revision: https://reviews.llvm.org/D49119
llvm-svn: 338189
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CUDA 8.0 E.3.9.4 says: Within the body of a __device__ or __global__
function, only __shared__ variables or variables without any device
memory qualifiers may be declared with static storage class.
It is unclear how a function-scope non-const static variable
without device memory qualifier is implemented, therefore only static
const variable without device memory qualifier is allowed, which
can be emitted as a global variable in constant address space.
Currently clang only allows function-scope static variable with
__shared__ qualifier.
This patch also allows function-scope static const variable without
device memory qualifier and emits it as a global variable in constant
address space.
Differential Revision: https://reviews.llvm.org/D49931
llvm-svn: 338188
|
|
|
|
|
|
| |
This should fix some bot failures introduced by r338165.
llvm-svn: 338186
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we just canonicalized the type, but this lead to crashes with
parameter types that referred to ParmVarDecls of the constructor. There may be
more cases that this TreeTransform needs to handle though, such as a constructor
parameter type referring to a member in an unevaluated context. Canonicalization
doesn't address these cases either though, so we can address them as-needed in
follow-up commits.
rdar://41330135
Differential revision: https://reviews.llvm.org/D49439
llvm-svn: 338165
|
|
|
|
|
|
|
|
|
| |
in some member function calls.
Specifically, when calling a conversion function, we would fail to
create the AST node representing materialization of the class object.
llvm-svn: 338135
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As discussed in IRC with @rsmith, it is slightly not good to keep that in the `CastExpr` itself:
Given the explicit cast, which is represented in AST as an `ExplicitCastExpr` + `ImplicitCastExpr`'s,
only the `ImplicitCastExpr`'s will be marked as `PartOfExplicitCast`, but not the `ExplicitCastExpr` itself.
Thus, it is only ever `true` for `ImplicitCastExpr`'s, so we don't need to write/read/dump it for `ExplicitCastExpr`'s.
We don't need to worry that we write the `PartOfExplicitCast` in PCH after `CastExpr::path_iterator`,
since the `ExprImplicitCastAbbrev` is only used when the `NumBaseSpecs == 0`, i.e. there is no 'path'.
Reviewers: rsmith, rjmccall, erichkeane, aaron.ballman
Reviewed By: rsmith, erichkeane
Subscribers: vsk, cfe-commits, rsmith
Tags: #clang
Differential Revision: https://reviews.llvm.org/D49838
llvm-svn: 338108
|
|
|
|
|
|
|
|
|
|
| |
Only apply this exception on a type that we're able to check.
rdar://41903969
Differential revision: https://reviews.llvm.org/D49868
llvm-svn: 338089
|
|
|
|
|
|
|
|
|
|
| |
Clang already has L__FUNCTION__ as a workaround for dealing with
pre-processor code that expects to be able to do L##__FUNCTION__ in a
macro. This patch implements the same logic for __FUNCSIG__.
Fixes PR38295.
llvm-svn: 338083
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Microsoft's C++ object model for ARM64 is the same as that for X86_64.
For example, small structs with non-trivial copy constructors or virtual
function tables are passed indirectly. Currently, they are passed in registers
when compiled with clang.
Reviewers: rnk, mstorsjo, TomTan, haripul, javed.absar
Reviewed By: rnk, mstorsjo
Subscribers: kristof.beyls, chrib, llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D49770
llvm-svn: 338076
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check each case value in turn while parsing it, performing the
conversion to the switch type within the context of the expression
itself. This will become necessary in order to properly handle cleanups
for temporaries created as part of the case label (in an upcoming
patch). For now it's just good hygiene.
This necessitates moving the checking for the switch condition itself to
earlier, so that the destination type is available when checking the
case labels.
As a nice side-effect, we get slightly improved diagnostic quality and
error recovery by separating the case expression checking from the case
statement checking and from tracking whether there are discarded case
labels.
llvm-svn: 338056
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to the result type of a message send if the result type cannot have a
nullability specifier.
Previously, clang would print the following message when the code in
nullability.m was compiled:
"incompatible integer to pointer conversion initializing 'int *' with
an expression of type 'int _Nullable'"
This is wrong as 'int' isn't supposed to have any nullability
specifiers.
rdar://problem/40830514
llvm-svn: 338048
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Clang supports the GNU style ``__attribute__((interrupt))`` attribute on RISCV targets.
Permissible values for this parameter are user, supervisor, and machine.
If there is no parameter, then it defaults to machine.
Reference: https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Function-Attributes.html
Based on initial patch by Zhaoshi Zheng.
Reviewers: asb, aaron.ballman
Reviewed By: asb, aaron.ballman
Subscribers: rkruppe, the_o, aaron.ballman, MartinMosbeck, brucehoult, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, rogfer01, cfe-commits
Differential Revision: https://reviews.llvm.org/D48412
llvm-svn: 338045
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Continuing off of:
https://reviews.llvm.org/D38382
Fixes:
https://bugs.llvm.org/show_bug.cgi?id=12176
Reviewers: srhines, pirama, vsk
Reviewed By: vsk
Subscribers: cfe-commits, vsk, maitesin
Differential Revision: https://reviews.llvm.org/D49760
llvm-svn: 337944
|
|
|
|
|
|
|
| |
Fixed the source locations of the conditional op so that they don'r
crash coverage pass.
llvm-svn: 337928
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As discussed in [[ https://bugs.llvm.org/show_bug.cgi?id=38166 | PR38166 ]], we need to be able to distinqush whether the cast
we are visiting is actually a cast, or part of an `ExplicitCast`.
There are at least four ways to get there:
1. Introduce a new `CastKind`, and use it instead of `IntegralCast` if we are in `ExplicitCast`.
Would work, but does not scale - what if we will need more of these cast kinds?
2. Introduce a flag in `CastExprBits`, whether this cast is part of `ExplicitCast` or not.
Would work, but it isn't immediately clear where it needs to be set.
2. Fix `ScalarExprEmitter::VisitCastExpr()` to visit these `NoOp` casts.
As pointed out by @rsmith, CodeGenFunction::EmitMaterializeTemporaryExpr calls
skipRValueSubobjectAdjustments, which steps over the CK_NoOp cast`,
which explains why we currently don't visit those.
This is probably impossible, as @efriedma points out, that is intentional as per `[class.temporary]` in the standard
3. And the simplest one, just record which NoOp casts we skip.
It just kinda works as-is afterwards.
But, the approach with a flag is the least intrusive one, and is probably the best one overall.
Reviewers: rsmith, rjmccall, majnemer, efriedma
Reviewed By: rsmith
Subscribers: cfe-commits, aaron.ballman, vsk, llvm-commits, rsmith
Differential Revision: https://reviews.llvm.org/D49508
llvm-svn: 337815
|
|
|
|
|
|
|
| |
Looks like MTE was previously used for its SourceLoc, but we're now
using a seperate SourceLocation here.
llvm-svn: 337796
|
|
|
|
|
|
| |
non-lifetime-extended temporary object.
llvm-svn: 337790
|
|
|
|
| |
llvm-svn: 337767
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang would crash when instantiating a BlockDecl that appeared in a
default-member-initializer of a class template. Fix this by deferring the
instantiation until we instantate the BlockExpr.
rdar://41200624
Differential revision: https://reviews.llvm.org/D49688
llvm-svn: 337766
|
|
|
|
|
|
|
|
|
| |
expressions.
CodeGen can't cope with that yet. Instead, produce a "not supported"
warning for now and don't extend lifetime.
llvm-svn: 337744
|