| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
| |
rdar://39593879
https://bugs.llvm.org/show_bug.cgi?id=37142
Differential Revision: https://reviews.llvm.org/D48139
llvm-svn: 334636
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
builtins. Use select builtins instead.
llvm-svn: 334577
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This was broken when the builtin was added in r334249.
llvm-svn: 334422
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
immediate range checking for BI__builtin_ia32_psrldqi128 and friends.
The limit was set to 1023 which only up to 127*8. It needs to be 2047 to allow 255*8.
llvm-svn: 334416
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
TypeScript uses the `!` token for strict property initialization
assertions, as in:
class X {
strictPropAsserted!: string;
}
Previously, clang-format would wrap between the `!` and the `:` for
overly long lines. This patch fixes that by generally preventing the
wrap in that location.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48030
llvm-svn: 334415
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This option replaces the BreakBeforeInheritanceComma option with an
enum, thus introducing a mode where the colon stays on the same line as
constructor declaration:
// When it fits on line:
class A : public B, public C {
...
};
// When it does not fit:
class A :
public B,
public C {
...
};
This matches the behavior of the `BreakConstructorInitializers` option,
introduced in https://reviews.llvm.org/D32479.
Reviewers: djasper, klimek
Reviewed By: djasper
Subscribers: mzeren-vmw, cfe-commits
Differential Revision: https://reviews.llvm.org/D43015
llvm-svn: 334408
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
submessage
Summary:
This patch updates clang-format text protos to put entries of a submessage into separate lines if the submessage contains at least two entries and contains at least one submessage entry.
For example, the entries here are kept on separate lines even if putting them on a single line would be under the column limit:
```
message: {
entry: 1
submessage: { key: value }
}
```
Messages containing a single submessage or several scalar entries can still be put on one line if they fit:
```
message { submessage { key: value } }
message { x: 1 y: 2 z: 3 }
```
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D46757
llvm-svn: 334401
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This kind of functionality is useful to other project apart from clang.
LLDB works with version numbers a lot, but it does not have a convenient
abstraction for this. Moving this class to a lower level library allows
it to be freely used within LLDB.
Since this class is used in a lot of places in clang, and it used to be
in the clang namespace, it seemed appropriate to add it to the list of
adopted classes in LLVM.h to avoid prefixing all uses with "llvm::".
Also, I didn't find any tests specific for this class, so I wrote a
couple of quick ones for the more interesting bits of functionality.
Reviewers: zturner, erik.pilkington
Subscribers: mgorny, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D47887
llvm-svn: 334399
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D47875
llvm-svn: 334388
|
| |
|
|
| |
llvm-svn: 334385
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to implement expandload/compressstore builtins.
Summary: We've had these target independent intrinsics for at least a year and a half. Looks like they do exactly what we need here and the backend already supports them.
Reviewers: RKSimon, delena, spatel, GBuella
Reviewed By: RKSimon
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D47693
llvm-svn: 334366
|
| |
|
|
|
|
|
|
|
| |
We currently support them only in AArch64. The NEON Reference,
however, says they are 'ARMv7, ARMv8' intrinsics.
Differential Revision: https://reviews.llvm.org/D47446
llvm-svn: 334362
|
| |
|
|
|
|
| |
builtins. Use select in IR instead.
llvm-svn: 334359
|
| |
|
|
|
|
|
|
|
|
| |
Symbols are cleaned up from the program state map when they go out of scope.
Memory regions are cleaned up when the corresponding object is destroyed, and
additionally in 'checkDeadSymbols' in case destructor modeling was incomplete.
Differential Revision: https://reviews.llvm.org/D47416
llvm-svn: 334352
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This check will mark raw pointers to C++ standard library container internal
buffers 'released' when the objects themselves are destroyed. Such information
can be used by MallocChecker to warn about use-after-free problems.
In this first version, 'std::basic_string's are supported.
Differential Revision: https://reviews.llvm.org/D47135
llvm-svn: 334348
|
| |
|
|
|
|
|
|
| |
SmallSet forwards to SmallPtrSet for pointer types. SmallPtrSet supports iteration, but a normal SmallSet doesn't. So if it wasn't for the forwarding, this wouldn't work.
These places were found by hiding the begin/end methods in the SmallSet forwarding.
llvm-svn: 334339
|
| |
|
|
|
|
|
|
|
|
| |
others.
I'd like to make the select builtins require an avx512f, avx512bw, or avx512vl fature to match what is normally required to get masking. Truncate is special in that there are instructions with a 128/256-bit masked result even without avx512vl.
By using special buitlins we can emit a select without using the 128/256-bit select builtins.
llvm-svn: 334331
|
| |
|
|
|
|
|
|
| |
I'm looking into making the select builtins require avx512f, avx512bw, or avx512vl since masking operations generally require those features.
The extract builtins are funny because the 512-bit versions return a 128 or 256 bit vector with masking even when avx512vl is not supported.
llvm-svn: 334330
|
| |
|
|
|
|
| |
checking.
llvm-svn: 334311
|
| |
|
|
|
|
| |
These builtins are all handled by CGBuiltin.cpp so it doesn't much matter what the immediate type is, but int matches the intrinsic spec.
llvm-svn: 334310
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CGM.GetAddrOfConstantCString() sets the adress of the created GlobalValue
to unnamed. When emitting the object file LLVM will mark the surrounding
section as SHF_MERGE iff the string is nul-terminated and contains no
other nuls (see IsNullTerminatedString). This results in problems when
saving temporaries because LLVM doesn't set an EntrySize, so reading in
the serialized assembly file fails.
This never happened for the GPU binaries because they usually contain
a nul-character somewhere. Instead this only affected the module ID
when compiling relocatable device code.
However, this points to a potentially larger problem: If we put a
constant string into a named section, we really want the data to end
up in that section in the object file. To avoid LLVM merging sections
this patch unmarks the GlobalVariable's address as unnamed which also
fixes the problem of invalid serialized assembly files when saving
temporaries.
Differential Revision: https://reviews.llvm.org/D47902
llvm-svn: 334281
|
| |
|
|
|
|
| |
immediate range checking.
llvm-svn: 334266
|
| |
|
|
|
|
| |
and immediate range checking.
llvm-svn: 334265
|
| |
|
|
|
|
| |
This was caught by the Header tests, but not the CodeGen tests.
llvm-svn: 334264
|
| |
|
|
|
|
|
|
| |
checking and immediate range checking.
Test changes are due to differences in how we generate undef elements now. We also changed the types used for extractf128_si256/insertf128_si256 to match the signature of the builtin that previously existed which this patch resurrects. This also matches gcc.
llvm-svn: 334261
|