Fixes #58392

Reviewed By: ldionne, #libc

Spies: alexfh, hans, joanahalili, dblaikie, libcxx-commits

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

got remove here:
https://github.com/llvm/llvm-project/commit/67b0b02ec9f2bbc57bf8f0550828d97f460ac11f#diff-e41832b8aa26da45585a57c5111531f2e1d07e91a67c4f8bf1cd6d566ae45a2bR42

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

(cherry picked from commit fc874529)

These new debug values get inserted after the place where the spill
happens, which means they won't be reached by the reverse traversal of
basic block instructions. This would crash or fail assertions if they
contained any virtual registers to be replaced. We can manually handle
the new debug values right away to resolve this.

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

Reviewed By: StephenTozer

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

(cherry picked from commit 87f57f45)

Define a `__heap_end` symbol that marks the end of the memory region
that starts at `__heap_base`. This will allow malloc implementations to
know how much memory they can use at `__heap_base` even if someone has
done a `memory.grow` before they can initialize their state.

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

If the src type is not extend type, after convert the truncate to and we need to truncate the and also to make sure the all user is legal.

The old fix D137613 doesn't work when the truncate convert to and have the other users. So this time I try to add the truncate after and to avoid all these potential issues.

Fix: #59554

Reviewed By: samparker

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

(cherry picked from commit a0b470c9)

The iterator over super and sub registers doesn't include both 8-bit
registers in its list. So if both registers are used and only one of
them is live on return, then we need to make sure that the other 8-bit
register is also marked as live and not zeroed out.

Reviewed By: nickdesaulniers

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

(cherry picked from commit 14d4cddc)

Fix ARMABIInfo::EmitVAAarg crash with empty record type variadic arg

Open issue: https://github.com/llvm/llvm-project/issues/58794

Reviewed By: rjmccall

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

(cherry picked from commit 80f44464)

Follows up on commit cd5d5ce2 by
additionally ignoring relative paths ending in "lto-wrapper.exe" as
can be the case for GCC cross-compiled for Windows.

Reviewed By: tejohnson

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

(cherry picked from commit cf4f35b7)

This patch is spamming compiles with unhelpful and confusing messages.
E.g. the Linux kernel uses "grep -q" in several places. It's meant to
quit with a return code of zero when the first match is found. This can
cause a SIGPIPE signal, but that's expected, and there's no way to turn
this error message off to avoid spurious error messages.

UNIX03 apparently doesn't require printing an error message on SIGPIPE,
but specifically when there's an error on the stdout stream in a normal
program flow, e.g. when SIGPIPE trap is disabled.

A separate patch is planned to address the specific case we care most
about (involving llvm-nm).

This reverts commit b89bcefa.

Link: https://github.com/llvm/llvm-project/issues/59037
Link: https://github.com/ClangBuiltLinux/linux/issues/1651

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

(cherry picked from commit 4787efa3)

Currently, codegen doesn't support cases where the type size doesn't
match the alloc size. Skip them for now.

Fixes #58722.

(cherry picked from commit 758699c3)

C++11 made the use of these macro obsolete, see https://sourceware.org/bugzilla/show_bug.cgi?id=15366

As a side effect this prevents https://github.com/swig/swig/issues/2193.

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

(cherry picked from commit 81fc5f79)

Fix the failure caused by change in SwigValueWraper for C++11 and later
for improved move semantics in SWIG commit.

https://github.com/swig/swig/commit/d1055f4b3d51cb8060893f8036846ac743302dab
(cherry picked from commit f0a25fe0)

Varargs and inalloca have a weird interaction where varargs are actually
passed via the inalloca alloca. Removing inalloca breaks the varargs
because they're still not passed as separate arguments.

Fixes #58718

Reviewed By: rnk

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

(cherry picked from commit 8c49b01a)

The Clang Static Analyzer will crash on this code:
```lang=C++
struct Box {
  int value;
};
template <Box V> int get() {
  return V.value;
}
template int get<Box{-1}>();
```
https://godbolt.org/z/5Yb1sMMMb

The problem is that we don't account for encountering `TemplateParamObjectDecl`s
within the `DeclRefExpr` handler in the `ExprEngine`.

IMO we should create a new memregion for representing such template
param objects, to model their language semantics.
Such as:
 - it should have global static storage
 - for two identical values, their addresses should be identical as well
http://eel.is/c%2B%2Bdraft/temp.param#8

I was thinking of introducing a `TemplateParamObjectRegion` under `DeclRegion`
for this purpose. It could have `TemplateParamObjectDecl` as a field.

The `TemplateParamObjectDecl::getValue()` returns `APValue`, which might
represent multiple levels of structures, unions and other goodies -
making the transformation from `APValue` to `SVal` a bit complicated.

That being said, for now, I think having `Unknowns` for such cases is
definitely an improvement to crashing, hence I'm proposing this patch.

Reviewed By: xazax.hun

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

(cherry picked from commit b062ee7d)

This is necessary at least on PPC32.

Depends on D136280.

Bug: https://bugs.gentoo.org/874024


Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>

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

(cherry picked from commit 20132d8e)

Also simplify code for liblldCommon using the new LLVM_ATOMIC_LIB variable.

Depends on D136280.

Bug: https://bugs.gentoo.org/832675


Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>

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

(cherry picked from commit f0b451c7)

* Set LLVM_ATOMIC_LIB to keep track of when we need to link against libatomic.
* Add detection of mold linker which is required for this.
* Use --as-needed when linking against libatomic as a bonus. On some platforms,
  libatomic may be required only sometimes.

Bug: https://bugs.gentoo.org/832675


Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>

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

(cherry picked from commit fa981b54)

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

Reviewed By: samtebbs

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

(cherry picked from commit 597f4440)

Add the missing include to fix an error when `cmake_push_check_state()`
is called and incidentally the CMakePushCheckState module is not loaded
by any other check running prior to `FindLibEdit.cmake`:

    CMake Error at /var/no-tmpfs/portage/dev-util/lldb-15.0.4/work/cmake/Modules/FindLibEdit.cmake:24 (cmake_push_check_state):
      Unknown CMake command "cmake_push_check_state".
    Call Stack (most recent call first):
      cmake/modules/LLDBConfig.cmake:52 (find_package)
      cmake/modules/LLDBConfig.cmake:59 (add_optional_dependency)
      CMakeLists.txt:28 (include)

Gentoo Bug: https://bugs.gentoo.org/880065

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

(cherry picked from commit 3676a86a)

gnu17 and earlier modes automatically expose several POSIX C APIs, and
this was accidentally disabled for gnu2x in
7d644e12.

This restores the behavior for gnu2x mode (without changing the
behavior in C standards modes instead of GNU modes).

Fixes #56607

Fixes warnings (or errors, if someone injects -Werror in their build system,
which happens in fact with some folks vendoring LLVM too) with Clang 16:
```
+/var/tmp/portage.notmp/portage/sys-devel/llvm-15.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
-/var/tmp/portage.notmp/portage/sys-devel/llvm-14.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: error: a function declaration without a prototype is
deprecated in all versions of C [-Werror,-Wstrict-prototypes]
 int main() {return 0;}
         ^
          void
```

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

(cherry picked from commit 32a2af44)

Surprisingly these were getting legalized to something
zero initialized.

This fixes an infinite loop when combining some vector types.
Also fixes zero initializing some undef values.

SimplifyDemandedVectorElts / SimplifyDemandedBits are not checking
for the legality of the output undefs they are replacing unused
operations with. This resulted in turning vectors into undefs
that were later re-legalized back into zero vectors.

(cherry picked from commit 7a846240)

For the following program,
  $ cat t.c
  struct t {
   int (__attribute__((btf_type_tag("rcu"))) *f)();
   int a;
  };
  int foo(struct t *arg) {
    return arg->a;
  }
Compiling with 'clang -g -O2 -S t.c' will cause a failure like below:
  clang: /home/yhs/work/llvm-project/clang/lib/Sema/SemaType.cpp:6391: void {anonymous}::DeclaratorLocFiller::VisitParenTypeLoc(clang::ParenTypeLoc):
         Assertion `Chunk.Kind == DeclaratorChunk::Paren' failed.
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  ......
  #5 0x00007f89e4280ea5 abort (/lib64/libc.so.6+0x21ea5)
  #6 0x00007f89e4280d79 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21d79)
  #7 0x00007f89e42a6456 (/lib64/libc.so.6+0x47456)
  #8 0x00000000045c2596 GetTypeSourceInfoForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
  #9 0x00000000045ccfa5 GetFullTypeForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
  ......

The reason of the failure is due to the mismatch of TypeLoc and D.getTypeObject().Kind. For example,
the TypeLoc is
  BTFTagAttributedType 0x88614e0 'int  btf_type_tag(rcu)()' sugar
  |-ParenType 0x8861480 'int ()' sugar
  | `-FunctionNoProtoType 0x8861450 'int ()' cdecl
  |   `-BuiltinType 0x87fd500 'int'
while corresponding D.getTypeObject().Kind points to DeclaratorChunk::Paren, and
this will cause later assertion.

To fix the issue, similar to AttributedTypeLoc, let us skip BTFTagAttributedTypeLoc in
GetTypeSourceInfoForDeclarator().

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

Implement CanLowerReturn and associated CallingConv changes for SPARC/SPARC64.

In particular, for SPARC64 there's new `RetCC_Sparc64_*` functions that handles the return case of the calling convention.
It uses the same analysis as `CC_Sparc64_*` family of funtions, but fails if the return value doesn't fit into the return registers.

This makes calls to functions with big return values converted to an sret function as expected, instead of crashing LLVM.

Reviewed By: MaskRay

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

(cherry picked from commit d3fcbee1)

This appeared in https://reviews.llvm.org/D126903#3884061

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

(cherry picked from commit 1a726cfa)

We already do this for personality pointers referenced from compact
unwind entries; this patch extends that behavior to personalities
referenced via EH frames as well.

This reduces the number of distinct personalities we need in the final
binary, and helps us avoid hitting the "too many personalities" error.

I renamed `UnwindInfoSection::prepareRelocations()` to simply `prepare`
since we now do some non-reloc-specific stuff within.

Fixes #58277.

Reviewed By: #lld-macho, oontvoo

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

(cherry picked from commit 7b45dfc6)

This breaks when the newest available devtoolset directory is not a
complete toolset: https://github.com/llvm/llvm-project/issues/57843

Remove this again in favor or just adding the two new directories for
devtoolset/gcc-toolset 12.

This reverts commit 35aaf548.
This reverts commit 9f977202.

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

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

Fixes github.com/clangd/clangd/issues/1216

If the Snippet string is empty, Snippet.front() would trigger a crash.
Move the Snippet->empty() check up a few lines to avoid this. Should not
break any existing behavior.

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

(cherry picked from commit 60528c69)

When looking at template arguments in LLDB, we usually care about what
the user passed in his code, not whether some of those arguments where
passed as a variadic parameter pack.

This patch extends all the C++ APIs to look at template parameters to
take an additional 'expand_pack' boolean that automatically unwraps the
potential argument packs. The equivalent SBAPI calls have been changed
to pass true for this parameter.

A byproduct of the patch is to also fix the support for template type
that have only a parameter pack as argument (like the OnlyPack type in
the test). Those were not recognized as template instanciations before.

The added test verifies that the SBAPI is able to iterate over the
arguments of a variadic template.

The original patch was written by Fred Riss almost 4 years ago.

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

(cherry picked from commit b706f561)

Unfortunately these notes were compiled until now, but these are the release notes for SystemZ.

(Did not find anything under clang)

@tstellar Should I push this patch onto release/15.x once approved, or will you apply it?

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

```
template <typename T> struct A {
  A() {}
  int value = 0;
};

template <typename Value> struct B {
  static A<int> a;
};

template <typename Value> A<int> B<Value>::a;

inline int foo() {
  return B<int>::a.value;
}
```

```
clang++ -c -fno-pic a.cc -o weak.o
g++ -c -fno-pic a.cc -o unique.o  # --enable-gnu-unique-object

# Duplicate symbol error. In postParse, we do not check `sym.binding`
ld.lld -e 0 weak.o unique.o
```

Mixing GCC and Clang object files in this case is not ideal. .bss._ZGVN1BIiE1aE
has different COMDAT groups. It appears to work in practice because the guard
variable prevents harm due to double initialization.

For the linker, we just stick with the rule that a weak binding does not cause
"duplicate symbol" errors.

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

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

(cherry picked from commit 0051b6bb)

This was remangling the old function rather than the new one, and
could result in failures when we were performing both a struct
return upgrade and an opaque pointer upgrade.

(cherry picked from commit c8938809)

Fixes #58307

Reviewed By: nikic

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

(cherry picked from commit 86e57e66)

Fixes an SROA crash.

Fallout from opaque pointers since with typed pointers we'd bail out at the bitcast.

Reviewed By: nikic

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

(cherry picked from commit 6219ec07)

and fix it for 32-bit ports defining sem_init@GLIBC_2.0 (i386, mips32, powerpc32) for glibc>=2.36.

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

Reviewed By: mgorny

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

(cherry picked from commit 6f46ff37)

We were hitting an assert as the legalied type needn't be a vector.

Fixes #58364

(cherry picked from commit de6dfbbb)