my bad, wrong repo ,so sorry.

This reverts commit 0b9350f3.

Limit can also be bumped up to 999 to allow OS versions over 100

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

On ARM, a C fallback version of __kmp_invoke_microtask is used,
which only handles up to a fixed number of arguments - while
many-microtask-args.c tests that the function can handle an
arbitrarily large number of arguments (the testcase produces 17
arguments).

On the CMake level, we can't add ${LIBOMP_ARCH} directly to
OPENMP_TEST_COMPILER_FEATURES in OpenMPTesting.cmake, since
that file is parsed before LIBOMP_ARCH is set. Instead
convert the feature list into a proper CMake list, and append
${LIBOMP_ARCH} into it before serializing it to an Python array.

Reapply: Make sure OPENMP_TEST_COMPILER_FEATURES is defined
properly in all other test subdirectories other than
runtime/test too.

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

There's some variation in where different toolchain distributions
(and linux distributions) package the mingw sysroots - this is
so far handled by adding specific known subdirectory paths
to the include and lib directory lists.

There are multiple degrees of combinatorics involved here though;
the distros may use different locations such as
/usr/x86_64-w64-mingw32/include or
/usr/x86_64-w64-mingw32/sys-root/mingw/include.

So far, this setup has been treated as base=/usr, subdir=x86_64-w64-mingw32,
and the driver tries to add further subdirectories such as
<base>/<subdir>/include, <base>/<subdir>/sys-root/mingw/include.

When it comes to libstdc++ (and libc++), each of these come with
a large number of potential subdirectories. Instead of further
exploding the combinatorics another step by adding all combinations
of all paths, check whether <base>/<subdir>/sys-root/mingw/include
exists, and if it does, append that subpath into the subdir variable.

This allows finding libstdc++ headers in e.g.
/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/x86_64-w64-mingw32
on Fedora.

The same logic (where everything belonging to this target fits
under one expanded <subdir> path, with just /include and /lib
under it) doesn't seem to apply on Gentoo, where the includes
are found in <base>/<subdir>/usr/include while the libraries
are in <base>/<subdir>/mingw/lib (see
8e218026). But apparently
the libstdc++ headers aren't installed under
<base>/<subdir>/usr/include, so that path hierarchy quirk doesn't
need to be taken into account in AddClangCXXStdlibIncludeArgs.

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

There are three functions that try to detect the right implicit
sysroot and libgcc directory setup to use
- One which looks for mingw sysroots located in
  <clangbin>/../<sysrootname>
- One which looks for a mingw-targeting gcc executables in the PATH
- One which looks in the <gccroot>/lib/gcc directory to find the
  right one to use, and the right specific triple used for arch
  specific directories in the gcc/libstdc++ install

These have mostly tried to look for executables named
"<arch>-w64-mingw32-gcc" or "mingw32-gcc" or subdirectories
named "<arch>-w64-mingw32" or "mingw32".

In the case of findClangRelativeSysroot, it also has looked
for directories with the name of the actual triple. This
was added in deff7536,
with the intent of looking for a directory matching exactly
the user provided literal triple - however the triple here
is the normalized one, not the one provided by the user on
the command line.

Improve and unify this logic somewhat:
- Always first look for things based on the literal triple
  provided by the user.
- Secondly look for things based on the normalized triple
  (which usually ends up as e.g. x86_64-w64-windows-gnu),
  accessed via the Triple which is passed to the constructor
- Then look for the common triple form <arch>-w64-mingw32

The literal triple provided by the user is available via
Driver::getTargetTriple(), but computeTargetTriple() may
change e.g. the architecture of it, so we need to
reapply the effective architecture on the literal triple
spelling from Driver::getTargetTriple().

Do this consistently for all of findGcc, findClangRelativeSysroot
and findGccLibDir (while keeping the existing plain "mingw32"
cases in findGcc and findGccLibDir too).

Fedora 37 started shipping mingw sysroots targeting UCRT,
in addition to the traditional msvcrt.dll, and these use
triples in the form <arch>-w64-mingw32ucrt - see
https://fedoraproject.org/wiki/Changes/F37MingwUCRT.

Thus, in addition to the existing default tested triples,
try looking for triples in the form <arch>-w64-mingw32ucrt,
to automatically find the UCRT sysroots on Fedora 37.
By explicitly setting a specific target on the Clang command
line, the user can be more explicit with which flavour is
to be preferred.

This should fix the main issue in
https://github.com/llvm/llvm-project/issues/59001.

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

The use of a PSV for buffer intrinsics is misleading because it may be
misinterpreted as all buffer intrinsics accessing the same address in
memory, which is clearly not true.

Instead, build MachineMemOperands without a pointer value but with an
address space, so that address space-based alias analysis can still
work.

There is a lot of test churn because previously address space 4
(constant address space) was used as an address space for buffer
intrinsics. This doesn't make much sense and seems to have been an
accident -- see the change in
AMDGPUTargetMachine::getAddressSpaceForPseudoSourceKind.

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

`connectToSink` uses a value by putting it in a future instruction.
It will replace the operand of a future instruction with the current value.

However, if current value is an `Instruction` and put into a switch case, the module is invalid.
We fix that by only connecting to Br/Switch's condition, and don't touch other operands.

Will have other strategies to mutate other Br/Switch operands to be patched once this patch is passed

Reviewed By: arsenm

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

Summary:
A previous change removed a transient inclusion of `stdlib.h` from the
`string_utils.h` file which this test depended on. Include it directly
here.

msan's app memory mappings for aarch64 are constrained by
the MEM_TO_SHADOW constant to 64GB or less, and some app
memory mappings (in kMemoryLayout) are even smaller in
practice. This will lead to a crash with the error message
"MemorySanitizer can not mmap the shadow memory" if the
executable's memory mappings (e.g., libraries) extend
beyond msan's app memory mappings.

This patch makes the app/shadow/origin memory mappings
considerably larger, along with corresponding changes to
the MEM_TO_SHADOW and SHADOW_TO_ORIGIN constants.

Note that this deprecates compatibility with 39- and 42-bit
VMAs.

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

This patch introduces documentation for the new GPU mode added in
D138608. The documentation includes instructions for building and using
the library, along with a description of the supported functions and
headers.

Reviewed By: sivachandra, lntue, michaelrj

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

This patch contains the initial support for building LLVM's libc as a
target for the GPU. Currently this only supports a handful of very basic
functions that can be implemented without an operating system. The GPU
code is build using the existing OpenMP toolchain. This allows us to
minimally change the existing codebase and get a functioning static
library. This patch allows users to create a static library called
`libcgpu.a` that contains fat binaries containing device IR.

Current limitations are the lack of test support and the fact that only
one target OS can be built at a time. That is, the user cannot get a
`libc` for Linux and one for the GPU simultaneously.

This introduces two new CMake variables to control the behavior
`LLVM_LIBC_TARET_OS` is exported so the user can now specify it to equal
`"gpu"`. `LLVM_LIBC_GPU_ARCHITECTURES` is also used to configure how
many targets to build for at once.

Depends on D138607

Reviewed By: sivachandra

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

The `strdup` family of functions rely on `malloc` to be implemented.
Its presence in the `string_utils.h` header meant that compiling many of
the string functions relied on `malloc` being implementated as well.
This patch simply moves the implementation into a new file to avoid
including `stdlib.h` from the other string functions. This was a barrier
for compiling string functions for the GPU where there is no malloc
currently.

Reviewed By: sivachandra

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

Implements `dwim-print`, a printing command that chooses the most direct,
efficient, and resilient means of printing a given expression.

DWIM is an acronym for Do What I Mean. From Wikipedia, DWIM is described as:

  > attempt to anticipate what users intend to do, correcting trivial errors
  > automatically rather than blindly executing users' explicit but
  > potentially incorrect input

The `dwim-print` command serves as a single print command for users who don't
yet know, or prefer not to know, the various lldb commands that can be used to
print, and when to use them.

This initial implementation is the base foundation for `dwim-print`. It accepts
no flags, only an expression. If the expression is the name of a variable in
the frame, then effectively `frame variable` is used to get, and print, its
value. Otherwise, printing falls back to using `expression` evaluation. In this
initial version, frame variable paths will be handled with `expression`.

Following this, there are a number of improvements that can be made. Some
improvements include supporting `frame variable` expressions or registers.

To provide transparency, especially as the `dwim-print` command evolves, a new
setting is also introduced: `dwim-print-verbosity`. This setting instructs
`dwim-print` to optionally print a message showing the effective command being
run. For example `dwim-print var.meth()` can print a message such as: "note:
ran `expression var.meth()`".

See https://discourse.llvm.org/t/dwim-print-command/66078 for the proposal and
discussion.

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

Reviewed By: aartbik

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

Part of the project to eliminate special handling for triples in lit
expressions.

Add functions that generate masks for the HVX instructions we were
targeting. This is both simpler than analyzing the masks, and these
functions may also be used in other places.

Part of the project to eliminate special handling for triples in lit
expressions.

This reverts commit 8076c70d.
After discussion in D137791, a test that shows a miscompile
is better than the more isolated test for a transform (that
may not be wrong in all cases).

Use captured values to match loop metadata.

Use BaseBoxType in `genComponentByComponentAssignment`
so the component by component assignment involving polymorphic entities
does not fall back to scalar assignment.

Reviewed By: PeteSteinfeld

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

This completes the initial pass over all of the C DRs.

This patch fixes a "failed to annotate CFG" error in
SIAnnotateControlFlow. The problem occurs when there are
divergent and uniform unreachable/return blocks in the same
region. In this case, AMDGPUUnifyDivergentExitNodes does not
create a unified block so the region contains multiple exits.

StructurizeCFG does not work properly when there are multiple
exits, so the neccessary CFG transformations do not occur along
divergent control flow. Subsequently, SIAnnotateControlFlow
processes the path to the divergent exit block, but may only
partially process blocks along a unform control flow path to
another exit block.

This patch fixes the bug by creating a single exit block when
there is a divergent exit block in the function.

Differential revision: https://reviews.llvm.org/D136892

This patch moves the outlined function registration, function attribute
configuration and function ID creation to the OpenMPIRBuilder. This will later
be used by flag as well.

Reviewed By: jdoerfert

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

ld64 rejects `-no_pie` when targeting arm64, this mirrors that behavior.
Newer versions of ld64 also reject it based on minimum OS versions, but
that logic isn't in an open source dump yet so it isn't implemented
here.

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

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

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

This moves debug info tests in `test/CodeGen/WebAssembly` into
`test/DebugInfo/WebAssembly`, to gather all wasm debug info related
tests there.

Reviewed By: dschuff

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

This patch fixes:

  bolt/lib/Passes/CallGraph.cpp:27:15: error: unused function
  'hash_int64_fallback' [-Werror,-Wunused-function]

  bolt/lib/Passes/CallGraph.cpp:40:15: error: unused function
  'hash_int64' [-Werror,-Wunused-function]

Summary:
libc++abi LIT test case vec_reg_restore.pass.cpp for AIX uses instructions mtvsrd and mfvsrd that are only available on Power8 CPU and higher, and therefore, fails on Power7 which is supported by the current AIX Clang. This patch replaces mtvsrd/mfvsrd with vector instructions available on Power7.

Reviewed by: nemanjai

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

The functionality of LSHIFT and RSHIFT intrinsics is the same as the
standard SHIFTL and SHIFTA intrinsics respectively. The patch is to
alias the two intrinsics to the standardized ones.

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

D132090 is too verbose.
Don't explain obvious.
Add simpler explanation of rounding reasoning.

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

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

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