| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The very idea of construction context implies that first the object is
constructed, and then later, in a separate moment of time, the constructed
object goes into scope, i.e. becomes "live".
Most construction contexts require path-sensitive tracking of the constructed
object region in order to compute the outer expressions accordingly before
the object becomes live.
Semantics of simple variable construction contexts don't immediately require
that such tracking happens in path-sensitive manner, but shortcomings of the
analyzer force us to track it path-sensitively as well. Namely, whether
construction context was available at all during construction is a
path-sensitive information. Additionally, path-sensitive tracking takes care of
our liveness problems that kick in as the temporal gap between construction and
going-into-scope becomes larger (eg., due to copy elision).
Differential Revision: https://reviews.llvm.org/D47305
llvm-svn: 334681
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When analyzing C++ code, a common operation in the analyzer is to discover
target region for object construction by looking at CFG metadata ("construction
contexts"), and then track the region path-sensitively until object construction
is resolved, where the amount of information, again, depends on construction
context.
Scan construction context only once for both purposes.
Differential Revision: https://reviews.llvm.org/D47304
llvm-svn: 334678
|
| |
|
|
| |
llvm-svn: 334677
|
| |
|
|
| |
llvm-svn: 334674
|
| |
|
|
| |
llvm-svn: 334673
|
| |
|
|
| |
llvm-svn: 334671
|
| |
|
|
|
|
| |
These were true at one point but haven't been true for a long time.
llvm-svn: 334669
|
| |
|
|
|
|
|
| |
No reason to have the 'bool' as an intermediary value,
simply use the fact that curley braces enforce eval order.
llvm-svn: 334652
|
| |
|
|
|
|
|
|
|
| |
As requested here:https://bugs.llvm.org/show_bug.cgi?id=37633
permit the __builtin_*_overflow builtins in constexpr functions.
Differential Revision: https://reviews.llvm.org/D48040
llvm-svn: 334650
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: These intrinsics result in hint instructions. They are provided here for MSVC ARM64 compatibility.
Reviewers: mstorsjo, compnerd, javed.absar
Reviewed By: mstorsjo
Subscribers: kristof.beyls, chrib, cfe-commits
Differential Revision: https://reviews.llvm.org/D48132
llvm-svn: 334639
|
| |
|
|
|
|
|
|
|
| |
rdar://39593879
https://bugs.llvm.org/show_bug.cgi?id=37142
Differential Revision: https://reviews.llvm.org/D48139
llvm-svn: 334636
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://bugs.llvm.org/show_bug.cgi?id=37778
...shows a miscompile resulting from marking nan builtins as 'const'.
The nan libcalls/builtins take a pointer argument:
http://www.cplusplus.com/reference/cmath/nan-function/
...and the chars dereferenced by that arg are used to fill in the NaN constant payload bits.
"const" means that the pointer argument isn't dereferenced. That's translated to "readnone" in LLVM.
"pure" means that the pointer argument may be dereferenced. That's translated to "readonly" in LLVM.
This change prevents the IR optimizer from killing the lead-up to the nan call here:
double a() {
char buf[4];
buf[0] = buf[1] = buf[2] = '9';
buf[3] = '\0';
return __builtin_nan(buf);
}
...the optimizer isn't currently able to simplify this to a constant as we might hope,
but this patch should solve the miscompile.
Differential Revision: https://reviews.llvm.org/D48134
llvm-svn: 334628
|
| |
|
|
|
|
| |
Just use field initializers that don't suffer from this problem
llvm-svn: 334619
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Diasble the use of the type __float128 for PPC machines older
than Power9.
The use of -mfloat128 for PPC machine older than Power9 will result
in an error.
Differential Revision: https://reviews.llvm.org/D48088
llvm-svn: 334613
|
| |
|
|
|
|
| |
Fixes a build bot breakage caused by r334593.
llvm-svn: 334612
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In many cases we can't devirtualize
because definition of vtable is not present. Most of the
time it is caused by inline virtual function not beeing
emitted. Forcing emitting of vtable adds a reference of these
inline virtual functions.
Note that GCC was always doing it.
Reviewers: rjmccall, rsmith, amharc, kuhar
Subscribers: llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D47108
Co-authored-by: Krzysztof Pszeniczny <krzysztof.pszeniczny@gmail.com>
llvm-svn: 334600
|
| |
|
|
|
|
|
|
|
|
| |
Enable these builtins to be called across a lambda
boundary with captureless const/constexpr, as brought up by
Eli here: https://reviews.llvm.org/D48040
Differential Revision: https://reviews.llvm.org/D48053
llvm-svn: 334597
|
| |
|
|
|
|
|
|
| |
Follow up for D41537 - libclang part.
Differential Revision: https://reviews.llvm.org/D46862
llvm-svn: 334593
|
| |
|
|
|
|
| |
builtins. Use select builtins instead.
llvm-svn: 334577
|
| |
|
|
| |
llvm-svn: 334574
|
| |
|
|
| |
llvm-svn: 334573
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
argument, use the context in which it is used for checking its
accessibility.
This fixes PR32898.
rdar://problem/33737747
Differential Revision: https://reviews.llvm.org/D36918
llvm-svn: 334569
|
| |
|
|
| |
llvm-svn: 334565
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There are HIP applications e.g. Tensorflow 1.3 using amdgpu kernel attributes, however
currently they are only allowed on OpenCL kernel functions.
This patch will allow amdgpu kernel attributes to be applied to CUDA/HIP __global__
functions.
Differential Revision: https://reviews.llvm.org/D47958
llvm-svn: 334561
|
| |
|
|
|
|
|
|
|
|
| |
arguments than it has parameters
rdar://40335545
Differential Revision: https://reviews.llvm.org/D48107
llvm-svn: 334560
|
| |
|
|
|
|
|
|
|
|
| |
Loop widening can invalidate a reference. If the analyzer attempts to visit the
destructor to a non-existent reference, it will crash. This patch ensures that
the reference is preserved.
https://reviews.llvm.org/D47044
llvm-svn: 334554
|
| |
|
|
|
|
| |
This was changed in r334477.
llvm-svn: 334550
|
| |
|
|
|
|
|
|
|
|
|
| |
removeInvalidation is a very problematic API, as it makes suppression
order-dependent.
Moreover, it was used only once, and could be rewritten in a much
cleaner way.
Differential Revision: https://reviews.llvm.org/D48045
llvm-svn: 334542
|
| |
|
|
|
|
|
|
|
|
| |
BugReporter.cpp is already severely overloaded, and those dump methods
are on PathDiagnostics and should belong in the corresponding
implementation file.
Differential Revision: https://reviews.llvm.org/D48035
llvm-svn: 334541
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getEndPath is a problematic API, because it's not clear when it's called
(hint: not always at the end of the path), it crashes at runtime with
more than one non-nullptr returning implementation, and diagnostics
internal depend on it being called at some exact place.
However, most visitors don't actually need that: all they want is a
function consistently called after all nodes are traversed, to perform
finalization and to decide whether invalidation is needed.
Differential Revision: https://reviews.llvm.org/D48042
llvm-svn: 334540
|
| |
|
|
|
|
| |
fixed in r314838
llvm-svn: 334539
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Register x20 is a callee-saved register which may be used for other
purposes in certain contexts, for example to hold special variables
within the kernel. This change adds support for reserving this register
both to frontend and backend to make this register usable for these
purposes.
Differential Revision: https://reviews.llvm.org/D46552
llvm-svn: 334531
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The added test case was currently crashing with an assertion:
```
krasimir@krasimir> cat test.cc ~
// How to run:
// bbbbb run \
// rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr \
// <log_file> -- --output_directory="<output_directory>"
krasimir@krasimir> ~/work/llvm-build/bin/clang-format test.cc ~
clang-format: /usr/local/google/home/krasimir/work/llvm/tools/clang/lib/Format/WhitespaceManager.cpp:117: void clang::format::WhitespaceManager::calculateLineBreakInformation(): Assertion `PreviousOriginalWhitespaceEndOffset <= OriginalWhitespaceStartOffset' failed.
```
The root cause was that BreakableToken was not considering the case of a reflow between an unescaped newline in a line comment.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48089
llvm-svn: 334527
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D47808
llvm-svn: 334526
|
| |
|
|
|
|
|
|
|
|
| |
Once we removed AlternateExtensive, I've looked closer into the
difference between Minimal and Extensive, and turns out, the difference
was not that large.
Differential Revision: https://reviews.llvm.org/D47756
llvm-svn: 334525
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename AlternateExtensive to Extensive.
In 2013, five years ago, we have switched to AlternateExtensive
diagnostics by default, and Extensive was available under unused,
undocumented flag.
This change remove the flag, renames the Alternate
diagnostic to Extensive (as it's no longer Alternate), and ports the
test.
Differential Revision: https://reviews.llvm.org/D47670
llvm-svn: 334524
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies some code which had StringRefs to begin with, and
makes other code more complicated which had const char* to begin
with.
In the end, I think this makes for a more idiomatic and platform
agnostic API. Not all platforms launch process with null terminated
c-string arrays for the environment pointer and argv, but the api
was designed that way because it allowed easy pass-through for
posix-based platforms. There's a little additional overhead now
since on posix based platforms we'll be takign StringRefs which
were constructed from null terminated strings and then copying
them to null terminate them again, but from a readability and
usability standpoint of the API user, I think this API signature
is strictly better.
llvm-svn: 334518
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently clang-format allows this for text protos:
```
submessage:
{ key: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' }
```
when it is under the column limit and when putting it all on one line exceeds the column limit.
This is not a very intuitive formatting, so I'd prefer having
```
submessage: {
key: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
}
```
instead, even if it takes one line more.
This patch prevents clang-format from inserting a break between `: {` and similar cases.
Reviewers: djasper, sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48063
llvm-svn: 334517
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported here (https://bugs.llvm.org/show_bug.cgi?id=19808)
and discovered independently when looking at plum-hall tests,
we incorrectly implemented over.ics.rank, which says "A conversion
that is not a conversion of a pointer, or pointer to member, to bool
is better than another conversion that is such a conversion.".
In the current Draft (N4750), this is phrased slightly differently in
paragraph 4.1: A conversion that does not convert a pointer, a pointer
to member, or std::nullptr_t to bool is better than one that does.
The comment on isPointerConversionToBool (the changed function)
also confirms that this is the case (note outdated reference):
isPointerConversionToBool - Determines whether this conversion is
a conversion of a pointer or pointer-to-member to bool. This is
used as part of the ranking of standard conversion sequences
(C++ 13.3.3.2p4).
However, despite this comment, it didn't check isMemberPointerType
on the 'FromType', presumably incorrectly assuming that 'isPointerType'
matched it. This patch fixes this by adding isMemberPointerType to
this function. Additionally, member function pointers are just
MemberPointerTypes that point to functions insted of data, so that
is fixed in this patch as well.
llvm-svn: 334503
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lit internal shell now"
Plus change run lines from
not env FOO=bar %clang
to
env FOO=bar not %clang
To not confuse the internal shell.
llvm-svn: 334494
|
| |
|
|
|
|
|
|
|
|
| |
lit internal shell now"
The tests fail on Windows bots, and for me locally.
> Enable crash recovery tests on Windows, globs work in the lit internal shell now
llvm-svn: 334493
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes the ranges for the vcvth family of FP16 intrinsics in the clang front end. Previously it was accepting incorrect ranges
-Changed builtin range checking in SemaChecking
-added tests SemaCheck changes - included in their own file since no similar one exists
-modified existing tests to reflect new ranges
Reviewers: SjoerdMeijer, javed.absar
Reviewed By: SjoerdMeijer
Subscribers: kristof.beyls, cfe-commits
Differential Revision: https://reviews.llvm.org/D47592
llvm-svn: 334489
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
rL334399 put VersionTuple in the llvm namespace, but this header still assumes it's in the clang namespace.
This leads to compilation failures with enabled modules when building Clang.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48062
llvm-svn: 334471
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently clang set kernel calling convention for CUDA/HIP after
arranging function, which causes incorrect kernel function type since
it depends on calling convention.
This patch moves setting kernel convention before arranging
function.
Differential Revision: https://reviews.llvm.org/D47733
llvm-svn: 334457
|
| |
|
|
|
|
|
|
|
|
| |
We want to build the second stage compiler with libc++ and compiler-rt,
also include builtins and runtimes into extra bootstrap components to
ensure these get built.
Differential Revision: https://reviews.llvm.org/D47356
llvm-svn: 334445
|
| |
|
|
|
|
|
|
|
| |
This allows adding additional bootstrap dependencies to the bootstrap
compiler that may be needed by later stages.
Differential Revision: https://reviews.llvm.org/D47355
llvm-svn: 334437
|
| |
|
|
|
|
| |
This was broken when the builtin was added in r334249.
llvm-svn: 334422
|
| |
|
|
|
|
|
|
|
|
|
|
| |
conditionals.
Changed the function signature and removed conditionals from loop body.
Patch By: emmettneyman
Differential Revision: https://reviews.llvm.org/D47964
llvm-svn: 334421
|
| |
|
|
| |
llvm-svn: 334418
|
| |
|
|
|
|
|
|
| |
This should reduce the binary size penalty of ASan on Windows. After
r334313, ASan will add red zones to globals in comdats, so we will still
find OOB accesses to string literals.
llvm-svn: 334417
|