Added NUW flags for all the add|mul|sub operations + replaced sdiv by udiv
as we operate on unsigned values only (addresses, converted to integers)
llvm-svn: 329411
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
Summary:
`ASTPrinter` allows setting the ouput to any O-Stream, but that printer creates source-code-like syntax (and is also marked with a `FIXME`). The nice, colourful, mostly human-readable `ASTDumper` only works on the standard output, which is not feasible in case a user wants to see the AST of a file through a code navigation/comprehension tool.
This small addition of an overload solves generating a nice colourful AST block for the users of a tool I'm working on, [[ http://github.com/Ericsson/CodeCompass | CodeCompass ]], as opposed to having to duplicate the behaviour of definitions that only exist in the anonymous namespace of implementation TUs related to this module.
Reviewers: alexfh, klimek, rsmith
Reviewed By: alexfh
Subscribers: rnkovacs, dkrupp, gsd, xazax.hun, cfe-commits, #clang
Tags: #clang
Patch by Whisperity!
Differential Revision: https://reviews.llvm.org/D45096
llvm-svn: 329391
Summary:
This change introduces `-fxray-link-deps` and `-fnoxray-link-deps`. The
`-fnoxray-link-deps` allows for directly controlling which specific XRay
runtime to link. The default is for clang to link the XRay runtime that
is shipped with the compiler (if there are any), but users may want to
explicitly add the XRay dependencies from other locations or other
means.
Reviewers: eizan, echristo, chandlerc
Reviewed By: eizan
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D45354
llvm-svn: 329376
Summary:
This change fixes http://llvm.org/PR36985 to define a single place in
CommonArgs.{h,cpp} where XRay runtime flags and link-time dependencies
are processed for all toolchains that support XRay instrumentation. This
is a refactoring of the same functionality spread across multiple
toolchain definitions.
Reviewers: echristo, devnexen, eizan
Reviewed By: eizan
Subscribers: emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D45243
llvm-svn: 329372
This CMake flag allows setting the default value for the
-f[no]-experimental-new-pass-manager flag.
Differential Revision: https://reviews.llvm.org/D44330
llvm-svn: 329366
the tail padding is not reused.
We track on the AggValueSlot (and through a couple of other
initialization actions) whether we're dealing with an object that might
share its tail padding with some other object, so that we can avoid
emitting stores into the tail padding if that's the case. We still
widen stores into tail padding when we can do so.
Differential Revision: https://reviews.llvm.org/D45306
llvm-svn: 329342
layout" rules.
The new rules say that a standard-layout struct has its first non-static
data member and all base classes at offset 0, and consider a class to
not be standard-layout if that would result in multiple subobjects of a
single type having the same address.
We track "is C++11 standard-layout class" separately from "is
standard-layout class" so that the ABIs that need this information can
still use it.
Differential Revision: https://reviews.llvm.org/D45176
llvm-svn: 329332
Summary:
"-fmerge-all-constants" is a non-conforming optimization and should not
be the default. It is also causing miscompiles when building Linux
Kernel (https://lkml.org/lkml/2018/3/20/872).
Fixes PR18538.
Reviewers: rjmccall, rsmith, chandlerc
Reviewed By: rsmith, chandlerc
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D45289
llvm-svn: 329300
Summary:
Previously, `clang-format` didn't understand lightweight
Objective-C generics, which have the form:
```
@interface Foo <KeyType,
ValueTypeWithConstraint : Foo,
AnotherValueTypeWithGenericConstraint: Bar<Baz>, ... > ...
```
The lightweight generic specifier list appears before the base
class, if present, but because it starts with < like the protocol
specifier list, `UnwrappedLineParser` was getting confused and
failed to parse interfaces with both generics and protocol lists:
```
@interface Foo <KeyType> : NSObject <NSCopying>
```
Since the parsed line would be incomplete, the format result
would be very confused (e.g., https://bugs.llvm.org/show_bug.cgi?id=24381).
This fixes the issue by explicitly parsing the ObjC lightweight
generic conformance list, so the line is fully parsed.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=24381
Test Plan: New tests added. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45185
llvm-svn: 329298
structs.
r326307 and r327870 made changes that allowed using non-trivial C
structs with fields qualified with __strong or __weak. This commit makes
the following C++ triviality type traits available to non-trivial C
structs:
__has_trivial_assign
__has_trivial_move_assign
__has_trivial_copy
__has_trivial_move_constructor
__has_trivial_constructor
__has_trivial_destructor
This reapplies r328680. This commit fixes a bug where the copy/move
__has_trivial_* traits would return false when a volatile type was being
passed. Thanks to Richard Smith for pointing out the mistake.
rdar://problem/33599681
Differential Revision: https://reviews.llvm.org/D44913
llvm-svn: 329289
Summary:
This patch extend getTargetDefines and implement handleTargetFeatures
and hasFeature. and define corresponding marco for those features.
Reviewers: asb, apazos, eli.friedman
Differential Revision: https://reviews.llvm.org/D44727
Patch by Kito Cheng.
llvm-svn: 329278
It unintentionally caused the values of the __has_* type traits to change in
C++ for trivially-copyable classes with volatile members.
llvm-svn: 329247
Memory sanitizer compatibility are already done in
MemorySanitizer::doInitialization. It verifies whether the necessary offsets
exist and bails out if not. For this reason it is no good to duplicate two
checks in two projects. This patch removes clang check and postpones msan
compatibility validation till MemorySanitizer::doInitialization.
Another reason for this patch is to allow using msan with any CPU (given
compatible runtime) and custom mapping provided via the arguments added by
https://reviews.llvm.org/D44926.
Patch by vit9696.
Differential Revision: https://reviews.llvm.org/D44927
llvm-svn: 329241
The implementation of shadow call stack on aarch64 is quite different to
the implementation on x86_64. Instead of reserving a segment register for
the shadow call stack, we reserve the platform register, x18. Any function
that spills lr to sp also spills it to the shadow call stack, a pointer to
which is stored in x18.
Differential Revision: https://reviews.llvm.org/D45239
llvm-svn: 329236
Summary:
Most Android headers live in a single directory, but a small handful
live in multiarch directories.
Reviewers: srhines
Reviewed By: srhines
Subscribers: javed.absar, cfe-commits
Differential Revision: https://reviews.llvm.org/D44995
llvm-svn: 329234
Summary:
In https://reviews.llvm.org/D44960, file status check is executed every
time a real file system directory iterator is constructed or
incremented, and emits an error code. This change list fixes the errors
in VirtualFileSystem caused by https://reviews.llvm.org/D44960.
Patch by Yuke Liao (@liaoyuke).
Reviewers: vsk, pcc, zturner, liaoyuke
Reviewed By: vsk
Subscribers: mgrang, cfe-commits
Differential Revision: https://reviews.llvm.org/D45178
llvm-svn: 329223
Summary:
This patch was originally reviewed in D45126. It enables clang to add
the XRay runtime and the link-time dependencies for XRay instrumentation
in OpenBSD.
Landing for devnexen.
Reviewers: brad, dberris
Subscribers: dberris, krytarowski, cfe-commits
Author: devnexen
Differential Revision: https://reviews.llvm.org/D45126
llvm-svn: 329183
Previously UnaryTransformType nodes were comparing the same node
for structural equivalence. This was due to a typo where T1 was
on both sides of the comparison. This patch corrects that typo.
Unfortunately I couldn't find a way to test this change. It seems
that currently UnaryTransform nodes are never actually checked
for equivalence, only their canonical types are.
None the less, this correction seemed appropriate.
llvm-svn: 329151
identifier.
This patch fixes a few places in CGObjCMac.cpp where the class
identifier was used instead of the name specified by objc_runtime_name.
rdar://problem/37910822
Differential Revision: https://reviews.llvm.org/D45101
llvm-svn: 329128
We were already performing checks on non-template variables,
but the checks on templated ones were missing.
Differential Revision: https://reviews.llvm.org/D45231
llvm-svn: 329127
Summary:
Add support for the -fsanitize=shadow-call-stack flag which causes clang
to add ShadowCallStack attribute to functions compiled with that flag
enabled.
Reviewers: pcc, kcc
Reviewed By: pcc, kcc
Subscribers: cryptoad, cfe-commits, kcc
Differential Revision: https://reviews.llvm.org/D44801
llvm-svn: 329122
removeUnneededCalls() is responsible for removing path diagnostic pieces within
functions that don't contain "interesting" events. It makes bug reports
much tidier.
When a stack frame is known to be interesting, the function doesn't descend
into it to prune anything within it, even other callees that are totally boring.
Fix the function to prune boring callees in interesting stack frames.
Differential Revision: https://reviews.llvm.org/D45117
llvm-svn: 329102
This reverts r328795 which introduced an issue with referencing __global__
function templates. More details in the original review D44747.
llvm-svn: 329099
Summary:
The following C++ code was being detected by
`guessLanguage()` as Objective-C:
#define FOO(...) auto bar = [] __VA_ARGS__;
This was because `[] __VA_ARGS__` is not currently detected as a C++
lambda expression (it has no parens or braces), so
`TokenAnnotator::parseSquare()` incorrectly treats the opening square
as an ObjC method expression.
We have two options to fix this:
1. Parse `[] __VA_ARGS__` explicitly as a C++ lambda
2. Make it so `[]` is never parsed as an Objective-C method expression
This diff implements option 2, which causes the `[` to be parsed
as `TT_ArraySubscriptLSquare` instead of `TT_ObjCMethodExpr`.
Note that when I fixed this, it caused one change in formatting
behavior, where the following was implicitly relying on the `[`
being parsed as `TT_ObjCMethodExpr`:
A<int * []> a;
becomes:
A<int *[]> a;
with `Style.PointerAlignment = Middle`.
I don't really know what the desired format is for this syntax; the
test was added by Janusz Sobczak and integrated by @djasper in
b511fe9818
.
I went ahead and changed the test for now.
Test Plan: New tests added. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Fixes: https://bugs.llvm.org/show_bug.cgi?id=36248
Reviewers: djasper, jolesiak
Reviewed By: djasper
Subscribers: klimek, cfe-commits, djasper
Differential Revision: https://reviews.llvm.org/D45169
llvm-svn: 329070
Summary:
D44816 attempted to fix a few cases where `clang-format` incorrectly
inserted a space before the closing brace of an Objective-C dictionary
literal.
This revealed there were still a few cases where we inserted a space
after the opening brace of an Objective-C dictionary literal.
This fixes the formatting to be consistent and adds more tests.
Test Plan: New tests added. Confirmed tests failed before
diff and passed after diff.
Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak, krasimir
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45168
llvm-svn: 329069
D30700 added the -f[no-]rtlib-add-rpath flag, but that flag was never
wired up in the driver and tests were updated to check whether it
actually does anything. This patch wires up the flag and updates test.
Differential Revision: https://reviews.llvm.org/D45145
llvm-svn: 329032
Microsoft has reserved 'U' for the PreserveMostCC which is used in the
swift runtime. Add support for this. This allows the swift runtime to
be built for Windows again.
llvm-svn: 329025
Summary:
The following class hierarchy requires that we be able to emit a
this-adjusting thunk for B::foo in C's vftable:
struct Incomplete;
struct A {
virtual A* foo(Incomplete p) = 0;
};
struct B : virtual A {
void foo(Incomplete p) override;
};
struct C : B { int c; };
This TU is valid, but lacks a definition of 'Incomplete', which makes it
hard to build a thunk for the final overrider, B::foo.
Before this change, Clang gives up attempting to emit the thunk, because
it assumes that if the parameter types are incomplete, it must be
emitting the thunk for optimization purposes. This is untrue for the MS
ABI, where the implementation of B::foo has no idea what thunks C's
vftable may require. Clang needs to emit the thunk without necessarily
having access to the complete prototype of foo.
This change makes Clang emit a musttail variadic call when it needs such
a thunk. I call these "unprototyped" thunks, because they only prototype
the "this" parameter, which must always come first in the MS C++ ABI.
These thunks work, but they create ugly LLVM IR. If the call to the
thunk is devirtualized, it will be a call to a bitcast of a function
pointer. Today, LLVM cannot inline through such a call, but I want to
address that soon, because we also use this pattern for virtual member
pointer thunks.
This change also implements an old FIXME in the code about reusing the
thunk's computed CGFunctionInfo as much as possible. Now we don't end up
computing the thunk's mangled name and arranging it's prototype up to
around three times.
Fixes PR25641
Reviewers: rjmccall, rsmith, hans
Subscribers: Prazek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45112
llvm-svn: 329009
This re-lands r328845 with fixes for crbug.com/827810.
The initial motiviation was to hoist MethodVFTableLocation to global
scope so it could be forward declared.
In this patch, I noticed that MicrosoftVTableContext uses some risky
patterns. It has methods that return references to data stored in
DenseMaps. I've made some of them return by value for trivial structs
and I've moved some things into separate allocations.
llvm-svn: 329007
commit 519b97132a4c960e8dedbfe4290d86970d92e995
Author: Richard Trieu <rtrieu@google.com>
Date: Sat Mar 24 00:52:44 2018 +0000
[ODRHash] Support pointer and reference types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328404 91177308-0d34-0410-b5e6-96231b3b80d8
As it's breaking some tests. I've communicated with Richard offline about testcases.
llvm-svn: 329001
CUDA shared variable should be initialized with undef.
Patch by Greg Rodgers.
Revised and lit test added by Yaxun Liu.
Differential Revision: https://reviews.llvm.org/D44985
llvm-svn: 328994
Alexey Bataev