UBSAN 'invalid value' failures
The commit r300556 introduced a UBSAN issue that was caught by
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap. The DenseMap
failed to create an empty/tombstone value as the empty/tombstone values for the
SubjectMatchRule enum were not valid enum constants.
llvm-svn: 300591
- To be consistent with the rest of the intrinsics headers, I removed the tags <i> .. </i> for marking instruction names in italics in in smmintrin.h.
- Formatting changes to fit into 80 characters.
I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.
llvm-svn: 300578
The Result variable is unused both in Sema::CheckARMBuiltinFunctionCall
and Sema::CheckAArch64BuiltinFunctionCall, remove it.
Patch by Wei-Ren Chen!
Reviewers: craig.topper, rnk
Reviewed By: rnk
Subscribers: aemerson, cfe-commits, rengolin
Differential Revision: https://reviews.llvm.org/D32014
llvm-svn: 300572
This is a recommit of r300539 that was reverted in r300543 due to test failures.
The original commit message is displayed below:
The new '#pragma clang attribute' directive can be used to apply attributes to
multiple declarations. An attribute must satisfy the following conditions to
be supported by the pragma:
- It must have a subject list that's defined in the TableGen file.
- It must be documented.
- It must not be late parsed.
- It must have a GNU/C++11 spelling.
Differential Revision: https://reviews.llvm.org/D30009
llvm-svn: 300556
This passes an option to the ARM assembly parser to emit build
attributes for the hardware selected by command line options, when
assembling an assembly file.
This is not enabled for C/C++, as this would result in duplicate build
attribute directives being emitted in each inline assembly block, when
emitting assembly.
This also adds an option to allow disabling this behaviour for assembly
files, for users who were relying on the old behaviour.
Differential revision: https://reviews.llvm.org/D31813
llvm-svn: 300550
The new '#pragma clang attribute' directive can be used to apply attributes to
multiple declarations. An attribute must satisfy the following conditions to
be supported by the pragma:
- It must have a subject list that's defined in the TableGen file.
- It must be documented.
- It must not be late parsed.
- It must have a GNU/C++11 spelling.
Differential Revision: https://reviews.llvm.org/D30009
llvm-svn: 300539
Summary:
This patch implements [dcl.fct.def.coroutine]p8:
> The unqualified-id get_return_object_on_allocation_failure is looked up in the scope of
> class P by class member access lookup (3.4.5). If a declaration is found, ..., and if a
> global allocation function is selected, the ::operator new(size_t, nothrow_t) form shall be used.
> [...]
> The allocation function used in this case must have a non-throwing noexcept-specification.
Reviewers: GorNishanov, rsmith, majnemer, aaron.ballman
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31562
llvm-svn: 300524
LLVM has changed the semantics of dbg.declare for describing function
arguments. After this patch a dbg.declare always takes the *address*
of a variable as the first argument, even if the argument is not an
alloca.
https://bugs.llvm.org/show_bug.cgi?id=32382
rdar://problem/31205000
llvm-svn: 300523
Previously, if an escaped newline was followed by a newline or a nul, we'd lex
the escaped newline as a bogus space character. This led to a bunch of
different broken corner cases:
For the pattern "\\\n\0#", we would then have a (horizontal) space whose
spelling ends in a newline, and would decide that the '#' is at the start of a
line, and incorrectly start preprocessing a directive in the middle of a
logical source line. If we were already in the middle of a directive, this
would result in our attempting to process multiple directives at the same time!
This resulted in crashes, asserts, and hangs on invalid input, as discovered by
fuzz-testing.
For the pattern "\\\n" at EOF (with an implicit following nul byte), we would
produce a bogus trailing space character with spelling "\\\n". This was mostly
harmless, but would lead to clang-format getting confused and misformatting in
rare cases. We now produce a trailing EOF token with spelling "\\\n",
consistent with our handling for other similar cases -- an escaped newline is
always part of the token containing the next character, if any.
For the pattern "\\\n\n", this was somewhat more benign, but would produce an
extraneous whitespace token to clients who care about preserving whitespace.
However, it turns out that our lexing for line comments was relying on this bug
due to an off-by-one error in its computation of the end of the comment, on the
slow path where the comment might contain escaped newlines.
llvm-svn: 300515
The IR builder can constant-fold null checks if the pointer operand
points to a constant. If the "is-non-null" check is folded away to
"true", don't emit the null check + branch.
Testing: check-clang, check-ubsan.
This slightly reduces the amount of null checks we emit when compiling
X86ISelLowering.cpp. Here are the numbers from patched/unpatched clangs
based on r300371.
-------------------------------------
| Setup | # of null checks |
-------------------------------------
| unpatched, -O0 | 25251 |
| patched, -O0 | 23925 | (-5.3%)
-------------------------------------
llvm-svn: 300509
Pointers to the start of an alloca are non-null, so we don't need to
emit runtime null checks for them.
Testing: check-clang, check-ubsan.
This significantly reduces the amount of null checks we emit when
compiling X86ISelLowering.cpp. Here are the numbers from patched /
unpatched clangs based on r300371.
-------------------------------------
| Setup | # of null checks |
-------------------------------------
| unpatched, -O0 | 45439 |
| patched, -O0 | 25251 | (-44.4%)
-------------------------------------
llvm-svn: 300508
Summary:
Certain implicitly generated coroutine statements, such as the calls to 'return_value()' or `return_void()` or `get_return_object_on_allocation_failure()`, cannot be built until the promise type is no longer dependent. This means they are not built until after the coroutine body statement has been transformed.
This patch fixes an issue where these statements would never be built for coroutine templates.
It also fixes a small issue where diagnostics about `get_return_object_on_allocation_failure()` were incorrectly suppressed.
Reviewers: rsmith, majnemer, GorNishanov, aaron.ballman
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31487
llvm-svn: 300504
It sounds like MSVC is adding support for two-phase name lookup in a
future version, enabled by this flag (see bug).
Differential Revision: https://reviews.llvm.org/D32138
llvm-svn: 300501
The code implements Richard Smith suggestion in comment 3 of the PR.
reviewer: Vassil Vassilev
Differential Revision: https://reviews.llvm.org/D31540
llvm-svn: 300443
This diff registers isConstexpr matcher.
Test plan:
make check-all
check that "match varDecl(isConstexpr())"
works in clang-query
Differential revision: https://reviews.llvm.org/D32112
llvm-svn: 300427
Summary:
This patch implements [dcl.fct.def.coroutine]p8:
> The unqualified-id get_return_object_on_allocation_failure is looked up in the scope of
> class P by class member access lookup (3.4.5). If a declaration is found, ..., and if a
> global allocation function is selected, the ::operator new(size_t, nothrow_t) form shall be used.
> [...]
> The allocation function used in this case must have a non-throwing noexcept-specification.
Reviewers: GorNishanov, rsmith, majnemer, aaron.ballman
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31562
llvm-svn: 300420
available.
Original patch by Douglas Gregor with minor modifications.
This recommits r300389, which broke bots because there have been API
changes since the original patch was written.
rdar://problem/20689633
llvm-svn: 300396
If expensive checks are enabled, safe mode of libstdc++ is enabled too.
In this mode the library uses more complex data that allow additional
checks, for instance, a container may keep list of iterators that points
to it. If a code crashes it can leave these complex library objects in
inconsistent state. It occurs in a few tests that check error recovery
if compiler crashes. These test hang in expensive check mode, as the
library tries to synchronize access to the iterators pointing to some
container, but corresponding mutex remains locked after the crash.
This fix marks these tests as unsupported if clang is built with
libstdc++ safe mode enabled.
Differential Revision: https://reviews.llvm.org/D31126
llvm-svn: 300392
The modules side of r299226, which serializes #pragma pack state,
doesn't work well.
The main purpose was to make -include and -include-pch match semantics
(the PCH side). We also started serializing #pragma pack in PCMs, in
the hopes of making modules and non-modules builds more consistent. But
consider:
$ cat a.h
$ cat b.h
#pragma pack(push, 2)
$ cat module.modulemap
module M {
module a { header "a.h" }
module b { header "b.h" }
}
$ cat t.cpp
#include "a.h"
#pragma pack(show)
As of r299226, the #pragma pack(show) gives "2", even though we've only
included "a.h".
- With -fmodules-local-submodule-visibility, this is clearly wrong. We
should get the default state (8 on x86_64).
- Without -fmodules-local-submodule-visibility, this kind of matches how
other things work (as if include-the-whole-module), but it's still
really terrible, and it doesn't actually make modules and non-modules
builds more consistent.
This commit disables the serialization for modules, essentially a
partial revert of r299226.
Going forward:
1. Having this #pragma pack stuff escape is terrible design (or, more
often, a horrible bug). We should prioritize adding warnings (maybe
-Werror by default?).
2. If we eventually reintroduce this for modules, it should only apply
to -fmodules-local-submodule-visibility, and it should be tracked on
a per-submodule basis.
llvm-svn: 300380
If a pointer is 1-byte aligned, there's no use in checking its
alignment. Somewhat surprisingly, ubsan can spend a significant amount
of time doing just that!
This loosely depends on D30283.
Testing: check-clang, check-ubsan, and a stage2 ubsan build.
Differential Revision: https://reviews.llvm.org/D30285
llvm-svn: 300371
This patch teaches ubsan to insert an alignment check for the 'this'
pointer at the start of each method/lambda. This allows clang to emit
significantly fewer alignment checks overall, because if 'this' is
aligned, so are its fields.
This is essentially the same thing r295515 does, but for the alignment
check instead of the null check. One difference is that we keep the
alignment checks on member expressions where the base is a DeclRefExpr.
There's an opportunity to diagnose unaligned accesses in this situation
(as pointed out by Eli, see PR32630).
Testing: check-clang, check-ubsan, and a stage2 ubsan build.
Along with the patch from D30285, this roughly halves the amount of
alignment checks we emit when compiling X86FastISel.cpp. Here are the
numbers from patched/unpatched clangs based on r298160.
------------------------------------------
| Setup | # of alignment checks |
------------------------------------------
| unpatched, -O0 | 24326 |
| patched, -O0 | 12717 | (-47.7%)
------------------------------------------
Differential Revision: https://reviews.llvm.org/D30283
llvm-svn: 300370
CodeGenFunction::EmitObjCForCollectionStmt currently emits lifetime markers for the loop variable in an inconsistent way: lifetime.start is emitted before the loop is entered, but lifetime.end is emitted inside the loop. AddressSanitizer uses these markers to track out-of-scope accesses to local variables, and we get false positives in Obj-C foreach loops (in the 2nd iteration of the loop). This patch keeps the loop variable alive for the whole loop by extending ForScope and registering the cleanup function inside EmitAutoVarAlloca.
Differential Revision: https://reviews.llvm.org/D32029
llvm-svn: 300340
The config-*triple* file handling isn't tolerant of
leading/trailing whitespace, making it not terribly
obvious when a single extraneous tab/space/etc will
cause the override to be ignored. This patch simply
trims the lines to ensure that it is tolerant of
whitespace.
llvm-svn: 300328
MOVNTDQA non-temporal aligned vector loads can be correctly represented using generic builtin loads, allowing us to remove the existing x86 intrinsics.
LLVM companion patch: D31767.
Differential Revision: https://reviews.llvm.org/D31766
llvm-svn: 300326
Printing out stack traces along with UBSan diagnostics is unsupported on
Darwin. That's because it isn't possible to use the fast unwinder or the
slow unwinder.
Apparently, it's inappropriate to use the fast unwinder for UBSan
issues. I'm not exactly sure why (see the comment in ubsan_diag.cc).
Forcing use of the fast unwinder produces decent results, AFAICT.
Darwin also does not appear to have a slow unwinder suitable for use
with the sanitizers. Apparently that's because of PR20800 [1][2]. But
that bug has been fixed. I'm not sure if there is anything preventing
use of the slow unwinder now.
Currently, passing UBSAN_OPTIONS=print_stacktrace=1 does nothing on
Darwin. This isn't good, but it might be a while before we can fix the
situation, so we should at least document it.
[1] https://github.com/google/sanitizers/issues/137
"We can't use the slow unwinder on OSX now, because Clang produces
incorrect unwind info for the ASan runtime functions on OSX
(http://llvm.org/PR20800)."
[2] https://bugs.llvm.org/show_bug.cgi?id=20800
Bug 20800 - Invalid compact unwind info generated for a function without
frame pointers on OSX
llvm-svn: 300295
CodeGenFunction::EmitObjCForCollectionStmt currently emits lifetime markers for the loop variable in an inconsistent way: lifetime.start is emitted before the loop is entered, but lifetime.end is emitted inside the loop. AddressSanitizer uses these markers to track out-of-scope accesses to local variables, and we get false positives in Obj-C foreach loops (in the 2nd iteration of the loop). The markers of the loop variable need to be either both inside the loop (so that we poison and unpoison the variable in each iteration), or both outside. This patch implements the "both inside" approach.
Differential Revision: https://reviews.llvm.org/D32029
llvm-svn: 300287
Add hasParamAttribute() and use it instead of hasAttribute(ArgNo+1,
Kind) everywhere.
The fact that the AttributeList index for an argument is ArgNo+1 should
be a hidden implementation detail.
NFC
llvm-svn: 300272
This reverts an attempt to check that types match when matching a
dependently-typed non-type template parameter. (This comes up when matching the
parameters of a template template parameter against the parameters of a
template template argument.)
The matching rules here are murky at best. Our behavior after this revert is
definitely wrong for certain C++17 features (for 'auto' template parameter
types within the parameter list of a template template argument in particular),
but our behavior before this revert is wrong for some pre-existing testcases,
so reverting to our prior behavior seems like our best option.
llvm-svn: 300262
With the new release of VS, it's required that all plugins migrate to
the new VSIX manifest format. The new format is backwards compatible
with all versions newer that Visual Studio 2012, so this migration
effectively drops support for older versions of the IDE.
It's also required that these new extensions are built with Visual
Studio 2017, so unfortunately it was necessary to migrate the project
and solution. Also removed COM references to EnvDTE and
Microsoft.VisualStudio.TextManager.Interop from the csproj, as they seem
to both be unnecessary and would trigger build warnings because of
changes to GAC.
Patch by Hugo Puhlmann!
Differential Revision: https://reviews.llvm.org/D31740
llvm-svn: 300225
Adding RUN lines with %clang_cl was causing these tests to fail on Mac
because absolute paths there tend to start with "/User/", which is
recognized as the "/U" flag.
Re-lands r300122
llvm-svn: 300209
We now check the type of the super-region pointer for most SubRegion classes
in compile time; some checks are run-time though.
This is an API-breaking change (we now require explicit casts to specific region
sub-classes), but in practice very few checkers are affected.
Differential Revision: https://reviews.llvm.org/D26838
llvm-svn: 300189
Clean up vtable anchors (remove anchors for regions that have regular
out-of-line virtual methods, add anchors for regions that don't have those).
Fix private/public methods (all constructors should now be private for leaf
classes, protected for abstract classes).
No functional change intended, only extra sanity checks and cleanups.
Differential Revision: https://reviews.llvm.org/D26837
llvm-svn: 300187
SValBuilder tries to constant-fold symbols in the left-hand side of the symbolic
expression whenever it fails to evaluate the expression directly. However, it
only constant-folds them when they are atomic expressions, not when they are
complicated expressions themselves. This patch adds recursive constant-folding
to the left-hand side subexpression (there's a lack of symmetry because we're
trying to have symbols on the left and constants on the right). As an example,
we'd now be able to handle operations similar to "$x + 1 < $y", when $x is
constrained to a constant.
rdar://problem/31354676
Differential Revision: https://reviews.llvm.org/D31886
llvm-svn: 300178
This seems like a much more natural API, based on Derek Schuff's
comments on r300015. It further hides the implementation detail of
AttributeList that function attributes come last and appear at index
~0U, which is easy for the user to screw up. git diff says it saves code
as well: 97 insertions(+), 137 deletions(-)
This also makes it easier to change the implementation, which I want to
do next.
llvm-svn: 300153
This test has apparently been broken for years, but we never noticed before
because it's a long test and long tests approximately never get run.
llvm-svn: 300151
Remove "REQUIRES: long_tests" from test/Driver/response-file.c since it is now about 10x faster. (We can add that back if it's still too slow for some buildbot.)
llvm-svn: 300136
Summary:
Use a tablegen let {} block so that new sanitizer flags are available by
default in all driver modes. This should cut down on time wasted with
bugs like http://crbug.com/710928.
Reviewers: vitalybuka, hans
Subscribers: kcc, llvm-commits
Differential Revision: https://reviews.llvm.org/D31988
llvm-svn: 300122
This diff adds a defensive check in getExtraInvalidatedValues
for the case when there are no regions for the ivar associated with
a property. Corresponding test case added.
Test plan:
make check-clang
make check-clang-analysis
llvm-svn: 300114
This patch implements the suggestion in D29753 that calling DeclMustBeEmitted in
the middle of deserialization should be avoided and that the actual check should
be deferred until it's safe to do so.
This patch fixes a crash when accessing the invalid redecl chains while trying
to evaluate the value of a const VarDecl that contains a function call.
Patch by Raphael Isemann (D30793)!
llvm-svn: 300110
One way to currently test the reproducers is to setup
"FORCE_CLANG_DIAGNOSTICS_CRASH=1" before invoking clang. This simulates
a crash and produces the same contents needed by the reproducers. The
reproducers are specially useful when triaging Modules issues, not only
on crashes, but also for reproducing misleading warnings, errors, etc.
Add a '-gen-reproducer' driver option to clang (or any similar name) and
give users a flag option.
Note that clang already has a -fno-crash-diagnostics, which disables the
crash reproducers. I've decided not to propose "-fcrash-diagnostics"
since it doesn't convey the ideia of reproduction despite a crash.
rdar://problem/24114619
Differential Revision: https://reviews.llvm.org/D27604
llvm-svn: 300109
Remove the restriction where this is only valid with C++
rdar://problem/29055656
Differential Revision: https://reviews.llvm.org/D31781
llvm-svn: 300108
This allows using and testing these two features separately. (noteably,
debug info is, so far as I know, always a win (basically). But function
modular codegen is currently a loss for highly optimized code - where
most of the linkonce_odr definitions are optimized away, so providing
weak_odr definitions is only overhead)
llvm-svn: 300104
This isn't need anymore and modules options -fbuild-session-file and
-fmodules-validate-once-per-build-session already provide a sane
mechanism to validate the system headers.
rdar://problem/19767523
llvm-svn: 300027
Vassil Vassilev