llvm-svn: 333088

llvm-svn: 333087

Summary:
Currently we do not import the implicit CXXRecordDecl of a
ClassTemplateSpecializationDecl. This patch fixes it.

Reviewers: a.sidorin, xazax.hun, r.stahl

Subscribers: rnkovacs, dkrupp, cfe-commits

Differential Revision: https://reviews.llvm.org/D47057

llvm-svn: 333086

Summary:
This patch fixes two bugs in clang-format where the template wrapper doesn't skip over
comments causing a long template declaration to not be split into multiple lines.
These were latent and exposed by r332436.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D47257

llvm-svn: 333085

llvm-svn: 333084

llvm-svn: 333083

Summary:
We fail to import a `ClassTemplateDecl` if the "To" context already
contains a definition and then a forward decl.  This is because
`localUncachedLookup` does not find the definition.  This is not a
lookup error, the parser behaves differently than assumed in the
importer code.  A `DeclContext` contains one DenseMap (`LookupPtr`)
which maps names to lists.  The list is a special list `StoredDeclsList`
which is optimized to have one element.  During building the initial
AST, the parser first adds the definition to the `DeclContext`.  Then
during parsing the second declaration (the forward decl) the parser
again calls `DeclContext::addDecl` but that will not add a new element
to the `StoredDeclsList` rarther it simply overwrites the old element
with the most recent one.  This patch fixes the error by finding the
definition in the redecl chain.  Added tests for the same issue with
`CXXRecordDecl` and with `ClassTemplateSpecializationDecl`.  These tests
pass and they pass because in `VisitRecordDecl` and in
`VisitClassTemplateSpecializationDecl` we already use
`D->getDefinition()` after the lookup.

Reviewers: a.sidorin, xazax.hun, szepet

Subscribers: rnkovacs, dkrupp, cfe-commits

Differential Revision: https://reviews.llvm.org/D46950

llvm-svn: 333082

llvm-svn: 333080

For RISC-V it is desirable to have relaxation happen in the linker once 
addresses are known, and as such the size between two instructions/byte 
sequences in a section could change.

For most assembler expressions, this is fine, as the absolute address results 
in the expression being converted to a fixup, and finally relocations. 
However, for expressions such as .quad .L2-.L1, the assembler folds this down 
to a constant once fragments are laid out, under the assumption that the 
difference can no longer change, although in the case of linker relaxation the 
differences can change at link time, so the constant is incorrect. One place 
where this commonly appears is in debug information, where the size of a 
function expression is in a form similar to the above.

This patch extends the assembler to allow an AsmBackend to declare that it 
does not want the assembler to fold down this expression, and instead generate 
a pair of relocations that allow the linker to carry out the calculation. In 
this case, the expression is not folded, but when it comes to emitting a 
fixup, the generic FK_Data_* fixups are converted into a pair, one for the 
addition half, one for the subtraction, and this is passed to the relocation 
generating methods as usual. I have named these FK_Data_Add_* and 
FK_Data_Sub_* to indicate which half these are for.

For RISC-V, which supports this via e.g. the R_RISCV_ADD64, R_RISCV_SUB64 pair 
of relocations, these are also set to always emit relocations relative to 
local symbols rather than section offsets. This is to deal with the fact that 
if relocations were calculated on e.g. .text+8 and .text+4, the result 12 
would be stored rather than 4 as both addends are added in the linker.

Differential Revision: https://reviews.llvm.org/D45181
Patch by Simon Cook.

llvm-svn: 333079

The Sparc asm parser currently has custom parsing logic for .half, .word, 
.nword and .xword. Rather than use this custom logic, we can just use 
addAliasForDirective to enable the reuse of AsmParser::parseDirectiveValue.

https://reviews.llvm.org/D47003

llvm-svn: 333078

The AArch64 asm parser currently has custom parsing logic for .hword, .word, 
and .xword. Rather than use this custom logic, we can just use 
addAliasForDirective to enable the reuse of AsmParser::parseDirectiveValue.

Differential Revision: https://reviews.llvm.org/D47000

llvm-svn: 333077

This is a different approach to fixing the problem described in D46746. 
RISCVAsmBackend currently depends on the getSize helper function returning the 
number of bytes a fixup may change (note: some other backends have a similar 
helper named getFixupNumKindBytes). As noted in that review, this doesn't 
return the correct size for FK_Data_1, FK_Data_2, or FK_Data_8 meaning that 
too few bytes will be written in the case of FK_Data_8, and there's the 
potential of writing outside the Data array for the smaller fixups.

D46746 extends getSize to recognise some of the builtin fixup types. Rather 
than having a function that needs to be kept up to date as new builtin or 
target-specific fixups are added, We can calculate an appropriate bound on the 
number of bytes that might be touched using Info.TargetSize and 
Info.TargetOffset.

Differential Revision: https://reviews.llvm.org/D46965

llvm-svn: 333076

There is need to use internal_syscall64() instead of internal_syscall_ptr().
The offset argument of type off_t is always 64-bit.

llvm-svn: 333075

The tests added in r332842 don't work on windows, because they do path
comparisons on strings, and on windows, the paths coming out of the
mappings had backslashes in them.

This switches comparisons to FileSpecs, so the results come out right.

llvm-svn: 333074

This call was originally being only made when launching for debug (as an
attempt to make sure we don't impart extra privileges on the launched
process), but after the debug and non-debug paths were merged, it made
it's way into generic code. This was causing problems in locked down
android environments which disallowed calling setgid even if it would be
a no-op. This prevented launching llgs from lldb-server platform.

Overall I'm not sure we should be calling setgid in the first place
(it seems random -- e.g. why don't we call setuid then as well).
However, all our other copies of launch code have it, so I choose to
keep it for now.

llvm-svn: 333073

Loop unswitching makes substantial changes to a loop that can also affect cached
SCEV info in its outer loops as well, but it only cares to invalidate SCEV cache for the
innermost loop in case of full unswitching and does not invalidate anything at all in
case of trivial unswitching. As result, we may end up with incorrect data in cache.

Differential Revision: https://reviews.llvm.org/D46045
Reviewed By: mzolotukhin

llvm-svn: 333072

Differential Revision: https://reviews.llvm.org/D46004

llvm-svn: 333071

Summary:
Patch for capture tracking broke
bootstrap of clang with -fstict-vtable-pointers
which resulted in debbugging nightmare. It was fixed
https://reviews.llvm.org/D46900 but as it turned
out, there were other parts like inliner (computing of
noalias metadata) that I found after bootstraping with enabled
assertions.

Reviewers: hfinkel, rsmith, chandlerc, amharc, kuhar

Subscribers: JDevlieghere, eraman, llvm-commits, hiraditya

Differential Revision: https://reviews.llvm.org/D47088

llvm-svn: 333070

Summary: The blob data is unaligned, so we also should read it as such. Should fix the random failures with the sanitizer builds.

Reviewers: rsmith, v.g.vassilev

Reviewed By: v.g.vassilev

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D47247

llvm-svn: 333069

Reviewers: jyknight

Reviewed By: jyknight

Subscribers: fedor.sergeev, jrtc27, llvm-commits

Differential Revision: https://reviews.llvm.org/D47140

llvm-svn: 333068

It caused asserts, see PR37560.

> Use zeroinitializer for (trailing zero portion of) large array initializers
> more reliably.
>
> Clang has two different ways it emits array constants (from InitListExprs and
> from APValues), and both had some ability to emit zeroinitializer, but neither
> was able to catch all cases where we could use zeroinitializer reliably. In
> particular, emitting from an APValue would fail to notice if all the explicit
> array elements happened to be zero. In addition, for large arrays where only an
> initial portion has an explicit initializer, we would emit the complete
> initializer (which could be huge) rather than emitting only the non-zero
> portion. With this change, when the element would have a suffix of more than 8
> zero elements, we emit the array constant as a packed struct of its initial
> portion followed by a zeroinitializer constant for the trailing zero portion.
>
> In passing, I found a bug where SemaInit would sometimes walk the entire array
> when checking an initializer that only covers the first few elements; that's
> fixed here to unblock testing of the rest.
>
> Differential Revision: https://reviews.llvm.org/D47166

llvm-svn: 333067

Summary:
Checks for narrowing conversions, e.g.

int i = 0;
i += 0.1;

This has what some might consider false positives for:
i += ceil(d);

Reviewers: alexfh, hokein

Subscribers: srhines, nemanjai, mgorny, JDevlieghere, xazax.hun, kbarton

Differential Revision: https://reviews.llvm.org/D38455

llvm-svn: 333066

(1) I added some \see cross-references to a few select intrinsics that are related (and have the same or similar semantics). 

(2) pmmintrin.h, smmintrin.h, xmmintrin.h have very few minor formatting changes. They make rendering of our intrinsics documentation better. 

llvm-svn: 333065

These are implementation helper macros we shouldn't expose them to user code if we don't need to.

llvm-svn: 333064

SafepointIRVerifier crashed while traversing blocks without a DomTreeNode.
This could happen with a custom pipeline or when some optional passes were skipped by OptBisect.

SafepointIRVerifier is fixed to traverse basic blocks that are reachable from entry. Test are added.

Patch Author: Yevgeny Rouban!
Reviewers: anna, reames, dneilson, DaniilSuchkov, skatkov
Reviewed By: reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47011

llvm-svn: 333063

Previously we negated the whole vector after splatting infinity. But its better to negate the infinity before splatting. This generates IR with the negate already folded with the infinity constant.

llvm-svn: 333062

[X86] Remove mask argument from more builtins that are handled completely in CGBuiltin.cpp. Just wrap a select builtin around them in the header file instead.

llvm-svn: 333061

Again, strlc* does not return a pointer so the zero size case doest not fit.

Reviewers: NoQ, george.karpenkov

Reviewed by: NoQ

Differential Revision: https://reviews.llvm.org/D47007

llvm-svn: 333060

llvm-svn: 333059

llvm-svn: 333058

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D47243

llvm-svn: 333057

Also bringing ARMRegisterBankInfo::getRegBankFromRegClass
implementation up to speed with the *.td-definition.

Reviewed By: qcolombet

Differential Revision: https://reviews.llvm.org/D43982

llvm-svn: 333056

llvm-svn: 333055

A user program may enumerate sections named with a C identifier using
__start_* and __stop_* symbols. We cannot ICF any such sections because
that could change program semantics.

Differential Revision: https://reviews.llvm.org/D47242

llvm-svn: 333054

This patch continues a series of patches started by r332907 (reapplied
as r332917)

In this commit we start grouping rules with common first condition on
the second level of the table.

This is expected to decrease time GlobalISel spends in its
InstructionSelect pass by roughly 13% for an -O0 build as measured on
sqlite3-amalgamation (http://sqlite.org/download.html) targeting
AArch64.

Reviewers: qcolombet, dsanders, bogner, aemerson, javed.absar

Reviewed By: qcolombet

Subscribers: rovka, llvm-commits, kristof.beyls

Differential Revision: https://reviews.llvm.org/D44700

llvm-svn: 333053

Note that this doesn't do the right thing in the case where there is
a linker script. We probably need to move output section assignment
before ICF to get the correct behaviour here.

Differential Revision: https://reviews.llvm.org/D47241

llvm-svn: 333052

The wchar_t is unsigned. 

https://msdn.microsoft.com/en-us/library/s3f49ktz.aspx

llvm-svn: 333051

llvm-svn: 333050

Summary:
Implement FindGlobalVariables and ParseVariableContext methods.

Compile unit information is necessary for resolving variable context, however some PDB symbols do not have this information. For now an empty DWARFExpression is used to construct a lldb::Variable instance with the limitation that using lldb to lookup the value of a global or local variable is not available.

This commit may slow down lit/SymbolFile/PDB/compilands.test since the test includes MS specific modules that spend more time parsing variables.

Reviewers: rnk, zturner, lldb-commits

Subscribers: aprantl, JDevlieghere, llvm-commits

Differential Revision: https://reviews.llvm.org/D45224

llvm-svn: 333049

llvm-svn: 333048