The normalization component of average pool has a very specific
rounding behavior for compouting the division for floating
point values. Updated so that the bit-exact version is implemented.

Also includes a fix for computing the stride part of the average pool
operation.

Reviewed By: jpienaar

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

Currently in Sema::getDestructorName we call SS.getScopeRep()->getPrefix() but
SS.getScopeRep() can return nullptr because LookupInNestedNameSpec(...) called a
little before can invalidate SS.

This fixes: https://github.com/llvm/llvm-project/issues/59446

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

Reviewed By: nikic

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

This reverts commit 366e1faa.

It looks like this exposes another set of crashes on the buildbots.
Revert while I investigate.

The recommitted version fixes a crash when one of the operands is a
constant other than a ConstantInt. Test for that case have been added
in 5b16cd97.

It splits off the new logic into a separate function because setting the
flags is quite different compared to the other cases handled in replaceSignedInst
which all require replacing an existing instruction. Instructions are
now refined before any replacements are done, which has the advantage
that we should have lattice values for all operands (fixing the crashes
and simplifies the logic) and also allows optimizing more cases where one
of the operands also gets replaced (see improvements in
@sge_with_sext_to_zext_conversion).

It also guards makeGuaranteedNoWrapRegion by `if (!Inst.hasNoUnsignedWrap())`
as discussed in the review.

Fixes #60280.
Fixes #60278.

Original message:
    This patch updates SCCP to use the value ranges of AddInst operands to
    try to prove the AddInst does not overflow in the unsigned sense and
    adds the NUW flag. The reasoning is done with
    makeGuaranteedNoWrapRegion (thanks @nikic for point it out!).

    Follow-ups will include adding NSW and extension to more
    OverflowingBinaryOperators.

    Reviewed By: nikic

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

In SUnit::removePred edges are removed from the Preds and Succs lists before
updating the bookkeeping. This could result in incorrect values for
NumPreds/SuccsLeft and cause WeakPreds/SuccsLeft to underflow, since the
incorrect SDep will be used to update these values.

Reviewed By: rampitec

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

The stripDebugLocFromLoopID() may mistakenly remove useful metadata nodes
when they are operands of a child node, which also has DILocation operands.

It can be reproduced by the output of clang for code similar to the following:

for(int i = 0; i < n; i++)
  x[i] = 10;
-strip-debug removes the child node of llvm.loop.vectorize.followup_all,
which contains llvm.loop.isvectorized and llvm.loop.unroll.count.

This patch fixes by checking all children nodes and only remove a metadata
node if all its children are DILocation.

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

This revision is a part of a series of patches extending
AddressSanitizer C++ container overflow detection
capabilities by adding annotations, similar to those existing
in std::vector, to std::string and std::deque collections.
These changes allow ASan to detect cases when the instrumented
program accesses memory which is internally allocated by
the collection but is still not in-use (accesses before or
after the stored elements for std::deque, or between the size and
capacity bounds for std::string).

The motivation for the research and those changes was a bug,
found by Trail of Bits, in a real code where an out-of-bounds read
could happen as two strings were compared via a std::equals function
that took iter1_begin, iter1_end, iter2_begin iterators
(with a custom comparison function).
When object iter1 was longer than iter2, read out-of-bounds on iter2
could happen. Container sanitization would detect it.

In revision D132522, support for non-aligned memory buffers (sharing
first/last granule with other objects) was added, therefore the
check for standard allocator is not necessary anymore.
This patch removes the check in std::vector annotation member
function (__annotate_contiguous_container) to support
different allocators.

If you have any questions, please email:
 - advenam.tacet@trailofbits.com
 - disconnect3d@trailofbits.com

Reviewed By: #libc, #sanitizers, philnik, vitalybuka

Spies: EricWF, philnik, #sanitizers, libcxx-commits

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

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

Previously, RewriteStatepointsForGC had a hardcoded list of GC
strategies for which it would run, and using it with a custom strategy
required patching LLVM.

The logic for selecting the variables that are considered managed was
also hardcoded to use pointers in address space 1, rather than
delegating to GCStrategy::isGCManagedPointer.

This patch fixes both of these flaws: this pass now applies to all
functions whose GCStrategy returns true for useStatepoints, and checking
if a pointer is managed or not is also now done by the strategy.

One potentially questionable design decision in this change: the pass will
be enabled for all GC strategies that use statepoints. It seems unlikely
this would be a problem - consumers that don't use this pass probably
aren't adding it to the pass manager anyway - but if you had two different
GC strategies and only one wants this pass enabled then that'd need a new
flag in GCStrategy, which I can add if anyone thinks it's necessary.

This is an updated version of D140458, rebased to account for LLVM's
changes since D140504 (required by this patch) landed.

Reviewed By: dantrushin

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

It meant to check that `UseRS4GC` requires `UseStatepoints`.
Instead it always required `UseStatepoints` when `useRS4GC()`
was called.

'{', '}' and (conditionally) '*' were allowed at the start of a
statement. This behavior was copied from AsmParser, where they were
added to support Hexagon bundles (braces) and BFP memory instructions
(the star).
MASM dialect is x86-specific and does not allow these symbols to be
used at the beginning of an instruction.

Worth noting that '{' is a valid first character in AT&T syntax
(e.g. "{vex} vpmadd52huq ..."); MASM variant is to omit the braces.

Reviewed By: epastor

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

Derived type default initialization was not taking the step into
consideration.

```
module dt_init
  type p1
    integer :: a
  end type
  type, extends(p1) :: p2
    integer :: b = 10
  end type
contains
  subroutine init_dt(z)
    class(p1), intent(out) :: z(:)
    select type(z)
    type is (p2)
      print*,z
    end select
  end subroutine
end module
program test
  use dt_init
  type(p2) :: t(6) = [ p2(1,2),p2(3,4),p2(5,6),p2(7,8),p2(9,10),p2(11,12) ]
  print*,t
  call init_dt(t(::2))
  print*,t
end program
```

Without the fix, the three first elements are initialized

```
 1 2 3 4 5 6 7 8 9 10 11 12
 1 10 5 10 9 10
 1 10 3 10 5 10 7 8 9 10 11 12
```

Where it should be element number 1,3,5

```
 1 2 3 4 5 6 7 8 9 10 11 12
 1 10 5 10 9 10
 1 10 3 4 5 10 7 8 9 10 11 12
```

Reviewed By: klausler

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

operands() is the preferred accessor since D142213. OpInfo will be
removed in D142219.

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

The test has been failing since after last update of ISL (a749e09e).

Reviewed By: kstoimenov

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

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

WIFEXITED and friends expect an `int *` but these methods
were marked `const` so they instead got a `const int *`.
This macros aren't actually modifying their argument, but
we were never using these functions on an immutable
`ProcessStatus` type anyway.

The bugfix https://reviews.llvm.org/D142308 might already have been
fixed upstream.

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

Use VPDominatorTree to generalize def-use verification.

Depends on D140513.

Reviewed By: Ayal

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

There was a FIXME comment for this. Stop getting the values in
OffsetHelper and let the caller do that instead, so we can control
whether the value(s) are removed from the stack at all.

Also use ArithOp instead of the unclear boolean for Add.

This patch fixes:

  clang-tools-extra/clangd/Hover.cpp:1036:28: warning: unused variable
  ‘MTE’ [-Wunused-variable]

  llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:22295:19: error:
  unused variable 'AN' [-Werror,-Wunused-variable]

We know we save a Block* here, so do the cast there instead of
everywhere we're calling this function.

When initializing a primitive array, we don't need to dup the base
pointer for every element.

Check region before use it.
Fixes #60215  https://github.com/llvm/llvm-project/issues/60215

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

We need to run the functions we compiled immediately after to check if
they can ever be a constant expression.

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

This creates fewer instructions, makes the bytecode easier to read and
InitThisField also cares about checkingPotentialConstantExpression()
cases.

... in EvalEmitter.

This is unused, with all relevant patterns and instructions using the
HasAES / HasSHA2 / HasSHA3 / HasSM4 predicates.

Summary:
We only support this offloading on Linux currently, and this handling of
static libraries is mostly based on Linux systems. So we should only
test those systems for now until we expland to other operating systems
in the future.

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

This change fixes an issue introduced by
https://reviews.llvm.org/D140315.  A new unit test was added to validate
the search for the device libraries being placed in Clang's resource
directory; however, the test didn't take into account that certain
platforms use lib64 for 64-bit library directory.

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

Change-Id: I9c31a4f08fbc383350d82d6aba01987a3ef63e51

This commit introduces support for importing result attributes.

Depends on D142372

Reviewed By: gysit

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