Summary:
GPUs like to execute instructions in the background until something
excplitely consumes them. We are working on adding some
microbenchmarking code, which requires flushing the pending memory
operations beforehand. This patch simply adds these utility functions
that will be used in the near future.

These are just bit operations, exactly the same as with f16.

This partially reverts b86e0992.

Just the default is changed back, on the Driver side.
No Frontend changes.
The positive spelling of the flag is undeprecated.

No documentation changes or changelog entries because we plan to revert
this revert as soon as https://github.com/llvm/llvm-project/issues/62529
is fixed.

Revert "[Pipelines] Do not run CoroSplit and CoroCleanup in LTO pre-link pipeline (#90310)" and related patches

This change is incorrect when thinlto and asan are enabled, and this can
be observed by adding `-fsanitize=address` to the provided
coro-elide-thinlto.cpp test. It results in the error "Coroutines cannot
handle non static allocas yet", and ASan introduces a dynamic alloca.

In other words, we must preserve the invariant that CoroSplit runs
before ASan. If we move CoroSplit to the post post-link compile stage,
ASan has to be moved to the post-link compile stage first.  It would
also be correct to make CoroSplit handle dynamic allocas so the pass
ordering doesn't matter, but sanitizer instrumentation really ought to
be last, after coroutine splitting.

This reverts commit bafc5f42.
This reverts commit b1b1bfa7.
This reverts commit 0232b77e.
This reverts commit fb2d3056.
This reverts commit 1cb33713.
This reverts commit cd68d7b3.

This tool doesn't work unless it's signed with the entitlements used
here. We should probably consider using the
macos_command_line_application rule from rules_apple which manages this
more flexibly for us, but for now this works. This uses apple_genrule as
opposed to genrule since the former encodes the Xcode environment info
into the action so it is correctly invalidated if that changes.

Some functions and subroutines are available in device context
(device/global). These functions have interfaces declared in the
`cudadevice` module.

This patch adds interfaces as `__cuda_device_builtins_<fctname>` in a
builtin module and they are USE'd rename in the `cudadevice` module. The
module is implicitly used in device/global subprograms.

The builtin module only contains procedures from section 3.6.4 for now.

Fix the problem:
https://github.com/llvm/llvm-project/pull/90663#issuecomment-2105164917
by enhancing a double-check for #90663

The directory was created by 2f1fe9a3
(2020).

Pull Request: https://github.com/llvm/llvm-project/pull/91783

Offset annotation is used in writing BAT tables.

Test Plan: updated sctc-bug4.test

When generating block terminators in `genFIR(Evaluation)`, treat
`Directives` with nested evaluations the same way as `Constructs` to
determine the successor block.

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

[Flang] Remove deprecated cast style that snuck in during landing of 435e850b

Since 98c90a13 (ISel: introduce vector ISD::LRINT, ISD::LLRINT; custom
RISCV lowering), ISD::LRINT and ISD::LLRINT now have vector variants,
that are custom lowered on RISCV, and scalarized on all other targets.
Since 2302e4c3 (Reland "VectorUtils: mark xrint as trivially
vectorizable"), lrint and llrint are trivially vectorizable, so all the
vectorizers in-tree will produce vector variants when possible. Add a
custom lowering for AArch64 to custom-lower the vector variants natively
using a combination of frintx, fcvte, and fcvtzs.

Reverts llvm/llvm-project#91657 and Relands #91485

hasExtension checks if the extension name is a known extension name.
That should always be true for the extensions listed here so we can
skip that check.

This patch is one in a series of four patches that seeks to refactor
slightly and extend the current record type map support that was
put in place for Fortran's descriptor types to handle explicit
member mapping for record types at a single level of depth.

For example, the below case where two members of a Fortran
derived type are mapped explicitly:

''''
  type :: scalar_and_array
    real(4) :: real
    integer(4) :: array(10)
    integer(4) :: int
  end type scalar_and_array
  type(scalar_and_array) :: scalar_arr

  !$omp target map(tofrom: scalar_arr%int, scalar_arr%real)
''''

Current cases of derived type mapping left for future work are:
  > explicit member mapping of nested members (e.g. two layers of
     record types where we explicitly map a member from the internal
     record type)
  > Fortran's automagical mapping of all elements and nested elements
     of a derived type
  > explicit member mapping of a derived type and then con...

This patch seeks to refactor slightly and extend the current record type map
support that was put in place for Fortran's descriptor types to handle explicit
member mapping for record types at a single level of depth (the case of explicit
mapping of nested record types is currently unsupported).

This patch seeks to support this by extending the OpenMPToLLVMIRTranslation phase
to more generally support record types, building on the prior groundwork in the
Fortran allocatables/pointers patch. It now supports different kinds of record type
mapping, in this case full record type mapping and then explicit member mapping
in which there is a special case for certain types when mapped individually to not
require any parent map link in the kernel argument structure. To facilitate this
required:
   *  The movement of the setting of the map flag type "ptr_and_obj" to respective
         frontends, now supporting it as a possible flag that can be read and printed
         in mlir form. Some minor changes to declare target map type setting was
         neccesary for this.
   * The addition of a member index array operand, which tracks the position
       of the member in the parent, required for caclulating the appropriate size
       to offload to the target, alongside the parents offload pointer (always the
       first member currently being mapped).
   * A partial mapping attribute operand, to indicate if the entire record type is
       being mapped or just member components, aiding the ability to lower
       record types in the different manners that are possible.
   * Refactoring bounds calculation for record types and general arrays to one
       location (as well as load/store generation prior to assigning to the kernel
       argument structure), as a side affect enter/exit/update/data mapping
       should now be more correct and fully support bounds mapping, previously
       this would have only worked for target.

Pull Request: https://github.com/llvm/llvm-project/pull/82852

This PR adds two new fields to omp.map_info, one BoolAttr and one I64ArrayAttr.

The BoolAttr is named partial_map, and is a flag that indicates if the record type captured by
the map_info operation is a partial map, or if it is mapped in its entirety, this currently helps
the later lowering determine the type of map entries that need to be generated.

The I64ArrayAttr named members_index is intended to track the placement of each member
map_info operations (and by extension mapped member variable) placement in the parent
record type. This may need to be extended to an N-D array for nested member mapping.

Pull Request: https://github.com/llvm/llvm-project/pull/82851

This is a large series of runtime tests that help to add coverage for the specific cases intended to be supported by the PR stack
that extends derived type map support in Flang+OpenMP. Primarily this will add functionality coverage, there's cases where
things may work, but not optimally (or at least similarly to the status quo in Clang), addiitonal IR tests are added in the
relevant segments of the related PRs to test for breakages like that.

Pull Request: https://github.com/llvm/llvm-project/pull/82850

Hi! Here is a patch for #81859 that fix the vulnerabilities found in
gitpython, cryptography, urllib3 and requests.

I have just regenerated the requirements.txt files running pip-compile
again. Fortunately, this was enough to set all the dependencies on safe
versions.

I have also checked if new vulnerabilities were introduced by running
scorecard on my fork, but none has been introduced.

Thanks!

Signed-off-by: Joyce Brum <joycebrum@google.com>

... into a `whilelo` instruction with a pair of predicate registers.

Test failures on big endian bots after this change.

Reverts llvm/llvm-project#91506

**NOTE**: we still have implementation holes when handling multiple COO
segments in the encoding. But the format should be considered to be
legal.

Follow-up from `265953cc`

Reverts llvm/llvm-project#82850, applied accidentally without the rest of the PR series.

`__apply_cv_t` and `__copy_cvref_t` are very closely related. They are
in fact identical except that `__copy_cvref_t` handles rvalue references
properly. Some uses don't actually require handling of references, so
they are replaced with `__copy_cv_t`.

This is a large series of runtime tests that help to add coverage for
the specific cases intended to be supported by the PR stack
that extends derived type map support in Flang+OpenMP. Primarily this will add functionality coverage, there's cases where
things may work, but not optimally (or at least similarly to the status quo in Clang), additional IR tests are added in the
relevant segments of the related PRs to test for breakages like that.

This change addresses some of the additional review feedback on
https://github.com/llvm/llvm-project/pull/87234

.

A summary of the changes:

1. Cleaned up the language to use 'roll back' rather than revert to
reduce the chance of confusion. Improved some function names as well.
2. Eliminated string comparisons on dialect names.
3. Prevented the introduction of redundant tensor.cast operations for
the same value.

---------

Co-authored-by: Spenser Bauman <sabauma@fastmail>

Test that these combinations do not lead to a warning.

-funsafe-math-optimizations -ffp-contract=off
and
-ffast-math -ffp-contract=off

may issue a warning after #91271.

Required to fix an llvm-test-suite failure:

    error: expected writable system register or pstate: "msr DIT, x0"

The restriction was completely removed in #89677. This was a bit too
much. Reapply the restriction on elemental, pure and recursive but only
for kernel subprogram (`grid_global` and `global` attributes).

lldb-dap was setting a flag which was meant to shut it down as soon as
it sent a terminated event. The problem with this flag is two-fold:
- as far as I can tell (definitely not an expert here), there's no
justification for this in the protocol spec. The only way I found to
shut the server down was to send it a disconnect request.
- the flag did not actually work most of the time, because it's only
checked between requests so nothing will happen if the server starts
listening for a new request before a different thread manages to send
the terminated event. And since the next request is usually the
disconnect request, everything will operate normally.

The combination of these two things meant that the issue was largely
unnoticable, except for rare flaky test failures, which happened when
the handler thread was too slow, and checked the flag after it has
already been said. This caused the test suite to complain as it did not
get a response to the disconnect request. This situation could be
s(t)imulated by adding a sleep to the and of the main loop, which
delayed the flag check, and caused the DAP tests to fail reliably.

This patch changes the shutdown condition to only trigger when the
disconnect request has been received. Since the flag can now only be set
from the handler thread, it no longer needs to be atomic.

Projects like libc use mutually exclusive macros to compile files
multiple times and then merge the result into the final library. For
installapi to accept these, we'd need to parse the same declarations in
different ways. This patch adds the basic pipelining for installapi to
create the correct TBD file.

* -Xproject allows: -fmodules, -fobjc-arc, fvisibility=hidden, prefix
headers
* -Xlabel allows: -D and -U settings
* Error on 'private' and 'public' labels -X<label>
* Xplatform allows: -iframework <path> This is to support the case where
zippered frameworks want to pass in iOSSupport search path.

[lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (#90663)

This is the implementation for
https://discourse.llvm.org/t/rfc-delay-definition-die-searching-when-parse-a-declaration-die-for-record-type/78526.

#### Motivation
Currently, lldb eagerly searches for definition DIE when parsing a
declaration DIE for struct/class/union definition DIE. It will search
for all definition DIEs with the same unqualified name (just
`DW_AT_name` ) and then find out those DIEs with same fully qualified
name. Then lldb will try to resolve those DIEs to create the Types from
definition DIEs. It works fine most time. However, when built with
`-gsimple-template-names`, the search graph expands very quickly,
because for the specialized-template classes, they don’t have template
parameter names encoded inside `DW_AT_name`. They have
`DW_TAG_template_type_parameter` to reference the types used as template
parameters. In order to identify if a definition DIE matches a
declaration DIE, lldb needs to resolve all template parameter types
first and those template parameter types might be template classes as
well, and so on… So, the search graph explodes, causing a lot
unnecessary searching/type-resolving to just get the fully qualified
names for a specialized-template class. This causes lldb stack overflow
for us internally on template-heavy libraries.

#### Implementation
Instead of searching for definition DIEs when parsing declaration DIEs,
we always construct the record type from the DIE regardless if it's
definition or declaration. The process of searching for definition DIE
is refactored to `DWARFASTParserClang::FindDefinitionTypeForDIE` which
is invoked when 1) completing the type on
`SymbolFileDWARF::CompleteType`. 2) the record type needs to start its
definition as a containing type so that nested classes can be added into
it in `PrepareContextToReceiveMembers`.

The key difference is `SymbolFileDWARF::ResolveType` return a `Type*`
that might be created from declaration DIE, which means it hasn't starts
its definition yet. We also need to change according in places where we
want the type to start definition, like `PrepareContextToReceiveMembers`
(I'm not aware of any other places, but this should be a simple call to
`SymbolFileDWARF::FindDefinitionDIE`)

#### Result
It fixes the stack overflow of lldb for the internal binary built with
simple template name. When constructing the fully qualified name built
with `-gsimple-template-names`, it gets the name of the type parameter
by resolving the referenced DIE, which might be a declaration (we won't
try to search for the definition DIE to just get the name).
I got rough measurement about the time using the same commands (set
breakpoint, run, expr this, exit). For the binary built without
`-gsimple-template-names`, this change has no impact on time, still
taking 41 seconds to complete. When built with
`-gsimple-template-names`, it also takes about 41 seconds to complete
wit this change.

This is a follow-up for ed128c7d