Using a BlockDecl in a default member initializer causes it to be attached to
CXXMethodDecl without its access specifier being set. This prevents a crash
where getAccess is called on this BlockDecl, since that method expects any
Decl in CXXRecord scope to have an access specifier.
llvm-svn: 322984
Summary:
Upstream LLVM is changing the the prototypes of the @llvm.memcpy/memmove/memset
intrinsics. This change updates the Clang tests for this change.
The @llvm.memcpy/memmove/memset intrinsics currently have an explicit argument
which is required to be a constant integer. It represents the alignment of the
dest (and source), and so must be the minimum of the actual alignment of the
two.
This change removes the alignment argument in favour of placing the alignment
attribute on the source and destination pointers of the memory intrinsic call.
For example, code which used to read:
call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 false)
will now read
call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false)
At this time the source and destination alignments must be the same (Step 1).
Step 2 of the change, to be landed shortly, will relax that contraint and allow
the source and destination to have different alignments.
llvm-svn: 322964
The standard says:
[expr.static.cast] p11: "If the prvalue of type “pointer to cv1 B” points to a B
that is actually a subobject of an object of type D, the resulting pointer points
to the enclosing object of type D. Otherwise, the behavior is undefined."
Therefore, the GEP must be inbounds.
This should solve the failure to optimize away a null check shown in PR35909:
https://bugs.llvm.org/show_bug.cgi?id=35909
Differential Revision: https://reviews.llvm.org/D42249
llvm-svn: 322950
This removes the following (already default-off) warnings from -Wextra:
-Wtautological-type-limit-compare,
-Wtautological-unsigned-zero-compare
-Wtautological-unsigned-enum-zero-compare
On the thread "[cfe-dev] -Wtautological-constant-compare issues", clang
code owners Richard Smith, John McCall, and Reid Kleckner as well as
libc++ code owner Marshall Clow stated that these new warnings are not
yet ready for prime time and shouldn't be part of -Wextra.
Furthermore, Vedant Kumar (Apple), Peter Hosek (Fuchsia), and me (Chromium)
expressed the same concerns (Vedant on that thread, Peter on
https://reviews.llvm.org/D39462, me on https://reviews.llvm.org/D41512).
So remove them from -Wextra, and remove TautologicalInRangeCompare from
TautologicalCompare too until they're usable with real-world code.
llvm-svn: 322901
Firstly, each offloading entry must have a unique name or the
linker will complain if there are multiple files with target
regions. Secondly, the compiler must not introduce padding so
mark the struct with a PackedAttr.
Differential Revision: https://reviews.llvm.org/D42168
llvm-svn: 322858
PreStmt<CXXNewExpr> was never called.
Additionally, under c++-allocator-inlining=true, PostStmt<CXXNewExpr> was
called twice when the allocator was inlined: once after evaluating the
new-expression itself, once after evaluating the allocator call which, for the
lack of better options, uses the new-expression as the call site.
This patch fixes both problems.
Differential Revision: https://reviews.llvm.org/D41934
rdar://problem/12180598
llvm-svn: 322797
Add PostAllocatorCall program point to represent the moment in the analysis
between the operator new() call and the constructor call. Pointer cast from
"void *" to the correct object pointer type has already happened by this point.
The new program point, unlike the previously used PostImplicitCall, contains a
reference to the new-expression, which allows adding path diagnostics over it.
Differential Revision: https://reviews.llvm.org/D41800
rdar://problem/12180598
llvm-svn: 322796
Pointer escape event notifies checkers that a pointer can no longer be reliably
tracked by the analyzer. For example, if a pointer is passed into a function
that has no body available, or written into a global, MallocChecker would
no longer report memory leaks for such pointer.
In case of operator new() under -analyzer-config c++-allocator-inlining=true,
MallocChecker would start tracking the pointer allocated by operator new()
only to immediately meet a pointer escape event notifying the checker that the
pointer has escaped into a constructor (assuming that the body of the
constructor is not available) and immediately stop tracking it. Even though
it is theoretically possible for such constructor to put "this" into
a global container that would later be freed, we prefer to preserve the old
behavior of MallocChecker, i.e. a memory leak warning, in order to
be able to find any memory leaks in C++ at all. In fact, c++-allocator-inlining
*reduces* the amount of false positives coming from this-pointers escaping in
constructors, because it'd be able to inline constructors in some cases.
With other checkers working similarly, we simply suppress the escape event for
this-value of the constructor, regardless of analyzer options.
Differential Revision: https://reviews.llvm.org/D41797
rdar://problem/12180598
llvm-svn: 322795
Implements finding appropriate source locations for intermediate diagnostic
pieces in path-sensitive bug reports that need to descend into an inlined
operator new() call that was called via new-expression. The diagnostics have
worked correctly when operator new() was called "directly".
Differential Revision: https://reviews.llvm.org/D41409
rdar://problem/12180598
llvm-svn: 322791
Fix the const qualifier so that the operator defined in the tests indeed does
override the default global nothrow version of new.
Differential Revision: https://reviews.llvm.org/D41408
llvm-svn: 322790
The callback runs after operator new() and before the construction and allows
the checker to access the casted return value of operator new() (in the
sense of r322780) which is not available in the PostCall callback for the
allocator call.
Update MallocChecker to use the new callback instead of PostStmt<CXXNewExpr>,
which gets called after the constructor.
Differential Revision: https://reviews.llvm.org/D41406
rdar://problem/12180598
llvm-svn: 322787
Make sure that with c++-allocator-inlining=true we have the return value of
conservatively evaluated operator new() in the correct memory space (heap).
This is a regression/omission that worked well in c++-allocator-inlining=false.
Heap regions are superior to regular symbolic regions because they have
stricter aliasing constraints: heap regions do not alias each other or global
variables.
Differential Revision: https://reviews.llvm.org/D41266
rdar://problem/12180598
llvm-svn: 322780
According to [basic.stc.dynamic.allocation], the return type of any C++
overloaded operator new() is "void *". However, type of the new-expression
"new T()" and the type of "this" during construction of "T" are both "T *".
Hence an implicit cast, which is not present in the AST, needs to be performed
before the construction. This patch adds such cast in the case when the
allocator was indeed inlined. For now, in the case where the allocator was *not*
inlined we still use the same symbolic value (which is a pure SymbolicRegion of
type "T *") because it is consistent with how we represent the casts and causes
less surprise in the checkers after switching to the new behavior.
The better approach would be to represent that value as a cast over a
SymbolicRegion of type "void *", however we have technical difficulties
conjuring such region without any actual expression of type "void *" present in
the AST.
Differential Revision: https://reviews.llvm.org/D41250
rdar://problem/12180598
llvm-svn: 322777
The -analyzer-config c++-allocator-inlining experimental option allows the
analyzer to reason about C++ operator new() similarly to how it reasons about
regular functions. In this mode, operator new() is correctly called before the
construction of an object, with the help of a special CFG element.
However, the subsequent construction of the object was still not performed into
the region of memory returned by operator new(). The patch fixes it.
Passing the value from operator new() to the constructor and then to the
new-expression itself was tricky because operator new() has no call site of its
own in the AST. The new expression itself is not a good call site because it
has an incorrect type (operator new() returns 'void *', while the new expression
is a pointer to the allocated object type). Additionally, lifetime of the new
expression in the environment makes it unsuitable for passing the value.
For that reason, an additional program state trait is introduced to keep track
of the return value.
Finally this patch relaxes restrictions on the memory region class that are
required for inlining the constructor. This change affects the old mode as well
(c++-allocator-inlining=false) and seems safe because these restrictions were
an overkill compared to the actual problems observed.
Differential Revision: https://reviews.llvm.org/D40560
rdar://problem/12180598
llvm-svn: 322774
When using -fno-integrated-as flag, the gnu assembler produces code
with some default march/mabi which later causes linker failure due
to incompatible mabi/march.
In this patch we explicitly propagate -mabi and -march flags to the
GNU assembler.
In this patch we explicitly propagate -mabi and -march flags to the GNU assembler.
Differential Revision: https://reviews.llvm.org/D41271
llvm-svn: 322769
Both are related to handling anonymous structures.
* clang didn't handle () around an anonymous struct variable.
* clang also crashed on syntax errors that could lead to other
syntactic constructs following the declaration of an
anonymous struct. While the code is invalid, that's not
a good reason to panic compiler.
Differential Revision: https://reviews.llvm.org/D41788
llvm-svn: 322742
When parsing C++ type construction expressions with list initialization,
forward the locations of the braces to Sema.
Without these locations, the code coverage pass crashes on the given test
case, because the pass relies on getLocEnd() returning a valid location.
Here is what this patch does in more detail:
- Forwards init-list brace locations to Sema (ParseExprCXX),
- Builds an InitializationKind with these locations (SemaExprCXX), and
- Uses these locations for constructor initialization (SemaInit).
The remaining changes fall out of introducing a new overload for
creating direct-list InitializationKinds.
Testing: check-clang, and a stage2 coverage-enabled build of clang with
asserts enabled.
Differential Revision: https://reviews.llvm.org/D41921
llvm-svn: 322729
HTML diagnostics can be an overwhelming blob of pages of code.
This patch adds a checkbox which filters this list down to only the
lines *relevant* to the counterexample by e.g. skipping branches which
analyzer has assumed to be infeasible at a time.
The resulting amount of output is much smaller, and often fits on one
screen, and also provides a much more readable diagnostics.
Differential Revision: https://reviews.llvm.org/D41378
llvm-svn: 322612
parallel for simd` directives.
Added codegen for `depend` clauses on `#pragma omp target teams
distribute parallel for simd` directives.
llvm-svn: 322587
Summary:
noload_lookups() was too lazy: in addition to avoiding external decls, it
avoided populating the lazy lookup structure for internal decls.
This is the right behavior for the existing callsite in ASTDumper, but I think
it's not a very useful default, so we populate it by default.
While here:
- remove an unused test file accidentally added in r322371.
- remove lookups_begin()/lookups_end() in favor of lookups().begin(), which is
more common and more efficient.
Reviewers: ilya-biryukov
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D42077
llvm-svn: 322548
Summary:
Introduce clang_getCursorPrettyPrinted() for pretty printing
declarations. Expose also PrintingPolicy, so the user gets more
fine-grained control of the entities being printed.
The already existing clang_getCursorDisplayName() is pretty limited -
for example, it does not handle return types, parameter names or default
arguments for function declarations. Addressing these issues in
clang_getCursorDisplayName() would mean to duplicate existing code
(e.g. clang::DeclPrinter), so rather expose new API to access the
existing functionality.
Reviewed By: jbcoe
Subscribers: cfe-commits
Tags: #clang
Patch by nik (Nikolai Kosjar)
Differential Revision: https://reviews.llvm.org/D39903
llvm-svn: 322540
We were trying to emit a diag::err_bad_multiversion_option diagnostic,
which expects an int as its first argument, with a string argument. As
it happens, the string `Feature` that was causing this was shadowing an
int `Feature` from the surrounding scope. :)
llvm-svn: 322530
Summary:
There are only two valid integrated Clang driver tools: `-cc1` and
`-cc1as`. If a user asks for an unknown tool, such as `-cc1asphalt`,
an error message is displayed to indicate that there is no such tool,
but the message doesn't indicate what the valid options are.
Include the valid options in the error message.
Test Plan: `check-clang`
Reviewers: sepavloff, bkramer, phosek
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42004
llvm-svn: 322517
simd`.
Added host codegen + codegen for devices with default codegen for
`#pragma omp target teams distribute parallel for simd` directive.
llvm-svn: 322515
Thanks to Eli Friedman, who suggested the reason these tests failed on a few
buildbots yet works fine locally is because non-assert builds don't emit value
labels.
llvm-svn: 322514
RISCVABIInfo is implemented in terms of XLen, supporting both RV32 and RV64.
Unfortunately we need to count argument registers in the frontend in order to
determine when to emit signext and zeroext attributes. Integer scalars are
extended according to their type up to 32-bits and then sign-extended to XLen
when passed in registers, but are anyext when passed on the stack. This patch
only implements the base integer (soft float) ABIs.
For more information on the RISC-V ABI, see [the ABI
doc](https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md),
my [golden model](https://github.com/lowRISC/riscv-calling-conv-model), and
the [LLVM RISC-V calling convention
patch](https://reviews.llvm.org/D39898#2d1595b4) (specifically the comment
documenting frontend expectations).
Differential Revision: https://reviews.llvm.org/D40023
llvm-svn: 322494
Summary:
kunpck intrinsics were removed in favor of native IR a few months ago. The implementation lowers them as by operation on the integer types passed to the intrinsic and then just shifting, masking, and oring them together. A special X86 DAG combine was added to recognize this patter and turn it into a concat_vector operation.
I think it makes more sense to keep the IR implementation closer to vector operations on vXi1. Given that we expect these builtins to be used around other builtins that operate on k-registers which we try to represent in IR with vXi1. InstCombine should be able to get rid of the bitcasts between integers and vXi1 leaving only the vector operations.
Reviewers: RKSimon, spatel, zvi, jina.nahias
Reviewed By: RKSimon
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42016
llvm-svn: 322461
Summary:
In https://reviews.llvm.org/D41733, the driver was modified such that,
when a user provided a mispelled option such as `-hel`, it would
suggest a valid option with a nearby edit distance: "did you mean
'-help'?".
Add these suggestions to invocations of `clang -cc1as` as well.
Test Plan: `check-clang`
Reviewers: v.g.vassilev, bruno
Reviewed By: v.g.vassilev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42001
llvm-svn: 322445
Petr Hosek reported an external buildbot was failing on riscv32-toolchain.c,
seemingly as it set CLANG_DEFAULT_LINKER to lld. Address this by explicitly
setting -fuse-ld=ld in the tests.
llvm-svn: 322435
While here, fix up the myriad other ways in which Sema's two "can this handler
catch that exception?" implementations get things wrong and unify them.
llvm-svn: 322431
InitListExprs without types (well, with type 'void') represent not-yet-analyzed
initializer lists; InitListExpr with types fool Sema into thinking they don't
need further analysis in some cases (particularly C++17 copy omission).
llvm-svn: 322414
In the security package, we have a simple syntactic check that warns about
strcpy() being insecure, due to potential buffer overflows.
Suppress that check's warning in the trivial situation when the source is an
immediate null-terminated string literal and the target is an immediate
sufficiently large buffer.
Patch by András Leitereg!
Differential Revision: https://reviews.llvm.org/D41384
llvm-svn: 322410
getAssociatedStmt() returns the outermost captured statement for the
OpenMP directive. It may return incorrect region in case of combined
constructs. Reworked the code to reduce the number of calls of
getAssociatedStmt() and used getInnermostCapturedStmt() and
getCapturedStmt() functions instead.
In case of firstprivate variables it may lead to an extra allocas
generation for private copies even if the variable is passed by value
into outlined function and could be used directly as private copy.
llvm-svn: 322393
Fix makes the loop in LexAngledStringLiteral more like the loops in
LexStringLiteral, LexCharConstant. When we skip a character after
backslash, we need to check if we reached the end of the file instead of
reading the next character unconditionally.
Discovered by OSS-Fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3832
rdar://problem/35572754
Reviewers: arphaman, kcc, rsmith, dexonsmith
Reviewed By: rsmith, dexonsmith
Subscribers: cfe-commits, rsmith, dexonsmith
Differential Revision: https://reviews.llvm.org/D41423
llvm-svn: 322390
Referenced implementation from Fuchsia and Darwin Toolchain.
Still only support CST_Libcxx. Now checks that the argument
is really '-stdlib=libc++', and display error.
Also, now will pass -lc++ and -lc++abi to the linker.
Patch by Patrick Cheng!
Differential Revision: https://reviews.llvm.org/D41937
llvm-svn: 322382
Summary:
Enumerating the contents of a namespace or global scope will omit any
decls that aren't already loaded, instead of deserializing them from the
PCH.
This allows a fast hybrid code completion where symbols from headers are
provided by an external index. (Sema already exposes the information
needed to do a reasonabl job of filtering them).
Clangd plans to implement this hybrid.
This option is just a hint - callers still need to postfilter results if
they want to *avoid* completing decls outside the main file.
Reviewers: bkramer, ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41989
llvm-svn: 322371
In certain combinations of templated classes and friend functions, the body
of friend functions does not get propagated along with function signature.
Exclude friend functions for hashing to avoid this case.
llvm-svn: 322350
Summary:
The STL types `std::pair` and `std::tuple` can both store reference types. However their constructors cannot adequately check if the initialization of reference types is safe. For example:
```
std::tuple<std::tuple<int> const&> t = 42;
// The stored reference is already dangling.
```
Libc++ has a best effort attempts in tuple to diagnose this, but they're not able to handle all valid cases (If I'm not mistaken). For example initialization of a reference from the result of a class's conversion operator. Libc++ would benefit from having a builtin traits which can provide a much better implementation.
This patch introduce the `__reference_binds_to_temporary(T, U)` trait that determines whether a reference of type `T` bound to an expression of type `U` would bind to a materialized temporary object.
Note that the trait simply returns false if `T` is not a reference type instead of reporting it as an error.
```
static_assert(__is_constructible(int const&, long));
static_assert(__reference_binds_to_temporary(int const&, long));
```
Reviewers: majnemer, rsmith
Reviewed By: rsmith
Subscribers: compnerd, cfe-commits
Differential Revision: https://reviews.llvm.org/D29930
llvm-svn: 322334
While updating clang tests for having clang set dso_local I noticed
that:
- There are *a lot* of tests to update.
- Many of the updates are redundant.
They are redundant because a GV is "obviously dso_local". This patch
starts formalizing that a bit by requiring that internal and private
GVs be dso_local too. Since they all are, we don't have to print
dso_local to the textual representation, making it a bit more compact
and easier to read.
llvm-svn: 322318
In C++17, guaranteed copy elision means that there isn't necessarily a
constructor call when a local variable is initialized by a function call that
returns a scoped_lockable by value. In order to model the effects of
initializing a local variable with a function call returning a scoped_lockable,
pretend that the move constructor was invoked within the caller at the point of
return.
llvm-svn: 322316
We were seeing test failures of riscv32-toolchain.c on windows due to the \
path separator being used for the linker. Add {{/|\\\\}} pattern (made
horrible due to escaping), just like introduced in r214931.
llvm-svn: 322286
The dummy crtbegin.o files were left out in r322276 (as they were ignored by
svn add of test/Driver/Inputs/multilib_riscv_linux_sdk) and are necessary for
the driver test to work.
llvm-svn: 322277
As RV64 codegen has not yet been upstreamed into LLVM, we focus on RV32 driver
support (RV64 to follow).
Differential Revision: https://reviews.llvm.org/D39963
llvm-svn: 322276
Summary:
Enable the compile-time flag -fsanitize-memory-use-after-dtor by
default. Note that the run-time option MSAN_OPTIONS=poison_in_dtor=1
still needs to be enabled for destructors to be poisoned.
Reviewers: eugenis, vitalybuka, kcc
Reviewed By: eugenis, vitalybuka
Subscribers: cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D37860
llvm-svn: 322221
Summary:
The `llvm::OptTable::findNearest` bug fixed in
https://reviews.llvm.org/D41873 manifested itself as the following
erroneous message when invoking Clang:
```
clang -version
clang-6.0: error: unknown argument '-version', did you mean 'version'?
```
Add a test to catch any future regressions to the now correct behavior,
which asks "did you mean '--version'?".
Test Plan: `check-clang`
Reviewers: v.g.vassilev, teemperor, ruiu, jroelofs, yamaguchi
Reviewed By: v.g.vassilev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41912
llvm-svn: 322220
The current code used to not suppress the report, if the dereference was
performed in a macro, assuming it is that same macro.
However, the assumption might not be correct, and XNU has quite a bit of
code where dereference is actually performed in a different macro.
As the code uses macro name and not a unique identifier it might be fragile,
but in a worst-case scenario we would simply emit an extra diagnostic.
rdar://36160245
Differential Revision: https://reviews.llvm.org/D41749
llvm-svn: 322149
GCOV in the old pass manager also strips debug info (if debug info is
disabled/only produced for profiling anyway) after the GCOV pass runs.
I think the strip pass hasn't been ported to the new pass manager, so it
might take me a little while to wire that up.
llvm-svn: 322126
Summary:
First, this patch fixes an assert failure when, for example, "omp for"
has num_teams.
Second, this patch prevents duplicate diagnostics when, for example,
"omp for" has uniform.
This patch makes the general assumption (even where it doesn't
necessarily fix an existing bug) that it is worthless to perform sema
for a clause that appears on a directive on which OpenMP does not
permit that clause. However, due to this assumption, this patch
suppresses some diagnostics that were expected in the test suite. I
assert that those diagnostics were likely just distracting to the
user.
Reviewers: ABataev
Reviewed By: ABataev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41841
llvm-svn: 322107
The Ananas Operating System (https://github.com/zhmu/ananas) has shared
library support as of commit 57739c0b6ece56dd4872aedf30264ed4b9412c77.
This change adds the necessary settings to clang so that shared
executables and libraries can be build correctly.
Submitted by: Rink Springer
Differential Revision: https://reviews.llvm.org/D41500
llvm-svn: 322064
Cf-protection is a target independent flag that instructs the back-end to instrument control flow mechanisms like: Branch, Return, etc.
For example in X86 this flag will be used to instrument Indirect Branch Tracking instructions.
Differential Revision: https://reviews.llvm.org/D40478
Change-Id: I5126e766c0e6b84118cae0ee8a20fe78cc373dea
llvm-svn: 322063
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.
This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.
Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.
The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.
Function templates and virtual functions are NOT yet supported (not supported
in GCC either).
Additionally, constructors/destructors are disallowed, but the former is
planned.
llvm-svn: 322028
This is not quite NFC: we don't perform the usual arithmetic conversions unless
we have an operand of arithmetic or enumeration type any more. This matches the
standard rule, but actually has no effect other than to marginally improve our
diagnostics for the non-arithmetic, non-enumeration cases (by not performing
integral promotions on one operand if the other is a pointer).
llvm-svn: 322024
Summary:
The flag has been deprecated, and is becoming invalid in the latest
MDK.
Reviewers: jyknight
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41713
llvm-svn: 322023
Adds the -fstack-size-section flag to enable the .stack_sizes section. The flag defaults to on for the PS4 triple.
Differential Revision: https://reviews.llvm.org/D40712
llvm-svn: 321992
Check whether we are comparing the same entity, not merely the same
declaration, and don't assume that weak declarations resolve to distinct
entities.
llvm-svn: 321976
These just overloads for _Float128. They're supported by GCC 7 and used
by glibc. APFloat support is already there so just add the overloads.
__builtin_copysignf128
__builtin_fabsf128
__builtin_huge_valf128
__builtin_inff128
__builtin_nanf128
__builtin_nansf128
This is the same support that GCC has, according to the documentation,
but limited to _Float128.
llvm-svn: 321948
Any hashing for methods should be able to compile this test case without
emitting an error. Since the class and method come from the same header from
each module, there should be no messages about ODR violations.
llvm-svn: 321924
Attempting to recompute it are doomed to fail because the IDNS of a declaration
is not necessarily preserved across serialization and deserialization (in turn
because whether a friend declaration is visible depends on whether some prior
non-friend declaration exists).
llvm-svn: 321921
Summary:
Depends on https://reviews.llvm.org/D41732.
Utilities such as `opt`, when invoked with arguments that are very
nearly spelled correctly, suggest the correctly spelled options:
```
bin/opt -hel
opt: Unknown command line argument '-hel'. Try: 'bin/opt -help'
opt: Did you mean '-help'?
```
Clang, on the other hand, prior to this commit, does not:
```
bin/clang -hel
clang-6.0: error: unknown argument: '-hel'
```
This commit makes use of the new libLLVMOption API from
https://reviews.llvm.org/D41732 in order to provide correct suggestions:
```
bin/clang -hel
clang-6.0: error: unknown argument: '-hel', did you mean '-help'?
```
Test Plan: `check-clang`
Reviewers: yamaguchi, v.g.vassilev, teemperor, ruiu, bruno
Reviewed By: bruno
Subscribers: bruno, jroelofs, cfe-commits
Differential Revision: https://reviews.llvm.org/D41733
llvm-svn: 321917
redecl chain for an imported declaration, make sure to check the IDNS of prior
imported decls.
Otherwise we can end up finding an invisible friend declaration and incorrectly
believing that it should be visible.
llvm-svn: 321916
Summary:
#pragma STDC FP_CONTRACT handler is only registered in parser so we
should keep the unknown STDC pragma through preprocessor and we also
should not emit warning for unknown STDC pragma during preprocessor.
rdar://problem/35724351
Reviewers: efriedma, rsmith, arphaman
Reviewed By: efriedma
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41780
llvm-svn: 321909
When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to override/shadow modules
with the same name that are found implicitly by header search. If such a
module is looked up by name (e.g. @import), we will always find the one
from -fmodule-map-file. If we try to use a shadowed module by including
one of its headers report an error.
This enables developers to force use of a specific copy of their module
to be used if there are multiple copies that would otherwise be visible,
for example if they develop modules that are installed in the default
search paths.
Patch originally by Ben Langmuir,
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html
Based on cfe-dev discussion:
http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html
Differential Revision: https://reviews.llvm.org/D31269
rdar://problem/23612102
llvm-svn: 321855
This implements the DWARF 5 feature described at
http://www.dwarfstd.org/ShowIssue.php?issue=141215.1
This allows a consumer to understand whether a composite data type is
trivially copyable and thus should be passed by value instead of by
reference. The canonical example is being able to distinguish the
following two types:
// S is not trivially copyable because of the explicit destructor.
struct S {
~S() {}
};
// T is a POD type.
struct T {
~T() = default;
};
<rdar://problem/36034993>
Differential Revision: https://reviews.llvm.org/D41039
llvm-svn: 321845
each kind.
Attribute instantiation would previously default to instantiating each kind of
attribute only once. This was overridden by a flag whose intended purpose was
to permit attributes from a prior declaration to be inherited onto a new
declaration even if that new declaration had its own copy of the attribute.
This is the wrong behavior: when instantiating attributes from a template, we
should always instantiate all the attributes that were written on that
template.
This patch renames the flag in the Attr class (and TableGen sources) to more
clearly identify what it's actually for, and removes the usage of the flag from
template instantiation. I also removed the flag from AlignedAttr, which was
only added to work around the incorrect suppression of duplicate attribute
instantiation.
llvm-svn: 321834
Summary:
xargs supports escaping of newline characters with backslash.
xargs -0 is neither part of POSIX nor the LSB.
This patch removes the -0 option and adjusts the input to xargs
accordingly; that is, the input is a text file not ending in an
incomplete line, and the newline of interest is preceded by a backslash.
Note: The treatment of escaped newline characters is not as clearly
specified by POSIX as for escaped blank characters; however, the same
can be said for escaped backslashes. It is slightly more clear for the
case where the -I option is used; however, -I is also of limited
portability.
Reviewers: bruno
Reviewed By: bruno
Subscribers: bruno, rcraik, cfe-commits
Differential Revision: https://reviews.llvm.org/D41544
llvm-svn: 321828
Patch fixes incorrect capturing of the expressions in clauses with
expressions that must be captured for the combined constructs. Incorrect
capturing may lead to compiler crash during codegen phase.
llvm-svn: 321820
If the reduction required shuffle in the NVPTX codegen, we may need to
cast the reduced value to the integer type. This casting was implemented
incorrectly and may cause compiler crash. Patch fixes this problem.
llvm-svn: 321818
This is useful for e.g. highlighting purposes in an IDE.
Note: First version of this patch was reverted due to failing tests in
opencl-types.cl with -target ppc64le-unknown-linux. These tests are
adapted now.
Patch by Nikolai Kosjar.
Differential Revision: https://reviews.llvm.org/D40072
llvm-svn: 321794
When modules come from module map files explicitly specified by
-fmodule-map-file= arguments, allow those to override/shadow modules
with the same name that are found implicitly by header search. If such a
module is looked up by name (e.g. @import), we will always find the one
from -fmodule-map-file. If we try to use a shadowed module by including
one of its headers report an error.
This enables developers to force use of a specific copy of their module
to be used if there are multiple copies that would otherwise be visible,
for example if they develop modules that are installed in the default
search paths.
Patch originally by Ben Langmuir,
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20151116/143425.html
Based on cfe-dev discussion:
http://lists.llvm.org/pipermail/cfe-dev/2015-November/046164.html
Differential Revision: https://reviews.llvm.org/D31269
rdar://problem/23612102
llvm-svn: 321781
during template argument deduction.
We already did this when the injected-class-name was in P, but missed the case
where it was in A. This (probably) can't happen except in implicit deduction
guides.
llvm-svn: 321779
Summary:
cp -a is neither part of POSIX nor the LSB. The nearest equivalent under
POSIX is cp -RPp; however, cp -R is sufficient for the intended purpose.
test/Modules/crash-vfs-headermaps.m is not updated since it requires
system-darwin anyway.
Reviewers: bruno
Reviewed By: bruno
Subscribers: bruno, rcraik, cfe-commits
Differential Revision: https://reviews.llvm.org/D41545
llvm-svn: 321778
a warning
This commit separates out the warn_nsconsumed_attribute_mismatch and
warn_nsreturns_retained_attribute_mismatch diagnostic into a warning and error.
This is needed to avoid a module import regression introduced by r313717 that
turned these errors into warnings and started promoting them only when needed,
which caused an error when importing a module as it had different warning
settings.
rdar://36265651
llvm-svn: 321775
r320902 fixed the IRGen for some types of checked multiplications. It
did not handle unsigned overflow correctly in the case where the signed
operand is negative (PR35750).
Eli pointed out that on overflow, the result must be equal to the unique
value that is equivalent to the mathematically-correct result modulo two
raised to the k power, where k is the number of bits in the result type.
This patch fixes the specialized IRGen from r320902 accordingly.
Testing: Apart from check-clang, I modified the test harness from
r320902 to validate the results of all multiplications -- not just the
ones which don't overflow:
https://gist.github.com/vedantk/3eb9c88f82e5c32f2e590555b4af5081
llvm.org/PR35750, rdar://34963321
Differential Revision: https://reviews.llvm.org/D41717
llvm-svn: 321771
an inline namespace, update its semantic DeclContext to match.
We would previously get the semantic DeclContext wrong (pointing to the named
scope rather than the inline namespace within it), resulting in wrong lookup
results and linkage-related problems if the inline namespace was an anonymous
namespace.
llvm-svn: 321770
This patch adds support to the attribute tablegen for specifying a [[]] attribute is allowed in C mode. This patch also adds the annotate attribute to the list of double square bracket attributes we support in C mode.
Eventually, I anticipate that this logic will be reversed (you have to opt out of allowing an attribute in C rather than opting in), but I want to see how the design plays out as more attributes are considered.
llvm-svn: 321763
When a type is only used as a template parameter and that type is the
only type imported from another #include'd module, no skeleton CU for
that module is generated, so a consumer doesn't know where to find the
type definition. By emitting an import declaration, we can force a
skeleton CU to be generated for each imported module.
rdar://problem/36266156
llvm-svn: 321754
This one was rolled back as follow-up to the failing commit.
Second try.
For the function declaration
auto foo5(Foo) -> Foo;
the parameter tokens were mapped to cursors representing the
FunctionDecl:
Keyword: "auto" [1:1 - 1:5] FunctionDecl=test5:1:6
Identifier: "test5" [1:6 - 1:11] FunctionDecl=test5:1:6
Punctuation: "(" [1:11 - 1:12] FunctionDecl=test5:1:6
Identifier: "X" [1:12 - 1:13] FunctionDecl=test5:1:6 // Ops, not a TypeRef
Punctuation: ")" [1:13 - 1:14] FunctionDecl=test5:1:6
Punctuation: "->" [1:15 - 1:17] FunctionDecl=test5:1:6
Identifier: "X" [1:18 - 1:19] TypeRef=struct X:7:8
Punctuation: ";" [1:19 - 1:20]
Fix this by ensuring that the trailing return type is not visited as
first.
Patch by Nikolai Kosjar.
Differential Revision: https://reviews.llvm.org/D40561
llvm-svn: 321709
This broke test/Index/opencl-types.cl on several buildbots:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/3294http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/6498http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/5239
> [libclang] Support querying whether a declaration is invalid
>
> This is useful for e.g. highlighting purposes in an IDE.
>
> Patch by Nikolai Kosjar.
>
> Differential Revision: https://reviews.llvm.org/D40072
Also reverting follow-ups that otherwise caused conflicts for the
revert:
r321700 "Fix line endings."
r321701 "Fix more line endings."
r321698 "[libclang] Fix cursors for functions with trailing return type"
> For the function declaration
>
> auto foo5(Foo) -> Foo;
> the parameter tokens were mapped to cursors representing the
> FunctionDecl:
>
> Keyword: "auto" [1:1 - 1:5] FunctionDecl=test5:1:6
> Identifier: "test5" [1:6 - 1:11] FunctionDecl=test5:1:6
> Punctuation: "(" [1:11 - 1:12] FunctionDecl=test5:1:6
> Identifier: "X" [1:12 - 1:13] FunctionDecl=test5:1:6 // Ops, not a TypeRef
> Punctuation: ")" [1:13 - 1:14] FunctionDecl=test5:1:6
> Punctuation: "->" [1:15 - 1:17] FunctionDecl=test5:1:6
> Identifier: "X" [1:18 - 1:19] TypeRef=struct X:7:8
> Punctuation: ";" [1:19 - 1:20]
>
> Fix this by ensuring that the trailing return type is not visited as
> first.
>
> Patch by Nikolai Kosjar.
>
> Differential Revision: https://reviews.llvm.org/D40561
llvm-svn: 321708
For the function declaration
auto foo5(Foo) -> Foo;
the parameter tokens were mapped to cursors representing the
FunctionDecl:
Keyword: "auto" [1:1 - 1:5] FunctionDecl=test5:1:6
Identifier: "test5" [1:6 - 1:11] FunctionDecl=test5:1:6
Punctuation: "(" [1:11 - 1:12] FunctionDecl=test5:1:6
Identifier: "X" [1:12 - 1:13] FunctionDecl=test5:1:6 // Ops, not a TypeRef
Punctuation: ")" [1:13 - 1:14] FunctionDecl=test5:1:6
Punctuation: "->" [1:15 - 1:17] FunctionDecl=test5:1:6
Identifier: "X" [1:18 - 1:19] TypeRef=struct X:7:8
Punctuation: ";" [1:19 - 1:20]
Fix this by ensuring that the trailing return type is not visited as
first.
Patch by Nikolai Kosjar.
Differential Revision: https://reviews.llvm.org/D40561
llvm-svn: 321698
This is useful for e.g. highlighting purposes in an IDE.
Patch by Nikolai Kosjar.
Differential Revision: https://reviews.llvm.org/D40072
llvm-svn: 321697
Summary:
The diagnostic was mostly introduced in D38101 by me, as a reaction to wasting a lot of time, see [[ https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171009/206427.html | mail ]].
However, the diagnostic is pretty dumb. While it works with no false-positives,
there are some questionable cases that are diagnosed when one would argue that they should not be.
The common complaint is that it diagnoses the comparisons between an `int` and
`long` when compiling for a 32-bit target as tautological, but not when
compiling for 64-bit targets. The underlying problem is obvious: data model.
In most cases, 64-bit target is `LP64` (`int` is 32-bit, `long` and pointer are
64-bit), and the 32-bit target is `ILP32` (`int`, `long`, and pointer are 32-bit).
I.e. the common pattern is: (pseudocode)
```
#include <limits>
#include <cstdint>
int main() {
using T1 = long;
using T2 = int;
T1 r;
if (r < std::numeric_limits<T2>::min()) {}
if (r > std::numeric_limits<T2>::max()) {}
}
```
As an example, D39149 was trying to fix this diagnostic in libc++, and it was not well-received.
This *could* be "fixed", by changing the diagnostics logic to something like
`if the types of the values being compared are different, but are of the same size, then do diagnose`,
and i even attempted to do so in D39462, but as @rjmccall rightfully commented,
that implementation is incomplete to say the least.
So to stop causing trouble, and avoid contaminating upcoming release, lets do this workaround:
* move these three diags (`warn_unsigned_always_true_comparison`, `warn_unsigned_enum_always_true_comparison`, `warn_tautological_constant_compare`) into it's own `-Wtautological-constant-in-range-compare`
* Disable them by default
* Make them part of `-Wextra`
* Additionally, give `warn_tautological_constant_compare` it's own flag `-Wtautological-type-limit-compare`.
I'm not happy about that name, but i can't come up with anything better.
This way all three of them can be enabled/disabled either altogether, or one-by-one.
Reviewers: aaron.ballman, rsmith, smeenai, rjmccall, rnk, mclow.lists, dim
Reviewed By: aaron.ballman, rsmith, dim
Subscribers: thakis, compnerd, mehdi_amini, dim, hans, cfe-commits, rjmccall
Tags: #clang
Differential Revision: https://reviews.llvm.org/D41512
llvm-svn: 321691
Previously, we would:
* compute the type of the conversion function and static invoker as a
side-effect of template argument deduction for a conversion
* re-compute the type as part of deduced return type deduction when building
the conversion function itself
Neither of these turns out to be quite correct. There are other ways to reach a
declaration of the conversion function than in a conversion (such as an
explicit call or friend declaration), and performing auto deduction causes the
function type to be rebuilt in the context of the lambda closure type (which is
different from the context in which it originally appeared, resulting in
spurious substitution failures for constructs that are valid in one context but
not the other, such as the use of an enclosing class's "this" pointer).
This patch switches us to use a different strategy: as before, we use the
declared type of the operator() to form the type of the conversion function and
invoker, but we now populate that type as part of return type deduction for the
conversion function. And the invoker is now treated as simply being an
implementation detail of building the conversion function, and isn't given
special treatment by template argument deduction for the conversion function
any more.
llvm-svn: 321683
This addresses an issue introduced in r183451: since
`removePiecesWithInvalidLocations` is called *after* `adjustCallLocations`,
it is not necessary, and in fact harmful, to have this assertion in
adjustCallLocations.
Addresses rdar://36170689
Differential Revision: https://reviews.llvm.org/D41680
llvm-svn: 321682
The way to fix an undefined-template warning is to add lines to the header file that defines the template pattern. We should suppress the warnings when the template pattern is in a system header because we don't expect users to edit those.
llvm-svn: 321665
Summary:
The C++ Itanium ABI says:
No cookie is required if the new operator being used is ::operator new[](size_t, void*).
We should only avoid poisoning the cookie if we're calling this
operator, not others. This is dealt with before the call to
InitializeArrayCookie.
Reviewers: rjmccall, kcc, rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41301
llvm-svn: 321645
Clang is inherently a cross compiler and can generate code for any target
enabled during build. It however requires to specify many parameters in the
invocation, which could be hardcoded during configuration process in the
case of single-target compiler. The purpose of configuration files is to
make specifying clang arguments easier.
A configuration file is a collection of driver options, which are inserted
into command line before other options specified in the clang invocation.
It groups related options together and allows specifying them in simpler,
more flexible and less error prone way than just listing the options
somewhere in build scripts. Configuration file may be thought as a "macro"
that names an option set and is expanded when the driver is called.
Use of configuration files is described in `UserManual.rst`.
Differential Revision: https://reviews.llvm.org/D24933
llvm-svn: 321621
(Re-submission of D39937 with fixed tests.)
Adjust wording for const-qualification mismatch to be a little more clear.
Also add another diagnostic for a ref qualifier mismatch, which previously produced a useless error (this error path is simply very old; see rL119336):
Before:
error: cannot initialize object parameter of type 'X0' with an expression of type 'X0'
After:
error: 'this' argument to member function 'rvalue' is an lvalue, but function has rvalue ref-qualifier
Reviewers: aaron.ballman
Reviewed By: aaron.ballman
Subscribers: lebedev.ri, cfe-commits
Differential Revision: https://reviews.llvm.org/D41646
llvm-svn: 321609
Summary:
Adjust wording for const-qualification mismatch to be a little more clear.
Also add another diagnostic for a ref qualifier mismatch, which previously produced a useless error (this error path is simply very old; see rL119336):
Before:
error: cannot initialize object parameter of type 'X0' with an expression of type 'X0'
After:
error: 'this' argument to member function 'rvalue' is an lvalue, but function has rvalue ref-qualifier
Reviewers: rsmith, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: lebedev.ri, aaron.ballman, cfe-commits
Differential Revision: https://reviews.llvm.org/D39937
llvm-svn: 321592
Clang is inherently a cross compiler and can generate code for any target
enabled during build. It however requires to specify many parameters in the
invocation, which could be hardcoded during configuration process in the
case of single-target compiler. The purpose of configuration files is to
make specifying clang arguments easier.
A configuration file is a collection of driver options, which are inserted
into command line before other options specified in the clang invocation.
It groups related options together and allows specifying them in simpler,
more flexible and less error prone way than just listing the options
somewhere in build scripts. Configuration file may be thought as a "macro"
that names an option set and is expanded when the driver is called.
Use of configuration files is described in `UserManual.rst`.
Differential Revision: https://reviews.llvm.org/D24933
llvm-svn: 321587
only.
Added support for -fopenmp-simd option that allows compilation of
simd-based constructs without emission of OpenMP runtime calls.
llvm-svn: 321560
-target has no OS version
This ensures that Clang won't warn about redundant -m<os>-version-min
argument for an invocation like
`-target x86_64-apple-macos -mmacos-version-min=10.11`
llvm-svn: 321559
I based that commit on what was in Intel's public documentation here https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
Which specifically said CLWB wasn't until Icelake.
But I've since cross checked with SDE and it thinks these features exist on CNL and ICL. So now I don't know what to believe.
I've added test coverage of the current behavior as part of the revert so at least now have proof of what we're doing.
llvm-svn: 321547
Summary:
Previsouly clang tried instantiating member initializers even if ctor
body was skipped, this caused spurious errors (see the test).
Reviewers: sepavloff, klimek
Reviewed By: sepavloff
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41492
llvm-svn: 321520
...when such an operation is done on an object during con-/destruction.
This is the cfe part of a patch covering both cfe and compiler-rt.
Differential Revision: https://reviews.llvm.org/D40295
llvm-svn: 321519
We have cannonlake and icelake inheriting from skylake server in a switch using fallthroughs. But they aren't perfect supersets of skylake server.
llvm-svn: 321504
added vbmi2 feature recognition
added intrinsics support for vbmi2 instructions
_mm[128,256,512]_mask[z]_compress_epi[16,32]
_mm[128,256,512]_mask_compressstoreu_epi[16,32]
_mm[128,256,512]_mask[z]_expand_epi[16,32]
_mm[128,256,512]_mask[z]_expandloadu_epi[16,32]
_mm[128,256,512]_mask[z]_sh[l,r]di_epi[16,32,64]
_mm[128,256,512]_mask_sh[l,r]dv_epi[16,32,64]
matching a similar work on the backend (D40206)
Differential Revision: https://reviews.llvm.org/D41557
llvm-svn: 321487
added vpclmulqdq feature recognition
added intrinsics support for vpclmulqdq instructions
_mm256_clmulepi64_epi128
_mm512_clmulepi64_epi128
matching a similar work on the backend (D40101)
Differential Revision: https://reviews.llvm.org/D41573
llvm-svn: 321480
added vaes feature recognition
added intrinsics support for vaes instructions, matching a similar work on the backend (D40078)
_mm256_aesenc_epi128
_mm512_aesenc_epi128
_mm256_aesenclast_epi128
_mm512_aesenclast_epi128
_mm256_aesdec_epi128
_mm512_aesdec_epi128
_mm256_aesdeclast_epi128
_mm512_aesdeclast_epi128
llvm-svn: 321474
Suggest moving the following erroneous attrib list (based on location)
[[]] struct X;
to
struct [[]] X;
Additionally, added a fixme for the current implementation that diagnoses misplaced attributes to consider using the newly introduced diagnostic (that I think is more user-friendly).
llvm-svn: 321449
Extend the hashing to functions, which allows detection of function definition
mismatches across modules. This is a re-commit of r320230.
llvm-svn: 321395
If the clause is applied to the combined construct and has captured
expression, try to capture this expression by value rather than by
reference.
llvm-svn: 321386
Now that in the new TBAA format we allow access types to be of
any object types, including aggregate ones, it becomes critical
to specify types of all sub-objects such aggregates comprise as
their members. In order to meet this requirement, this patch
enables generation of field descriptors for members of array
types.
Differential Revision: https://reviews.llvm.org/D41399
llvm-svn: 321352
Now that the MDBuilder helpers generating TBAA type and access
descriptors in the new format are in place, we can teach clang to
use them when requested.
Differential Revision: https://reviews.llvm.org/D41394
llvm-svn: 321351
In case `@import Foo.Private` fails because the submodule doesn't exist,
look for `Foo_Private` (if available) and build/load that module
instead. In that process emit a warning and tell the user about the
assumption.
The intention here is to assist all existing private modules owners
(in ObjC and Swift) to migrate to the new `Foo_Private` syntax.
rdar://problem/36023940
llvm-svn: 321342
The standard correctly forbids various decl-specifiers that dont make sense on non-type template parameters - such as the extern in:
template<extern int> struct X;
This patch implements those restrictions (in a fashion similar to the corresponding checks on function parameters within ActOnParamDeclarator).
Credit goes to miyuki (Mikhail Maltsev) for drawing attention to this issue, authoring the initial versions of this patch, and supporting the effort to re-engineer it slightly. Thank you!
For details of how this patch evolved please see: https://reviews.llvm.org/D40705
llvm-svn: 321339
We used to advertise private modules to be declared as submodules
(Foo.Private). This has proven to not scale well since private headers
might carry several dependencies, introducing unwanted content into the
main module and often causing dep cycles.
Change the canonical way to name it to Foo_Private, forcing private
modules as top level ones, and provide warnings under -Wprivate-module
to suggest fixes for other private naming. Update documentation to
reflect that.
rdar://problem/31173501
llvm-svn: 321337
This is a slightly odd construct (it's more common to see "A (::B)()") but can
happen in friend declarations, and the parens are not redundant as they prevent
the :: binding to the left.
llvm-svn: 321318
An unscoped enumeration used as template argument, should not have any
qualified information about its enclosing scope, as its visibility is
global.
In the case of scoped enumerations, they must include information
about their enclosing scope.
Patch by Carlos Alberto Enciso!
Differential Revision: https://reviews.llvm.org/D39239
llvm-svn: 321312
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.
Fixes the -Wreorder issue and fixes the ast-dump-color.cpp test.
llvm-svn: 321310
When a function taking transparent union is declared as taking one of
union members earlier in the translation unit, clang would hit an
"Invalid cast" assertion during EmitFunctionProlog. This case
corresponds to function f1 in test/CodeGen/transparent-union-redecl.c.
We decided to cast i32 to union because after merging function
declarations function parameter type becomes int,
CGFunctionInfo::ArgInfo type matches with ABIArgInfo type, so we decide
it is a trivial case. But these types should also be castable to
parameter declaration type which is not the case here.
The fix is in checking for the trivial case if ABIArgInfo type matches with
parameter declaration type. It exposed inconsistency that we check
hasScalarEvaluationKind for different types in EmitParmDecl and
EmitFunctionProlog, and comment says they should match.
Additional tests in Sema/transparent-union.c capture current behavior and make
sure there are no regressions.
rdar://problem/34949329
Reviewers: rjmccall, rafael
Reviewed By: rjmccall
Subscribers: aemerson, cfe-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D41311
llvm-svn: 321296
Using ARC, strong, weak, and autoreleasing stack variables are implicitly
initialized with nil. This includes variable-length arrays of Objective-C object
pointers. However, in the analyzer we don't zero-initialize them. We used to,
but it accidentally regressed after r289618.
Under ARC, the array variable's initializer within DeclStmt is an
ImplicitValueInitExpr. Environment doesn't maintain any bindings for this
expression kind - instead it always knows that it's a known constant
(0 in our case), so it just returns the known value by calling
SValBuilder::makeZeroVal() (see EnvironmentManager::getSVal().
Commit r289618 had introduced reasonable behavior of SValBuilder::makeZeroVal()
for the arrays, which produces a zero-length compoundVal{}. When such value
is bound to arrays, in RegionStoreManager::bindArray() "remaining" items in the
array are default-initialized with zero, as in
RegionStoreManager::setImplicitDefaultValue(). The similar mechanism works when
an array is initialized by an initializer list that is too short, eg.
int a[3] = { 1, 2 };
would result in a[2] initialized with 0. However, in case of variable-length
arrays it didn't know if any more items need to be added,
because, well, the length is variable.
Add the default binding anyway, regardless of how many actually need
to be added. We don't really care how many, because the default binding covers
the whole array anyway.
Differential Revision: https://reviews.llvm.org/D41478
rdar://problem/35477763
llvm-svn: 321290
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.
Testing: check-clang, check-ubsan, check-ubsan-minimal, D40700
rdar://33660464
Differential Revision: https://reviews.llvm.org/D40698
llvm-svn: 321231
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.
llvm-svn: 321223
__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.
rdar://36094951
Differential Revision: https://reviews.llvm.org/D41405
llvm-svn: 321222
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.
Differential Revision: https://reviews.llvm.org/D41303
llvm-svn: 321201
Summary: Plant an inline version of "((ac+bd)/(cc+dd)) + i((bc-ad)/(cc+dd))" instead.
Patch by Paul Walker.
Reviewed By: hfinkel
Differential Revision: https://reviews.llvm.org/D40299
llvm-svn: 321183
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.
Reviewers: sepavloff, bkramer
Reviewed By: sepavloff
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D41237
llvm-svn: 321174
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.
Differential Revision: https://reviews.llvm.org/D41258
llvm-svn: 321135
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.
Differential revision: https://reviews.llvm.org/D41254
llvm-svn: 321133
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.
Differential revision: https://reviews.llvm.org/D41253
llvm-svn: 321130
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).
Differential revision: https://reviews.llvm.org/D40841
rdar://problem/35441058
llvm-svn: 321128
OS instead of inferring it from SDK / environment
The OS version is specified in -target should be used instead of the one in an
environment variable / SDK name.
rdar://35813850
Differential Revision: https://reviews.llvm.org/D40998
llvm-svn: 321099
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.
This fixes PR33670
Patch by: Dmitry Venikov <venikov@phystech.edu>
Differential revision: https://reviews.llvm.org/D39834
llvm-svn: 321090
Summary: This is to be consistent with latest Movidius MDK releases.
Also, don't inherit any gcc paths for shave triple.
Reviewers: jyknight
Subscribers: emaste, fedor.sergeev
Differential Revision: https://reviews.llvm.org/D41295
llvm-svn: 321080
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.
For the motivating example from PR27372:
float foo(float a, float x) { return ((a + x) - x); }
$ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub'
%add = fadd nnan ninf nsz arcp contract float %0, %1
%sub = fsub nnan ninf nsz arcp contract float %add, %2
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:
$ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm
addss %xmm1, %xmm0
subss %xmm1, %xmm0
We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example:
$ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd
%add = fadd reassoc float %0, %1
$ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm
addss %xmm1, %xmm0
subss %xmm1, %xmm0
Differential Revision: https://reviews.llvm.org/D39812
llvm-svn: 320920
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.
Patch by Joel E. Denny, thanks!
Differential Revision: https://reviews.llvm.org/D39694
llvm-svn: 320908
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.
Patch by Joel E. Denny, thanks!
Differential Revision: https://reviews.llvm.org/D40995
llvm-svn: 320904
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.
llvm.org/PR34920, rdar://34963321
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
Differential Revision: https://reviews.llvm.org/D41149
llvm-svn: 320902
This ensures that when compiling for "arm64" __is_target_arch will succeed for
both "arm64" and "aarch64".
Thanks to Bob Wilson who pointed this out!
llvm-svn: 320853
Previously the attributes were emitted only for function definitions.
Patch adds emission of the attributes for function declarations.
llvm-svn: 320826
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.
llvm-svn: 320765
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.
Reviewers: aaron.ballman, mclow.lists, rsmith
Reviewed By: aaron.ballman
Subscribers: mclow.lists, aaron.ballman, andrew, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D41080
llvm-svn: 320755
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.
Differential Revision: https://reviews.llvm.org/D41224
llvm-svn: 320753
Summary:
Now that r320495, "[debuginfo-tests] Support moving
debuginfo-tests to llvm/projects," has landed, remove temporary FIXME
that supported the old mechanism.
Reviewers: zturner, aprantl
Reviewed By: aprantl
Subscribers: JDevlieghere, cfe-commits
Differential Revision: https://reviews.llvm.org/D41259
llvm-svn: 320751
This patch allows checking whether a C++ record declaration is abstract through
libclang and clang.cindex (Python).
Patch by Johann Klähn!
Differential Revision: https://reviews.llvm.org/D36952
llvm-svn: 320748
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
Resolves bug https://llvm.org/PR35251
Patch by Colden Cullen!
Reviewers: rnk, agutowski
Reviewed By: rnk
Subscribers: majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D41032
llvm-svn: 320730
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.
llvm-svn: 320709
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'.
llvm-svn: 320707
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".
llvm-svn: 320697
Summary:
This fixes an invalid warning about missing definition of a function when
parsing with SkipFunctionBodies=true
Reviewers: bkramer, sepavloff
Reviewed By: sepavloff
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D41189
llvm-svn: 320696
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.
Differential Revision: https://reviews.llvm.org/D41036
llvm-svn: 320638
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.
Reviewers: hfinkel, Hahnfeld, ABataev, carlo.bertolli, caomhin
Reviewed By: ABataev
Subscribers: cfe-commits, jholewinski
Differential Revision: https://reviews.llvm.org/D41123
llvm-svn: 320527
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.
Differential Revision: https://reviews.llvm.org/D40968
llvm-svn: 320521
unexpected error messages for incompatibility between the
default SM level and the support in the installed toolkit.
Differential Revision: https://reviews.llvm.org/D40996
llvm-svn: 320506
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.
This is a prerequisite for D40971.
Reviewers: zturner, aprantl
Subscribers: mgorny, JDevlieghere, llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D41055
llvm-svn: 320494
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.
Differential Revision: https://reviews.llvm.org/D41042
llvm-svn: 320455
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.
Differential Revision: https://reviews.llvm.org/D40230
llvm-svn: 320419
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).
llvm-svn: 320411
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.
References:
http://wg21.link/p0620r0http://wg21.link/n3922
Reviewers: rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39451
llvm-svn: 320401
Summary:
Clang was crashing when diagnosing an unused-lambda-capture for a VLA because
From.getVariable() is null for the capture of a VLA bound.
Warning about the VLA bound capture is not helpful, so only warn for the VLA
itself.
Fixes: PR35555
Reviewers: aaron.ballman, dim, rsmith
Reviewed By: aaron.ballman, dim
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41016
llvm-svn: 320396
As reported in llvm bugzilla 32377.
Here’s a patch to add preinclude of stdc-predef.h.
The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.” See https://gcc.gnu.org/gcc-4.8/porting_to.html;
The preinclude is inhibited with –ffreestanding.
Basically I fixed the failing test cases by adding –ffreestanding which inhibits this behavior.
I fixed all the failing tests, including some in extra/test, there's a separate patch for that which is linked here
Note: this is a recommit after a test failure took down the original (r318669)
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D34158
llvm-svn: 320391
The simulator variant of Darwin's platforms is removed in favor of a new
environment field.
The code that selects the platform and the version is split into 4 different
functions instead of being all in one function.
This is an NFC commit, although it slightly improves the
"invalid version number" diagnostic by displaying the environment variable
instead of -m<os>-version-min if the OS version was derived from the
environment.
rdar://35813850
Differential Revision: https://reviews.llvm.org/D41035
llvm-svn: 320235
This commit fixes a bug in IRGen where it generates completely broken
code for __fp16 vectors on X86. For example when the following code is
compiled:
half4 hv0, hv1, hv2; // these are vectors of __fp16.
void foo221() {
hv0 = hv1 + hv2;
}
clang generates the following IR, in which two i16 vectors are added:
@hv1 = common global <4 x i16> zeroinitializer, align 8
@hv2 = common global <4 x i16> zeroinitializer, align 8
@hv0 = common global <4 x i16> zeroinitializer, align 8
define void @foo221() {
%0 = load <4 x i16>, <4 x i16>* @hv1, align 8
%1 = load <4 x i16>, <4 x i16>* @hv2, align 8
%add = add <4 x i16> %0, %1
store <4 x i16> %add, <4 x i16>* @hv0, align 8
ret void
}
To fix the bug, this commit uses the code committed in r314056, which
modified clang to promote and truncate __fp16 vectors to and from float
vectors in the AST. It also fixes another IRGen bug where a short value
is assigned to an __fp16 variable without any integer-to-floating-point
conversion, as shown in the following example:
__fp16 a;
short b;
void foo1() {
a = b;
}
@b = common global i16 0, align 2
@a = common global i16 0, align 2
define void @foo1() #0 {
%0 = load i16, i16* @b, align 2
store i16 %0, i16* @a, align 2
ret void
}
rdar://problem/20625184
Differential Revision: https://reviews.llvm.org/D40112
llvm-svn: 320215
and fold together into a single function.
In so doing, fix a handful of remaining bugs where we would report false
positives or false negatives if we promote a signed value to an unsigned type
for the comparison.
This re-commits r320122 and r320124, minus two changes:
* Comparisons between a constant and a non-constant expression of enumeration
type never warn, not even if the constant is out of range. We should be
warning about the creation of such a constant, not about its use.
* We do not use more precise bit-widths for comparisons against bit-fields.
The more precise diagnostics probably are the right thing, but we should
consider moving them under their own warning flag.
Other than the refactoring, this patch should only change the behavior for the
buggy cases (where the warnings didn't take into account that promotion from
signed to unsigned can leave a range of inaccessible values in the middle of
the promoted type).
llvm-svn: 320211
This is a follow-up to r320128. Eli pointed out that there is some gray
area in the language standard about whether the constant size is exact,
or a lower bound.
https://reviews.llvm.org/D40940
llvm-svn: 320185
> Unify implementation of our two different flavours of -Wtautological-compare.
>
> In so doing, fix a handful of remaining bugs where we would report false
> positives or false negatives if we promote a signed value to an unsigned type
> for the comparison.
This caused a new warning in Chromium:
../../base/trace_event/trace_log.cc:1545:29: error: comparison of constant 64
with expression of type 'unsigned int' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
DCHECK(handle.event_index < TraceBufferChunk::kTraceBufferChunkSize);
~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 'unsigned int' is really a 6-bit bitfield, which is why it's always
less than 64.
I thought we didn't use to warn (with out-of-range-compare) when comparing
against the boundaries of a type?
llvm-svn: 320162
There is no way to apply sanitizer suppressions to ObjC blocks. A
reasonable default is to have blocks inherit their parent's sanitizer
options.
rdar://32769634
Differential Revision: https://reviews.llvm.org/D40668
llvm-svn: 320132
In so doing, fix a handful of remaining bugs where we would report false
positives or false negatives if we promote a signed value to an unsigned type
for the comparison.
llvm-svn: 320122
This adds -std=c17, -std=gnu17, and -std=iso9899:2017 as language mode flags for C17 and updates the value of __STDC_VERSION__ to the value based on the C17 FDIS. Given that this ballot cannot succeed until 2018, it is expected that we (and GCC) will add c18 flags as aliases once the ballot passes.
llvm-svn: 320089
This behaves similar to the __has_cpp_attribute builtin macro in that it allows users to detect whether an attribute is supported with the [[]] spelling syntax, which can be enabled in C with -fdouble-square-bracket-attributes.
llvm-svn: 320088
requested by client
This is a follow up to r319702 which records parsing invocations.
These files are not emitted by default, and the client has to specify the
invocation emission path first.
rdar://35322543
llvm-svn: 320085
Private variables are completely redefined in the outlined regions, so
we don't need to capture them. Patch adds this behavior to the
target-based regions.
llvm-svn: 320078
This is a follow up of r302131, in which we forgot to add SemaChecking
tests. Adding these tests revealed two problems which have been fixed:
- added missing intrinsic __qdbl,
- properly range checking ssat16 and usat16.
Differential Revision: https://reviews.llvm.org/D40888
llvm-svn: 320019
This is a fix for PR35509 in which we crash because we attempt to compute the
alignment of an incomplete type.
Differential Revision: https://reviews.llvm.org/D40895
llvm-svn: 320017
Summary:
This feature was discussed but not yet proposed. It allows a structured binding to appear as a //condition//
if (auto [ok, val] = f(...))
So the user can save an extra //condition// if the statement can test the value to-be-decomposed instead. Formally, it makes the value of the underlying object of the structured binding declaration also the value of a //condition// that is an initialized declaration.
Considering its logicality which is entirely evident from its trivial implementation, I think it might be acceptable to land it as an extension for now before I write the paper.
Reviewers: rsmith, faisalv, aaron.ballman
Reviewed By: rsmith
Subscribers: aaron.ballman, cfe-commits
Differential Revision: https://reviews.llvm.org/D39284
llvm-svn: 320011
CreateCoercedLoad/CreateCoercedStore assumes pointer argument of
memcpy is in addr space 0, which is not correct and causes invalid
bitcasts for triple amdgcn---amdgiz.
It is fixed by using alloca addr space instead.
Differential Revision: https://reviews.llvm.org/D40806
llvm-svn: 320000
Summary:
This is so we can implement concepts per P0734R0. Relevant failing test
cases are disabled.
Reviewers: hubert.reinterpretcast, rsmith, saar.raz, nwilson
Reviewed By: saar.raz
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40380
Patch by Changyu Li!
llvm-svn: 319992
The adjustment is calculated with CreatePtrDiff() which returns
the difference in (base) elements. This is passed to CreateGEP()
so make sure that the GEP base has the correct pointer type:
It needs to be a pointer to the base type, not a pointer to a
constant sized array.
Differential Revision: https://reviews.llvm.org/D40911
llvm-svn: 319931
Summary: This patch implements 4.3 of http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4220.pdf. If a raw string contains a newline character, replace each newline character with the \n escape code. Without this patch, included test case (macro_raw_string.cpp) results compilation failure.
Reviewers: rsmith, doug.gregor, jkorous-apple
Reviewed By: jkorous-apple
Subscribers: jkorous-apple, vsapsai, cfe-commits
Differential Revision: https://reviews.llvm.org/D39279
llvm-svn: 319904
An enumeration with a fixed underlying type can have any value in its
underlying type, not just those spanned by the values of its enumerators.
llvm-svn: 319875
Array subscript is almost always an lvalue, except for a few cases where
it is not, such as a subscript into an Objective-C property, or a
return from the function.
This commit prevents crashing in such cases.
Fixes rdar://34829842
Differential Revision: https://reviews.llvm.org/D40584
llvm-svn: 319834
This patch, together with a matching llvm patch (https://reviews.llvm.org/D39720), implements the lowering of X86 kunpack intrinsics to IR.
Differential Revision: https://reviews.llvm.org/D39719
Change-Id: Id5d3cb394ad33b98be79a6783d1d15569e2b798d
llvm-svn: 319777
If the error is generated during analysis of implicitly or explicitly
mapped variables, it may cause compiler crash because of incorrect
analysis.
llvm-svn: 319774
This definition is similar to __WCHAR_MAX__, except that it applies to
wint_t. It's also documented as being supported by GCC 4.5 and later.
llvm-svn: 319746
Storing the contents of unsaved files is too expensive.
Instead a hash is stored with a record invocation. When a reproducer is
generated, Clang will compare the stored hashes to the new hashes to determine
if the contents of a file has changed. This way we'll know when a reproducer was
generated for a different source to the one that triggered the original crash.
rdar://35322543
llvm-svn: 319729
The current code would hit an assert in ASTWriter when trying to write
out the filename for a line table entry that didn't have any. Fix this
by allowing the -1 sentinel value to round-trip through serialization.
Differential revision: https://reviews.llvm.org/D40746
llvm-svn: 319707
Fedora27 is using a new version of glibc that refers to the _Float128 type. This
patch adds that name as an alias to float128. I also added some predefined macro
values for the digits, mantissa, epilon, etc (FloatMacros). For the test case, I
copied an existing float128 test. This functionality needs work long term, but
it should be sufficient to tread water for a while. At Intel we have test
servers running our LLVM compiler with various open source workloads, the server
has been upgraded to Fedora27 so many workloads are failing due to _Float128.
Patch-By: mibintc
Differential Revision: https://reviews.llvm.org/D40673
llvm-svn: 319703
by client
This patch extends libclang by allowing it to record parsing operations to a
temporary JSON file. The file is deleted after parsing succeeds. When a crash
happens during parsing, the file is preserved and the client will be able to use
it to generate a reproducer for the crash.
These files are not emitted by default, and the client has to specify the
invocation emission path first.
rdar://35322543
Differential Revision: https://reviews.llvm.org/D40527
llvm-svn: 319702
Though it is incorrect from point of view of OpenMP standard to have
dependent iteration space in OpenMP loops, compiler should not crash.
Patch fixes this problem.
llvm-svn: 319700
RegionStore has special logic to evaluate captured constexpr variables.
However, if the constexpr initializer cannot be evaluated as an integer, the
value is treated as undefined. This leads to false positives when, for example,
a constexpr float is captured by a lambda.
To fix this, treat a constexpr capture that cannot be evaluated as unknown
rather than undefined.
rdar://problem/35784662
llvm-svn: 319638
whether they have an initializer.
We cannot distinguish between a declaration of a variable template
specialization and a definition of one that lacks an initializer without this,
and would previously mistake the latter for the former.
llvm-svn: 319605
There are 20 LLVM math intrinsics that correspond to mathlib calls according to the LangRef:
http://llvm.org/docs/LangRef.html#standard-c-library-intrinsics
We were only converting 3 mathlib calls (sqrt, fma, pow) and 12 builtin calls (ceil, copysign,
fabs, floor, fma, fmax, fmin, nearbyint, pow, rint, round, trunc) to their intrinsic-equivalents.
This patch pulls the transforms together and handles all 20 cases. The switch is guarded by a
check for const-ness to make sure we're not doing the transform if errno could possibly be set by
the libcall or builtin.
Differential Revision: https://reviews.llvm.org/D40044
llvm-svn: 319593
Previously we emitted `__tgt_target_teams` only for standalone teams
directives. This patch allows emit this function for all teams-based
directives.
llvm-svn: 319585
of its argument, perform function-to-pointer and array-to-pointer decay on the
parameter type first.
Otherwise deduction will fail, as the type of the argument will be decayed.
llvm-svn: 319584
The driver-based test is still not identical to the front-end line, remove the
hotness threshold from there and add a new front-end based test with
threshold.
llvm-svn: 319578
1. Require hotness on all remark lines with -verify.
3. Fix the samplePGO file to actually produce hotness on each line.
The second remark has hotness 60 rather 30 which I don't quite understand but
testing this is strictly better than before. It also unblocks the commit of
D40678.
llvm-svn: 319577
A RUN line was referring to the previous RUN line but a new test was added in
between them. Just reorder the lines.
Note this still does not completely fix this the brokenness of the comment as
the driver-based test gained a new hotness-threshold argument in r306948 but
I'll fix that is a separate commit.
llvm-svn: 319576
distribute directives.
OpenMP standard does not allow to mark the variables as firstprivate and lastprivate at the same time in distribute-based directives. Patch fixes this problem.
llvm-svn: 319560
Clang asserts on undeclared variables on the to or link clause in the declare
target directive. The patch is to properly diagnose the error.
// foo1 and foo2 are not declared
#pragma omp declare target to(foo1)
#pragma omp declare target link(foo2)
Differential Revision: https://reviews.llvm.org/D40588
llvm-svn: 319458
teams region.
If the inner teams region is not correct, it may cause an assertion when
processing outer target region. Patch fixes this problem.
llvm-svn: 319450
As rsmith pointed out, the original implementation of this intrinsic
missed a number of important situations. This patch fixe a bunch of
shortcomings and implementation details to make it work correctly.
Differential Revision: https://reviews.llvm.org/D39347
llvm-svn: 319446
To be compatible with GCC if soft floating point is in effect any FPU
specified is effectively ignored, eg,
-mfloat-abi=soft -fpu=neon
If any floating point features which require FPU hardware are enabled
they must be disable.
There was some support for doing this for NEON, but it did not handle
VFP, nor did it prevent the backend from emitting the build attribute
Tag_FP_arch describing the generated code as using the floating point
hardware if a FPU was specified (even though soft float does not use
the FPU).
Disabling the hardware floating point features for targets which are
compiling for soft float has meant that some tests which were incorrectly
checking for hardware support also needed to be updated. In such cases,
where appropriate the tests have been updated to check compiling for
soft float and a non-soft float variant (usually softfp). This was
usually because the target specified in the test defaulted to soft float.
Differential Revision: https://reviews.llvm.org/D40256
llvm-svn: 319420
The basic idea behind this patch is that since in strict aliasing
mode all accesses to union members require their outermost
enclosing union objects to be specified explicitly, then for a
couple given accesses to union members of the form
p->a.b.c...
q->x.y.z...
it is known they can only alias if both p and q point to the same
union type and offset ranges of members a.b.c... and x.y.z...
overlap. Note that the actual types of the members do not matter.
Specifically, in this patch we do the following:
* Make unions to be valid TBAA base access types. This enables
generation of TBAA type descriptors for unions.
* Encode union types as structures with a single member of a
special "union member" type. Currently we do not encode
information about sizes of types, but conceptually such union
members are considered to be of the size of the whole union.
* Encode accesses to direct and indirect union members, including
member arrays, as accesses to these special members. All
accesses to members of a union thus get the same offset, which
is the offset of the union they are part of. This means the
existing LLVM TBAA machinery is able to handle such accesses
with no changes.
While this is already an improvement comparing to the current
situation, that is, representing all union accesses as may-alias
ones, there are further changes planned to complete the support
for unions. One of them is storing information about access sizes
so we can distinct accesses to non-overlapping union members,
including accesses to different elements of member arrays.
Another change is encoding type sizes in order to make it
possible to compute offsets within constant-indexed array
elements. These enhancements will be addressed with separate
patches.
Differential Revision: https://reviews.llvm.org/D39455
llvm-svn: 319413
Sometimes we check the validity of some construct between producing a
diagnostic and producing its notes. Ideally, we wouldn't do that, but in
practice running code that "cannot possibly produce a diagnostic" in such a
situation should be safe, and reasonable factoring of some code requires it
with our current diagnostics infrastruture. If this does happen, a diagnostic
that's suppressed due to SFINAE should not cause notes connected to the prior
diagnostic to be suppressed.
llvm-svn: 319408
Summary:
The -fxray-always-emit-customevents flag instructs clang to always emit
the LLVM IR for calls to the `__xray_customevent(...)` built-in
function. The default behaviour currently respects whether the function
has an `[[clang::xray_never_instrument]]` attribute, and thus not lower
the appropriate IR code for the custom event built-in.
This change allows users calling through to the
`__xray_customevent(...)` built-in to always see those calls lowered to
the corresponding LLVM IR to lay down instrumentation points for these
custom event calls.
Using this flag enables us to emit even just the user-provided custom
events even while never instrumenting the start/end of the function
where they appear. This is useful in cases where "phase markers" using
__xray_customevent(...) can have very few instructions, must never be
instrumented when entered/exited.
Reviewers: rnk, dblaikie, kpw
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40601
llvm-svn: 319388
This matches MSVC's behaviour, and we already do it for class templates
since r270897.
Differential revision: https://reviews.llvm.org/D40621
llvm-svn: 319386
Richard Trieu