After https://github.com/llvm/llvm-project/pull/73301, all semantics
tests using `triple XXX` options need to have a
`REQUIRED: XX-registered-target` since the llvm::TargetMachine is needed
to get the llvm::DataLayout before semantics.

Fix three tests that lacked this.

Fixes:
https://lab.llvm.org/buildbot/#/builders/21/builds/87263
https://lab.llvm.org/buildbot/#/builders/268/builds/3841

We use X32 for gnux32 triples - X86 should be used for 32-bit triples

This makes libc++'s <filesystem> tests compatible with MSVC's STL.

In msvc_stdlib_force_include.h, we need to define 3 more macros:

- _CRT_DECLARE_NONSTDC_NAMES activates the POSIX names of
  `getcwd` etc. As the comment explains, we need this because
  we test with Clang `-fno-ms-compatibility`, which defines 
  `__STDC__` to `1`, which causes the UCRT headers to disable 
  the POSIX names by default.
- Then we need _CRT_NONSTDC_NO_WARNINGS to avoid emitting
  deprecation warnings about the POSIX names.
- Finally, we need `NOMINMAX` to seal away the ancient evil.

These macros are documented in https://learn.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=msvc-170.

As a drive-by change, the patch adds a "simulated" macro for 
__has_feature(hwaddress_sanitizer). It also clang-formats all
of msvc_stdlib_force_include.h and removes guards for
__has_builtin(__builtin_source_location) in <source_location>,
since those are not needed anymore.

Found while running libc++'s test suite with MSVC's STL.

This is a pure syntax cleanup, I don't need it for running libc++'s
tests with MSVC's STL.

This is possible because std::layout_meow and layout_wrapping_integral<1729>
aren't dependent types. We only need typename and template when reaching
into a dependent type, like `typename OtherLayout::template mapping<E2>` or
`typename layout_wrapping_integral<Wraps>::template mapping<Extents>`.

On AIX malloc(0) reutrns nullptr, which fails test case
`Evaluate/ISO-Fortran-binding.test`, using malloc(1) in AIX for
consistent behaviour

---------

Co-authored-by: Mark Danial <mark.danial@ibm.com>

Summary:
There are now a few cases that check if a symbol is present before
continuing, effectively making them optional features if present in the
image. This was done in at least three locations and required an ugly
operation to consume the error. This patch makes a utility function to
handle that instead.

Preliminary patch to change lowering/code generation to use
llvm::DataLayout information instead of generating "sizeof" GEP (see
https://github.com/llvm/llvm-project/issues/71507).

Fortran Semantic analysis needs to know about the target type size and
alignment to deal with common blocks, and intrinsics like
C_SIZEOF/TRANSFER. This information should be obtained from the
llvm::DataLayout so that it is consistent during the whole compilation
flow.

This change is changing flang-new and bbc drivers to:
1. Create the llvm::TargetMachine so that the data layout of the target
can be obtained before semantics.
2. Sharing bbc/flang-new set-up of the
SemanticConstext.targetCharateristics from the llvm::TargetMachine. For
now, the actual part that set-up the Fortran type size and alignment
from the llvm::DataLayout is left TODO so that this change is mostly an
NFC impacting the drivers.
3. Let the lowering bridge set-up the mlir::Module datalayout attributes
since it is doing it for the target attribute, and that allows the llvm
data layout information to be available during lowering.

For flang-new, the changes are code shuffling: the `llvm::TargetMachine`
instance is moved to `CompilerInvocation` class so that it can be used
to set-up the semantic contexts. `setMLIRDataLayout` is moved to
`flang/Optimizer/Support/DataLayout.h` (it will need to be used from
codegen pass for fir-opt target independent testing.)), and the code
setting-up semantics targetCharacteristics is moved to
`Tools/TargetSetup.h` so that it can be shared with bbc.

As a consequence, LLVM targets must be registered when running
semantics, and it is not possible to run semantics for a target that is
not registered with the -triple option (hence the power pc specific
modules can only be built if the PowerPC target is available.

This adds support for using dominating conditions in computeKnownBits()
when called from InstCombine. The implementation uses a
DomConditionCache, which stores which branches may provide information
that is relevant for a given value.

DomConditionCache is similar to AssumptionCache, but does not try to do
any kind of automatic tracking. Relevant branches have to be explicitly
registered and invalidated values explicitly removed. The necessary
tracking is done inside InstCombine.

The reason why this doesn't just do exactly the same thing as
AssumptionCache is that a lot more transforms touch branches and branch
conditions than assumptions. AssumptionCache is an immutable analysis
and mostly gets away with this because only a handful of places have to
register additional assumptions (mostly as a result of cloning). This is
very much not the case for branches.

This change regresses compile-time by about ~0.2%. It also improves
stage2-O0-g builds by about ~0.2%, which indicates that this change results
in additional optimizations inside clang itself.

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

Add commutative variant of m_DisjointOr.

Instead of linking to the doxygen documentation, link to the new sphinx
documentation instead.

It's rather disturbing that malformed syntax does not generate any
warnings or errors when building either locally or on the bots.

Tests to exercise vectorization of function calls where a vector variant
takes a linear parameter.

These tests were broken after
https://github.com/llvm/llvm-project/pull/74315

Fixing them to ignore the fastmath attribute on fcmp

We perform do this check independently of whether this is an old
or new style load.

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

This PR introduce `fence.mbarrier.init` OP

I'd copied and adjusted the doc comments for LLVMGetNNeg and LLVMSetNNeg
in #74517. Nikita pointed out in that review my comments were missing a
full stop, so I'm applying the same fix to these.

Follows #73952 doing the same thing for the nneg flag on zext (i.e.,
exposing support in the C API).

We can't easily convert this to use the update scripts, but we can manually improve the checks so we check for the right number of stores

Unblock build bot, while investigating. Issue is tracked under llvm
https://github.com/llvm/llvm-project/issues/74582

Found while running libc++'s tests with MSVC's STL.

`ranges::rotate_copy` takes `forward_iterator`s as this test's comment
banner correctly depicts. However, this test had bogus assertions
expecting that `ranges::rotate_copy` would be constrained away for
not-quite-**bidi** iterators. @philnik777 confirmed that these were
copy-paste relics from the `ranges::reverse_copy` test.

I fixed this by replacing the assertions with the test types that aren't
quite **forward** iterators/ranges. Additionally, I noticed that the
top-level `test()` function was missing coverage with the weakest
possible `forward_iterator<int*>`.

This revealed that the product code in `ranges_rotate_copy.h` was
similarly damaged. In addition to fixing it by taking `forward_iterator`
and `forward_range` as depicted in the Standard, this drops the
inclusion of `<__iterator/reverse_iterator.h>` as this algorithm doesn't
need `std::__reverse_range`.

`llvm.fcmp` does support fast math attributes therefore so should
`arith.cmpf`.

The heavy churn in flang tests are because flang sets
`fastmath<contract>` by default on all operations that support the fast
math interface. Downstream users of MLIR should not be so effected.

This was requested in https://github.com/llvm/llvm-project/issues/74263

This reverts commit f42b7615.

The fold pattern is incorrect, because it does not even look at the
permutation of non-unit dims and is happy to replace a pattern such as
```
%22 = vector.shape_cast %21 : vector<1x256x256xf32> to vector<256x256xf32>
%23 = vector.transpose %22, [1, 0] : vector<256x256xf32> to vector<256x256xf32>
```
with
```
%22 = vector.shape_cast %21 : vector<1x256x256xf32> to vector<256x256xf32>
```
which is obviously incorrect.

Current context set to where alias was met, not where it is declared
caused incorrect access check in case alias referenced private members
of the parent class.

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

See https://github.com/ARM-software/acle/pull/217

Patch by: Hassnaa Hamdi <hassnaa.hamdi@arm.com>

This should make it a bit harder to miss this type of issue. The warning
only shows if amdgpu-waves-per-eu is used.

See SWDEV-434482

`gpu.dynamic_shared_memory` currently does not get lowered when it is
used with vector dialect. The reason is that vector-to-llvm conversion
is not included in gpu-to-nvvm. This PR includes that and adds a test.

Use the or disjoint flag for decomposing or into add, which will handle
cases that haveNoCommonBitsSet() may not be able to reinfer (e.g.
because they require context-sensitive facts, which the call here does
not use.)

-nopie is an option for OpenBSD, and other linux distribution might
report an `unsupported option '-nopie' for target` error.

Co-authored-by: Stanislav Mekhanoshin <Stanislav.Mekhanoshin@amd.com>

This is derived from one of the regressions reported
after aed1a2217a1da0c9fb7d2c0856302dee25b1d4a1