Follow-up to https://github.com/llvm/llvm-project/pull/88257

[P1787R6](https://wg21.link/p1787r6):
> [CWG1820](https://cplusplus.github.io/CWG/issues/1820.html) is
resolved by requiring that a qualified declarator-id declare an entity.

P1787R6 changes wording of [dcl.pre]/9. Quote from the current draft
([[dcl.pre]/5](https://eel.is/c++draft/dcl.pre#5)):
> If a
[declarator-id](https://eel.is/c++draft/dcl.decl.general#nt:declarator-id)
is a name, the
[init-declarator](https://eel.is/c++draft/dcl.decl.general#nt:init-declarator)
and (hence) the declaration introduce that
name[.](https://eel.is/c++draft/dcl.pre#5.sentence-1)
> [Note [3](https://eel.is/c++draft/dcl.pre#note-3): Otherwise, the
[declarator-id](https://eel.is/c++draft/dcl.decl.general#nt:declarator-id)
is a
[qualified-id](https://eel.is/c++draft/expr.prim.id.qual#nt:qualified-id)
or names a destructor or its
[unqualified-id](https://eel.is/c++draft/expr.prim.id.unqual#nt:unqualified-id)
is a [template-id](https://eel.is/c++draft/temp.names#nt:template-id)
and no name is
introduced[.](https://eel.is/c++draft/dcl.pre#5.sentence-2)
— end note]

This should fix buildbot failures in:
https://lab.llvm.org/buildbot/#/builders/5/builds/43303
https://lab.llvm.org/buildbot/#/builders/168/builds/20347

Align with DataReader::readProfile that sets entry block counts from
FuncBranchData->EntryData.

Test Plan: updated bolt-address-translation-yaml.test

Align BAT YAML to fdata profile.

Test Plan: updated register-fragments-bolt-symbols.s

Reviewers: dcci, rafaelauler, ayermolo, maksfb

Reviewed By: dcci

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

[clang-tidy] `readability-simplify-boolean-expr` avoid to warn expression expand from macro when ``IgnoreMacro`` option is enabled. (#91757)

Fixes: #91487

There are 100+ references.
Use a wrapper similar to a623a4c8

Remove FormatToken::isSimpleTypeSpecifier() and call
Token::isSimpleTypeSpecifier(LangOpts) instead.

The uses have been removed by commit 2b5cd8be

The `APInt *` version is pretty useless as any case one needs an
`APInt *` out, they could just replace whatever they have the
`m_Checked...` lambda with direct checks on the `APInt`.

Leaving other helpers such as `m_Negative`, `m_Power2`,
etc... unchanged as the `APInt` out version is used mostly for
convenience and rarely change functionality when converted output a
`Constant *`.

Closes #91377

Reverts llvm/llvm-project#91668

Fixes: https://lab.llvm.org/buildbot/#/builders/192/builds/9313

`vp.reduce.fmaximum/fminimum` are the VP version of
`vector.reduce.fmaximum/fminimum`.

A few tests were checking for all driver flags.
We should revert this commit when we revert #91811

libfuzzer's -jobs option will, depending on the number of CPUs, spin up
a
WorkerThread and end up printing the log file using CopyFileToErr.
This leads to an MSan false positive. This patch disables the MSan
interceptor checks,
similarly to other instances in https://reviews.llvm.org/D48891

Side-note: this false positive issue first appeared when printf()
was replaced by puts() (90b4d1bc).
The interceptor check was always present; however, MSan does not
check_printf by default.

We can extract each extension as we process them without much
complexity.

Initializes the MachineFunctionInfo for unittest introduced in #88257

Additionally, also rephrases the test condition considering the abort/exit does not occur within emitKernel but is generally triggered through the Ctx.hadError() call.

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 constituient members
     (redundant in Fortran due to former case but still legal as far as I am aware)
  > explicit member mapping of a record type (may be handled reasonably, just
     not fully tested in this iteration)
  > explicit member mapping for Fortran allocatable types (a variation of nested
     record types)

This patch seeks to support this by extending the Flang-new OpenMP lowering to
support generation of this newly required information, creating the neccessary
parent <-to-> member map_info links, calculating the member indices and
setting if it's a partial map.

The OMPDescriptorMapInfoGen pass has also been generalized into a map
finalization phase, now named OMPMapInfoFinalization. This pass was extended
to support the insertion of member maps into the BlockArg and MapOperands of
relevant map carrying operations. Similar to the method in which descriptor types
are expanded and constituient members inserted.

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

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