It is possible to craft a .hash section that triggers an infinite loop
in llvm-readelf code. This patch fixes the issue and introduces
a warning.

Differential revision: https://reviews.llvm.org/D68086

llvm-svn: 373476

The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.

llvm-svn: 373475

The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.

llvm-svn: 373474

This is a follow-up for D68085 which allows using "Size"
tag together with "Content" tag or alone.

Differential revision: https://reviews.llvm.org/D68216

llvm-svn: 373473

Summary:
This patch disable extraction of the body of the enclosing function.
`void f() [[{}]]`

Extracting this CompoundStmt would leave the enclosing function without
a body.

Reviewers: sammccall, kadircet

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

llvm-svn: 373472

Summary:
We weren't always checking if children are RootStmts in ExtractFunction.

For `void f([[int a]]);`, the ParmVarDecl appeared as a RootStmt since
we didn't perform the check and ended up being casted to a (null) Stmt.

Reviewers: sammccall, kadircet

Subscribers: kristof.beyls, ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

llvm-svn: 373471

This makes sure that we associate DIEs that are imported from other CUs with the appropriate decl context.

Without this fix, nested classes can be dumped directly into their CU context if their parent was imported from another CU.

Reviewed By: teemperor, labath

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

Patch by Jaroslav Sevcik!

llvm-svn: 373470

llvm-svn: 373469

Summary: This patch includes tests for the VecOfBitcastsToInt type added by D68021

Reviewers: c-rhodes, sdesmalen, rovka

Reviewed By: c-rhodes

Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl, llvm-commits, cfe-commits

Tags: #llvm

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

llvm-svn: 373468

MemorySSAUpdater::applyInsertUpdates - silence static analyzer dyn_cast<MemoryAccess> null dereference warning. NFCI.

The static analyzer is warning about a potential null dereference, but we should be able to use cast<MemoryAccess> directly and if not assert will fire for us.

llvm-svn: 373467

Silences static analyzer null dereference warning.

llvm-svn: 373466

LoopAccessAnalysis isConsecutiveAccess() - silence static analyzer dyn_cast<SCEVConstant> null dereference warning. NFCI.

The static analyzer is warning about potential null dereferences, but in these cases we should be able to use cast<SCEVConstant> directly and if not assert will fire for us.

llvm-svn: 373465

All the calls to emitGlobalConstantFP should provide a nonnull Type for the float.

llvm-svn: 373464

llvm-svn: 373463

Summary:
This extends the PeelingModuloScheduleExpander to generate prolog and epilog code,
and correctly stitch uses through the prolog, kernel, epilog DAG.

The key concept in this patch is to ensure that all transforms are *local*; only a
function of a block and its immediate predecessor and successor. By defining the problem in this way
we can inductively rewrite the entire DAG using only local knowledge that is easy to
reason about.

For example, we assume that all prologs and epilogs are near-perfect clones of the
steady-state kernel. This means that if a block has an instruction that is predicated out,
we can redirect all users of that instruction to that equivalent instruction in our
immediate predecessor. As all blocks are clones, every instruction must have an equivalent in
every other block.

Similarly we can make the assumption by construction that if a value defined in a block is used
outside that block, the only possible user is its immediate successors. We maintain this
even for values that are used outside the loop by creating a limited form of LCSSA.

This code isn't small, but it isn't complex.

Enabled a bunch of testing from Hexagon. There are a couple of tests not enabled yet;
I'm about 80% sure there isn't buggy codegen but the tests are checking for patterns
that we don't produce. Those still need a bit more investigation. In the meantime we
(Google) are happy with the code produced by this on our downstream SMS implementation,
and believe it generates correct code.

Subscribers: mgorny, hiraditya, jsji, llvm-commits

Tags: #llvm

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

llvm-svn: 373462

Fixes PR43181. This option was recently added to GNU objcopy (binutils
PR24942).

`llvm-objcopy -I binary -O elf64-x86-64 --set-section-alignment .data=8` can set the alignment of .data.

Reviewed By: grimar, jhenderson, rupprecht

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

llvm-svn: 373461

We now only use this function directly after initialization. As Clear()
resets the ASTContext back to its initial state, this is just a no-op.
There are no other users for this and we no longer can set the ASTContext
after construction, so Clear has no useful purpose anymore. It's also
mostly copy-pasted from Finalize().

llvm-svn: 373460

In similar fashion to D67721, we can simplify FMA multiplications if any
of the operands is NaN or undef. In instcombine, we will simplify the
FMA to an fadd with a NaN operand, which in turn gets folded to NaN.

Note that this just changes SimplifyFMAFMul, so we still not catch the
case where only the Add part of the FMA is Nan/Undef.

Reviewers: cameron.mcinally, mcberg2017, spatel, arsenm

Reviewed By: cameron.mcinally

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

llvm-svn: 373459

llvm-svn: 373458

Reason for this patch is the Ssame reason as for the previous patches:
Having a ClangASTContext and being able to switch the associated ASTContext isn't
a use case we have (or should have), so let's simplify all this code.
This way it becomes clearer in what order we initialize data structures.

The DWARFASTParserClangTests changes are necessary as the test is using
a ClangASTContext but relied on the fact that no called function ever calls
getASTContext() on our ClangASTContext (as that would create the ASTContext).
As we now always create the ASTContext the fact that we had an uninitialized
FileSystem made the test crash.

llvm-svn: 373457

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 373456

This is intended to be similar to the constant folding results from
D67446
and earlier, but not all operands are constant in these tests, so the
responsibility for folding is left to InstSimplify.

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

llvm-svn: 373455

Revert r373431 "Switch lowering: omit range check for bit tests when default is unreachable (PR43129)"

This broke http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/19967

> Switch lowering: omit range check for bit tests when default is unreachable (PR43129)
>
> This is modeled after the same functionality for jump tables, which was
> added in r357067.
>
> Differential revision: https://reviews.llvm.org/D68131

llvm-svn: 373454

Appeases both clang static analyzer and cppcheck

llvm-svn: 373453

llvm-svn: 373452

Silences clang static analyzer warning about out of bounds (negative) shifts.

llvm-svn: 373451

llvm-svn: 373450

WinException::emitExceptHandlerTable - silence static analyzer dyn_cast<Function> null dereference warning. NFCI.

The static analyzer is warning about a potential null dereference, but we should be able to use cast<Function> directly and if not assert will fire for us.

llvm-svn: 373449

MetadataLoader upgradeCUVariables() - silence static analyzer dyn_cast_or_null<> null dereference warning. NFCI.

The static analyzer is warning about a potential null dereference, but we know that the source won't be null so just use dyn_cast, which will assert if the value somehow is actually null.

llvm-svn: 373448

The static analyzer is warning about potential null dereferences, but we should be able to use castAs<> directly and if not assert will fire for us.

llvm-svn: 373447

Identity shuffles, of the form (0, 1, 2, 3, ...) are perfectly OK under MVE
(they essentially just become bitcasts). We were not catching that in the
existing set of what we considered legal though. On NEON, they would be covered
by vext's, but that is not generally available in MVE.

This uses ShuffleVectorInst::isIdentityMask which is a little odd to use here
but does what we want and prevents us from just rewriting what is the same
function.

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

llvm-svn: 373446

Patch by Adam Kallai!

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

llvm-svn: 373445

Summary:
This would reduce the false positive when the static index is in an
unavailable state, e.g. background index is not finished.

Reviewers: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

llvm-svn: 373444

[clangd] SelectionTree should mark a node as fully-selected if the only claimed tokens were early-claimed.

Summary:
Previously they would be marked as partially-selected based on the early claim,
and never updated as no more tokens were claimed.
This affects simple VarDecls like "int x".

Reviewers: SureYeaah

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

llvm-svn: 373442

llvm-svn: 373441

Summary:
when renaming a typedef decl, we used to rename the underlying decl of the
typedef, we should rename the typedef itself.

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 373440

Summary:
The historical context:
- clang-format was written when C++11 was current,
  and the main language-version concern was >> vs > > template-closers.
  An option was added to allow selection of the 03/11 behavior, or auto-detection.
- there was no option to choose simply "latest standard" so anyone who didn't
  ever want 03 behavior or auto-detection specified Cpp11.
- In r185149 this option started to affect lexer mode.
- no options were added to cover c++14, as parsing/formatting
  didn't change that much. The usage of Cpp11 to mean "latest" became
  codified e.g. in r206263
- c++17 added some new constructs. These were mostly backwards-compatible and so
  not used in old programs, so having no way to turn them off was OK.
- c++20 added some new constructs and keywords (e.g. co_*) that changed the
  meaning of existing programs, and people started to complain that
  the c++20 parsing couldn't be turned off.

New plan:
 - Default ('Auto') behavior remains unchanged: parse as latest, format
   template-closers based on input.
 - Add new 'Latest' option that more clearly expresses the intent "use
   modern features" that many projects have chosen for their .clang-format files.
 - Allow pinning to *any* language version, using the same name as clang -std:
   c++03, c++11, c++14 etc. These set precise lexer options, and any
   clang-format code depending on these can use a >= check.
 - For backwards compatibility, `Cpp11` is an alias for `Latest`, not `c++11`.
   This matches the historical documented semantics of this option.
   This spelling (and `Cpp03`) are deprecated.

Reviewers: klimek, modocache

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 373439

llvm-svn: 373438

Summary:
This allows intrinsics such as the following to be defined:
 - declare <n x 4 x i32> @llvm.something.nxv4f32(<n x 4 x i32>, <n x 4 x i1>, <n x 4 x float>)

...where <n x 4 x i32> is derived from <n x 4 x float>, but
the element needs bitcasting to int.

Reviewers: c-rhodes, sdesmalen, rovka

Reviewed By: c-rhodes

Subscribers: tschuett, hiraditya, jdoerfert, llvm-commits, cfe-commits

Tags: #llvm

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

llvm-svn: 373437

llvm-svn: 373436