Ivan A. Kosarev [Thu, 21 Dec 2017 08:14:16 +0000 (08:14 +0000)]
[CodeGen] Fix access sizes in new-format TBAA tags
The new format requires to specify both the type of the access
and its size. This patch fixes setting access sizes for TBAA tags
that denote accesses to structure members. This fix affects all
future TBAA metadata tests for the new format, so I guess we
don't need any special tests for this fix.
Vedant Kumar [Thu, 21 Dec 2017 00:10:25 +0000 (00:10 +0000)]
[ubsan] Diagnose noreturn functions which return
Diagnose 'unreachable' UB when a noreturn function returns.
1. Insert a check at the end of functions marked noreturn.
2. A decl may be marked noreturn in the caller TU, but not marked in
the TU where it's defined. To diagnose this scenario, strip away the
noreturn attribute on the callee and insert check after calls to it.
Aaron Ballman [Wed, 20 Dec 2017 22:04:54 +0000 (22:04 +0000)]
Add a printing policy to the ASTDumper.
This allows you to dump C++ code that spells bool instead of _Bool, leaves off the elaborated type specifiers when printing struct or class names, and other C-isms.
Alex Lorenz [Wed, 20 Dec 2017 21:03:38 +0000 (21:03 +0000)]
Fix an assertion failure regression in isDesignatorAtObjectEnd for
__builtin_object_size with incomplete array type in struct
The commit r316245 introduced a regression that causes an assertion failure when
Clang tries to cast an IncompleteArrayType to a PointerType when evaluating
__builtin_object_size.
Erich Keane [Wed, 20 Dec 2017 18:51:08 +0000 (18:51 +0000)]
Add support for ObjectFormat to TargetSpecificAttr
Looking through the code, I saw a FIXME on IFunc to switch it
to a target specific attribute. In looking through it, i saw that
the no-longer-appropriately-named TargetArch didn't support ObjectFormat
checking.
This patch changes the name of TargetArch to TargetSpecific
(since it checks much more than just Arch), makes "Arch" optional, adds
support for ObjectFormat, better documents the TargetSpecific type, and
changes IFunc over to a TargetSpecificAttr.
Ilya Biryukov [Wed, 20 Dec 2017 14:32:38 +0000 (14:32 +0000)]
[Frontend] Handle skipped bodies in template instantiations
Summary:
- Fixed an assert in Sema::InstantiateFunctionDefinition and added
support for instantiating a function template with skipped body.
- Properly call setHasSkippedBody for FunctionTemplateDecl passed to
Sema::ActOnSkippedFunctionBody.
Pavel Labath [Wed, 20 Dec 2017 11:34:38 +0000 (11:34 +0000)]
Remove llvm::MemoryBuffer const_casts
Summary:
llvm has grown a WritableMemoryBuffer class, which is convertible
(inherits from) a MemoryBuffer. We can use it to avoid conts_casting the
buffer contents when we want to write to it.
Artem Dergachev [Wed, 20 Dec 2017 01:17:53 +0000 (01:17 +0000)]
[analyzer] De-duplicate path diagnostics for each exploded graph node.
The bugreporter::trackNullOrUndefValue() mechanism contains a system of bug
reporter visitors that recursively call each other in order to track where a
null or undefined value came from, where each visitor represents a particular
tracking mechanism (track how the value was stored, track how the value was
returned from a function, track how the value was constrained to null, etc.).
Each visitor is only added once per value it needs to track. Almost. One
exception from this rule would be FindLastStoreBRVisitor that has two operation
modes: it contains a flag that indicates whether null stored values should be
suppressed. Two instances of FindLastStoreBRVisitor with different values of
this flag are considered to be different visitors, so they can be added twice
and produce the same diagnostic twice. This was indeed the case in the affected
test.
With the current logic of this whole machinery, such duplication seems
unavoidable. We should be able to safely add visitors with different flag
values without constructing duplicate diagnostic pieces. Hence the effort
in this commit to de-duplicate diagnostics regardless of what visitors
have produced them.
Artem Dergachev [Wed, 20 Dec 2017 01:03:22 +0000 (01:03 +0000)]
[analyzer] trackNullOrUndefValue: always track through parentheses and casts.
When trying to figure out where a null or undefined value came from,
parentheses and cast expressions are either completely irrelevant, or,
in the case of lvalue-to-rvale cast, straightforwardly lead us in the right
direction when we remove them.
There is a regression that causes a certain diagnostic to appear twice in the
path-notes.cpp test (changed to FIXME). It would be addressed in the next
commit.
Artem Dergachev [Wed, 20 Dec 2017 00:47:17 +0000 (00:47 +0000)]
[analyzer] trackNullOrUndefValue: track last store to non-variables.
When reporting certain kinds of analyzer warnings, we use the
bugreporter::trackNullOrUndefValue mechanism, which is part of public checker
API, to understand where a zero, null-pointer, or garbage value came from,
which would highlight important events with respect to that value in the
diagnostic path notes, and help us suppress various false positives that result
from values appearing from particular sources.
Previously, we've lost track of the value when it was written into a memory
region that is not a plain variable. Now try to resume tracking in this
situation by finding where the last write to this region has occured.
Artem Dergachev [Wed, 20 Dec 2017 00:40:38 +0000 (00:40 +0000)]
[analyzer] Fix a crash during C++17 aggregate construction of base objects.
Since C++17, classes that have base classes can potentially be initialized as
aggregates. Trying to construct such objects through brace initialization was
causing the analyzer to crash when the base class has a non-trivial constructor,
while figuring target region for the base class constructor, because the parent
stack frame didn't contain the constructor of the subclass, because there is
no constructor for subclass, merely aggregate initialization.
This patch avoids the crash, but doesn't provide the actually correct region
for the constructor, which still remains to be fixed. Instead, construction
goes into a fake temporary region which would be immediately discarded. Similar
extremely conservative approach is used for other cases in which the logic for
finding the target region is not yet implemented, including aggregate
initialization with fields instead of base-regions (which is not C++17-specific
but also never worked, just didn't crash).
[clang] -foptimization-record-file= should imply -fsave-optimization-record
The Clang option -foptimization-record-file= controls which file an
optimization record is output to. Optimization records are output if you
use the Clang option -fsave-optimization-record. If you specify the
first option without the second, you get a warning that the command line
argument was unused. Passing -foptimization-record-file= should imply
-fsave-optimization-record.
Stephan Bergmann [Mon, 18 Dec 2017 13:51:48 +0000 (13:51 +0000)]
Revert r320978 "No -fsanitize=function warning when calling noexcept function through non-noexcept pointer in C++17"
At least <http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/
builds/6013/steps/annotate/logs/stdio> complains about
__ubsan::__ubsan_handle_function_type_mismatch_abort (compiler-rt
lib/ubsan/ubsan_handlers.cc) returning now despite being declared 'noreturn', so
looks like a different approach is needed for the function_type_mismatch check
to be called also in cases that may ultimately succeed.
Stephan Bergmann [Mon, 18 Dec 2017 13:05:42 +0000 (13:05 +0000)]
No -fsanitize=function warning when calling noexcept function through non-noexcept pointer in C++17
As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/
#!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non-
noexcept pointer is undefined behavior?", such a call should not be UB.
However, Clang currently warns about it.
There is no cheap check whether two function type_infos only differ in noexcept,
so pass those two type_infos as additional data to the function_type_mismatch
handler (with the optimization of passing a null "static callee type" info when
that is already noexcept, so the additional check can be avoided anyway). For
the Itanium ABI (which appears to be the only one that happens to be used on
platforms that support -fsanitize=function, and which appears to only record
noexcept information for pointer-to-function type_infos, not for function
type_infos themselves), we then need to check the mangled names for occurrence
of "Do" representing "noexcept".
This is the cfe part of a patch covering both cfe and compiler-rt.
Sanjay Patel [Sat, 16 Dec 2017 16:11:17 +0000 (16:11 +0000)]
[Driver, CodeGen] pass through and apply -fassociative-math
There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF:
1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the
interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math.
This was mostly already done - we just need to translate the flag as a codegen option.
The test file is complicated because there are many potential combinations of flags here.
Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math.
2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and
corresponding test.
So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch).
This case now works as expected end-to-end although the underlying logic is still wrong:
Hal Finkel [Sat, 16 Dec 2017 02:23:22 +0000 (02:23 +0000)]
[VerifyDiagnosticConsumer] support -verify=<prefixes>
This mimics FileCheck's --check-prefixes option.
The default prefix is "expected". That is, "-verify" is equivalent to
"-verify=expected".
The goal is to permit exercising a single test suite source file with different
compiler options producing different sets of diagnostics. While cpp can be
combined with the existing -verify to accomplish the same goal, source is often
easier to maintain when it's not cluttered with preprocessor directives or
duplicate passages of code. For example, this patch also rewrites some existing
clang tests to demonstrate the benefit of this feature.
Hal Finkel [Sat, 16 Dec 2017 01:40:19 +0000 (01:40 +0000)]
[TextDiagnosticBuffer] Fix diagnostic note emission order
The frontend currently groups diagnostics from the command line according to
diagnostic level, but that places all notes last. Fix that by emitting such
diagnostics in the order they were generated.
This patch introduces a specialized way to lower overflow-checked
multiplications with mixed-sign operands. This fixes link failures and
ICEs on code like this:
void mul(int64_t a, uint64_t b) {
int64_t res;
__builtin_mul_overflow(a, b, &res);
}
The generic checked-binop irgen would use a 65-bit multiplication
intrinsic here, which requires runtime support for _muloti4 (128-bit
multiplication), and therefore fails to link on i386. To get an ICE
on x86_64, change the example to use __int128_t / __uint128_t.
Adding runtime and backend support for 65-bit or 129-bit checked
multiplication on all of our supported targets is infeasible.
This patch solves the problem by using simpler, specialized irgen for
the mixed-sign case.
Testing: Apart from check-clang, I compared the output from this fairly
comprehensive test driver using unpatched & patched clangs:
https://gist.github.com/vedantk/3eb9c88f82e5c32f2e590555b4af5081
Erich Keane [Fri, 15 Dec 2017 16:37:14 +0000 (16:37 +0000)]
Remove "FunctionName -" from docs on FunctionDecl(NFC)
Removed the repetative usage of the operator name on the
documentation for FunctionDecl. Also reflowed some of the
comments since this changes the 80 character rule.
Erich Keane [Thu, 14 Dec 2017 23:37:08 +0000 (23:37 +0000)]
Correct UnaryTransformTypeLoc to properly initialize.
The initializeLocal function of UnaryTransformTypeLoc missed
the UnderlyingTInfo member. This caused a null-dereference
issue, as reported in PR23421. This patch correctly initializss
the UnderlyingTInfo.
Dimitry Andric [Thu, 14 Dec 2017 22:32:24 +0000 (22:32 +0000)]
Don't trigger -Wuser-defined-literals for system headers
Summary:
In D41064, I proposed adding `#pragma clang diagnostic ignored
"-Wuser-defined-literals"` to some of libc++'s headers, since these
warnings are now triggered by clang's new `-std=gnu++14` default:
```
$ cat test.cpp
#include <string>
$ clang -std=c++14 -Wsystem-headers -Wall -Wextra -c test.cpp
In file included from test.cpp:1:
In file included from /usr/include/c++/v1/string:470:
/usr/include/c++/v1/string_view:763:29: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view<char> operator "" sv(const char *__str, size_t __len)
^
/usr/include/c++/v1/string_view:769:32: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view<wchar_t> operator "" sv(const wchar_t *__str, size_t __len)
^
/usr/include/c++/v1/string_view:775:33: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view<char16_t> operator "" sv(const char16_t *__str, size_t __len)
^
/usr/include/c++/v1/string_view:781:33: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string_view<char32_t> operator "" sv(const char32_t *__str, size_t __len)
^
In file included from test.cpp:1:
/usr/include/c++/v1/string:4012:24: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string<char> operator "" s( const char *__str, size_t __len )
^
/usr/include/c++/v1/string:4018:27: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string<wchar_t> operator "" s( const wchar_t *__str, size_t __len )
^
/usr/include/c++/v1/string:4024:28: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string<char16_t> operator "" s( const char16_t *__str, size_t __len )
^
/usr/include/c++/v1/string:4030:28: warning: user-defined literal suffixes not starting with '_' are reserved [-Wuser-defined-literals]
basic_string<char32_t> operator "" s( const char32_t *__str, size_t __len )
^
8 warnings generated.
```
Both @aaron.ballman and @mclow.lists felt that adding this workaround to
the libc++ headers was the wrong way, and it should be fixed in clang
instead.
Here is a proposal to do just that. I verified that this suppresses the
warning, even when -Wsystem-headers is used, and that the warning is
still emitted for a declaration outside of system headers.
Yi Kong [Thu, 14 Dec 2017 22:24:45 +0000 (22:24 +0000)]
[ThreadSafetyAnalysis] Fix isCapabilityExpr
There are many more expr types that can be a capability expr, like
CXXThisExpr, CallExpr, MemberExpr. Instead of enumerating all of them,
just check typeHasCapability for any type given.
Also add & and * operators to allowed unary operators.
Aaron Ballman [Thu, 14 Dec 2017 22:17:09 +0000 (22:17 +0000)]
Harmonize GNU- and C++-style attribute spellings.
Most attributes will now use the Clang<"name"> construct to provide both __attribute__((name)) and [[clang::name]] syntaxes for the attribute. Attributes deviating from this should be marked with a comment explaining why they are not supported under both spellings. Common reasons are: the attribute is provided by some other specification that controls the syntax or the attribute cannot be exposed under a particular spelling for some given reason.
Because this is a mechanical change that only introduces new spellings, there are no test cases for the commit.
Don Hinton [Thu, 14 Dec 2017 22:12:46 +0000 (22:12 +0000)]
[debuginfo] Remove temporary FIXME.
Summary:
Now that r320495, "[debuginfo-tests] Support moving
debuginfo-tests to llvm/projects," has landed, remove temporary FIXME
that supported the old mechanism.
Zachary Turner [Thu, 14 Dec 2017 22:07:03 +0000 (22:07 +0000)]
Fix many -Wsign-compare and -Wtautological-constant-compare warnings.
Most of the -Wsign-compare warnings are due to the fact that
enums are signed by default in the MS ABI, while the
tautological comparison warnings trigger on x86 builds where
sizeof(size_t) is 4 bytes, so N > numeric_limits<unsigned>::max()
is always false.
This patch implements the __is_target_arch, __is_target_vendor, __is_target_os,
and __is_target_environment Clang preprocessor extensions that were proposed by
@compnerd in Bob's cfe-dev post:
http://lists.llvm.org/pipermail/cfe-dev/2017-November/056166.html.
These macros can be used to examine the components of the target triple at
compile time. A has_builtin(is_target_???) preprocessor check can be used to
check for their availability.
__is_target_arch allows you to check if an arch is specified without worring
about a specific subarch, e.g.
__is_target_arch(arm) returns 1 for the target arch "armv7"
__is_target_arch(armv7) returns 1 for the target arch "armv7"
__is_target_arch(armv6) returns 0 for the target arch "armv7"
__is_target_vendor and __is_target_environment match the specific vendor
or environment. __is_target_os matches the specific OS, but
__is_target_os(darwin) will match any Darwin-based OS. "Unknown" can be used
to test if the triple's component is specified.
Summary:
InterlockedCompareExchange128 is a bit more complicated than the other
InterlockedCompareExchange functions, so it requires a bit more work. It
doesn't directly refer to 128bit ints, instead it takes pointers to
64bit ints for Destination and ComparandResult, and exchange is taken as
two 64bit ints (high & low). The previous value is written to
ComparandResult, and success is returned. This implementation does the
following in order to produce a cmpxchg instruction:
1. Cast everything to 128bit ints or int pointers, and glues together
the Exchange values
2. Reads from CompareandResult to get the comparand
3. Calls cmpxchg volatile (on X86 this will produce a lock cmpxchg16b
instruction)
1. Result 0 (previous value) is written back to ComparandResult
2. Result 1 (success bool) is zext'ed to a uchar and returned
Richard Smith [Thu, 14 Dec 2017 15:40:16 +0000 (15:40 +0000)]
When attempting to complete an incomplete array bound type in an expression,
update the type from the definition even if we didn't instantiate a definition.
We may have instantiated the definition in an earlier stage of semantic
analysis, after creating the DeclRefExpr but before we reach a point where a
complete expression type is required.
Richard Smith [Thu, 14 Dec 2017 15:16:18 +0000 (15:16 +0000)]
[c++20] P0515R3: Parsing support and basic AST construction for operator <=>.
Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.
All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.
Richard Smith [Thu, 14 Dec 2017 13:15:08 +0000 (13:15 +0000)]
Warn if we find a Unicode homoglyph for a symbol in an identifier.
Specifically, warn if:
* we find a character that the language standard says we must treat as an
identifier, and
* that character is not reasonably an identifier character (it's a punctuation
character or similar), and
* it renders identically to a valid non-identifier character in common
fixed-width fonts.
Some tools "helpfully" substitute the surprising characters for the expected
characters, and replacing semicolons with Greek question marks is a common
"prank".
IRGen: When performing CFI checks, load vtable pointer from vbase when necessary.
Under the Microsoft ABI, it is possible for an object not to have
a virtual table pointer of its own if all of its virtual functions
were introduced by virtual bases. In that case, we need to load the
vtable pointer from one of the virtual bases and perform the type
check using its type.
[OpenMP] Add function attribute for triggering data sharing.
Summary:
The backend should only emit data sharing code for the cases where it is needed.
A new function attribute is used by Clang to enable data sharing only for the cases where OpenMP semantics require it and there are variables that need to be shared.
Kelvin Li [Tue, 12 Dec 2017 20:08:12 +0000 (20:08 +0000)]
[OpenMP] Diagnose function name on the link clause
This patch is to add diagnose when a function name is
specified on the link clause. According to the OpenMP
spec, only the list items that exclude the function
name are allowed on the link clause.
Kelvin Li [Tue, 12 Dec 2017 18:33:39 +0000 (18:33 +0000)]
Add --cuda-path to mock a CUDA Toolkit installation to avoid
unexpected error messages for incompatibility between the
default SM level and the support in the installed toolkit.
Don Hinton [Tue, 12 Dec 2017 16:48:35 +0000 (16:48 +0000)]
[debuginfo-tests] Add support for moving debuginfo-tests from clang/test to llvm/projects or monorepo.
Summary:
The new version of debuginfo-tests will have it's own
lit.cfg.py file which is incompatible with the one in clang/test.
This change supports both the old and new versions, and can be used
until the bots actually move debuginfo-tests to either clang/test or
the monorepo.
Artem Dergachev [Tue, 12 Dec 2017 02:59:09 +0000 (02:59 +0000)]
[analyzer] StackAddrEscape: For now, disable the new async escape checks.
The new check introduced in r318705 is useful, but suffers from a particular
class of false positives, namely, it does not account for
dispatch_barrier_sync() API which allows one to ensure that the asyncronously
executed block that captures a pointer to a local variable does not actually
outlive that variable.
The new check is split into a separate checker, under the name of
alpha.core.StackAddressAsyncEscape, which is likely to get enabled by default
again once these positives are fixed. The rest of the StackAddressEscapeChecker
is still enabled by default.
Artem Dergachev [Tue, 12 Dec 2017 02:27:55 +0000 (02:27 +0000)]
[analyzer] In getSVal() API, disable auto-detection of void type as char type.
This is a follow-up from r314910. When a checker developer attempts to
dereference a location in memory through ProgramState::getSVal(Loc) or
ProgramState::getSVal(const MemRegion *), without specifying the second
optional QualType parameter for the type of the value he tries to find at this
location, the type is auto-detected from location type. If the location
represents a value beyond a void pointer, we thought that auto-detecting the
type as 'char' is a good idea. However, in most practical cases, the correct
behavior would be to specify the type explicitly, as it is available from other
sources, and the few cases where we actually need to take a 'char' are
workarounds rather than an intended behavior. Therefore, try to fail with an
easy-to-understand assertion when asked to read from a void pointer location.
Craig Topper [Mon, 11 Dec 2017 21:09:19 +0000 (21:09 +0000)]
[Driver][CodeGen] Add -mprefer-vector-width driver option and attribute during CodeGen.
This adds a new command line option -mprefer-vector-width to specify a preferred vector width for the vectorizers. Valid values are 'none' and unsigned integers. The driver will check that it meets those constraints. Specific supported integers will be managed by the targets in the backend.
Clang will take the value and add it as a new function attribute during CodeGen.
This represents the alternate direction proposed by Sanjay in this RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-November/118734.html
The syntax here matches gcc, though gcc treats it as an x86 specific command line argument. gcc only allows values of 128, 256, and 512. I'm not having clang check any values.
Erich Keane [Mon, 11 Dec 2017 19:44:28 +0000 (19:44 +0000)]
PR35586: Relax two asserts that are overly restrictive
The two asserts are too aggressive. In C++ mode, an
enum is NOT considered an integral type, but an enum value
is allowed to be an enum. This patch relaxes the two asserts
to allow the enum value as well (as typechecking does).
Zhihao Yuan [Mon, 11 Dec 2017 18:29:54 +0000 (18:29 +0000)]
P0620 follow-up: deducing `auto` from braced-init-list in new expr
Summary:
This is a side-effect brought in by p0620r0, which allows other placeholder types (derived from `auto` and `decltype(auto)`) to be usable in a `new` expression with a single-clause //braced-init-list// as its initializer (8.3.4 [expr.new]/2). N3922 defined its semantics.
projects / clang / log