This patch just reruns the update_llc_test_checks script on the AArch64
tests claiming to be updated by the script, cleaning up the output.

Enhance the generic register fallback code to support "eflags" register
name in addition to "rflags", as the former is used by gdbserver.  This
permits lldb-server to recognize the generic flags register when
interfacing with gdbserver-style target.xml (i.e. without generic=""
attributes), and therefore aligns ABI plugins' AugmentRegisterInfo()
between lldb-server and gdbserver.

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

This patch extends the preliminary support for vector-predicated (VP)
operation legalization to include promotion of illegal integer vector
types.

Integer promotion of binary VP operations is relatively simple and
piggy-backs on the non-VP logic, but passing the two extra mask and VP
operands through to the promoted operation.

Tests have been added to the RISC-V target to cover the basic scenarios
for integer promotion for both fixed- and scalable-vector types.

Reviewed By: craig.topper

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

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

Fix 'platform file read' and 'platform file write' commands to correctly
detect erraneous return and report it as such.  Currently, errors were
implicitly printed as a return value of -1, and the commands were
assumed to be successful.

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

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

Also fixes a warning mentioned in D109359.

Reviewed By: sdesmalen

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

Use the same codepaths as for MSVC. Mingw-w64 does have the _mktemp_s
function; on Vista and newer, msvcrt.dll does contain the function,
which ends up called. (Same thing in the UCRT.) In older versions of
msvcrt.dll (older than what libc++ supports), mingw-w64 provides a
fallback implementation.

This effectively reverts 23323e25 (and
d07e5c23). That commit tried to fix
unspecified MinGW build breakage.

This reduces the risk of temp name collisions between processes (when
running multiple tests in parallel); the path returned by
GetTempFileName can easily collide with other similar paths.
(_mktemp_s on the other hand tries to avoid such clashes by using
the process id as part of the uniqueness seed.)

This avoids stray random failures in fstreams tests in mingw configurations.

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

This patch implements extract_subvector for predicate types when
the input type is more than twice the size of the subvector that
is being extracted.

Reviewed By: CarolineConcatto

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

The Clang attribute `enum_extensibility(open)` (2017) is too new.
Just use a cast.

This improvement adds "assume" after removal of branch basing on UB in successor block.

Consider the following example:

```
pred:
  x = ...
  cond = x > 10
  br cond, bb, other.succ

bb:
  phi [nullptr, pred], ... // other possible preds
  load(phi) // UB if we came from pred

other.succ:
  // here we know that x <= 10, but this knowledge is lost
  // after the branch is turned to unconditional unless we
  // preserve it with assume.
```

If we remove the branch basing on knowledge about UB in a successor block,
then the fact that x <= 10 is other.succ might be lost if this condition is
not inferrable from any dominating condition. To preserve this knowledge, we
can add assume intrinsic with (possibly inverted) branch condition.

Patch by Dmitry Bakunevich!

Differential Revision: https://reviews.llvm.org/D109054
Reviewed By: lebedev.ri

Revert GCC -Wnon-virtual-dtor workarounds "[SCEV] Fix GCC -Wnon-virtual-dtor" & "[SampleFDO] Fix -Wnon-virtual-dtor"

This reverts commits 4852c770 and 6df09d6c.

After D109404, -Wnon-virtual-dtor will not be added when the host compiler is GCC.

See the discussion on
https://reviews.llvm.org/rG4852c770fe8703145dd2a35395985646ce57a454
The GCC behavior (https://gcc.gnu.org/PR102168) seems unhelpful.

Unconditional -Wnon-virtual-dtor led to other unnecessary workarounds like
6df09d6c

This patches uses a variant of the 4bb5f44c
check to detect GCC PR102168.

Reviewed By: dblaikie

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

format.

Currently when we add a new section in the profile format and generate a profile
containing the new section, older compiler which reads the new profile will
issue an error. The forward incompatibility can cause unnecessary churn when
extending the profile. This patch removes the incompatibility when adding a new
section for extbinary format.

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

Reviewed By: Dylan McKay, Ben Shi

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

Prevent the folding if it leads to worse code.

Reviewed By: dmgreen, kda

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

The alignment of vector variable arguments in callee side is 4, which is
aligned with MSVC. But the caller aligns them to the size of vector
arguments. It results in run fails. This patch fixes this problem by
trimming it to 4 bytes for variable arguments on Win32.

Fixed vector arguments are passed by pointer on Win32. So they don't have
the problem.

I don't find a doc in MSDN for this calling conversion, so I did several
experiments here: https://godbolt.org/z/n1zn1Gx1z

Reviewed By: rnk

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

See PR48617.

When assigning the new template arguments to the new TypeLoc, we were looping
on the argument count of the original TypeLoc instead of the new one,
which can be different when packs are present.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: rsmith

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

This reverts 61ddc3d3 to reapply
91eda9c3 after fixing the " |& "
causing failures on windows.

Change-Id: Ib646c803b2274f0f24f9a8932de7aa97003529c5

- `this` used in lambda expression parameter declarations needs no capture.
- Set up CXXThisOverride for default template arguments of a lambda.

A similar fix to this is c3d2ebb6.

Reviewed By: aaron.ballman

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

This is to make sure the pass is not skipped at O0 where optnone is
applied to functions by default.

The basic problem being solved is that we largely give up when encountering a trip count involving an IV which is not an addrec. We will fall back to the brute force constant eval, but that doesn't have the information about the fact that we can't cycle back through the same set of values.

There's a high level design question of whether this is the right place to handle this, and if not, where that place is. The major alternative here would be to return a conservative upper bound, and then rely on two invocations of indvars to add the facts to the narrow IV, and then reconstruct SCEV. (I have not implemented the alternative and am not 100% sure this would work out.) That's arguably more in line with existing code, but I find this substantially easier to reason about.  During review, no one expressed a strong opinion, so we went with this one.

Differential Revision: D108651

Both Wasm & Emscripten SjLj handling has a restriction that `setjmp`
cannot be called indirectly. I thought we have been erroring out on
indirect uses of `setjmp`, but some recent CL disrupted the logic and
we are not erroring out anymore.

We currently
1. Collect functions that contain `setjmp` calls in `SetjmpUsers`. This
   only counts direct calls:
   https://github.com/llvm/llvm-project/blob/8f77dc459e31aad6daab89a124fa92067916274c/llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp#L869-L878
2. Run `runSjLjOnFunction` only on those `SetjmpUsers`. Within
   `runSjLjOnFunction`, if we see an indirect use of `setjmp`, we error
   out:
   https://github.com/llvm/llvm-project/blob/8f77dc459e31aad6daab89a124fa92067916274c/llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp#L1218-L1221

So if there are only indirect setjmp calls within the module,
`SetjmpUsers` will be empty, and `runSjLjOnFunction` is not even entered
once. And the indirect `setjmp` call will error out at link time. So in
this CL we check for the indirect uses of `setjmp` upfront before we
enter `runSjLjOnFunction`.

Also this currently errors out on `invoke @setjmp`, which can only occur
when using Wasm EH + Wasm SjLj within a function. We recently added Wasm
SjLj support but we don't support using Wasm EH + Wasm SjLj in the same
function yet. We plan to add this support very soon, so I don't think
it's worth creating another test file just for this. (This is an error
test so it needs its own file)

Reviewed By: dschuff

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

It's the same as unsigned, but clearer in intent.

Low-level code may occasionally deal with direct access by concrete addresses
such as 0x1234. Values at these addresses act like globals: they can change
at any time. They typically wear volatile qualifiers.

Suppress all warnings on loops with conditions that involve casting anything to
a pointer-to-...-pointer-to-volatile type.

The closely related bugprone-redundant-branch-condition check
doesn't seem to be affected. Add a test just in case.

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

Verified that previously nothing was calling dataOperandHasImpliedAttr()
with AttributeList::ReturnIndex even though we had a code path for it.

Reviewed By: rnk

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

Adds missing semantic checks for ELEMENTAL functions and subroutines,
their dummy arguments, and their results from F'2018 15.8.1 C15100-15102.

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

Perhaps one of these days I will actually learn how to spell opaque....

Reviewed By: bixia

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

This reverts commit 6be7f5c3.
We'll need this file eventually, but it in fact shouldn't have been in
cfe02847. It's currently unreferenced.

Many `flang` tests currently `FAIL` on Solaris because the module files
aren't found.  I could trace this to `sys::fs::getMainExecutable` not being
implemented.

This patch does this and fixes all affected `flang` tests.

Tested on `amd64-pc-solaris2.11`.

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

Follow on to D109029. I realized we had no mention of mustprogrress in the comment (as it prexisted mustprogress in the codebase). In the process of adding it, I tweaked the preconditions into something I think is more clear. Note that mustprogress is checked in the code.

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

This prints a more helpful error for folks who aren't intrinsically
familiar with the system.

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

Right now all but the last bullet are relying on applied "must not" that
isn't there and the last bullet is a "must".

Reviewed By: mehdi_amini

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