The calls to std::construct_at might overwrite the previously set
__has_value_ flag in the case where the flag is overlapping with
the actual value or error being stored (since we use [[no_unique_address]]).
To fix this issue, this patch ensures that we initialize the
__has_value_ flag after we call std::construct_at.

Fixes #68552

(cherry picked from commit 134c9159)

Test still fail on ARM machine (no float_control support)

(cherry picked from commit 5fdb70be)

The test Sema/PR69717.cpp fails on platforms that do not support
pragma float_control. So run this test on x86 only.

(cherry picked from commit 93ae2633)

When instantiation function, a call to Sema::resetFPOption was used to
set the FP options associated with AST node. However this function also
cleared FP pragma stack, and it is incorrect. Template instantiation
takes place on AST representation and semantic information like the FP
pragma stack should not affect it. This was a reason for miscompilation
in some cases.

To make the Sema interface more consistent, now `resetFPOptions` does
not clear FP pragma stack anymore. It is cleared in
`FpPragmaStackSaveRAII`, which is used in parsing only.

This change must fix https://github.com/llvm/llvm-project/issues/69717
(Problems with float_control pragma stack in Clang 17.x).

(cherry picked from commit f6f625f4)

No need to change the insert point for reduction gather node, we can use
the ReductionRoot as insert point instead to avoid possible crashes.

(cherry picked from commit d79051f8)

Fixes Issue #70208

(cherry picked from commit c9c9bf0f)

If we start with an i128 shift, the initial shift amount would usually
have zeros in bit 8 and above. xoring the shift amount with -1 will set
those upper bits to 1. If DAGCombiner is able to prove those bits are
now 1, then the shift that uses the xor will be replaced with undef.
Which we don't want.

Reduce the xor constant to VT.bits-1 where VT is half the size of the
larger shift type. This avoids toggling the upper bits. The hardware
shift instruction only uses the lower bits of the shift amount. I assume
the code used NOT because the hardware doesn't use the upper bits, but
that isn't compatible with the LLVM poison semantics.

Fixes #71142.

(cherry picked from commit 8d24d390)

Fixes #66890.

(cherry picked from commit 67b99fa8)

As noticed in D158846, the Solaris driver deviates from other targets in
that it links every executable with `-lm`, but doesn't for shared
objects. For C code, this is unnecessary, while for C++ `libm` is always
needed, even for shared objects.

This patch fixes this by following the `Gnu.cpp` precedent. It adjusts
the `solaris-ld.c` test accordingly, adding some more tests.

Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.

(cherry picked from commit 1e6b0df3)

A few symbols within libclangInterpreter have got explicit dllexport
attributes, in order to make them exported (and thus visible at runtime)
in any build, not only when they are part of e.g. a DLL libclang-cpp,
but also when they are part of a plain .exe.

Due to the explicit dllexports, these symbols would sidestep the regular
MinGW logic of exporting all symbols if there are no dllexports.
Therefore, for libclang-cpp, a separate fix was made in
592e935e, to pass --export-all-symbols
to the build of libclang-cpp.

If building with BUILD_SHARED_LIBS enabled, then the same issue appears
in libclangInterpreter; pass the same flag --export-all-symbols there as
well, to make sure all symbols are visible, not only the ones that are
explicitly marked as dllexport.

(cherry picked from commit 0d3eeac8)

Fixes a bug introduced by
commit b54294e2 ("[clang][ConstantEmitter] have
tryEmitPrivate[ForVarInit] try ConstExprEmitter fast-path first")

In the added test case, the QualType is a LValueReferenceType.

    LValueReferenceType 0x558412998d90 'const char (&)[41]'
    `-ParenType 0x558412998d30 'const char[41]' sugar
      `-ConstantArrayType 0x558412998cf0 'const char[41]' 41
        `-QualType 0x55841294c271 'const char' const
          `-BuiltinType 0x55841294c270 'char'

Fixes: #69979
(cherry picked from commit d9b15b06)

The check for whether a tail call is supported calls
determineAssignments(), which may modify argument flags. As such, even
though the check fails and a non-tail call will be emitted, it will not
have a different (incorrect) ABI.

Fix this by operating on a separate copy of the arguments.

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

(cherry picked from commit 292f34b0)

(cherry picked from commit d9cfb822)

replaceValuesPerBlockEntry() only handled simple and coerced load
values, however the load may also be referenced by a select value.

Additionally, I suspect that the previous code might have been incorrect
if a load had an offset, as it always constructed the AvailableValue
from scratch.

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

(cherry picked from commit 7f1733a2)

Resolved the crash that occurred during the use of a user-defined
C-style string literal. The fix entails checking whether the identifier
is non-empty before attempting to read its name.

(cherry picked from commit a396fb24)

Fixing ```#error "Unknown or unsupported OS"```

(cherry picked from commit 223852ae)

[OpenMP] Fixes #69905

(cherry picked from commit 01828c43)

This fixes a bug where functions generated by the MLIR Math dialect, for
example ipowi, would fail to link with link.exe on Windows due to having
linkonce linkage but no associated comdat. Adding the comdat on ELF also
allows linkers to perform better garbage collection in the binary.

Simply adding comdats to all functions with this linkage type should
also cover future cases where linkonce or linkonce_odr functions might
be necessary.

(cherry picked from commit 5f476b80)

This adds a new pass to add an Any comdat to each linkonce
and linkonce_odr function in the LLVM dialect. These comdats are
necessary on Windows
to allow the default system linker to link binaries containing these
functions.

(cherry picked from commit a6857156)

https://reviews.llvm.org/D146358 was assuming that all subobjects have
their own name (`SubobjectDecl`), but it was not true for array
elements.

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

GPRF64 represents a pair of registers. We were only copying the even
part. We need to copy the odd part too.

When partially packing an offset into an SVE load/store instruction we
are incorrectly calculating the remainder.

(cherry picked from commit 7c90be28)

Fixes #70578.

(cherry picked from commit 0c4f326d)

Use the getthrid() function instead of a syscall.

(cherry picked from commit 7e31b45d)

As explained in `__config`, we have an ABI tag that we use to ensure
that we don't run into ODR issues when mixing different versions of
libc++ in multiple TUs. However, the reasoning behind that extends not
only to different versions of libc++, but also to different
configurations of the same version of libc++. In fact, we've been aware
of this for a while but never really bothered to make the change because
ODR issues are often thought to be benign.

Well, it turns out that I just spent over an hour banging my head
against an issue that boils down to our lack of encoding of some ODR
properties in the ABI tag, so here's the patch we should have done a
long time ago.

For now, the ODR properties we encode in the ABI tag are:
- library version
- exceptions vs no-exceptions
- hardening mode

Those are all things that we support different values for on a per-TU
basis and they definitely affect ODR in a meaningful way. We can add
more properties later as we see fit.

(cherry picked from commit bc792a28)

This patch prevents argument promotion from promoting pointers to
fixed-length vector types larger than 128 bits like `<8 x float>` into
the values of the pointees.

Such vector types are used for SVE VLS but there is no ABI for SVE VLS
arguments and the backend cannot lower such value arguments.

Fixes #69147

(cherry picked from commit 926173c6)

With this patch, all CFRs can be used for register allocation.

(cherry picked from commit 271087e3)

This reverts commit a84e0b4b.

Fixes #68079.

(cherry picked from commit 7bc1031c)

When implementing thread_local as a keyword in C23, we accidentally
started using C++11 thread_local semantics when using that keyword
instead of using C11 _Thread_local semantics.

This oversight is fixed by pretending the user wrote _Thread_local
instead. This doesn't have the best behavior in terms of diagnostics,
but it does correct the semantic behavior.

Fixes https://github.com/llvm/llvm-project/issues/70068
Fixes https://github.com/llvm/llvm-project/issues/69167

Fixes https://github.com/llvm/llvm-project/issues/69369.
Fixes https://github.com/clangd/clangd/issues/1700.

(cherry picked from commit e63ab13c)

Our coefficients are 64-bits, so adding/multiplying them can wrap in
64-bits even if there would be no wrapping the full bit width.

The alternative would be to check for overflows during all adds/muls in
decomposition. I assume that we don't particularly care about handling
wide integers here, so I've opted to bail out.

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

(cherry picked from commit 1d43096e)

(cherry picked from commit 2b74db6c)

(cherry picked from commit a157a82b)

Fixes #68682.

(cherry picked from commit 2ad9a658)

Specifically, the test std/input.output/string.streams/stringstream/stringstream.members/gcount.pass.cpp
allocates a std::string with INT_MAX-1 elements, and then writes this to
a std::stringstream. On Linux, running this test consumes around 5.0 GB
of memory; on Windows, it ends up using up to 6.8 GB of memory.

This limits whether such tests can run on e.g. GitHub Actions runners,
where the free runners are limited to 8 GB of memory.

This is somewhat similar to, but still notably different, from the
existing test parameter long_tests.

(cherry picked from commit 122064a6)

(cherry picked from commit afdad4fd)