The `map` clause in OpenMP allows structure components to be specified
(unlike other clauses). Structure components do get their own symbols,
but these are not meant to be instantiated.

When a component reference is passed as an argument to the omp.target
op, it gets a corresponding parameter in the target op's entry block.
The original symbols are then bound to the same kind of an extended
value as before, but the value is now based on the parameters.

To handle structure components more gracefully, put their symbols on the
list of mapped objects, but skip them when creating extended values.

Fixes https://github.com/llvm/llvm-project/issues/79478.

This patch is aiming at resolving the below missed-optimization case. 

### Code
```
define <8 x i64> @vwadd_mask_v8i32(<8 x i32> %x, <8 x i64> %y) {
    %mask = icmp slt <8 x i32> %x, <i32 42, i32 42, i32 42, i32 42, i32 42, i32 42, i32 42, i32 42>
    %a = select <8 x i1> %mask, <8 x i32> %x, <8 x i32> zeroinitializer
    %sa = sext <8 x i32> %a to <8 x i64>
    %ret = add <8 x i64> %sa, %y
    ret <8 x i64> %ret
}
```

### Before this patch
[Compiler Explorer](https://godbolt.org/z/cd1bKTrx6)
```
vwadd_mask_v8i32:
        li      a0, 42
        vsetivli        zero, 8, e32, m2, ta, ma
        vmslt.vx        v0, v8, a0
        vmv.v.i v10, 0
        vmerge.vvm      v16, v10, v8, v0
        vwadd.wv        v8, v12, v16
        ret
```

### After this patch
```
vwadd_mask_v8i32:
        li a0, 42
        vsetivli zero, 8, e32, m2, ta, ma
        vmslt.vx v0, v8, a0
        vsetvli zero, zero, e32, m2, tu, mu
        vwadd.wv v12, v12, v8, v0.t
        vmv4r.v v8, v12
        ret
```
This pattern could be found in a reduction with a widening destination

Specifically, we first do a fold like `(vwadd.wv y, (vmerge cond, x, 0))
-> (vwadd.wv y, x, y, cond)`, then do pattern matching on it.

As it breaks buildkite CI

This pull request would solve
https://github.com/llvm/llvm-project/issues/78449 .
There is also a discussion about this on stackoverflow:
https://stackoverflow.com/questions/77832658/stdtype-identity-to-support-several-variadic-argument-lists


.

The following program is well formed:
```cpp
#include <type_traits>

template <typename... T>
struct args_tag
{
    using type = std::common_type_t<T...>;
};

template <typename... T>
void bar(args_tag<T...>, std::type_identity_t<T>..., int, std::type_identity_t<T>...) {}

// example
int main() {
    bar(args_tag<int, int>{}, 4, 8, 15, 16, 23);
}
```

but Clang rejects it, while GCC and MSVC doesn't. The reason for this is
that, in `Sema::DeduceTemplateArguments` we are not prepared for this
case.

# Substitution/deduction of parameter packs
The logic that handles substitution when we have explicit template
arguments (`SubstituteExplicitTemplateArguments`) does not work here,
since the types of the pack are not pushed to `ParamTypes` before the
loop starts that does the deduction.
The other "candidate" that may could have handle this case would be the
loop that does the deduction for trailing packs, but we are not dealing
with trailing packs here.

# Solution proposed in this PR
The solution proposed in this PR works similar to the trailing pack
deduction. The main difference here is the end of the deduction cycle.
When a non-trailing template pack argument is found, whose type is not
explicitly specified and the next type is not a pack type, the length of
the previously deduced pack is retrieved (let that length be `s`). After
that the next `s` arguments are processed in the same way as in the case
of non trailing packs.

# Another possible solution
There is another possible approach that would be less efficient. In the
loop when we get to an element of `ParamTypes` that is a pack and could
be substituted because the type is deduced from a previous argument,
then `s` number of arg types would be inserted before the current
element of `ParamTypes` type. Then we would "cancel" the processing of
the current element, first process the previously inserted elements and
the after that re-process the current element.
Basically we would do what `SubstituteExplicitTemplateArguments` does
but during deduction.

# Adjusted test cases
In
`clang/test/CXX/temp/temp.fct.spec/temp.deduct/temp.deduct.call/p1-0x.cpp`
there is a test case named `test_pack_not_at_end` that should work, but
still does not. This test case is relevant because the note for the
error message has changed.
This is what the test case looks like currently:
```cpp
template<typename ...Types>
void pack_not_at_end(tuple<Types...>, Types... values, int); // expected-note {{<int *, double *> vs. <int, int>}}

void test_pack_not_at_end(tuple<int*, double*> t2) {
  pack_not_at_end(t2, 0, 0, 0); // expected-error {{no match}}
  // FIXME: Should the "original argument type must match deduced parameter
  // type" rule apply here?
  pack_not_at_end<int*, double*>(t2, 0, 0, 0); // ok
}

```

The previous note said (before my changes):
```
deduced conflicting types for parameter 'Types' (<int *, double *> vs. <>)
````
The current note says (after my changesand also clang 14 would say this
if the pack was not trailing):
```
deduced conflicting types for parameter 'Types' (<int *, double *> vs. <int, int>)
```
GCC says: 
```
error: no matching function for call to ‘pack_not_at_end(std::tuple<int*, double*>&, int, int, int)’
   70 |     pack_not_at_end(t2, 0, 0, 9); // expected-error {{no match}}
````

---------

Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Co-authored-by: Erich Keane <ekeane@nvidia.com>

Implements https://isocpp.org/files/papers/P2662R3.pdf

The feature is exposed as an extension in older language modes.
Mangling is not yet supported and that is something we will have to do before release.

This patch bumps the mlgo-utils version to 19.0.0 as 18.0.0 got branched
recently.

classifyComplexElementType() doesn't return a std::optional anymore.

[Concepts] Traverse the instantiation chain for parameter injection inside a constraint scope (#79568)

We preserve the trailing requires-expression during the lambda
expression transformation. In order to get those referenced parameters
inside a requires-expression properly resolved to the instantiated
decls, we intended to inject these 'original' `ParmVarDecls` to the
current instantiaion scope, at `Sema::SetupConstraintScope`.

The previous approach seems to overlook nested instantiation chains,
leading to the crash within a nested lambda followed by a requires
clause.

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

On Gentoo, libc++ is indeed in /usr/include/c++/*, but libstdc++ is at
e.g. /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14.

Use '/include/g++' as it should be unique enough. Note that the omission of
a trailing slash is intentional to match g++-*.

See https://github.com/llvm/llvm-project/pull/78534#issuecomment-1904145839.

Reviewed by: mgorny
Closes: https://github.com/llvm/llvm-project/pull/79264



Signed-off-by: Sam James <sam@gentoo.org>

See #78920.

This reverts commit ce3e767a.

In trying to set up python headers in an out-of-tree bazel MLIR project,
I encountered the `pybind11_bazel` project, and found that the
`@python_runtime` target used here is not defined by it.

Instead, it seems that `@python_runtime` is an alias used in some
projects like Tensorflow (see

https://github.com/tensorflow/tensorflow/blob/322936ffdd96ee59e27d028467fe458859cf3855/third_party/python_runtime/BUILD#L7-L7),
where it is aliased to `@local_config_python`. In fact,
`@local_config_python` is defined by `@pybind11_bazel`, and so it seems
that this layer of indirection no longer serves a purpose, and instead
just prevents anyone who doesn't clone Tensorflow's config from using
the python bindings here.

This commit updates the dependent targets to their canonical de-aliased
equivalents, and I suspect this will not even break any downstream users
since the new target is defined in those projects already.

Without this change, running, f...

On Darwin, the Makefile already (ad-hoc) signs everything it builds.
There's also no need to use lldb_codesign for this.

Rushing this one out before vacation starts. Refactoring on top of
#66505

Fixes #78965.

The use of SmallDenseSet saves 0.39% of heap allocations during the
compilation of a large preprocessed file, namely X86ISelLowering.cpp,
for the X86 target.  During the experiment, WL.size() was 2 or less
99.9% of the time.  The inline size of 4 should accommodate up to 2
entries at the 3/4 occupancy rate.

This patch refactors the instantiation of BenchmarkMeasure within all
the unit tests to use BenchmarkMeasure::Create rather than through
direct struct instantialization. This allows us to change what values
are stored in BenchmarkMeasure without getting compiler warnings on
every instantiation in the unit tests, and is also just a cleanup in
general as the Create function didn't seem to exist at the time the unit
tests were originally written.

Use definitions from `<linux/mman.h>` to dispatch arch-specific flag
values.
For example, `MCL_CURRENT/MCL_FUTURE/MCL_ONFAULT` are different on
different architectures.

A distinction that doesn't _usually_ matter is that the
MachO::SymbolKind is really a mapping of entries in TBD files not
symbols. To better understand this, rename the enum so it represents an
encoding mapped to TBDs as opposed to symbols alone.

For example, it can be a bit confusing that "GlobalSymbol" is a enum
value when all of those values can represent a GlobalSymbol.

Currently llvm-exegesis assumes that there will only be 3 symbols in the
snippet object, in which the benchmarking function 'foo' is always the
last symbol.

These assumptions do not hold for object file formats of other targets
we support downstream. I think it would be more ideal to generalize this
part of the logics into a simple search on all symbols, as proposed by
this patch.

Constructing `std::span` objects with the two parameter constructors
could introduce mismatched bounds information, which defeats the
purpose of using `std::span`.  Therefore, we warn every use of such
constructors.

rdar://115817781

This fixes two issues related to the DebugSymbols symbol locator:

1. Only the default symbol locator plugin reports progress. On Darwin,
which uses the DebugSymbols framework we need to report the same
progress form the corresponding SymbolLocator plugin.

2. Forceful dSYM lookups, for example when using `add-dsym`, use a
different code path that currently does not report progress, which is
confusing. Here the progress event can be more specific and specify its
downloading a symbol file rather than just locating it as we'll always
shell out to dsymForUUID or its equivalent.

rdar://121629777

Make it easier to go from a ConstString to a std::string without having
to go through a C-String or a llvm::StringRef. I made the conversion
operator explicit as this is a relatively expensive operations (compared
to a StringRef or string_view).

Almost all loops with getNumVirtRegs skip unused registers by means
of reg_nodbg_empty or empty live interval. Except for these two cases
that are revealed by GlobalISel since it can skip RegClass assignment
for unused registers.

Closes #64452, closes #71926

The `(( )?&)?` appears to match types which are references. However lldb
can load the
correct data formatters without having to pattern match against a `&`
suffix.

The suffix may have been needed at one point, but it's no longer needed.

Update `NVPTXAssignValidGlobalNames` to convert all characters which are
illegal in PTX identifiers to `_$_`. ([PTX ISA: 4.4
Identifiers](https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#identifiers)).

Currently this test is assuming that ~/.local/bin (or wherever the
Python binaries are installed to) is on the path. This is not a valid
assumption in most cases, and it also means we might not find the
version of pytype associated with the Python interpreter being used to
test LLVM, which could create some inconsistencies. This patch fixes
that by invoking pytype through the Python interpreter passed to lit.

This reverts commit 59bf6051.

Introduces a major compile-time regression.

PR 79573 introduced `ASSERT_ERRNO_*` macros for use in libc tests.
Introduce these macro definitions to FuchsiaTest.h for string tests to
compile on Fuchsia.

This lets the compiler eliminate unused/duplicate calls to it.

Co-authored-by: Martin Storsjö <martin@martin.st>

This patch adds a pytype test to the mlgo-utils lit test suite to
prevent regressions in typing while we wait to setup precommit CI for
this specific project.

This is somewhat hacky, but is a temporary fix and will be pulled out
soonish. It also should only impact the ML buildbots as they are the
only ones that should have `pytype` installed.