| Age | Commit message (Collapse) | Author |
|---|
|
Summary: This patch adds support to the clang-c API for identifying ObjCObjects in CXTypes, enumerating type args and protocols on ObjCObjectTypes, and retrieving the base type of ObjCObjectTypes. Currently only ObjCInterfaceTypes are exposed, which do not have type args or protocols.
Reviewers: yvvan, jbcoe
Reviewed By: yvvan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49063
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338804 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338800 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We can't read a deduced return type until we are sure that the types referred
to by it are not in the middle of being loaded. So defer all reading of such
deduced return types until the end of the recursive deserialization step.
Also, when we load a function type that has a deduced return type, update all
other redeclarations of the function to have that deduced return type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338798 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Add support for atomic.wait / atomic.wake builtins based on the Wasm
thread proposal.
Reviewers: dschuff
Subscribers: sbc100, jgravelle-google, sunfish, cfe-commits
Differential Revision: https://reviews.llvm.org/D49396
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338771 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338754 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D50108
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338753 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338707 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338675 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338641 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
OMPDeclareReductionDecl into DeclContext
This patch follows https://reviews.llvm.org/D49729
and https://reviews.llvm.org/D49732, and is
followed by https://reviews.llvm.org/D49734.
Move the bits from BlockDecl, LinkageSpecDecl and
OMPDeclareReductionDecl into DeclContext.
Differential Revision: https://reviews.llvm.org/D49733
Patch By: bricci
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338639 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
DeclContext
This patch follows https://reviews.llvm.org/D49729
and is followed by https://reviews.llvm.org/D49733
and https://reviews.llvm.org/D49734.
Move the bits from FunctionDecl and CXXConstructorDecl
into DeclContext.
Differential Revision: https://reviews.llvm.org/D49732
Patch By: bricci
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338636 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
DeclContext
DeclContext has a little less than 8 bytes free due to the alignment
requirements on 64 bits archs. This set of patches moves the
bit-fields from classes deriving from DeclContext into DeclContext.
On 32 bits archs this increases the size of DeclContext by 4 bytes
but this is balanced by an equal or larger reduction in the size
of the classes deriving from it.
On 64 bits archs the size of DeclContext stays the same but
most of the classes deriving from it shrink by 8/16 bytes.
(-print-stats diff here https://reviews.llvm.org/D49728)
When doing an -fsyntax-only on all of Boost this result
in a 3.6% reduction in the size of all Decls and
a 1% reduction in the run time due to the lower cache
miss rate.
For now CXXRecordDecl is not touched but there is
an easy 6 (if I count correctly) bytes gain available there
by moving some bits from DefinitionData into the free
space of DeclContext. This will be the subject of another patch.
This patch sequence also enable the possibility of refactoring
FunctionDecl: To save space some bits from classes deriving from
FunctionDecl were moved to FunctionDecl. This resulted in a
lot of stuff in FunctionDecl which do not belong logically to it.
After this set of patches however it is just a simple matter of
adding a SomethingDeclBitfields in DeclContext and moving the
bits to it from FunctionDecl.
This first patch introduces the anonymous union in DeclContext
and all the *DeclBitfields classes holding the bit-fields, and moves
the bits from TagDecl, EnumDecl and RecordDecl into DeclContext.
This patch is followed by https://reviews.llvm.org/D49732,
https://reviews.llvm.org/D49733 and https://reviews.llvm.org/D49734.
Differential Revision: https://reviews.llvm.org/D49729
Patch By: bricci
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338630 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
__builtin_memcpy and __builtin_memmove (in non-type-punning cases)."
It caused asserts during Chromium builds, see reply on the cfe-commits thread.
> This is intended to permit libc++ to make std::copy etc constexpr
> without sacrificing the optimization that uses memcpy on
> trivially-copyable types.
>
> __builtin_strcpy and __builtin_wcscpy are not handled by this change.
> They'd be straightforward to add, but we haven't encountered a need for
> them just yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338602 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338566 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338502 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
rC337815 / D49508 had to cannibalize one bit of `CastExprBitfields::BasePathSize` in order to squeeze `PartOfExplicitCast` boolean.
That reduced the maximal value of `PartOfExplicitCast` from 9 bits (~512) down to 8 bits (~256).
Apparently, that mattered. Too bad there weren't any tests.
It caused [[ https://bugs.llvm.org/show_bug.cgi?id=38356 | PR38356 ]].
So we need to increase `PartOfExplicitCast` back at least to 9 bits, or a bit more.
For obvious reasons, we can't do that in `CastExprBitfields` - that would blow up the size of every `Expr`.
So we need to either just add a variable into the `CastExpr` (as done here),
or use `llvm::TrailingObjects`. The latter does not seem to be straight-forward.
Perhaps, that needs to be done not for the `CastExpr` itself, but for all of it's `final` children.
Reviewers: rjmccall, rsmith, erichkeane
Reviewed By: rjmccall
Subscribers: bricci, hans, cfe-commits, waddlesplash
Differential Revision: https://reviews.llvm.org/D50050
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338489 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Newly added methods allow reasoning about the stack frame of the call (as
opposed to the stack frame on which the call was made, which was always
available) - obtain the stack frame context, obtain parameter regions - even if
the call is not going to be (or was not) inlined, i.e. even if the analysis
has never actually entered the stack frame.
Differential Revision: https://reviews.llvm.org/D49715
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338474 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D50011
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338471 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
warnings.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338467 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338464 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
__builtin_memmove (in non-type-punning cases).
This is intended to permit libc++ to make std::copy etc constexpr
without sacrificing the optimization that uses memcpy on
trivially-copyable types.
__builtin_strcpy and __builtin_wcscpy are not handled by this change.
They'd be straightforward to add, but we haven't encountered a need for
them just yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338455 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is a refactoring patch; no functional change intended.
The common part of ConstructionContextLayer and ConstructedObjectKey is
factored out into a new structure, ConstructionContextItem.
Various sub-kinds of ConstructionContextItem are enumerated in order to
provide richer information about construction contexts.
Differential Revision: https://reviews.llvm.org/D49210.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338439 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
In r330377 and r338425 we have already identified what constitutes function
argument constructors and added stubs in order to prevent confusing them
with other temporary object constructors.
Now we implement a ConstructionContext sub-class to carry all the necessary
information about the construction site, namely call expression and argument
index.
On the analyzer side, the patch interacts with the recently implemented
pre-C++17 copy elision support in an interesting manner. If on the CFG side we
didn't find a construction context for the elidable constructor, we build
the CFG as if the elidable constructor is not elided, and the non-elided
constructor within it is a simple temporary. But the same problem may occur
in the analyzer: if the elidable constructor has a construction context but
the analyzer doesn't implement such context yet, the analyzer should also
try to skip copy elision and still inline the non-elided temporary constructor.
This was implemented by adding a "roll back" mechanism: when elision fails,
roll back the changes and proceed as if it's a simple temporary. The approach
is wonky, but i'm fine with that as long as it's merely a defensive mechanism
that should eventually go away once all construction contexts become supported.
Differential Revision: https://reviews.llvm.org/D48681.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338436 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D49058
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338433 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Like any normal funciton, Objective-C message can return a C++ object
in Objective-C++. Such object would require a construction context.
This patch, therefore, is an extension of r327343 onto Objective-C++.
Differential Revision: https://reviews.llvm.org/D48608
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338426 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Reviewers: rnk, mstorsjo, ssijaric, haripul, TomTan
Reviewed By: rnk
Subscribers: kristof.beyls, chrib, cfe-commits
Differential Revision: https://reviews.llvm.org/D50029
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338405 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Any of these template argument kinds can be represented with an expression, so
accept them in this constructor.
Patch by Balaji Iyer!
rdar://41459965
Differential revision: https://reviews.llvm.org/D49766
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338338 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
state to analysis manager
Differential Revision: https://reviews.llvm.org/D49772
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338315 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338301 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338291 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
C and C++ are interesting languages. They are statically typed, but weakly.
The implicit conversions are allowed. This is nice, allows to write code
while balancing between getting drowned in everything being convertible,
and nothing being convertible. As usual, this comes with a price:
```
unsigned char store = 0;
bool consume(unsigned int val);
void test(unsigned long val) {
if (consume(val)) {
// the 'val' is `unsigned long`, but `consume()` takes `unsigned int`.
// If their bit widths are different on this platform, the implicit
// truncation happens. And if that `unsigned long` had a value bigger
// than UINT_MAX, then you may or may not have a bug.
// Similarly, integer addition happens on `int`s, so `store` will
// be promoted to an `int`, the sum calculated (0+768=768),
// and the result demoted to `unsigned char`, and stored to `store`.
// In this case, the `store` will still be 0. Again, not always intended.
store = store + 768; // before addition, 'store' was promoted to int.
}
// But yes, sometimes this is intentional.
// You can either make the conversion explicit
(void)consume((unsigned int)val);
// or mask the value so no bits will be *implicitly* lost.
(void)consume((~((unsigned int)0)) & val);
}
```
Yes, there is a `-Wconversion`` diagnostic group, but first, it is kinda
noisy, since it warns on everything (unlike sanitizers, warning on an
actual issues), and second, there are cases where it does **not** warn.
So a Sanitizer is needed. I don't have any motivational numbers, but i know
i had this kind of problem 10-20 times, and it was never easy to track down.
The logic to detect whether an truncation has happened is pretty simple
if you think about it - https://godbolt.org/g/NEzXbb - basically, just
extend (using the new, not original!, signedness) the 'truncated' value
back to it's original width, and equality-compare it with the original value.
The most non-trivial thing here is the logic to detect whether this
`ImplicitCastExpr` AST node is **actually** an implicit conversion, //or//
part of an explicit cast. Because the explicit casts are modeled as an outer
`ExplicitCastExpr` with some `ImplicitCastExpr`'s as **direct** children.
https://godbolt.org/g/eE1GkJ
Nowadays, we can just use the new `part_of_explicit_cast` flag, which is set
on all the implicitly-added `ImplicitCastExpr`'s of an `ExplicitCastExpr`.
So if that flag is **not** set, then it is an actual implicit conversion.
As you may have noted, this isn't just named `-fsanitize=implicit-integer-truncation`.
There are potentially some more implicit conversions to be warned about.
Namely, implicit conversions that result in sign change; implicit conversion
between different floating point types, or between fp and an integer,
when again, that conversion is lossy.
One thing i know isn't handled is bitfields.
This is a clang part.
The compiler-rt part is D48959.
Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]].
Partially fixes [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]].
Fixes https://github.com/google/sanitizers/issues/940. (other than sign-changing implicit conversions)
Reviewers: rjmccall, rsmith, samsonov, pcc, vsk, eugenis, efriedma, kcc, erichkeane
Reviewed By: rsmith, vsk, erichkeane
Subscribers: erichkeane, klimek, #sanitizers, aaron.ballman, RKSimon, dtzWill, filcab, danielaustin, ygribov, dvyukov, milianw, mclow.lists, cfe-commits, regehr
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D48958
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338288 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
All use cases of DeclRegion actually have ValueDecl there,
and getting the name from declaration comes in very handy.
Differential Revision: https://reviews.llvm.org/D49998
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338286 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The "Procedure Call Procedure Call Standard for the ARM® Architecture"
(https://static.docs.arm.com/ihi0042/f/IHI0042F_aapcs.pdf), specifies that
composite types are passed according to their "natural alignment", i.e. the
alignment before alignment adjustment on the entire composite is applied.
The same applies for AArch64 ABI.
Clang, however, used the adjusted alignment.
GCC already implements the ABI correctly. With this patch Clang becomes
compatible with GCC and passes such arguments in accordance with AAPCS.
Differential Revision: https://reviews.llvm.org/D46013
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338279 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338238 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-escaping parameter but the implementation's method takes an escaping
parameter.
rdar://problem/39548196
Differential Revision: https://reviews.llvm.org/D49119
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338189 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338188 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Differential Revision: https://reviews.llvm.org/D49951
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338187 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Some functions/classes have renamed while the comments still use the old names. Delete them per coding style.
Also some whitespace cleanup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338183 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This patch allows the parsing of a postfix expression involving a fold expression, which is legal as a fold-expression is a primary-expression.
See also https://llvm.org/pr38282
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49848
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338170 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Some targets support only default set of the debug options and do not
support additional debug options, like NVPTX target. Patch introduced
virtual function supportsDebugInfoOptions() that can be overloaded
by the toolchain, checks if the target supports some debug
options and emits warning when an unsupported debug option is
found.
Reviewers: echristo
Subscribers: aprantl, JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D49148
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338155 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338141 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
declaration
ObjCIvarExpr is *not* a subclass of MemberExpr, and a separate matcher
is required to support it.
Adding a hasDeclaration support as well, as it's not very useful without
it.
Differential Revision: https://reviews.llvm.org/D49701
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338140 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
declaration.
ObjCIvarExpr is *not* a subclass of MemberExpr, and a separate matcher
is required to support it.
Adding a hasDeclaration support as well, as it's not very useful without
it.
Differential Revision: https://reviews.llvm.org/D49701
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338137 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338108 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338083 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338076 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338056 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
Refer the MS ARM64 ABI Convention for the behavior for struct returns:
https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions#return-values
Reviewers: mstorsjo, compnerd, rnk, javed.absar, yinma, efriedma
Reviewed By: rnk, efriedma
Subscribers: haripul, TomTan, yinma, efriedma, kristof.beyls, chrib, llvm-commits
Differential Revision: https://reviews.llvm.org/D49464
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338050 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338045 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Summary:
This patch replaces the current method of getting an `APSInt` from Z3's model by calling generic API method `getBitvector` instead of `Z3_get_numeral_uint64`.
By calling `getBitvector`, there's no need to handle bitvectors with bit width == 128 separately.
And, as a bonus, clang now compiles correctly with Z3 4.7.1.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49818
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338020 91177308-0d34-0410-b5e6-96231b3b80d8
|
