Michael Liao [Fri, 29 Mar 2019 03:55:52 +0000 (03:55 +0000)]
[Sema] Fix a crash when nonnull checking
Summary:
- If a parameter is used, nonnull checking needs function prototype to
retrieve the corresponding parameter's attributes. However, at the
prototype substitution phase when a template is being instantiated,
expression may be created and checked without a fully specialized
prototype. Under such a scenario, skip nonnull checking on that
argument.
Akira Hatanaka [Fri, 29 Mar 2019 00:23:20 +0000 (00:23 +0000)]
[CodeGen][ObjC] Adjust the addresses passed to calls to synthesized
copy/move constructor/assignment operator functions for non-trivial C
structs.
This commit fixes a bug where the offset of struct fields weren't being
taken into account when computing the addresses passed to calls to the
special functions.
For example, the copy constructor for S1 (__copy_constructor_8_8_s0_s8)
would pass the start addresses of the destination and source structs to
the call to S0's copy constructor (_copy_constructor_8_8_s0) without
adding the offset of field f1 to the addresses.
Alexey Bataev [Thu, 28 Mar 2019 19:15:36 +0000 (19:15 +0000)]
[OPENMP]Add check for undefined behavior with thread allocators on
target and task-based directives.
According to OpenMP 5.0, 2.11.4 allocate Clause, Restrictions, For task,
taskloop or target directives, allocation requests to memory allocators
with the trait access set to thread result in unspecified behavior.
Patch introduces a check for omp_thread_mem_alloc predefined allocator
on target- and trask-based directives.
Shoaib Meenai [Thu, 28 Mar 2019 17:01:20 +0000 (17:01 +0000)]
[CodeGen] Add additional mangling for struct members of non trivial structs
In https://bugs.llvm.org/show_bug.cgi?id=41206 we observe bad codegen
when embedding a non-trivial C struct within a C struct. This is due to
the fact that name mangling for non-trivial structs marks the two
structs as identical. This diff contains a fix for this issue.
Adam Balogh [Thu, 28 Mar 2019 13:05:59 +0000 (13:05 +0000)]
[Analyzer] Constraint Manager - Calculate Effective Range for Differences
Since rL335814, if the constraint manager cannot find a range set for `A - B`
(where `A` and `B` are symbols) it looks for a range for `B - A` and returns
it negated if it exists. However, if a range set for both `A - B` and `B - A`
is stored then it only returns the first one. If we both use `A - B` and
`B - A`, these expressions behave as two totally unrelated symbols. This way
we miss some useful deductions which may lead to false negatives or false
positives.
This tiny patch changes this behavior: if the symbolic expression the
constraint manager is looking for is a difference `A - B`, it tries to
retrieve the range for both `A - B` and `B - A` and if both exists it returns
the intersection of range `A - B` and the negated range of `B - A`. This way
every time a checker applies new constraints to the symbolic difference or to
its negated it always affects both the original difference and its negated.
Fangrui Song [Thu, 28 Mar 2019 08:24:00 +0000 (08:24 +0000)]
[Driver] Allow -gsplit-dwarf on ELF OSes other than Linux and Fuchsia
In gcc, -gsplit-dwarf is handled in gcc/gcc.c as a spec
(ASM_FINAL_SPEC): objcopy --extract-dwo + objcopy --strip-dwo. In
gcc/opts.c, -gsplit_dwarf has the same semantic of a -g. Except for the
availability of the external command 'objcopy', nothing precludes the
feature working on other ELF OSes. llvm doesn't use objcopy, so it doesn't
have to exclude other OSes.
Shafik Yaghmour [Wed, 27 Mar 2019 17:47:36 +0000 (17:47 +0000)]
[ASTImporter] Fix IsStructuralMatch specialization for EnumDecl to prevent re-importing an EnumDecl while trying to complete it
Summary:
We may try and re-import an EnumDecl while trying to complete it in IsStructuralMatch(...) specialization for EnumDecl. This change mirrors a similar fix for the specialization for RecordDecl.
Erik Pilkington [Tue, 26 Mar 2019 23:21:19 +0000 (23:21 +0000)]
[Sema] Fix an assert when a block captures a constexpr local
MarkVarDeclODRUsed indirectly calls captureInBlock, which creates a copy
expression. The copy expression is insulated in it's own
ExpressionEvaluationContext, so it saves, mutates, and restores MaybeODRUseExprs
as CleanupVarDeclMarking is iterating through it, leading to a crash. Fix this
by iterating through a local copy of MaybeODRUseExprs.
Basic: Return a reference from FileManager::getVirtualFileSystem, NFC
FileManager constructs a VFS in its constructor if it isn't passed one,
and there's no way to reset it. Make that contract clear by returning a
reference from its accessor.
Remove CompilerInstance::VirtualFileSystem and
CompilerInstance::setVirtualFileSystem, instead relying on the VFS in
the FileManager. CompilerInstance and its clients already went to some
trouble to make these match. Now they are guaranteed to match.
As part of this, I added a VFS parameter (defaults to nullptr) to
CompilerInstance::createFileManager, to avoid repeating construction
logic in clients that just wanted to customize the VFS.
Shoaib Meenai [Tue, 26 Mar 2019 22:16:53 +0000 (22:16 +0000)]
[cmake] Reset variable before using it
A bunch of macros use the same variable name, and since CMake macros
don't get their own scope, the value persists across macro invocations,
and we can end up exporting targets which shouldn't be exported. Clear
the variable before each use to avoid this.
Converting these macros to functions would also help, since it would
avoid the variable leaking into its parent scope, and that's something I
plan to follow up with. It won't fully address the problem, however,
since functions still inherit variables from their parent scopes, so if
someone in the parent scope just happened to use the same variable name
we'd still have the same issue.
Jessica Paquette [Tue, 26 Mar 2019 21:22:42 +0000 (21:22 +0000)]
Make -mno-outline pass -enable-machine-outliner=never to ld in LTO
Since AArch64 has default outlining behaviour, we need to make sure that
-mno-outline is actually passed along to the linker in this case. Otherwise,
it will run by default on minsize functions even when -mno-outline is specified.
Also fix the darwin-ld test for this, which wasn't actually doing anything.
Artem Dergachev [Tue, 26 Mar 2019 00:36:53 +0000 (00:36 +0000)]
[CFG] [analyzer] pr41142: C++17: Skip transparent InitListExprs in ExprEngine.
r356634 didn't fix all the problems caused by r356222 - even though simple
constructors involving transparent init-list expressions are now evaluated
precisely, many more complicated constructors aren't, for other reasons.
The attached test case is an example of a constructor that will never be
evaluated precisely - simply because there isn't a constructor there (instead,
the program invokes run-time undefined behavior by returning without a return
statement that should have constructed the return value).
Fix another part of the problem for such situations: evaluate transparent
init-list expressions transparently, so that to avoid creating ill-formed
"transparent" nonloc::CompoundVals.
Reid Kleckner [Mon, 25 Mar 2019 23:20:18 +0000 (23:20 +0000)]
[MS] Add frontend support for __declspec(allocator)
The intention is to add metadata to direct call sites of functions
marked with __declspec(allocator), which will ultimately result in some
S_HEAPALLOCSITE debug info records when emitting codeview.
Bruno Ricci [Mon, 25 Mar 2019 21:37:10 +0000 (21:37 +0000)]
[Sema] Don't check for array bounds when the types in the base expression are dependent
Bail-out of CheckArrayAccess when the types of the base expression before
and after eventual casts are dependent. We will get another chance to check
for array bounds during instantiation. Fixes PR41087.
Sam Clegg [Mon, 25 Mar 2019 21:14:26 +0000 (21:14 +0000)]
[WebAssembly] Don't use default GetLinkerPath
We can't (don't want to) honor the same set of "-fuse-ld" flags with
WebAssembly since the ELF linkers (ld.lld, ld.gnu, etc) don't work with
wasm object files.
Instead we implement our own linker finding logic, similar or other
non-ELF platforms like MSVC.
We've had a few issues with CLANG_DEFAULT_LINKER overriding the
WebAssembly linker which doesn't make sense since there is no generic
linker that can handle WebAssembly today.
JF Bastien [Mon, 25 Mar 2019 20:06:32 +0000 (20:06 +0000)]
Thread Safety: also look at ObjC methods
Summary:
SExprBuilder::translateDeclRefExpr was only looking at FunctionDecl and not also looking at ObjCMethodDecl. It should consider both because the attributes can be used on Objective-C as well.
Sylvestre Ledru [Mon, 25 Mar 2019 18:06:20 +0000 (18:06 +0000)]
clang -dumpversion returns 4.2.1 for legacy reason, update it
Summary:
It has been introduced in 2011 for gcc compat:
https://github.com/llvm-mirror/clang/commit/95a907fc0f2f717dca38a379c1d2353bfea06d4f
it is probably time to remove it to remove the confusion.
Bruno Ricci [Mon, 25 Mar 2019 17:08:51 +0000 (17:08 +0000)]
[Sema][NFCI] Don't allocate storage for the various CorrectionCandidateCallback unless we are going to do some typo correction
The various CorrectionCandidateCallbacks are currently heap-allocated
unconditionally. This was needed because of delayed typo correction.
However these allocations represent currently 15.4% of all allocations
(number of allocations) when parsing all of Boost (!), mostly because
of ParseCastExpression, ParseStatementOrDeclarationAfterAttrtibutes
and isCXXDeclarationSpecifier. Note that all of these callback objects
are small. Let's not do this.
Instead initially allocate the callback on the stack, and only do a
heap allocation if we are going to do some typo correction. Do this by:
1. Adding a clone function to each callback, which will do a polymorphic
clone of the callback. This clone function is required to be implemented
by every callback (of which there is a fair amount). Make sure this is
the case by making it pure virtual.
2. Use this clone function when we are going to try to correct a typo.
This additionally cut the time of -fsyntax-only on all of Boost by 0.5%
(not that much, but still something). No functional changes intended.
Brian Gesiak [Mon, 25 Mar 2019 00:53:10 +0000 (00:53 +0000)]
Un-revert "[coroutines][PR40978] Emit error for co_yield within catch block"
Summary:
https://reviews.llvm.org/D59076 added a new coroutine error that
prevented users from using 'co_await' or 'co_yield' within a exception
handler. However, it was reverted in https://reviews.llvm.org/rC356774
because it caused a regression in nested scopes in C++ catch statements,
as documented by https://bugs.llvm.org/show_bug.cgi?id=41171.
The issue was due to an incorrect use of a `clang::ParseScope`. To fix:
1. Add a regression test for catch statement parsing that mimics the bug
report from https://bugs.llvm.org/show_bug.cgi?id=41171.
2. Re-apply the coroutines error patch from
https://reviews.llvm.org/D59076, but this time with the correct
ParseScope behavior.
Hubert Tong [Sat, 23 Mar 2019 18:10:45 +0000 (18:10 +0000)]
libclang/CIndexer.cpp: Use loadquery() on AIX for path to library
Summary:
`dladdr` is not available on AIX. Similar functionality is presented
through `loadquery`. This patch replaces a use of `dladdr` with a
version based on `loadquery`.
Sylvestre Ledru [Sat, 23 Mar 2019 17:57:31 +0000 (17:57 +0000)]
Sync some doc changes ClangFormatStyleOptions.rst with doc comments in `Format.h`
Summary:
These changes were corrected directly in ClangFormatStyleOptions.rst (llvm-svn: 350192 and llvm-svn: 351976) but these sections can be produced automatically using `dump_format_style.py` so sync the corresponding doc comments in `Format.h` as well.
Paul Hoad [Sat, 23 Mar 2019 14:37:58 +0000 (14:37 +0000)]
Clang-format: add finer-grained options for putting all arguments on one line
Summary:
Add two new options,
AllowAllArgumentsOnNextLine and
AllowAllConstructorInitializersOnNextLine. These mirror the existing
AllowAllParametersOfDeclarationOnNextLine and allow me to support an
internal style guide where I work. I think this would be generally
useful, some have asked for it on stackoverflow:
James Y Knight [Fri, 22 Mar 2019 18:27:13 +0000 (18:27 +0000)]
IR: Support parsing numeric block ids, and emit them in textual output.
Just as as llvm IR supports explicitly specifying numeric value ids
for instructions, and emits them by default in textual output, now do
the same for blocks.
This is a slightly incompatible change in the textual IR format.
Previously, llvm would parse numeric labels as string names. E.g.
define void @f() {
br label %"55"
55:
ret void
}
defined a label *named* "55", even without needing to be quoted, while
the reference required quoting. Now, if you intend a block label which
looks like a value number to be a name, you must quote it in the
definition too (e.g. `"55":`).
Previously, llvm would print nameless blocks only as a comment, and
would omit it if there was no predecessor. This could cause confusion
for readers of the IR, just as unnamed instructions did prior to the
addition of "%5 = " syntax, back in 2008 (PR2480).
Now, it will always print a label for an unnamed block, with the
exception of the entry block. (IMO it may be better to print it for
the entry-block as well. However, that requires updating many more
tests.)
Thus, the following is supported, and is the canonical printing:
define i32 @f(i32, i32) {
%3 = add i32 %0, %1
br label %4
4:
ret i32 %3
}
New test cases covering this behavior are added, and other tests
updated as required.
Brian Gesiak [Fri, 22 Mar 2019 16:08:29 +0000 (16:08 +0000)]
Revert "[coroutines][PR40978] Emit error for co_yield within catch block"
The commit https://reviews.llvm.org/rC356296 is causing a regression in nested
catch scopes, https://bugs.llvm.org/show_bug.cgi?id=41171. Revert this change
for now in order to un-break that problem report.
Alexey Bataev [Fri, 22 Mar 2019 15:25:12 +0000 (15:25 +0000)]
[OPENMP]Allow no allocator clause in target regions with requires
dynamic_allocators.
According to the OpenMP 5.0, 2.11.3 allocate Directive, Restrictions,
allocate directives that appear in a target region must specify an
allocator clause unless a requires directive with the dynamic_allocators
clause is present in the same compilation unit. Patch adds a check for a
presence of the requires directive with the dynamic_allocators clause.
Alexey Bataev [Fri, 22 Mar 2019 14:41:39 +0000 (14:41 +0000)]
[OPENMP]Emit error message for allocate directive without allocator
clause in target region.
According to the OpenMP 5.0, 2.11.3 allocate Directive, Restrictions,
allocate directives that appear in a target region must specify an
allocator clause unless a requires directive with the dynamic_allocators
clause is present in the same compilation unit.
Roman Lebedev [Fri, 22 Mar 2019 13:40:36 +0000 (13:40 +0000)]
[AST] OMPStructuredBlockTest: avoid using multiline string literals in macros
That is what i have been doing elsewhere in these tests, maybe that's it?
Maybe this helps with failing builds:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/17921
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-global-isel/builds/10248
Amara Emerson [Thu, 21 Mar 2019 22:31:37 +0000 (22:31 +0000)]
[AArch64] Split the neon.addp intrinsic into integer and fp variants.
This is the result of discussions on the list about how to deal with intrinsics
which require codegen to disambiguate them via only the integer/fp overloads.
It causes problems for GlobalISel as some of that information is lost during
translation, while with other operations like IR instructions the information is
encoded into the instruction opcode.
This patch changes clang to emit the new faddp intrinsic if the vector operands
to the builtin have FP element types. LLVM IR AutoUpgrade has been taught to
upgrade existing calls to aarch64.neon.addp with fp vector arguments, and
we remove the workarounds introduced for GlobalISel in r355865.
Richard Smith [Thu, 21 Mar 2019 20:42:13 +0000 (20:42 +0000)]
Improve the diagnostic for #include_next occurring in a file not found
in the include path.
Instead of making the incorrect claim that the included file has an
absolute path, describe the actual problem: the including file was found
either by absolute path, or relative to such a file, or relative to the
primary source file.
Craig Topper [Thu, 21 Mar 2019 20:07:24 +0000 (20:07 +0000)]
[Driver] Pass -malign-double from the driver to the cc1 command line
-malign-double is currently only implemented in the -cc1 interface. But its declared in Options.td so it is a driver option too. But you try to use it with the driver you'll get a message about the option being unused.
This patch teaches the driver to pass the option through to cc1 so it won't be unused. The Options.td says the option is x86 only but I didn't see any x86 specific code in its impementation in cc1 so not sure if the documentation is wrong or if I should only pass this option through the driver on x86 targets.
Richard Smith [Thu, 21 Mar 2019 19:44:17 +0000 (19:44 +0000)]
Refactor handling of #include directives to cleanly separate the
"skipped header because it should be imported as a module" cases from
the "skipped header because of some other reason" cases.
Alexey Bataev [Thu, 21 Mar 2019 19:35:27 +0000 (19:35 +0000)]
[OPENMP]Codegen support for allocate directive on global variables.
For the global variables the allocate directive must specify only the
predefined allocator. This allocator must be translated into the correct
form of the address space for the targets that support different address
spaces.
Alexey Bataev [Thu, 21 Mar 2019 19:05:07 +0000 (19:05 +0000)]
[OPENMP]Simplify the check for the predefined allocators, NFC.
Previously implemented check required the reevaluation of the already
evaluated predefined allocator kind for the global variables. Patch
simplifies this evaluation and removes extra code.
Craig Topper [Thu, 21 Mar 2019 17:43:53 +0000 (17:43 +0000)]
[X86] Add __popcntd and __popcntq to ia32intrin.h to match gcc and icc. Remove popcnt feature flag from _popcnt32/_popcnt64 and move to ia32intrin.h to match gcc
gcc and icc both implement popcntd and popcntq which we did not. gcc doesn't seem to require a feature flag for the _popcnt32/_popcnt64 spelling and will use a libcall if its not supported.
Summary:
`OMPClause` is the base class, it is not descendant from **any**
other class, therefore for it to work with e.g.
`VariadicDynCastAllOfMatcher<>`, it needs to be handled here.
Erich Keane [Thu, 21 Mar 2019 13:30:56 +0000 (13:30 +0000)]
Permit redeclarations of a builtin to specify calling convention.
After https://reviews.llvm.org/rL355317 we noticed that quite a decent
amount of code redeclares builtins (memcpy in particular, I believe
reduced from an MSVC header) with a calling convention specified.
This gets particularly troublesome when the user specifies a new
'default' calling convention on the command line.
When looking to add a diagnostic for this case, it was noticed that we
had 3 other diagnostics that differed only slightly. This patch ALSO
unifies those under a 'select'. Unfortunately, the order of words in
ONE of these diagnostics was reversed ("'thiscall' calling convention"
vs "calling convention 'thiscall'"), so this patch also standardizes on
the former.
Paul Hoad [Thu, 21 Mar 2019 13:09:22 +0000 (13:09 +0000)]
[clang-format] Add basic support for formatting C# files
Summary:
This revision adds basic support for formatting C# files with clang-format, I know the barrier to entry is high here so I'm sending this revision in to test the water as to whether this might be something we'd consider landing.
Tracking in Bugzilla as:
https://bugs.llvm.org/show_bug.cgi?id=40850
Justification:
C# code just looks ugly in comparison to the C++ code in our source tree which is clang-formatted.
I've struggled with Visual Studio reformatting to get a clean and consistent style, I want to format our C# code on saving like I do now for C++ and i want it to have the same style as defined in our .clang-format file, so it consistent as it can be with C++. (Braces/Breaking/Spaces/Indent etc..)
Using clang format without this patch leaves the code in a bad state, sometimes when the BreakStringLiterals is set, it fails to compile.
Mostly the C# is similar to Java, except instead of JavaAnnotations I try to reuse the TT_AttributeSquare.
Almost the most valuable portion is to have a new Language in order to partition the configuration for C# within a common .clang-format file, with the auto detection on the .cs extension. But there are other C# specific styles that could be added later if this is accepted. in particular how `{ set;get }` is formatted.
This CL causes our creduce-clang-crash.py util to:
- try to preprocess the file before reducing
- try to remove some command line arguments
- now require a llvm bin directory, since the generated crash script
doesn't have an absolute path for clang
It also marks it as executable, since I forgot to do that in the last
commit. :)
Artem Dergachev [Thu, 21 Mar 2019 00:15:07 +0000 (00:15 +0000)]
[CFG] [analyzer] pr41142: C++17: Skip transparent InitListExprs in constructors.
When searching for construction contexts, i.e. figuring out which statements
define the object that is constructed by each construct-expression, ignore
transparent init-list expressions because they don't add anything to the
context. This allows the Static Analyzer to model construction, destruction,
materialization, lifetime extension correctly in more cases. Also fixes
a crash caused by incorrectly evaluating initial values of variables
initialized with such expressions.
Jordan Rupprecht [Wed, 20 Mar 2019 21:01:56 +0000 (21:01 +0000)]
[clang][OpenMP] Fix build when using libgomp
Summary: rL356570 introduced a test which only passes with the default openmp library, libomp, and fails with other openmp libraries, such as libgomp. Explicitly choose libomp.
Alexey Bataev [Wed, 20 Mar 2019 20:14:22 +0000 (20:14 +0000)]
[OPENMP]Improve detection of omp_allocator_handle_t type and predefined
allocators.
It is better to deduce omp_allocator_handle_t type from the predefined
allocators, because omp.h header might not define it explicitly. Plus,
it allows to identify the predefined allocators correctly when trying to
build the allcoator for the global variables.
Erik Pilkington [Wed, 20 Mar 2019 19:26:33 +0000 (19:26 +0000)]
[Sema] Deduplicate some availability checking logic
Before this commit, we emit unavailable errors for calls to functions during
overload resolution, and for references to all other declarations in
DiagnoseUseOfDecl. The early checks during overload resolution aren't as good as
the DiagnoseAvailabilityOfDecl based checks, as they error on the code from
PR40991. This commit fixes this by removing the early checking.
projects / clang / log