Currently an address_space is stored in a qualifier. This makes any type
declared with an address_space attribute in the form
`__attribute__((address_space(1))) int 1;` be wrapped in an AttributedType.
This is for a later patch where if `address_space` is declared in a macro,
any diagnostics that would normally print the address space will instead dump
the macro name. This will require saving any macro information in the
AttributedType.
Differential Revision: https://reviews.llvm.org/D51229
llvm-svn: 340765
This commit adds the flag -fno-c++-static-destructors and the attributes
[[clang::no_destroy]] and [[clang::always_destroy]]. no_destroy specifies that a
specific static or thread duration variable shouldn't have it's destructor
registered, and is the default in -fno-c++-static-destructors mode.
always_destroy is the opposite, and is the default in -fc++-static-destructors
mode.
A variable whose destructor is disabled (either because of
-fno-c++-static-destructors or [[clang::no_destroy]]) doesn't count as a use of
the destructor, so we don't do any access checking or mark it referenced. We
also don't emit -Wexit-time-destructors for these variables.
rdar://21734598
Differential revision: https://reviews.llvm.org/D50994
llvm-svn: 340306
Summary:
r306722 introduced a new note called note_silence_unligned_allocation_unavailable
where I believe what was meant is note_silence_aligned_allocation_unavailable.
Reviewers: ahatanak
Subscribers: dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D51043
llvm-svn: 340288
Specifically, AttributedType now tracks a regular attr::Kind rather than
having its own parallel Kind enumeration, and AttributedTypeLoc now
holds an Attr* instead of holding an ad-hoc collection of Attr fields.
Differential Revision: https://reviews.llvm.org/D50526
This reinstates r339623, reverted in r339638, with a fix to not fail
template instantiation if we instantiate a QualType with no associated
type source information and we encounter an AttributedType.
llvm-svn: 340215
expression
Clang emits invalid protocol metadata when a @protocol expression is used with a
forward-declared protocol. The protocol metadata is missing protocol conformance
list of the protocol since we don't have access to the definition of it in the
compiled translation unit. The linker then might end up picking the invalid
metadata when linking which will lead to incorrect runtime protocol conformance
checks.
This commit makes sure that Clang fails to compile code that uses a @protocol
expression with a forward-declared protocol. This ensures that Clang does not
emit invalid protocol metadata. I added an extra assert in CodeGen to ensure
that this kind of issue won't happen in other places.
rdar://32787811
Differential Revision: https://reviews.llvm.org/D49462
llvm-svn: 340102
Summary:
There isn't anything inherently wrong with returning a label from a
statement expression. In practice, the Linux kernel uses this pattern to
materialize PCs.
Fixes PR38569
Reviewers: niravd, rsmith, nickdesaulniers
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50805
llvm-svn: 340101
information is then discarded with a warning to the user that we don't
support it.
This patch gets us one step closer by getting the info down into the
AST in most cases.
Reviewed by: rsmith
Differential Revision: https://reviews.llvm.org/D49865
llvm-svn: 339693
This breaks compiling atlwin.h in Chromium. I'm sure the code is invalid
in some way, but we put a lot of work into accepting it, and I'm sure
rejecting it was not an intended consequence of this refactoring. :)
llvm-svn: 339638
Specifically, AttributedType now tracks a regular attr::Kind rather than
having its own parallel Kind enumeration, and AttributedTypeLoc now
holds an Attr* instead of holding an ad-hoc collection of Attr fields.
Differential Revision: https://reviews.llvm.org/D50526
llvm-svn: 339623
Multiversioned member functions inside of a template type were
not properly being emitted. The solution to this is to simply
ensure that their bodies are correctly evaluated/assigned during
template instantiation.
llvm-svn: 339597
Summary:
This is for use by clang-tidy's bugprone-use-after-move check -- see
corresponding clang-tidy patch at https://reviews.llvm.org/D49910.
Reviewers: aaron.ballman, rsmith
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49911
llvm-svn: 339569
Clang generates copy and dispose helper functions for each block literal
on the stack. Often these functions are equivalent for different blocks.
This commit makes changes to merge equivalent copy and dispose helper
functions and reduce code size.
To enable merging equivalent copy/dispose functions, the captured object
infomation is encoded into the helper function name. This allows IRGen
to check whether an equivalent helper function has already been emitted
and reuse the function instead of generating a new helper function
whenever a block is defined. In addition, the helper functions are
marked as linkonce_odr to enable merging helper functions that have the
same name across translation units and marked as unnamed_addr to enable
the linker's deduplication pass to merge functions that have different
names but the same content.
rdar://problem/42640608
Differential Revision: https://reviews.llvm.org/D50152
llvm-svn: 339438
Summary:
Case case of the switch statement here makes the same call, but it is
already done at the start of the function.
Reviewers: rsmith, dblaikie
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50409
llvm-svn: 339402
ParsedAttr is using a hand-rolled trailing-objects
implementation that gets cleaned up quite a bit by
just using llvm::TrailingObjects. This is a large
TrailingObjects list, but most things are length '0'.
Differential Revision: https://reviews.llvm.org/D50531
llvm-svn: 339380
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
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
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
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
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
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
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
Leonard Chan