| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 338630
|
|
|
|
|
|
|
|
|
|
| |
Fix %hmaptool path to refer to clang_tools_dir instead of
llvm_tools_dir, in order to fix standalone builds. The tool is built
as part of clang, so it won't be found in installed LLVM tools.
Differential Revision: https://reviews.llvm.org/D50156
llvm-svn: 338627
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Android's memory allocators also guarantee 8-byte alignment for 32-bit
architectures and 16-byte alignment for 64-bit.
Reviewers: rsmith
Subscribers: cfe-commits, srhines, enh
Differential Revision: https://reviews.llvm.org/D50112
llvm-svn: 338603
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__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.
llvm-svn: 338602
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Bug was caused due to comments at the start of scope. For a code like:
```
int func() { //
int b;
int c;
}
```
the comment at the first line gets IndentAndNestingLevel (1,1) whereas
the following declarations get only (0,1) which prevents them from insertion
of a new scope. So, I changed the AlignTokenSequence to look at previous
*non-comment* token when deciding whether to introduce a new scope into
stack or not.
Patch by Kadir Cetinkaya!
Reviewers: rsmith, djasper
Reviewed By: djasper
Subscribers: lebedev.ri, cfe-commits, klimek
Tags: #clang
Differential Revision: https://reviews.llvm.org/D43303
llvm-svn: 338578
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 338557
|
|
|
|
|
|
| |
implements useIntegratedAs() -> true
llvm-svn: 338553
|
|
|
|
| |
llvm-svn: 338552
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang-fuzzer/handle-llvm/handle_llvm.cpp.
Summary:
I don't have the whole list of GCC binaries available so I determined the exact
version where the warning disappeared via:
https://github.com/gcc-mirror/gcc/blob/gcc-4_9_0-release/gcc/cp/typeck.c#L6863
https://github.com/gcc-mirror/gcc/blob/gcc-4_8_5-release/gcc/cp/typeck.c#L6652
Reviewers: emmettneyman, erichkeane
Reviewed By: emmettneyman, erichkeane
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50056
llvm-svn: 338551
|
|
|
|
| |
llvm-svn: 338534
|
|
|
|
| |
llvm-svn: 338528
|
|
|
|
|
|
|
|
|
| |
This adds tests for Armv8.4-A, and also some v8.2 and v8.3 tests that were
missing.
Differential Revision: https://reviews.llvm.org/D50068
llvm-svn: 338525
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Adds 2 functions taking a text proto argument.
Reviewers: djasper, klimek
Reviewed By: djasper
Subscribers: acoomans, cfe-commits
Differential Revision: https://reviews.llvm.org/D50132
llvm-svn: 338524
|
|
|
|
| |
llvm-svn: 338520
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: acoomans, cfe-commits
Differential Revision: https://reviews.llvm.org/D50138
llvm-svn: 338519
|
|
|
|
| |
llvm-svn: 338510
|
|
|
|
| |
llvm-svn: 338508
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Clang emits error when implicit modules was relocated from the
first build directory. However this was biting our usecase where we copy
the contents of build directory to another directory in order to
distribute.
Differential Revision: https://reviews.llvm.org/D49852
llvm-svn: 338503
|
|
|
|
| |
llvm-svn: 338502
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 338489
|
|
|
|
|
|
|
|
|
|
|
| |
Tests added in r338294 implicitly assume that libgcc is the runtime library,
but that's not the case when the user configures Clang to use compiler-rt in
which case these tests will break. Explicitly request libgcc when invoking
clang in these tests to avoid that.
Differential Revision: https://reviews.llvm.org/D50123
llvm-svn: 338482
|
|
|
|
|
|
| |
See gcc.gnu.org/PR86769 for details of the bug.
llvm-svn: 338478
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 338474
|
|
|
|
| |
llvm-svn: 338473
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D50011
llvm-svn: 338471
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__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.
llvm-svn: 338455
|
|
|
|
|
|
|
|
| |
This change causes issues with distributed build systems, which may only
have compiler binaries without any runtime libraries. See discussion
about this on https://reviews.llvm.org/D15225.
llvm-svn: 338444
|
|
|
|
|
|
|
|
|
|
|
| |
Because of incomplete support for CXXDefaultArgExpr, we cannot yet commit to
asserting that the same destructor won't be elided twice.
Suppress the assertion failure for now. Proper support is still an open problem.
Differential Revision: https://reviews.llvm.org/D49213
llvm-svn: 338441
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 338439
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameters can have default arguments.
At least for function templates and class template partial
specializations, it's possible for a template parameter with a default
argument to be followed by a non-pack template parameter with no default
argument, and this case was not properly handled here.
Testcase by Steve O'Brien!
llvm-svn: 338438
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 338436
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D49058
llvm-svn: 338433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 338426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CFG now correctly identifies construction context for temporaries constructed
for the purpose of passing into a function as an argument.
Such context is still not fully implemented because the information it provides
is not rich enough: it doens't contain information about argument index.
It will be addresssed later.
This patch is an extension of r330377 to C++ construct-expressions and
Objective-C message expressions which aren't call-expressions but require
similar handling. C++ new-expressions with placement arguments still remain to
be handled.
Differential Revision: https://reviews.llvm.org/D49826
llvm-svn: 338425
|
|
|
|
|
|
|
|
| |
No functional change intended.
Differential Revision: https://reviews.llvm.org/D49826
llvm-svn: 338422
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fix is similar to r337769 and addresses a regression caused by r337167.
When an operation between a nonloc::LocAsInteger and a non-pointer symbol
is performed, the LocAsInteger-specific part of information is lost.
When the non-pointer symbol is collapsing into a constant, we cannot easily
re-evaluate the result, because we need to recover the missing
LocAsInteger-specific information (eg., integer type, or the very fact that
this pointer was at some point converted to an integer).
Add one more defensive check to prevent crashes on trying to simplify a
SymSymExpr with different Loc-ness of operands.
Differential Revision:
llvm-svn: 338420
|
|
|
|
|
|
|
| |
This configuration was (again) broken after r338385 because Clang
might be configured to always use libc++.
llvm-svn: 338414
|
|
|
|
|
|
|
|
| |
offload targets.
Changed the linkage of omp_offloading.img_start.<triple> and omp_offloading.img_end.<triple> symbols from external to external weak to allow dropping of some targets during linking.
llvm-svn: 338413
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: rnk, mstorsjo, ssijaric, haripul, TomTan
Reviewed By: rnk
Subscribers: kristof.beyls, chrib, cfe-commits
Differential Revision: https://reviews.llvm.org/D50029
llvm-svn: 338405
|
|
|
|
|
|
| |
No need to change the linkage, we can avoid the problem using special variable. That points to the original variable and, thus, prevent some of the optimizations that might break the compilation.
llvm-svn: 338399
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds a driver for the baremetal RISC-V target (i.e. riscv32-unknown-elf). For reference, D39963 added basic target info and added support for riscv32-linux-unknown-elf.
Patch by: asb (Alex Bradbury)
Reviewers: efriedma, phosek, apazos, espindola, mgrang
Reviewed By: mgrang
Subscribers: jrtc27, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, emaste, mgorny, arichardson, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, cfe-commits
Differential Revision: https://reviews.llvm.org/D46822
llvm-svn: 338385
|
|
|
|
|
|
|
|
| |
ConstructorInitializerAllOnOneLineOrOnePerLine more clear
PR38080 complained that the "OnePerLine" case wasn't previously shown.
llvm-svn: 338366
|
|
|
|
|
|
|
| |
This configuration was broken after r338294 because Clang might
be configured to always use libc++.
llvm-svn: 338360
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch improves support of PDB as an external layout source
in the next cases:
- Multiple non-virtual inheritance from packed base classes. When using
external layout, there's no need to align `NonVirtualSize` of a base class.
It may cause an overlapping when the next base classes will be layouted
(but there is a slightly different case in the test because I can't find
a way to specify a base offset);
- Support of nameless structs and unions. There is no info about nameless child
structs and unions in Microsoft cl-emitted PDBs. Instead all its fields
are just treated as outer structure's (union's) fields. This also causes
a fields overlapping, and makes it possible for unions to have fields located
at a non-zero offset.
Reviewers: rsmith, zturner, rnk, mstorsjo, majnemer
Reviewed By: rnk
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D49871
llvm-svn: 338353
|
|
|
|
|
|
|
|
|
|
|
| |
Fix "Invalid operator call kind" error (llvm_unreachable) in
DecodeOperatorCall when profiling a dependent co_await.
Patch by Victor Zverovich!
Differential Revision: https://reviews.llvm.org/D50002
llvm-svn: 338343
|