(cherry picked from commit 05b34938)

Fixes a null dereference in some diagnostic issuing code.

Closes https://github.com/llvm/llvm-project/issues/57370
Closes https://github.com/llvm/llvm-project/issues/58028

Reviewed By: shafik

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

(cherry picked from commit 9415aad6)

When checking the RHS of fdiv, we should set the SignBitOnly flag,
because a negative zero can become -Inf, which is ordered less
than zero.

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

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

If a C source file includes the libc++ stdatomic.h, compilation will
break because (a) the C++ standard check will fail (which is expected),
and (b) `_LIBCPP_COMPILER_CLANG_BASED` won't be defined because the
logic defining it in `__config` is guarded by a `__cplusplus` check, so
we'll end up with a blank header. Move the detection logic outside of
the `__cplusplus` check to make the second check pass even in a C context
when you're using Clang. Note that `_LIBCPP_STD_VER` is not defined when
in C mode, hence stdatomic.h needs to check if in C++ mode before using
that macro to avoid a warning.

In an ideal world, a C source file wouldn't be including the libc++
header directory in its search path, so we'd never have this issue.
Unfortunately, certain build environments make this hard to guarantee,
and in this case it's easy to tweak this header to make it work in a C
context, so I'm hoping this is acceptable.

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

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

(cherry picked from commit afec0f0e)

Improve the documentation for 'misc-const-correctness' to:

- include better examples
- improve the english
- fix links to other checks that were broken due to the directory-layout changes
- mention the limitation that the check does not run on `C` code.

Addresses #56749, #56958

Reviewed By: njames93

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

(cherry picked from commit b5b75034)

'misc-const-correctness' previously considered arrays as 'Values' independent of the type of the elements.
This is inconsistent with the configuration of the check to disable treating pointers as values.
This patch rectifies this inconsistency.

Fixes #56749

Reviewed By: njames93

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

(cherry picked from commit e66345d5)

(cherry picked from commit c9334538)

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

(cherry picked from commit 898c4219)

For RVC, GNU assembler and LLVM integrated assembler add c.nop followed by a
sequence of 4-byte nops. Even if remove % 4 == 0, we have to split one 4-byte
nop and therefore need to write the code sequence, otherwise we create an
incorrect c.unimp.

(cherry picked from commit 78084d9e)

The unittests are already included in check-polly, so check-all was
running them twice.  Running them twice causes a race on the output
files, which led to intermittent failures on the reverse-iteration
buildbot.

(cherry picked from commit 2c29268b)

This avoids deprecation warning:
```
warning: definition of implicit copy assignment operator for 'AddrInfo'
is deprecated because it has a user-declared copy constructor
[-Wdeprecated-copy]
```

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

(cherry picked from commit 252cea03)

This solves https://github.com/llvm/llvm-project/issues/57664

Reviewed By: sameerds

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

(cherry picked from commit c941d925)

In LLVM 15, we added the deprecation markup for unary_function and
binary_function for >= C++11, and we also removed it for >= C++17.
While this is in accordance with the Standard, it's also a bit quick
for our users, since there was no release in which the classes were
marked as deprecated before their removal.

We noticed widespread breakage due to this, and after months of trying
to fix downstream failures, I am coming to the conclusion that users
will be better served if we give them one release where unary_function
is deprecated but still provided even in >= C++17.

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

(cherry picked from commit 59351fe3)

Epilogue vectorization uses isScalarAfterVectorization to check if
widened versions for inductions need to be generated and bails out in
those cases.

At the moment, there are scenarios where isScalarAfterVectorization
returns true but VPWidenPointerInduction::onlyScalarsGenerated would
return false, causing widening.

This can lead to widened phis with incorrect start values being created
in the epilogue vector body.

This patch addresses the issue by storing the cost-model decision in
VPWidenPointerInductionRecipe and restoring the behavior before 151c1443.
This effectively reverts 151c1443, but the long-term fix is to properly
support widened inductions during epilogue vectorization

Fixes #57712.

The test requires the AArch64 backend, so move it to the right subdir.

Includes a test for the miscompile in #57712.

In https://llvm.org/D56913, we added an emulation for the __atomic_always_lock_free
compiler builtin when compiling in Freestanding mode. However, the emulation
did (and could not) give exactly the same answer as the compiler builtin,
which led to a potential ABI break for e.g. enum classes.

After speaking to the original author of D56913, we agree that the correct
behavior is to instead always use the compiler builtin, since that provides
a more accurate answer, and __atomic_always_lock_free is a purely front-end
builtin which doesn't require any runtime support. Furthermore, it is
available regardless of the Standard mode (see https://godbolt.org/z/cazf3ssYY).

However, this patch does constitute an ABI break. As shown by https://godbolt.org/z/1eoex6zdK:
- In LLVM <= 11.0.1, an atomic<enum class with 1 byte> would not contain a lock byte.
- In LLVM >= 12.0.0, an atomic<enum class with 1 byte> would contain a lock byte.

This patch breaks the ABI again to bring it back to 1 byte, which seems
like the correct thing to do.

Fixes #57440

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

(cherry picked from commit f1a601fe)

If libcxxabi is not included CMake will error out:

Cannot find target libcxxabi-SHARED

I ran into this doing the 15.0.0 release

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

Callee save registers must be preserved, so -fzero-call-used-regs
should not be zeroing them. The previous implementation only did
not zero callee save registers that were saved&restored inside the
function, but we need preserve all of them.

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

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

(cherry picked from commit b4309800)

(cherry picked from commit 3eca0b39)

This handles the new CLDXC options that was introduced in
https://reviews.llvm.org/D128462 inside clang-tooling to make sure cl driver
mode is not broken.

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

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

(cherry picked from commit 23ace26e)

These patches exposed a lot of problems in the AMD toolchain. Rather
than keep it broken we should revert it to its old semi-functional
state. This will prevent us from using device destructors but should
remove some new bugs. In the future this interface should be changed
once these problems are addressed more correctly.

This reverts commit ed0f2181.

This reverts commit 2b7203a3.

Fixes #57536

Reviewed By: jdoerfert

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

When .gnu.version_r is empty (allowed by readelf but warned by objdump),
llvm-objdump -p may decode the next section as .gnu.version_r and may crash due
to out-of-bounds C string reference. ELFFile<ELFT>::getVersionDependencies
handles 0-entry .gnu.version_r gracefully. Just use it.

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

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

(cherry picked from commit 25394c9d)

(cherry picked from commit 55a72dae)

As described in Issue #54196
<https://github.com/llvm/llvm-project/issues/54196>, the ideas of `clang`
and `compiler-rt` where runtime libs are located with
`-DLLVM_ENABLE_RUNTIMES` can differ.  This is the `compiler-rt` side of the
patch I've used to get them in sync for the `amd64-pc-solaris2.11` and
`sparc64-unknown-linux-gnu` release builds.

Tested on  `amd64-pc-solaris2.11` and `sparc64-unknown-linux-gnu`.

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

(cherry picked from commit cadc9cde)

The changes in Clang 15.0.0 which enabled these diagnostics as a
warning which defaulted to an error caused disruption for people
working on distributions such as Gentoo. There was an explicit request
to downgrade these to be warning-only in Clang 15.0.1 with the
expectation that Clang 16 will default the diagnostics to an error.

See
https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213
for more details on the discussion.

See https://reviews.llvm.org/D133800 for the public review of these
changes.

Folding them will cause the unwinder to compute the incorrect function
start address for the folded entries, which in turn will cause the
personality function to interpret the LSDA incorrectly and break
exception handling.

You can verify the end-to-end flow by creating a simple C++ file:
```
void h();
int main() { h(); }
```

and then linking this file against the liblsda.dylib produced by the
test case added here. Before this change, running the resulting program
would result in a program termination with an uncaught exception.
Afterwards, it works correctly.

Reviewed By: #lld-macho, thevinster

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

(cherry picked from commit 56bd3185)

This section is marked S_ATTR_LIVE_SUPPORT in input files, which meant
that on arm64, we were unnecessarily preserving FDEs if we e.g. had
multiple weak definitions for a function. Worse, we would actually
produce an invalid `__eh_frame` section in that case, because the CIE
associated with the unnecessary FDE would still get dead-stripped and
we'd end up with a dangling FDE. We set up associations from functions
to their FDEs, so dead-stripping will just work naturally, and we can
clear S_ATTR_LIVE_SUPPORT from our input `__eh_frame` sections to fix
dead-stripping.

Reviewed By: #lld-macho, int3

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

(cherry picked from commit a745e479)

During the discussion on the SG-10 mailinglist regarding the format
feature-test macros voted in during the last plenary it turns out libc++
can't mark the format feature-test macro as implemented.

According to
  https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#__cpp_lib_format
the not yet implemented paper
  P1361R2 Integration of chrono with text formatting
affects the feature test macro.

Note that P1361R2 doesn't mention the feature-test macro nor is there an
LWG-issue to address the issue. The reporter of the issue didn't recall
where this requirement exactly has been decided.

Reviewed By: ldionne, #libc

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

Bug: An assertion fails:

    Assertion failed: isa<To>(Val) && "cast<Ty>() argument of incompatible type!",
    file C:\Users\<user>\prog\llvm\llvm-git-lld-bug\llvm\include\llvm/Support/Casting.h, line 578

Bug is triggered, if

    - a map file is requested with /MAP, and
    - Architecture is ARMv7, Thumb, and
    - a relative jump (branch instruction) is greater than 16 MiB (2^24)

The reason for the Bug is:

    - a Thunk is created for the jump
    - a Symbol for the Thunk is created
        - of type `DefinedSynthetic`
        - in file `Writer.cpp`
        - in function `getThunk`
    - the Symbol has no name
    - when creating the map file, the name of the Symbol is queried
    - the function `Symbol::computeName` of the base class `Symbol`
      casts the `this` pointer to type `DefinedCOFF` (a derived type),
      but the acutal type is `DefinedSynthetic`
    - The in the llvm::cast an assertion fails

Changes:

- Modify regression test to trigger this bug
- Give the symbol pointing to the thunk a name, to fix the bug
- Add assertion, that only DefinedCOFF symbols are allowed to have an
  empty name, when the constructor of the base class Symbol is executed

Reviewed By: rnk

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

(cherry picked from commit 4e5a59a3)

CRunnerUtils builds as C++11. 9c1d133c broke
the build on OpenBSD. aligned_alloc() was only introduced in C++17.

DwarfEhPrepare inserts calls to _Unwind_Resume into landing pads.
If _Unwind_Resume happens to be defined in the same module and
debug info is used, then this leads to a verifier error:

  inlinable function call in a function with debug info must
    have a !dbg location
  call void @_Unwind_Resume(ptr %exn.obj) #0

Fix this by assigning a dummy location to the call. (As this
happens in the backend, inlining is not actually relevant here.)

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

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

(cherry picked from commit 5134bd43)

Clang crashes when encountering an `if consteval` statement.
This is the minimum fix not to crash.
The fix is consistent with the current behavior of if constexpr,
which does generate coverage data for the discarded branches.
This is of course not correct and a better solution is
needed for both if constexpr and if consteval.
See https://github.com/llvm/llvm-project/issues/54419.

Fixes #57377

Reviewed By: aaron.ballman

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

As discussed in this [comment](https://github.com/llvm/llvm-project/issues/56183#issuecomment-1224331699),
we end up building the lambda twice: once while parsing the function calls and then again while handling the immediate invocation.

This happens specially during removing nested immediate invocation.
Eg: When we have another consteval function as the parameter along with this lambda expression. Eg: `foo(bar([]{}))`, `foo(bar(), []{})`

While removing such nested immediate invocations, we should not rebuild this lambda. (IIUC, rebuilding a lambda would always generate a new type which will never match the original type from parsing)

Fixes: https://github.com/llvm/llvm-project/issues/56183
Fixes: https://github.com/llvm/llvm-project/issues/51695
Fixes: https://github.com/llvm/llvm-project/issues/50455
Fixes: https://github.com/llvm/llvm-project/issues/54872
Fixes: https://github.com/llvm/llvm-project/issues/54587

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

(cherry picked from commit e7eec382)