This patch introduces the `omp.simd` operation. In contrast to the existing
`omp.simdloop` operation, it is intended to hold SIMD information within
worksharing loops, rather than representing a SIMD-only loop. Some examples
of such loops are "omp do/for simd", "omp distribute simd", "omp target teams
distribute parallel do/for simd", etc. For more context on this work, refer to
PR #79559.

This operation must always be nested within an `omp.wsloop` operation as its
only non-terminator child. It follows the same approach as the `omp.distribute`
operation, by serving as a simple wrapper operation holding clause information.

Summary:
Currently, the AMDGPU toolchain accepts not passing `-mcpu` as a means
to create a sort of "generic" IR. The resulting IR will not contain any
target dependent attributes and can then be inserted into another
program via `-mlink-builtin-bitcode` to inherit its attributes.

However, there are a handful of macros that can leak incorrect
information when compiling for an unspecified architecture. Currently,
things like the wavefront size will default to 64, which is actually
variable. We should not expose these macros unless it is known.

This was broken by 859e6aa1, which added
quotes around the EXTRA_ARGS variable.

We try to only use X32 for gnux32 triple tests.

We try to only use X32 for gnux32 triple tests.

We try to only use X32 for gnux32 triple tests.

Both OPC_ExtractField and OPC_CheckField are currently defined to take
an unsigned 8-bit start value. On some architectures with long
instruction words, this value can silently overflow, resulting in a bad
decoder table.

This patch changes each to take a ULE128B-encoded start value instead.
Additionally, a range assertion is added for the 8-bit length to
prominently notify a user in case that field ever overflows.

This problem isn't currently exposed upstream since all in-tree targets
use small instruction words (i.e., bitwidth <= 64 bits). It does show up
in at least one downstream target with instructions > 64 bits long.

Co-authored-by: Jason Eckhardt <jeckhardt@nvidia.com>

Summary:
The AMDGPU fixed frequency clock is fixed to a chip dependent frequency.
More modern chips have started to fix this at known values of 25 MHz or
100 MHz, so this function forwards those values. This was done using the
individual architectures. This patch simply uses the more concise
`__GFXn__` macro which indicates the major revision

The test added in #73511 currently fails in
CLANG_DEFAULT_PIE_ON_LINUX=OFF configuration, because it uses the clang
driver in a codegen test.

Split the test into two, a driver test that checks that the appropriate
target feature is passed, and a codegen test that uses cc1.

We try to only use X32 for gnux32 triple tests.

Added support for COSD and SIND. This is quick fix. ATAND, TAND, COSD
and SIND needs to be revisited to make it a runtime call. This patch has
code changes and test cases.

The MSCV build doesn't allow the constexpr isMax variable to be used in lambda
without a capture. The -Weverything build does not allow isMax to be used in a
lambda capture as it is a constexpr. I've removed the constexpr as it shouldn't
be necessary.

This patch XFAILs TestStepScripted.py temporarily following 888501bc

,
until I fix it.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

This patch makes ScriptedThreadPlan conforming to the ScriptedInterface
& ScriptedPythonInterface facilities by introducing 2
ScriptedThreadPlanInterface & ScriptedThreadPlanPythonInterface classes.

This allows us to get rid of every ScriptedThreadPlan-specific SWIG
method and re-use the same affordances as other scripting offordances,
like Scripted{Process,Thread,Platform} & OperatingSystem.

To do so, this adds new transformer methods for `ThreadPlan`, `Stream` &
`Event`, to allow the bijection between C++ objects and their python
counterparts.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

This crash is basically caused by calling
`ASTContext::getRawCommentForDeclNoCacheImp` with its input arguments
`RepresentativeLocForDecl` and `CommentsInTheFile` refering to different
files. A reduced reproducer is provided in this patch.

After the source locations for instantiations of funtion template are
corrected in the commit 256a0b29, the
variable `CommitsInThisFile` in the function
`ASTContext::attachCommentsToJustParsedDecls` would refer to the source
file rather than the header file for implicit function template
instantiation. Therefore, in the first loop in
`ASTContext::attachCommentsToJustParsedDecls`, `D` should also be
adjusted for relevant scenarios like the second loop.

Fixes #67979 
Fixes #68524
Fixes #70550

When testing on gcc, both exitstat and cmdstat must be a kind=4 integer,
e.g. DefaultInt. This patch changes the input arg requirement from
`AnyInt` to `TypePattern{IntType, KindCode::greaterOrEqualToKind, n}`.

The standard stated in 16.9.73
- EXITSTAT (optional) shall be a scalar of type integer with a decimal
exponent range of at least nine.
- CMDSTAT (optional) shall be a scalar of type integer with a decimal
exponent range of at least four.
 
```fortran
program bug
  implicit none
  integer(kind = 2) :: exitstatvar
  integer(kind = 4) :: cmdstatvar 
  character(len=256) :: msg
  character(len=:), allocatable :: command
  command='echo hello'
  call execute_command_line(command, exitstat=exitstatvar, cmdstat=cmdstatvar)
end program
```
When testing the above program with exitstatvar kind<4, an error would
occur:
```
$ ../build-release/bin/flang-new test.f90 
error: Semantic errors in test.f90
./test.f90:8:47: error: Actual argument for 'exitstat=' has bad type or kind 'INTEGER(2)'
    call execute_command_line(command, exitstat=exitstatvar)
```

When testing the above program with exitstatvar kind<2, an error would
occur:
```
$ ../build-release/bin/flang-new test.f90 
error: Semantic errors in test.f90
./test.f90:8:47: error: Actual argument for 'cmdstat=' has bad type or kind 'INTEGER(1)'
    call execute_command_line(command, cmdstat=cmdstatvar)
```

Test file for this semantics has been added to `flang/test/Semantic`
Fixes: https://github.com/llvm/llvm-project/issues/77990

The use of `#include <stdlib.h>` introduces a libc dependency. In many
build environments such a file can be found under e.g. /usr/include, but
this does not necessarily correspond to the libc in use, which may not
be available until after the builtins have been built.

So far as I understand, it's not valid to have a dependency on libc from
builtins; there are a handful of such includes in builtins, but they are
protected by ifdefs.

Instead, use <stddef.h>, which provides `size_t` and is provided by the
compiler's resource headers and so should always be available.

[libc++][test] Fix zero-length arrays and copy-pasted lambdas in `ranges.contains.pass.cpp` (#79792)

* Fix MSVC error C2466: cannot allocate an array of constant size 0
  + MSVC rejects this non-Standard extension. Previous fixes: #74183
* Fix MSVC warning C4805: `'=='`: unsafe mix of type `'int'` and type
`'const bool'` in operation
+ AFAICT, these lambdas were copy-pasted, and didn't intend to take and
return `int` here. This part of the test is using `vector<bool>` for
random-access but non-contiguous iterators, and it's checking how many
times the projection is invoked, but the projection doesn't need to do
anything squirrely, it should otherwise be an identity.
* Fix typos: "continuous" => "contiguous".

* `libcxx/test/std/algorithms/alg.nonmodifying/alg.find/find.pass.cpp`
emits a bunch of warnings, all caused by what appears to be intentional
code:
+ Silence MSVC warning C4245: conversion from `'int'` to `'wchar_t'`,
signed/unsigned mismatch
    - Caused by: `test<U>(0, -1);`
+ Silence MSVC warning C4305: 'argument': truncation from `'int'` to
`'bool'`
    - Caused by: `test<U>(0, -1);`
  + Silence MSVC warning C4310: cast truncates constant value
    - Caused by: `test<U>(T(-129), U(-129));`
+ Silence MSVC warning C4805: `'=='`: unsafe mix of type `'char'` and
type `'bool'` in operation
    - Caused by: `bool expect_match = val == to_find;`
*
`libcxx/test/std/algorithms/alg.nonmodifying/alg.fold/left_folds.pass.cpp`
+ Silence MSVC warning C4244: 'argument': conversion from `'double'` to
`'const int'`, possible loss of data
- Caused by `[](int const x, double const y) { return x + y; }`
deliberately being given `double`s to truncate.
*
`libcxx/test/std/numerics/numeric.ops/numeric.ops.midpoint/midpoint.pointer.pass.cpp`
  + Silence MSVC warnings about C++20 deprecated `volatile`.
    - Caused by: `runtime_test<      volatile T>();`

I've not tried to change the purpose or style of the doc, just edited
for clarity and removed any Phabricator related language in favour of
GitHub terms.

Where possible, I've swapped direct links to LLVM's website with RST
links to the local documents. Which should be a bit more resilient.

Also it's less confusing if you're editing multiple pages locally, you
don't accidentally end up on the live site.

This is an extension to #74828 to handle maxloc too, to keep the minloc
and maxloc symmetric.

Extra characters and one with an incorrect file name.

These get wrapped by clang-format currently.

Move simplification of VPBlendRecipes from early VPlan construction to
VPlan-to-VPlan based recipe simplification. This simplifies initial
construction.

Note that some in-loop reduction tests are failing at the moment, due to
the reduction predicate being created after the reduction recipe. I will
provide a patch for that soon.

PR: https://github.com/llvm/llvm-project/pull/76090

OpenMP standard differentiates between omp simd (2.9.3.1) and omp do/for
simd (2.9.3.2 for OpenMP 5.0 standard) pragmas. The first one describes
the loop which needs to be vectorized. The second pragma describes the
loop which needs to be workshared between existing threads. Each thread
can use SIMD instructions to execute its chunk of the loop.

That's why we need to model
```
!$omp simd
  do-loop
```
as `omp.simdloop` operation and add compiler hints for vectorization.

The worksharing loop:
!$omp do simd
  do-loop
should be represented as worksharing loop (`omp.wsloop`).

Currently Flang denotes both types of OpenMP pragmas by `omp.simdloop`
operation. In consequence we cannot differentiate between:
```
!$omp parallel simd
   do-loop
```
and
```
!$omp parallel do simd
   do-loop
 ```
The second loop should be workshared between multiple threads. The first one describes the loop which needs to be redundantly executed by multiple threads. Current Flang implementation does not perform worksharing for `!$omp do simd` pragma and generates valid code only for the first case.

Code of `VisitVarTemplateSpecializationDecl` was rewritten based on code
of `VisitVarDecl`. Additional changes (in structural equivalence) were
made to make tests pass.

Fold expressions on Clang are limited to 256 elements. This causes
compilation errors in cases when the amount of elements added exceeds
this limit. Side-step the issue by restoring the original trick that
would use the std::initializer_list. For the record, in our downstream
Clang 16 gives:

mlir/include/mlir/IR/Dialect.h:269:23: fatal error: instantiating fold
expression with 688 arguments exceeded expression nesting limit of 256
    (addType<Args>(), ...);

Partially reverts 26d811b3

.

Co-authored-by: Nikita Kudriavtsev <nikita.kudriavtsev@intel.com>

remove_all_impl() opens the target path with O_NOFOLLOW, which fails if
the target is a symbolic link. On FreeBSD, rather than returning ELOOP,
openat() returns EMLINK. This is unlikely to change for compatibility
reasons, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214633 .

Thus, check for EMLINK as well.

Previosly we land
https://github.com/llvm/llvm-project/commit/085eae6b863881fb9fda323e5b672b04a00ed19e
to workaround the false positive ODR violations in
https://github.com/llvm/llvm-project/issues/76638.

However, we decided to not perform ODR checks for decls from GMF in
https://github.com/llvm/llvm-project/issues/79240 and we land the
corresponding change. So we should be able to remove the workaround now.

The original tests get remained.

- Support wait(devnum: ) with device_type support on all operations that
require it
- devnum value is stored as the first value of waitOperands in its
device_type sub-segment. The hasWaitDevnum attribute inform which
sub-segment has a wait(devnum) value.
- Make async/wait information homogenous on compute ops, data and update
op.
- Unify operands/attributes names across operations and use the same
custom parser/printer

We were converting several StringRefs to std::strings then to
char * so we could pass as %s to a format string. Use the Twine
signature of createStringError instead.

Close https://github.com/llvm/llvm-project/issues/79240.

See the linked issue for details. Given the frequency of issue reporting
about false positive ODR checks (I received private issue reports too),
I'd like to backport this to 18.x too.

Handle a special case when StoreInst's value operand is a kernel
argument of a pointer type. Since these arguments could have either a
basic element type (e.g. float*) or OpenCL builtin type (sampler_t),
bitcast the StoreInst's value operand to default pointer element type
(i8).

This pull request addresses the issue
https://github.com/llvm/llvm-project/issues/72864

Looks like a slip of the pen.