| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 341805
|
|
|
|
| |
llvm-svn: 341665
|
|
|
|
| |
llvm-svn: 341661
|
|
|
|
| |
llvm-svn: 341521
|
|
|
|
| |
llvm-svn: 341359
|
|
|
|
| |
llvm-svn: 341355
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D51356
llvm-svn: 341201
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D51212
llvm-svn: 340910
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
------------------------------------------------------------------------
r340376 | steveire | 2018-08-22 03:11:18 +0200 (Wed, 22 Aug 2018) | 7 lines
Update the docs for using LLVM toolset in Visual Studio
Reviewers: hans
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51079
------------------------------------------------------------------------
llvm-svn: 340730
|
|
|
|
|
|
|
|
| |
Patch by Stephen Kelly.
Differential Revision: https://reviews.llvm.org/D51069
llvm-svn: 340375
|
|
|
|
| |
llvm-svn: 339647
|
|
|
|
| |
llvm-svn: 338993
|
|
|
|
| |
llvm-svn: 338892
|
|
|
|
|
|
|
|
| |
$ bin/clang-tblgen -gen-attr-docs -I../cfe.src/include \
../cfe.src/include/clang/Basic/Attr.td \
-o ../cfe.src/docs/AttributeReference.rst
llvm-svn: 338575
|
|
|
|
|
|
|
|
|
| |
$ bin/clang-tblgen -gen-opt-docs -I../cfe.src/include \
-I../cfe.src/include/clang/Driver -I../llvm.src/include \
../cfe.src/include/clang/Driver/ClangOptionDocs.td \
-o ../cfe.src/docs/ClangCommandLineReference.rst
llvm-svn: 338574
|
|
|
|
| |
llvm-svn: 338528
|
|
|
|
|
|
|
|
| |
ConstructorInitializerAllOnOneLineOrOnePerLine more clear
PR38080 complained that the "OnePerLine" case wasn't previously shown.
llvm-svn: 338366
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Yes, i erroneously assumed that the "after" was meant,
but i was wrong:
> I really meant "performed before", for cases like 4u / -2,
> where -2 is implicitly converted to UINT_MAX - 2 before
> the computation. Conversions that are performed after
> a computation aren't part of the computation at all,
> so I think it's much clearer that they're not in scope
> for this sanitizer.
llvm-svn: 338306
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 338288
|
|
|
|
| |
llvm-svn: 338252
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 338137
|
|
|
|
| |
llvm-svn: 338055
|
|
|
|
|
|
| |
Updated ReleaseNotes + Status of the OpenMP support in clang.
llvm-svn: 338049
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Regenerate the Matchers documentation, forgotten in the original patch.
Reviewers: alexfh, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49850
llvm-svn: 338022
|
|
|
|
| |
llvm-svn: 337927
|
|
|
|
|
|
| |
Adding oses others than Linux.
llvm-svn: 337926
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Extend the Clang-Format IncludeCategories documentation by adding a link to the supported regular expression standard (POSIX).
And extenting the example with a system header regex.
[[ https://bugs.llvm.org/show_bug.cgi?id=35041 | bug 35041]]
Contributed by WimLeflere!
Reviewers: krasimir, Typz
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48827
llvm-svn: 337899
|
|
|
|
|
|
|
| |
The DuplicatesAllowedWhileMerging was removed a while ago,
but the documentation remained.
llvm-svn: 337835
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D49615
llvm-svn: 337761
|
|
|
|
| |
llvm-svn: 337760
|
|
|
|
| |
llvm-svn: 337620
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
no-ops.
A non-escaping block on the stack will never be called after its
lifetime ends, so it doesn't have to be copied to the heap. To prevent
a non-escaping block from being copied to the heap, this patch sets
field 'isa' of the block object to NSConcreteGlobalBlock and sets the
BLOCK_IS_GLOBAL bit of field 'flags', which causes the runtime to treat
the block as if it were a global block (calling _Block_copy on the block
just returns the original block and calling _Block_release is a no-op).
Also, a new flag bit 'BLOCK_IS_NOESCAPE' is added, which allows the
runtime or tools to distinguish between true global blocks and
non-escaping blocks.
rdar://problem/39352313
Differential Revision: https://reviews.llvm.org/D49303
llvm-svn: 337580
|
|
|
|
|
|
| |
Fixes rdar://24091053.
llvm-svn: 337525
|
|
|
|
| |
llvm-svn: 337524
|
|
|
|
| |
llvm-svn: 337505
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Support for this option is needed for building Linux kernel.
This is a very frequently requested feature by kernel developers.
More details : https://lkml.org/lkml/2018/4/4/601
GCC option description for -fdelete-null-pointer-checks:
This Assume that programs cannot safely dereference null pointers,
and that no code or data element resides at address zero.
-fno-delete-null-pointer-checks is the inverse of this implying that
null pointer dereferencing is not undefined.
This feature is implemented in as the function attribute
"null-pointer-is-valid"="true".
This CL only adds the attribute on the function.
It also strips "nonnull" attributes from function arguments but
keeps the related warnings unchanged.
Corresponding LLVM change rL336613 already updated the
optimizations to not treat null pointer dereferencing
as undefined if the attribute is present.
Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv
Reviewed By: jyknight
Subscribers: drinkcat, xbolva00, cfe-commits
Differential Revision: https://reviews.llvm.org/D47894
llvm-svn: 337433
|
|
|
|
| |
llvm-svn: 337381
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which was reverted in r337336.
The problem that required a revert was fixed in r337338.
Also added a missing "REQUIRES: x86-registered-target" to one of
the tests.
Original commit message:
> Teach Clang to emit address-significance tables.
>
> By default, we emit an address-significance table on all ELF
> targets when the integrated assembler is enabled. The emission of an
> address-significance table can be controlled with the -faddrsig and
> -fno-addrsig flags.
>
> Differential Revision: https://reviews.llvm.org/D48155
llvm-svn: 337339
|
|
|
|
|
|
|
|
|
| |
Causing multiple failures on sanitizer bots due to TLS symbol errors,
e.g.
/usr/bin/ld: __msan_origin_tls: TLS definition in /home/buildbots/ppc64be-clang-test/clang-ppc64be/stage1/lib/clang/7.0.0/lib/linux/libclang_rt.msan-powerpc64.a(msan.cc.o) section .tbss.__msan_origin_tls mismatches non-TLS reference in /tmp/lit_tmp_0a71tA/mallinfo-3ca75e.o
llvm-svn: 337336
|
|
|
|
|
|
|
|
|
|
|
| |
By default, we emit an address-significance table on all ELF
targets when the integrated assembler is enabled. The emission of an
address-significance table can be controlled with the -faddrsig and
-fno-addrsig flags.
Differential Revision: https://reviews.llvm.org/D48155
llvm-svn: 337333
|
|
|
|
|
|
|
|
| |
`isInstanceMessage` for ObjCMessageExpr
Differential Revision: https://reviews.llvm.org/D49333
llvm-svn: 337209
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Introduce built-ins to read the unsafe stack top and bottom. The unsafe
stack top is required to implement garbage collection scanning for
Oilpan. Currently there is already a built-in 'get_unsafe_stack_start'
to read the bottom of the unsafe stack, but I chose to duplicate this
API because 'start' is ambiguous (e.g. Oilpan uses WTF::GetStackStart to
read the safe stack top.)
Reviewers: pcc
Reviewed By: pcc
Subscribers: llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D49152
llvm-svn: 337037
|
|
|
|
|
|
|
| |
Since The type no longer contains the 'next' item anymore, it isn't a list,
so rename it to ParsedAttr to be more accurate.
llvm-svn: 337005
|
|
|
|
|
|
| |
documentation for -fconstexpr-steps.
llvm-svn: 336747
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D48910
llvm-svn: 336468
|
|
|
|
|
|
| |
backticks to silence the warning; NFC.
llvm-svn: 335843
|
|
|
|
|
|
| |
fixes a Sphinx build warning; NFC.
llvm-svn: 335842
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Setting UBSAN_OPTIONS=silence_unsigned_overflow=1 will silence all UIO
reports. This feature, combined with
-fsanitize-recover=unsigned-integer-overflow, is useful for providing
fuzzing signal without the excessive log output.
Helps with https://github.com/google/oss-fuzz/issues/910.
Reviewers: kcc, vsk
Reviewed By: vsk
Subscribers: vsk, kubamracek, Dor1s, llvm-commits
Differential Revision: https://reviews.llvm.org/D48660
llvm-svn: 335762
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similarly to CFI on virtual and indirect calls, this implementation
tries to use program type information to make the checks as precise
as possible. The basic way that it works is as follows, where `C`
is the name of the class being defined or the target of a call and
the function type is assumed to be `void()`.
For virtual calls:
- Attach type metadata to the addresses of function pointers in vtables
(not the functions themselves) of type `void (B::*)()` for each `B`
that is a recursive dynamic base class of `C`, including `C` itself.
This type metadata has an annotation that the type is for virtual
calls (to distinguish it from the non-virtual case).
- At the call site, check that the computed address of the function
pointer in the vtable has type `void (C::*)()`.
For non-virtual calls:
- Attach type metadata to each non-virtual member function whose address
can be taken with a member function pointer. The type of a function
in class `C` of type `void()` is each of the types `void (B::*)()`
where `B` is a most-base class of `C`. A most-base class of `C`
is defined as a recursive base class of `C`, including `C` itself,
that does not have any bases.
- At the call site, check that the function pointer has one of the types
`void (B::*)()` where `B` is a most-base class of `C`.
Differential Revision: https://reviews.llvm.org/D47567
llvm-svn: 335569
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Mention that no_sanitize attribute can be used with globals.
Reviewers: alekseyshl
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48390
llvm-svn: 335193
|