[LVI][CVP] Treat undef like a full range on abs(x, false) (#68711)

Fixes #68682.

(cherry picked from commit 2ad9a658005e6a4204d7ee617c3949632a707aa5)

[libcxx] [test] Add a test parameter for disabling memory intensive tests (#68214)

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 122064a6303eb9c06e0af231f5a4ce145d9a2e67)

workflows/release-tasks: Fix release note artifact upload (#69522)

(cherry picked from commit afdad4fd402d1e8917375960df7104bc16f4cba9)

Bump version to 17.0.4

workflows/release-lit: Pass correct build directory to pypa/gh-action-pypi-publish (#69438)

(cherry picked from commit 1db8abf21a7c025d850624b487b5b792c562094e)

workflows/release-lit: Fix dev suffix removal (#69397)

This was broken by b71edfaa4ec3c998aadb35255ce2f60bba2940b0.

(cherry picked from commit 6a7f0b9d9fb533abeb14a7b5af03205688b3786a)

[asan] Ensure __asan_register_elf_globals is called in COMDAT asan.module_ctor (#67745)

On ELF platforms, when there is no global variable and the unique module ID is
non-empty, COMDAT asan.module_ctor is created with no
`__asan_register_elf_globals` calls. If this COMDAT is the prevailing copy
selected by the linker, the linkage unit will have no
`__asan_register_elf_globals` call: the redzone will not be poisoned and ODR
violation checker will not work (#67677).

This behavior is benign for -fno-sanitize-address-globals-dead-stripping because
asan.module_ctor functions that call `__asan_register_globals`
(`InstrumentGlobalsWithMetadataArray`) do not use COMDAT.

To fix #67677:

* Use COMDAT for -fsanitize-address-globals-dead-stripping on ELF platforms.
* Call `__asan_register_elf_globals` even if there is no global variable.
* If the unique module ID is empty, don't call SetComdatForGlobalMetadata:
  placing `@.str` in a COMDAT would incorrectly discard internal COMDAT `@.str`
  in other compile units.

Alternatively, when there is no global variable, asan.module_ctor is not COMDAT
and does not call `__asan_register_elf_globals`. However, the asan.module_ctor
function cannot be eliminated by the linker.

Tested the following script. Only ELF -fsanitize-address-globals-dead-stripping has changed behaviors.
```
echo > a.cc  # no global variable, empty uniqueModuleId
echo 'void f() {}' > b.cc  # with global variable, with uniqueModuleId
echo 'int g;' > c.cc  # with global variable
for t in x86_64-linux-gnu arm64-apple-macosx x86_64-windows-msvc; do
  for gc in -f{,no-}sanitize-address-globals-dead-stripping; do
    for f in a.cc b.cc c.cc; do
      echo /tmp/Rel/bin/clang -S --target=$t -fsanitize=address $gc $f -o -
      /tmp/Rel/bin/clang -S --target=$t -fsanitize=address $gc $f -o - | sed -n '/asan.module_ctor/,/ret/p'
    done
  done
done
```

---

Identical to commit 16eed8c906875e748c3cb610f3dc4b875f3882aa.
6420d3301cd4f0793adcf11f59e8398db73737d8 is an incorrect revert for genuine
purely internal issues.

[clang-format][doc] Update the Linux kernel coding style URL

(cherry picked from commit 8902f12e61aa2d3053ad4d536e36569fc8bc9512)

[clang-format] Fix a serious bug in git-clang-format (#65723)

When applying format changes to staged files, git-clang-format
erroneously checks out all files in the index and thus may overwrite
unstaged changes.

Fixes #65643.

(cherry picked from commit 743659be87daff4cc8861c525d4a6229d787ef14)

[LSan] Mark create_thread_leak.cpp as UNSUPPORTED: darwin.

It started to fail in a flaky manner a few days ago on GreenDragon buildbots
(i.e. x86_64-darwin). I didn't track down the root cause but LSan isn't
actually supported on darwin anyway, so UNSUPPORTED seems appropriate.

Prior art: 3ff080b5.

(cherry picked from commit 0a3519d5a27b9400250b5f6656b50148021e7496)

[PowerPC] Use zext instead of anyext in custom and combine (#68784)

This custom combine currently converts `and(anyext(x),c)` into
`anyext(and(x,c))`. This is not correct, because the original expression
guaranteed that the high bits are zero, while the new one sets them to
undef.

Emit `zext(and(x,c))` instead.

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

(cherry picked from commit 127ed9ae266ead58aa525f74f4c86841f6674793)

[PowerPC] Add test for #68783 (NFC)

(cherry picked from commit 0ead1faef0bfaea499c3b2d13ab417f6bf3f67e1)

[clang-format] Fix a bug in RemoveParentheses: ReturnStatement (#67911)

Don't remove the outermost parentheses surrounding a return statement
expression when inside a function/lambda that has the decltype(auto)
return type.

Fixed #67892.

(cherry picked from commit 75441a684273268ce91036aa2c770e669d39f501)

[X86] Fix logic for optimizing movmsk(bitcast(shuffle(x))); PR67287

Prior logic would remove the shuffle iff all of the elements in `x`
where used. This is incorrect.

The issue is `movmsk` only cares about the highbits, so if the width
of the elements in `x` is smaller than the width of the elements
for the `movmsk`, then the shuffle, even if it preserves all the elements,
may change which ones are used by the highbits.

For example:
`movmsk64(bitcast(shuffle32(x, (1,0,3,2))))`

Even though the shuffle mask `(1,0,3,2)` preserves all the elements, it
flips which will be relevant to the `movmsk64` (x[1] and x[3]
before and x[0] and x[2] after).

The fix here, is to ensure that the shuffle mask can be scaled to the
element width of the `movmsk` instruction. This ensure that the
"high" elements stay "high". This is overly conservative as it
misses cases like `(1,1,3,3)` where the "high" elements stay
intact despite not be scalable, but for an relatively edge-case
optimization that should generally be handled during
simplifyDemandedBits, it seems okay.

(cherry picked from commit 1684c65bc997a8ce0ecf96a493784fe39def75de)

[X86] Add tests for incorrectly optimizing out shuffle used in `movmsk`; PR67287

(cherry picked from commit 65a576e27be814bd23f39b31a8074e9850b0fe26)

[clang] [MinGW] Explicitly always pass the -fno-use-init-array (#68571)

On MinGW targets, the .ctors section is always used for constructors.

When using the .ctors section, the constructors need to be emitted in
reverse order to get them execute in the right order. (Constructors with
a specific priority are sorted separately by the linker later.) In LLVM,
in CodeGen/AsmPrinter/AsmPrinter.cpp, there's code that reverses them
before writing them out, executed when using the .ctors section. This
logic is done whenever TM.Options.UseInitArray is set to false. Thus,
make sure to set UseInitArray to false for this target.

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

(cherry picked from commit a2b8c49c1839076b540c542c024fcfe2361a3e47)

[LVI][CVP] Treat undef like a full range (#68190)

When converting to ConstantRange, we should treat undef like a full range.
Fixes #68381.

(cherry picked from commit 81857940f278e21f7957a2833d4b6ec72819e79f)

[X86] combineConcatVectorOps - only concatenate single-use subops

We could maybe extend this by allowing the lowest subop to have multiple uses and extract the lowest subvector result of the concatenated op, but let's just get the fix in first.

Fixes #67333

Bump version to 17.0.3

[clang] Correct behavior of `LLVM_UNREACHABLE_OPTIMIZE=OFF` for `Release` builds (#68284)

```c++
AArch64SVEPcsAttr *AArch64SVEPcsAttr::CreateImplicit(ASTContext &Ctx, SourceRange Range, Spelling S) {
  AttributeCommonInfo I(Range, NoSemaHandlerAttribute, (
    S == GNU_aarch64_sve_pcs ? AttributeCommonInfo::Form{AttributeCommonInfo::AS_GNU, GNU_aarch64_sve_pcs, false /*IsAlignas*/, false /*IsRegularKeywordAttribute*/} :
    S == CXX11_clang_aarch64_sve_pcs ? AttributeCommonInfo::Form{AttributeCommonInfo::AS_CXX11, CXX11_clang_aarch64_sve_pcs, false /*IsAlignas*/, false /*IsRegularKeywordAttribute*/} :
    S == C23_clang_aarch64_sve_pcs ? AttributeCommonInfo::Form{AttributeCommonInfo::AS_C23, C23_clang_aarch64_sve_pcs, false /*IsAlignas*/, false /*IsRegularKeywordAttribute*/} :
    (llvm_unreachable("Unknown attribute spelling!"),  AttributeCommonInfo::Form{AttributeCommonInfo::AS_GNU, 0, false /*IsAlignas*/, false /*IsRegularKeywordAttribute*/})));
  return CreateImplicit(Ctx, I);
}
```

```c++
AArch64SVEPcsAttr *AArch64SVEPcsAttr::CreateImplicit(ASTContext &Ctx, SourceRange Range, Spelling S) {
  AttributeCommonInfo I(Range, NoSemaHandlerAttribute, [&]() {
    switch (S) {
    case GNU_aarch64_sve_pcs:
      return AttributeCommonInfo::Form{AttributeCommonInfo::AS_GNU, GNU_aarch64_sve_pcs, false /*IsAlignas*/, false /*IsRegularKeywordAttribute*/};
    case CXX11_clang_aarch64_sve_pcs:
      return AttributeCommonInfo::Form{AttributeCommonInfo::AS_CXX11, CXX11_clang_aarch64_sve_pcs, false /*IsAlignas*/, false /*IsRegularKeywordAttribute*/};
    case C23_clang_aarch64_sve_pcs:
      return AttributeCommonInfo::Form{AttributeCommonInfo::AS_C23, C23_clang_aarch64_sve_pcs, false /*IsAlignas*/, false /*IsRegularKeywordAttribute*/};
    default:
      llvm_unreachable("Unknown attribute spelling!");
      return AttributeCommonInfo::Form{AttributeCommonInfo::AS_GNU, 0, false /*IsAlignas*/, false /*IsRegularKeywordAttribute*/};
    }
  }());
  return CreateImplicit(Ctx, I);
}
```

Fixes https://github.com/llvm/llvm-project/issues/68237
Conflicts:
clang/docs/ReleaseNotes.rst

[LLD] [COFF] Fix handling of comdat .drectve sections (#68116)

This can happen when manually emitting strings into .drectve sections
with `__attribute__((section(".drectve")))`, which is a way to emulate
`#pragma comment(linker, "...")` for mingw compilers, without requiring
building with -fms-extensions.

Normally, this doesn't generate any comdat, but if compiled with
-fsanitize=address, this section does get turned into a comdat section.

This fixes #67261. This issue can be seen as a regression; a change in
the "lli" tool in 17.x triggers this case, if compiled with ASAN
enabled, triggering this unsupported corner case in LLD. With this
change, LLD can handle it.

(cherry picked from commit 503bc5f66111f7e4fc79972bb9bfec8bb5606bab)

workflows/release-binaries: Use more cores to avoid the 6 hour timeout (#67874)

(cherry picked from commit 95b2c6b3d6dc5f8b6ee5eb4f8dbc96dea0f50cac)

[AArch64] Disable loop alignment for Windows targets (#67894)

This should fix #66912. When emitting SEH unwind info, we need to be
able to calculate the exact length of functions before alignments are
fixed. Until that limitation is overcome, just disable all loop
alignment on Windows targets.

(cherry picked from commit 6ae36c012728a274a78a771e4506681732f85a6d)

[Sema] Use underlying type of scoped enum for -Wformat diagnostics (#67378)

Right now, `-Wformat` for a scoped enum will suggest a cast based on the
format specifier being used. This can lead to incorrect results, e.g.
attempting to format a scoped enum with `%s` would suggest casting to
`char *` instead of fixing the specifier. Change the logic to treat the
scoped enum's underlying type as the intended type to be printed, and
suggest format specifier changes and casts based on that.

(cherry picked from commit 0b07b06effe5fdf779b75bb5ac6cf15e477cb0be)

Fix release/export.sh to export runtimes tarball, too (#67404)

This addresses missing cmake files needed to build some sub-projects
like libstdcxx.

Co-authored-by: René Rebe <rene@exactcode.de>

[libc++] Fix `std::pair`'s  pair-like constructor's incorrect assumption (#66585)

The helper function `__pair_like_explicit_wknd` is only SFINAE-ed with
`tuple_size<remove_cvref_t<_PairLike>>::value == 2`, but its function
body assumes `std::get` being valid.

Fixes #65620

(cherry picked from commit 054f9c55c6b4520d3feb8b4354b9b942026b5124)

[CodeGen] Don't treat thread local globals as large data (#67764)

Otherwise they may mistakenly get the large section flag.

(cherry picked from commit b915f60678c3033c466611be1119a46ba4b0869c)
(fix was slightly different since cherry-pick didn't apply well)

[workflow] Fix abi checker in llvm-tests. Same fix as in 99fb0af80d16b0ff886f032441392219e1cac452 (#67957)

Fixes #67651

[clang] [MinGW] Tolerate mingw specific linker options during compilation (#67891)

Prior to 591c4b64b3650884c2c68eb47d755ebb62981b99, the mingw specific
linker options -mthreads, -mconsole, -mwindows and -mdll would be
tolerated also at compile time, but generating a warning about being
unused.

After that commit, they were marked as target specific, which means that
it's an error if they're unused (which would consider them used for the
wrong target). These specific options are only relevant when linking,
but we want to tolerate them at compile time too, like before.

This was fixed for -mthreads in
a79995ca6004082774a87f7a58ab6be5343364b7, while the other options didn't
seem to be commonly used during compilation.

After the 17.x release, we've got more reports about this actually being
an issue, in #64464. Therefore, apply the same fix for them; marking
them as tolerated for mingw targets during compilation, even if they're
unused. Also add a testcase for -mthreads which was already handled.

Thus, this fixes #64464.

(cherry picked from commit e39de2b8862ae43459324da84279366997265078)

Adapted from the original commit; the test in the original commit
depended on f39c399d9d15efe8309d8aa3d0ecf62205e6c474. Instead of
using -###, when we're not actually using the printed output of
-###, instead use -fdriver-only.

[LLD] [COFF] Restore the current dir as the first entry in the search path (#67857)

Before af744f0b84e2b6410be65277068b9033124c73b2, the first entry
among the search paths was the empty string, indicating searching
in (or starting from) the current directory. After
af744f0b84e2b6410be65277068b9033124c73b2, the toolchain/clang
specific lib directories were added at the head of the search path.

This would cause lookups of literal file names or relative paths
to match paths in the toolchain, if there are coincidental files
with similar names there, even if they would be find in the current
directory as well.

Change addClangLibSearchPaths to append to the list like all other
operations on searchPaths - but move the invocation of the
function to the right place in the sequence.

This fixes #67779.

(cherry picked from commit f906fd53b5ce12f07aec394ddf900c7f9f583405)

[LLD] [COFF] Clarify -print-search-path for the empty string element (#67856)

Also switch the test case to use -NEXT to strictly match all lines.

(cherry picked from commit 7d7d9e462a8983d71e01786c9ad61a976ff10e8a)

[NFC] clang-format lld/COFF/Driver.cpp and lld/Common/Filesystem.cpp

In order to reduce noise for a MR.

(cherry picked from commit a5e280bc6bda10607e0e7c864e4d23fac02d00aa)

[compiler-rt] Reinstate removal of CRT choice flags from CMAKE_*_FLAGS* (#67935)

This reverts one part of commit
9f4dfcb795bb0ecf9944553f49371164801cd83f, with a modified comment added
about the code.

Ideally, this would only be reinstated temporarily - but given the
situation in vcpkg, it looks likely that they would keep passing the
duplicate options for quite some time. The conflicting CRT choice
usually are benign but only would cause warnings about one option
overriding the other, if passing e.g. "/MDd /MT".

However when vcpkg currently sets these options in CMAKE_*_FLAGS_DEBUG,
it passes the redundant option /D_DEBUG; thus the compiler finally ends
up with e.g. "/D_DEBUG /MDd /MT", which has the effect of defining
_DEBUG while using a release mode CRT, which allegedly breaks the build.

There's a PR up for removing this redundant /D_DEBUG option in vcpkg in
https://github.com/microsoft/vcpkg/pull/34123. With that in place, this
change wouldn't be strictly needed.

(cherry picked from commit 7bc09a471fbc274d8632d1379d4134bec63fecc4)

[MemCpyOpt] Merge alias metadatas when replacing arguments (#67539)

Alias metadata may no longer be valid after replacing the call argument.
Fix this by merging it with the memcpy alias metadata.

This fixes a miscompilation encountered in
https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Failing.20tests.20when.20rustc.20is.20compiled.20with.201.20CGU.

(cherry picked from commit 4e6e476329a8359cb381517864ed6f88a152e37b)

[MemCpyOpt] Add test for #67539 (NFC)

(cherry picked from commit d5c8b23b1ee1dcb6922e8226143410840edabe50)

[DependencyScanningFilesystem] Make sure the local/shared cache filename lookups use only absolute paths (#66122)

Previously a relative path would be used as a key for cache lookup and
if the same relative path was used from another compiler invocation with
a different working directory then the first cache entry was erroneously
returned.

(cherry picked from commit 36b37c775c285bbff9b57630e7ea9d00b918cc91)

[Sema] Fix fixit cast printing inside macros (#66853)

`Lexer::getLocForEndOfToken` is documented as returning an invalid
source location when the end of the token is inside a macro expansion.
We don't want that for this particular application, so just calculate
the end location directly instead.

Before this, format fix-its would omit the closing parenthesis (thus
producing invalid code) for macros, e.g.:

```
$ cat format.cpp
extern "C" int printf(const char *, ...);
enum class Foo { Bar };
#define LOG(...) printf(__VA_ARGS__)
void f(Foo foo) { LOG("%d\n", foo); }

$ clang -fsyntax-only format.cpp
format.cpp:4:29: warning: format specifies type 'int' but the argument has type 'Foo' [-Wformat]
    4 | void f(Foo f) { LOG("%d\n", f); }
      |                      ~~     ^
      |                             static_cast<int>(
format.cpp:3:25: note: expanded from macro 'LOG'
    3 | #define LOG(...) printf(__VA_ARGS__)
      |                         ^~~~~~~~~~~
1 warning generated.
```

We now emit a valid fix-it:

```
$ clang -fsyntax-only format.cpp
format.cpp:4:31: warning: format specifies type 'int' but the argument has type 'Foo' [-Wformat]
    4 | void f(Foo foo) { LOG("%d\n", foo); }
      |                        ~~     ^~~
      |                               static_cast<int>( )
format.cpp:3:25: note: expanded from macro 'LOG'
    3 | #define LOG(...) printf(__VA_ARGS__)
      |                         ^~~~~~~~~~~
1 warning generated.
```

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

(cherry picked from commit 61c5ad8857a71510e4393680a1e42740da4ba6fa)

Work around two more instances of __noinline__ conflicts. (#66138)

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

(cherry picked from commit 588023ddafb4b0cd11914ab068c6d07187374d69)

[lldb] Fix building LLDB standlone without framework

In a809720102fae8d1b5a7073f99f9dae9395c5f41 I refactored some logic to
deal with the clang resource directory in standalone LLDB builds.
However, this logic escaped me because it only runs when you do not
build LLDB.framework.

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

(cherry picked from commit 6888de118707e6392b46073fc35738804f9f1d80)

[lldb][NFCI] Change logic to find clang resource dir in standalone builds

As of 0beffb854209a41f31beb18f9631258349a99299 there is a CMake
function to actually calculate the relative path to the clang resource
directory. Currently we have some bespoke logic that looks in a few
places, but with this new function we should be able to eliminate some
complexity here.

Also, I moved the functionality from LLDBConfig to LLDBStandalone since
it is only used in standalone builds.

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

(cherry picked from commit a809720102fae8d1b5a7073f99f9dae9395c5f41)

[XCOFF] Do not generate the special .ref for zero-length sections (#66805)

Co-authored-by: Wael Yehia <wyehia@ca.ibm.com>
(cherry picked from commit da55b1b52fbce80093eee8dd4185df4861a44ba5)

Fix buildbot failure caused by D157623

GCC doesn't like the implicit conversion here.

(cherry picked from commit f11f90d5f4ebfab2b44bf3c98b2d2162acf81e2c)

[lld][COFF] Remove incorrect flag from EHcont table

Fixes EHCont implementation in LLD. Closes #64570

Reviewed By: rnk

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

(cherry picked from commit e335c78ec2848e24b10e32e015a84347c69c8130)

workflows/release-tasks: Setup FileCheck and not for release-lit (#66799)

lit tests require commands FileCheck and not. They must be available in
the PATH.

This also guarantees that python3-psutil is installed in order to enable
more tests.

Fixes #64892.

(cherry picked from commit b2247f85dc4b187dd0ebc93059a0aa42f35dd64a)

[StackColoring] Handle fixed object index

This is a followup to #66988. The implementation there did not
account for the possibility of the catch object frame index
referrring to a fixed object, which is the case on win64.

(cherry picked from commit aa70f4d8cf8f09a2997773156289b16d6a16ec01)

[StackColoring] Handle SEH catch object stack slots conservatively

The write to the SEH catch object happens before cleanuppads are
executed, while the first reference to the object will typically
be in a catchpad.

If we make use of first-use analysis, we may end up allocating
an alloca used inside the cleanuppad and the catch object at the
same stack offset, which would be incorrect.

https://reviews.llvm.org/D86673 was a previous attempt to fix it.
It used the heuristic "a slot loaded in a WinEH pad and never
written" to detect catch objects. However, because it checks
for more than one load (while probably more than zero was
intended), the fix does not actually work.

The general approach also seems dubious to me, so this patch
reverts that change entirely, and instead marks all catch object
slots as conservative (i.e. excluded from first-use analysis)
based on the WinEHFuncInfo. As far as I can tell we don't need
any heuristics here, we know exactly which slots are affected.

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

(cherry picked from commit b3cb4f069c2cb99bdae68d6906156af20e76314f)

[X86] Add test for #66984 (NFC)

(cherry picked from commit 8b4e29b35d21b079e8b30244cbbfc4d4bc4a29d4)

[SimpleLoopUnswitch] Fix exponential unswitch

When unswitching via invariant condition injection, we currently
mark the condition in the old loop, so that it does not get
unswitched again. However, if there are multiple branches for
which conditions can be injected, then we can do that for both
the old and new loop. This means that the number of unswitches
increases exponentially.

Change the handling to be more similar to partial unswitching,
where we instead mark the whole loop, rather than a single
condition. This means that we will only generate a linear number
of loops.

TBH I think even that is still highly undesirable, and we should
probably be unswitching all candidates at the same time, so that
we end up with only two loops. But at least this mitigates the
worst case.

The test case is a reduced variant that generates 1700 lines of IR
without this patch and 290 with it.

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

(cherry picked from commit 8362cae71b80bc43c8c680cdfb13c495705a622f)

[SimpleLoopUnswitch] Fix reversed branch during condition injection

The in-loop successor is only on the left after a potential condition
inversion. As we re-use the old condition as-is, we should also
reuse the old successors as-is.

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

(cherry picked from commit afd7db48c55cb87566758e961f1ebac8af16b8bc)

[clang] Include `expected-no-diagnostics` in newly-added test (NFC)

(cherry picked from commit c990d9444350ef583c6d53e84d9c10cebbf65532)

[clang] Bail out when handling union access with virtual inheritance

An assertion issue that arose when handling union member access with
virtual base class has been addressed. As pointed out by @zygoloid,
there is no need for further derived-to-base analysis in this instance,
so we can bail out upon encountering a virtual base class. Minor
refinement on the function name as we might not be handling a union.

Reported-By: ormris
Fixes: https://github.com/llvm/llvm-project/issues/65982
(cherry picked from commit 660876a4019b81b5a7427a3dcec5ce8c39cd1ee0)

[clang][Diagnostics] Fix wrong line number display (#65238)

When the caret location is lower than the lowest source range, clang is
printing wrong line numbers. The first line number should consider caret
location line even when there are source ranges provided.

Current wrong line example: https://godbolt.org/z/aj4qEjzs4

(cherry picked from commit ef5217b3c0dcbb58927fe43400b6d1faa677bf98)

Revert "[InlineCost] Check for conflicting target attributes early"

This reverts commit d6f994acb3d545b80161e24ab742c9c69d4bbf33.

Several people have reported breakage resulting from this patch:

- https://github.com/llvm/llvm-project/issues/65152
- https://github.com/llvm/llvm-project/issues/65205

(cherry picked from commit b4301df61fc77a9d54ac236bc88742a731285f1c)

[GVN] Also remove phi nodes from VN table (PR65447)

Followup to D158849: We also need to remove the phi node from the
VN table, which is not handled by removeInstruction().

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

(cherry picked from commit 18e77760ce5e42d9057f69c3e64a8300d01a48ac)

[GVN] Invalidate MDA when deduplicating phi nodes

Duplicate phi nodes were being directly removed, without
invalidating MDA. This could result in a new phi node being
allocated at the same address, incorrectly reusing a cache entry.

Fix this by optionally allowing EliminateDuplicatePHINodes() to
collect phi nodes to remove into a vector, which allows GVN to
handle removal itself.

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

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

(cherry picked from commit 7c229f6e85478bb0626a5e598f47b7be94bb50b0)

Bump version to 17.0.2

[SVE] Ensure SVE call operands passed via memory are correctly initialised. (#66070)

The stores created when passing operands via memory don't typically
maintain the chain, because they can be done in any order. Instead,
a new chain is created based on all collated stores. SVE parameters
passed via memory don't follow this idiom and try to maintain the
chain, which unfortunately can result in them being incorrectly
deadcoded when the chain is recreated.

This patch brings the SVE side in line with the non-SVE side to
ensure no stores become lost whilst also allowing greater flexibility
when ordering the stores.

[SVE] Precommit test to show missing initialisation of call operand.

When calling func_f8_and_v0_passed_via_memory the memory used to
hold the first vector operand is allocated but not initialised.

Bump version to 17.0.1

Remove RC suffix

Revert "[C++20] [Coroutines] Mark await_suspend as noinline if the awaiter is not empty"

This reverts commit f05226d7e38c36efe029a0eb4201b0843f81b5e8.

Revert "[NFC] [C++20] [Coroutines] Mention the side effect of a fix may bring regressions"

This reverts commit 6998ecd330f2b028bf4678edd4f53b5489c5e6df.

[SimplifyCFG] handle monotonic wrapped case for D150943 (#65882)

(cherry picked from commit fef82492209b24fd0b36a199657f3ed822e601a6)

[lli] Make sure the exported __chkstk functions are included when exporting them

The trick we use (since cbc2a0623a39461b56bd9eeb308ca535f03793f8)
for exporting the __chkstk function (with various per-arch names)
that is defined in a different object file, relies on the function
already being linked in (by some function referencing it).

This function does end up referenced if there's a function that
allocates more than 4 KB on the stack. In most cases, it's referenced
somewhere, but in the case of builds with LLVM_LINK_LLVM_DYLIB
enabled (so most of the code resides in a separate libLLVM-<ver>.dll)
the only code in lli.exe is the lli tool specific code and the
mingw-w64 crt startup code. In the case of GCC based MinGW i386
builds with LLVM_LINK_LLVM_DYLIB, nothing else references it though.

Manually add a reference to the function to make sure it is linked
in (from libgcc or compiler-rt builtins) so that it can be exported.

This fixes one build issue encountered in
https://github.com/msys2/MINGW-packages/pull/18002.

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

(cherry picked from commit 4bba12f7226228221d1fa4bad7732e25647ecb87)

[ARM] Change CRC predicate to just HasCRC

This removes the backend requirement for crc instructions on HasV8, relying on
just HasCRC instead. This should allow them to be selected with ArmV7 + crc,
making them more usable whilst hopefully not making them incorrectly generated
(they only come from intrinsics, and HasCRC usually requires HasV8). This is
how most other instructions are specified.

(cherry picked from commit a82c106e571c6991a95c38a936a466895122d713)

[flang] Allow runtime build with AVOID_NATIVE_INT128_T=1

This patch enables the Fortran runtime support library to be
built without native 128-bit integer support in the C++ compiler.

Experimental: do not merge yet.

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

(cherry picked from commit 1c35c1a73907a95ce54b5a0edca513591e2bc069)

[Clang] Fix JIT test on 32-bit systems

As reported by mgorny at https://reviews.llvm.org/D159115#4638037, the
unsigned long long cast fails on 32-bit systems at least with GCC.

It looks like a pointer provenance/aliasing issue rather than a bug in GCC.

Acked by Vassil Vassilev on the original revision.

(cherry picked from commit 3403686b72507e3fdbcd69f21fb9235ffa0ca169)

[builtins][AArch64] Implement _sync out-of-line atomics

Whilst Clang does not use these, recent GCC does, and so on systems such
as FreeBSD that wish to use compiler-rt as the system runtime library
but also wish to support building programs with GCC these interfaces are
needed.

This is a light adaptation of the code committed to GCC by Sebastian Pop
<spop@amazon.com>, relicensed with permission for use in compiler-rt.

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

Reviewed By: sebpop, MaskRay

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

(cherry picked from commit 4bb2416d42eb593c44bbeb765e1b8641a58f853c)

Fix AIX OS requirements for ThinLTO to 7.2.5 SP7

[SCEV] Fix potentially empty set for unsigned ranges

The following commit enabled the analysis of ranges for heap allocations:
22ca38da25e19a7c5fcfeb3f22159aba92ec381e

The range turns out to be empty in cases such as the one in test (which
is [1,1)), leading to an assertion failure. This patch fixes for the
same case.

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

Reviewed By: fhahn

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

(cherry picked from commit 0609b65aaf03b083d282a4ffe8bf660351dac461)

[CodeGen] Fix incorrect insertion point selection for reduction nodes in ComplexDeinterleavingPass

When replacing ComplexDeinterleavingPass::ReductionOperation, we can do it
either from the Real or Imaginary part. The correct way is to take whichever
is later in the BasicBlock, but before the patch, we just always took the
Real part.

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

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

(cherry picked from commit e2cb07c322e85604dc48f9caec52b3570db0e1d8)

[CodeGen][AArch64] Commit test for #65044

(cherry picked from commit 2fce8f74b3c04bbf7e941cfed7604edae2b573b6)

[libc++][hardening] Remove hardening from release notes, undeprecate safe mode

This patch effectively maintains the status quo, making sure that the
safe mode keeps working the same way as before. Hardening will target
the next major release, allowing it to go through RFC and for the
implementation to stabilize and mature.

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

[LoopVectorize] Fix incorrect order of invariant stores when there are multiple reductions.

When a loop has multiple reductions, each with an intermediate invariant
store, the order in which those reductions are processed is not considered.
This can result in the invariant stores outside the loop not preserving the
original order.
This patch sorts VPReductionPHIRecipes by the order in which they have
stores in the original loop before running
`InnerLoopVectorizer::fixReduction` function, and it helps to maintain
the correct order of stores.

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

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

(cherry picked from commit ac65fb869977185b44757b94dc5130bd08c6f7e2)

[LoopVectorize] Pre-commit tests for D157631

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

(cherry picked from commit 2df9ed11c51ebf6d19f7cb22c3794d1bd460ddf8)

[RelNotes] Add more details on the removal of the legacy optimization pipeline

[mlir][nfc] Allow ops to have operands/attributes named `context`.

This is probably a bad idea, but it's only become a problem with properties and is easy to fix.

Reviewed By: mehdi_amini

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

[JumpThreading] Invalidate LVI after `combineMetadataForCSE`.

(cherry picked from commit 7ded71b1e43fff0be3acb74038bfea87f38d5cfa)

[JumpThreading][NFC] Pre-commit for invalid LVI.

(cherry picked from commit 5855a4be9cbc3c4584d8a1632886c347044dfbef)

Revert "[clang][Docs] Added release note for D142609"

The associated commit was reverted and backported in a93ca35, so this
release note line should also be removed.

This reverts commit 061e855767dbe0821d81a8d47158f468dd00ae5f.

[clang][clangd] Ensure the stack bottom before building AST

`clang::runWithSufficientStackSpace` requires the address of the
initial stack bottom to prevent potential stack overflows.

In addition, add a fallback to ASTFrontendAction in case any client
forgets to call it when not through CompilerInstance::ExecuteAction,
which is rare.

Fixes https://github.com/clangd/clangd/issues/1745.

Reviewed By: sammccall

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

(cherry picked from commit e257c0a9190637e44e292271103a13d70bec4b03)

[clang] Construct ExprRequirement with SubstitutionDiagnostic on SubstFailure

We're expecting a SubstitutionDiagnostic in diagnoseUnsatisfiedRequirement
if the status of ExprRequirement is SubstFailure. Previously, the Requirement
was created with Expr on SubstFailure by mistake, which could lead to the
assertion failure in the subsequent diagnosis.

Fixes https://github.com/clangd/clangd/issues/1726
Fixes https://github.com/llvm/llvm-project/issues/64723
Fixes https://github.com/llvm/llvm-project/issues/64172

In addition, this patch also fixes an invalid test from D129499.

Reviewed By: erichkeane

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

[NFC][Clang] Fix static analyzer concern about null value dereference

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

[sanitizer] scanf interceptor: fix write size for %mc/%mC/%mS

When the optional assignment-allocation character 'm' (Extension to the
ISO C standard) is present, we currently use internal_strlen(buf)+1 for
all of cCsS[ (D85350). Fix cCS to use the correct size.

Fix https://github.com/llvm/llvm-project/issues/61768

Reviewed By: #sanitizers, vitalybuka

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

(cherry picked from commit beeb37a8f3275281be305d2d1afe35ca053e21c0)

[CodeGen] First check the kind and then the llvm::Function properties.

This patch fixes valgrind reports from downstream consumers about conditional
jump over uninitialised memory.

The original report:

```[ RUN      ] ScopeReflectionTest.IsComplete
==987150== Conditional jump or move depends on uninitialised value(s)
==987150==    at 0x1E1128F: clang::CodeGen::CodeGenModule::SetLLVMFunctionAttributesForDefinition(clang::Decl const*, llvm::Function*) (CodeGenModule.cpp:2391)
==987150==    by 0x1E4F181: clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (CodeGenModule.cpp:5669)
==987150==    by 0x1E4A194: clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (CodeGenModule.cpp:3909)
==987150==    by 0x1E4A752: clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (CodeGenModule.cpp:3649)
==987150==    by 0x1E532F5: clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) [clone .part.0] (CodeGenModule.cpp:6563)
==987150==    by 0x1B0BEDD: (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) (ModuleBuilder.cpp:190)
==987150==    by 0x1AEA47B: clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (CodeGenAction.cpp:235)
==987150==    by 0x101B02F: clang::IncrementalASTConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (IncrementalParser.cpp:52)
==987150==    by 0x101ED93: clang::IncrementalParser::ParseOrWrapTopLevelDecl() (IncrementalParser.cpp:276)
==987150==    by 0x101FBBC: clang::IncrementalParser::Parse(llvm::StringRef) (IncrementalParser.cpp:342)
==987150==    by 0x100E104: clang::Interpreter::Parse(llvm::StringRef) (Interpreter.cpp:360)
==987150==    by 0xE734C0: Cpp::Interpreter::Parse(llvm::StringRef) (CppInterOpInterpreter.h:172)
==987150==  Uninitialised value was created by a heap allocation
==987150==    at 0x844BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==987150==    by 0x1B0C882: StartModule (ModuleBuilder.cpp:139)
==987150==    by 0x1B0C882: clang::CodeGenerator::StartModule(llvm::StringRef, llvm::LLVMContext&) (ModuleBuilder.cpp:360)
==987150==    by 0x101C4AF: clang::IncrementalParser::GenModule() (IncrementalParser.cpp:372)
==987150==    by 0x101FC0E: clang::IncrementalParser::Parse(llvm::StringRef) (IncrementalParser.cpp:362)
==987150==    by 0x100E104: clang::Interpreter::Parse(llvm::StringRef) (Interpreter.cpp:360)
==987150==    by 0x100E243: clang::Interpreter::create(std::unique_ptr<clang::CompilerInstance, std::default_delete<clang::CompilerInstance> >) (Interpreter.cpp:279)
==987150==    by 0xF2131A: compat::createClangInterpreter(std::vector<char const*, std::allocator<char const*> >&) (Compatibility.h:123)
==987150==    by 0xF22AB9: Cpp::Interpreter::Interpreter(int, char const* const*, char const*, std::vector<std::shared_ptr<clang::ModuleFileExtension>, std::allocator<std::shared_ptr<clang::ModuleFileExtension> > > const&, void*, bool) (CppInterOpInterpreter.h:146)
==987150==    by 0xF1827A: CreateInterpreter (CppInterOp.cpp:2494)
==987150==    by 0xECFA0E: TestUtils::GetAllTopLevelDecls(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<clang::Decl*, std::allocator<clang::Decl*> >&, bool) (Utils.cpp:23)
==987150==    by 0xE9CB85: ScopeReflectionTest_IsComplete_Test::TestBody() (ScopeReflectionTest.cpp:71)
==987150==    by 0xF0ED0C: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (in /home/vvassilev/workspace/builds/scratch/cppyy/InterOp/build-with-clang-repl-release/unittests/CppInterOp/CppInterOpTests)
==987150==
```

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

(cherry picked from commit 92246a9be0ba47788ada9621bef58ce7819be526)

[Driver] Report warnings for unclaimed TargetSpecific options for assembler input

This patch amends D151590 to not error for unlaimed TargetSpecific
options for `-x assembler` input files. This input type causes Driver to
construct tools::ClangAs (-fintegrated-as) or other assemblers (e.g.
tools::gnutools::Assembler) Their ConstructJobs methods, unlike
Clang::ConstructJobs, claim very few options. If an option is unclaimed,
it either leads to a -Wunused-command-line-argument warning or an error
(if `TargetSpecific` is set):
```
% clang '-###' --target=aarch64 -mbranch-protection=bti -c a.s
clang: error: unsupported option '-mbranch-protection=' for target 'aarch64'
```

It seems that downgrading the diagnostic to warning is most useful as
many users use CFLAGS even for `.s` files:
```
clang --target=aarch64 -mbranch-protection=bti -S a.c
clang --target=aarch64 -mbranch-protection=bti -c a.s
```

I decide not to suppress the warning so that
-Wunused-command-line-argument lovers still get a warning, and help
projects use proper ASFLAGS/CFLAGS/etc.

Note: `-mbranch-protection=bti a.S` currently has no warning as `-x assembler-with-cpp`
instructs clangDriver to select tools::Clang and claim most options.

Revert D159010 to demonstrate that we emit a warning for -mfpmath= for
`-x assembler` input.

Modify my AIX cleanup cd18efb61d759405956dbd30e4b5f2720d8e1783 to
add an err_drv_unsupported_opt_for_target.

Reviewed By: thesamesam

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

(cherry picked from commit e9d454d1c195958645fb0948f8b97262e7f8b33a)

[AArch64] Fix arm neon vstx lane memVT size

StN lane memory size set too big lead to alias analysis goes wrong.

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

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

(cherry picked from commit db8f6c009e5a17d304be7404e50eb20b2dd0c75b)

[llvm-windres] Implement the windres flag --use-temp-file

Whether a temp file or a pipe is used for preprocessing is an
internal detail, this flag has a notable effect on the preprocessing
in GNU windres. Without this flag, GNU windres passes command
arguments as-is to popen(), which means they get evaluated by a
shell without being re-escaped for this case. To mimic this,
llvm-windres has manually tried to unescape arguments.

When GNU windres is given the --use-temp-file flag, it uses a
different API for invoking the preprocessor, and this API takes care
of preserving special characters in the command line arguments.
For users of GNU windres, this means that by using --use-temp-file,
they don't need to do the (quite terrible) double escaping of
quotes/spaces etc.

The xz project uses the --use-temp-file flag when invoking
GNU windres, see
https://github.com/tukaani-project/xz/commit/6b117d3b1fe91eb26d533ab16a2e552f84148d47.
However as llvm-windres didn't implement this flag and just
assumed the GNU windres popen() behaviour, they had to use a
different codepath for llvm-windres.

That separate codepath for llvm-windres broke later when llvm-windres
got slightly more accurate unescaping of lone quotes in
0f4c6b120f21d582ab7c5c4f2b2a475086c34938 /
https://reviews.llvm.org/D146848 (fixing a discrepancy to GNU
windres as found in https://github.com/llvm/llvm-project/issues/57334),
and this was reported in
https://github.com/mstorsjo/llvm-mingw/issues/363.

Not touching the implementation of the --preprocessor option
with respect to the --use-temp-file flag; that option is doubly
tricky as GNU windres changed its behaviour in a backwards incompatible
way recently (and llvm-windres currently matches the old behaviour).
(See
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594 and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f;hp=3abbafc2aacc6706fea3e3e326e2f08d107c3672
for the behaviour change.)

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

(cherry picked from commit 2bcc0fdc58a220cb9921b47ec8a32c85f2511a47)

[Tooling/Inclusion] Add std::range symbols in the mapping.

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

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

(cherry picked from commit 171868dc2cd60c6e3eaeb3861b18ba0e22461291)

[sanitizer][test] -std=c2x instead of -std=c23

Adjust tests from dd230efe703f34678ce52280e50238abf908aaa1 to use
-std=c2x instead, as Clang in release/17.x doesn't support -std=c23.

[Driver] Adjust -fsanitize=function & -mexecute-only interop after D158614

clangDriver depends on clangBasic, so clangBasic should not depend on
clangDriver, even just its header. Also remove clangBasic's dependency
on LLVMOption.

The issue can be seen through the bazel commit
d26dd681f9726ed7d43d7c0bdd8ee3cb2db69a2b which is reverted now.

Add hasFlagNoClaim and use it as we don't want to suppress
-Wunused-command-line-argument for -mexecute-only just because
-fsanitize= is specified.

[UBSan] Disable the function and kcfi sanitizers on an execute-only target.

An execute-only target disallows data access to code sections.
-fsanitize=function and -fsanitize=kcfi instrument indirect function
calls to load a type hash before the function label. This results in a
non-execute access to the code section and a runtime error.

To solve the issue, -fsanitize=function should not be included in any
check group (e.g. undefined) on an execute-only target. If a user passes
-fsanitize=undefined, there is no error and no warning. However, if the
user explicitly passes -fsanitize=function or -fsanitize=kcfi on an
execute-only target, an error will be emitted.

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

Reviewed By: MaskRay, probinson, simon_tatham

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

[X86][BF16] Lower FP_ROUND for vector types under AVX512BF16

Reviewed By: RKSimon

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

(cherry picked from commit b667e9c23d6d2f1c7371eb4a03b30de4a6f8b7b6)

[X86][BF16] Add test coverage for AVX-NE-CONVERT

Split from D158952.

(cherry picked from commit 30ec9473c6685d64d5caa17e2a6e8f4ccf275159)

[clangd] Respect IWYU keep pragma for standard headers.

see the issue https://github.com/llvm/llvm-project/issues/64191

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

(cherry picked from commit dcb28244faa88cb566a852533790bcac75daaa0f)

[RISCV] Prevent tryToFoldBNEOnCmpXchgResult from deleting AND if it has others users.

This disables the transform if the branch does not have the kill
flag set for the AND we want to delete.

Ideally we'd be able to share the AND with the AND we create in
the expansion, but that's a more complex transform. So this starts
with the simple approach to fix miscompile.

This should be backported to LLVM 17.

Fixes PR65025.ll

Reviewed By: asb

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

(cherry picked from commit ff6d33382faf3709fa270ae0abb8d165142df9ae)

[PowerPC][lld] Account for additional X-Forms -> D-Form/DS-Forms load/stores when relaxing initial-exec to local-exec

D153645 added additional X-Form load/stores that can be generated for TLS accesses.
However, these added instructions have not been accounted for in lld. As a result,
lld does not know how to handle them and cannot relax initial-exec to local-exec
when the initial-exec sequence contains these additional load/stores.

This patch aims to resolve https://github.com/llvm/llvm-project/issues/64424.

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

(cherry picked from commit 698b45aa902de4d30c798e8d6bd080c8e31bade8)

[AArch64] Add Defs=[NZCV] to MTE loop pseudos.

The `STGloop` family of pseudo-instructions all expand to a loop which
iterates over a region of memory setting all its MTE tags to a given
value. The loop writes to the flags in order to check termination. But
the unexpanded pseudo-instructions were not marked as modifying the
flags. Therefore it was possible for one to end up in a location where
the flags were live, and then the loop would corrupt them.

We spotted the effect of this in a libc++ test involving a lot of
complicated inlining, and haven't been able to construct a smaller
test case that demonstrates actual incorrect output code. So my test
here is just checking that `implicit-def $nzcv` shows up on the
pseudo-instructions as they're output from isel.

Reviewed By: DavidSpickett

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

(cherry picked from commit b09c575975b691e988a0f2e31d632c5f1038ab1d)

[libc++][format] Fixes out of bounds access.

Fixes https://llvm.org/PR65011

Reviewed By: #libc, ldionne

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

(cherry picked from commit 8930d04d5580c6a2cf04545c87387cd150cd7b46)

[lldb][windows] _wsopen_s does not accept bits other than `_S_IREAD | _S_IWRITE`

When sending file from a Linux host to a Windows remote, Linux host will try to copy the source file's permission bits, which will contain `_S_I?GRP` and `_S_I?OTH` bits. Those bits are rejected by `_wsopen_s`, causing it to return EINVAL.

This patch masks out the rejected bits.

GitHub issue: #64313

Reviewed By: jasonmolenda, DavidSpickett

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

(cherry picked from commit 9a4b3fdb82327e808213070fd157be3c557b8b9d)