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

Previously, we would only pass the size parameter to the deallocation
function if the type is completely the same. But it is good enough to
make them unqualified the smae.

(cherry picked from commit d2b0b261)

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

(cherry picked from commit 3fe3f9c5)

(cherry picked from commit 78f17b2a)

Currently, libunwind just uses stxvd2x/lxvd2x to save/restore
VSX registers respectively. This puts the registers in
doubleword-reversed order into memory on little endian systems.
If both the save and restore are done the same way, this
isn't a problem. However if the unwinder is just restoring
a callee-saved register, it will restore it in the wrong
order (since function prologues save them in the correct order).
This patch adds the necessary swaps before the saves and after
the restores.

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

(cherry picked from commit 372820bf)

This fixes test failures on AArch64 with libgcc-13:

Clang :: Interpreter/global-dtor.cpp
Clang-Unit :: Interpreter/./ClangReplInterpreterTests/2/4

Reviewed By: lhames, v.g.vassilev

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

(cherry picked from commit 68c14f58)

When linking a shared library with Flang on MinGW, the functions from the
Flang runtime are exported from the shared library. When trying to link an
executable to that library using Flang, the linker errors out because the
functions from the runtime conflict with the functions exported from the
shared library.

Add the Flang runtime libraries to the list of libraries for which no
symbols are exported.

Reapplying the patch with the git author name corrected.

Reviewed By: mstorsjo

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

(cherry picked from commit 0ea8229b)

We were accidentally issuing "overloaded 'operator[]' with more than
one parameter is a C++2b extension" with -pedantic because it was an
ExtWarn diagnostic rather than a Warning. This corrects the diagnostic
category and adds some test coverage.

Fixes #61582

Add unwind_arm_ehabi.h and unwind_itanium.h to the unwind module and use angle includes to include them.

Reviewed By: ldionne, #libunwind

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

(cherry picked from commit 1187d8a6)

This patch fixes #60307 issue. The 8bb4451a introduces the possibility
to unite overlapped or adjacent address ranges to keep address ranges
in an unambiguous state. The AddressRangesMap is used to normalize
address ranges. The AddressRangesMap keeps address ranges and the value
of the relocated address. For intersected range, it creates a united
range that keeps the last inserted mapping value. The same for adjusted ranges.
While it is OK to use the last inserted mapping value for intersected ranges
(as there is no way how to resolve ambiguity) It is not OK to use the
last inserted value for adjacent address ranges. Currently, two following
address ranges are united into a single one:

{0,24,17e685c} {24,d8,55afe20} -> {0,d8,55afe20}

To avoid the problem, the AddressRangesMap should not unite adjacent address ranges
with different relocated addresses. Instead, it should leave adjacent address ranges
as separate ranges. So, the ranges should look like this:

{0,24,17e685c} {24,d8,55afe20}

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

(cherry picked from commit 1e72920c)

An #elif SANITIZER_SOLARIS clause was removed in D120048, but it also
removed the #else clause for the error fallback, causing the build to
fail on NetBSD.

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

(cherry picked from commit 8510cf9f)

Fixes PR#61384.

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

(cherry picked from commit 2ebbcfa0)

This patch adds a negative test for the issue discovered in D145930.

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

(cherry picked from commit d8c2a102)

Since FreeBSD 8 / 9 support was dropped from the Driver there is room to simplify
things with the ARM handling.

The exception model handling function can be removed.

EABI is now the default.

Reviewed By: dim

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

(cherry picked from commit 13a10e7e)

In the following example, we will end up hitting the `llvm_unreachable()`:
https://godbolt.org/z/5sccc95Ec
```lang=C++
enum class E {};
const E glob[] = {{}};
void initlistWithinInitlist() {
  clang_analyzer_dump(glob[0]); // crashes at loading from `glob[0]`
}
```

We should just return `std::nullopt` instead for these cases.
It's better than crashing.

Reviewed By: xazax.hun

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

(cherry picked from commit 558b46fd)

D138249 renamed a number of wasm intrinsics without implementing
auto-upgrade support.

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

(cherry picked from commit 6fc670e5)

Reviewed By: LuoYuanke
Differential Revision: https://reviews.llvm.org/D144163

(cherry picked from commit 96df79af)

GCC on AArch64 uses DW_CFA_GNU_NegateRAState for return address signing.

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

(cherry picked from commit 99211979)

This fixes unittest failures reported in D142279:
  flang-Unit :: Frontend/./FlangFrontendTests/5/7
  flang-Unit :: Frontend/./FlangFrontendTests/6/7

(cherry picked from commit e054e0da)

CheckDoConcurrentClauseRestriction and CheckTileClauseRestriction expect
that the construct has associated DoConstruct, while it is not set
when the do-loop has no loop control. The change is to skip the clauses
checks, when the do-loop does not have the loop control.

An alternative fix would be to associate the DoConstruct even when
the do-loop has no loop control and let Check*ClauseRestriction run their
checks, but I am not sure if associating invalid DoConstruct is a good idea.

This fixes failure in Semantics/OpenACC/acc-canonicalization-validity.f90
reported in D142279.

Reviewed By: clementval

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

(cherry picked from commit 02445263)

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

(cherry picked from commit 6772966d)

This is a follow up of D145550.

I think Reloc{Type,Symbol}{32,64} can keep unchanged as they are not
directly returning a field of the ELFRel[a] struct.

Reviewed By: DavidSpickett

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

(cherry picked from commit 27705f45)

According to `/usr/include/elf.h` and `lldb/source/Plugins/ObjectFile/ELF/ELFHeader.h`.
For ELF64 relocation, types of `offset` and `addend` should be `elf_addr` and `elf_sxword`.

Reviewed By: DavidSpickett

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

(cherry picked from commit 174a38f9)

Currently ApplyReloctions() deals with different archs' relocation types
together (in a single `switch() {..}`). I think it is incorrect because
different relocation types of different archs may have same enum values.

For example:
`R_LARCH_32` and `R_X86_64_64` are both `1`;
`R_LARCH_64` and `R_X86_64_PC32` are both `2`.

This patch handles each arch in seperate `switch()` to solve the enum
values conflict issue.

And a new test is added for LoongArch64.

Reviewed By: DavidSpickett

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

(cherry picked from commit c2c93873)

Commit 3671bdbc("[BPF] Fix a BTF type pruning bug") fixed a
pruning bug to allow generate more types. But the commit has a bug
which permits to generate more types than necessary. The following
is an example to illustrate the problem.

   struct t1 {
     int a;
   };
   struct t2 {
     struct t1 *p1;
     struct t1 *p2;
     int b;
   };
   int foo(struct t2 *arg) {
     return arg->b;
   }

The following is the part of BTF generation sequence:
  (1). 'struct t2 *arg' -> 'struct t1 *p1'
       In this step, the type 'struct t1' will be generated as
       a forward decl and the ptr type (to 'struct t1') will
       be stored in the internal type table.
  (2). now the second field 'struct t1 *p2' will be processed.
       Since the ptr type (to 'struct t1') already in the type
       table, the existing logic strips out ptr modifier and
       is able to generate BTF type for 'struct t1'.

In the above step (2), if CheckPointer is true (the type traversal
chain including a struct member), 'ptr' modifier should be checked
and the subsequent type generation should be skipped since
the same case has been processed in visitDerivedType().

The issue is exposed when I am trying to use llvm15 to compile
some internal bpf programs. The bpf skeleton put the whole
ELF section (after striping some sections like dwarf) as a string.
The large BTF section triggered the following error:

  bpf_object_with_struct_ops_test_prog_bpf/BpfObjectWithStructOpsTestProg.skel.h:222:23:
  error: string literal of length 140144 exceeds maximum length 65536 that C++ compilers
  are required to support [-Werror,-Woverlength-strings]
        return (const void *)"\
                             ^~
  1 error generated.

Although adding -Wno-overlength-strings could workaround the issue,
improving llvm BTF generation sounds better esp. for users using vmlinux.h.

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

(cherry picked from commit db3d2ade)

GNU assembler mandates armv8.5-a for memtag instructions. Maybe
we should remove this restriction in GNU assembler, but let's work
around it for current GNU Binutils releases.

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

(cherry picked from commit 5d276380)

We currently already canonicalize icmp eq (%x & Pow2), Pow2 to
icmp ne (%x & Pow2), 0. This patch generalizes the fold based on
known bits.

In particular, this allows us to handle comparisons against
!range !{i64 0, i64 2} loads, which addresses an optimization
regression in Rust caused by 8df376db.

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

(cherry picked from commit 61d2f3a7)

(cherry picked from commit 9043cb75)

This is a partial revert of D128830, restoring the previous
position of DeadArgElim in the fat LTO pipeline. The motivation
for this is a major code size regression observed in Rust and
illustrated in the PhaseOrdering test.

This is a conservative fix restoring the previous pipeline order.
The real problem is that the LTO pipeline is conceptually broken:
It doesn't have a CGSCC function simplification pipeline. The
inliner is just being run by itself. This wouldn't be a problem
if fat LTO used a standard design where ArgPromotion and DAE are
only run after functions have already been simplified by the
CGSCC inliner pipeline.

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

(cherry picked from commit fb568344)

(cherry picked from commit 8df140c8)

We thought we had implemented these papers appropriately but have since
discovered significant issues. See discussion of the issues at:
https://github.com/llvm/llvm-project/issues/61145

The work already done on these papers is remaining in tree for the
moment while people investigate whether the issues can be fixed
forward in main. The status page is being updated so the status is
clear to users of the upcoming Clang 16 release.

This was preventing lit from being uploaded to pypi.

Reviewed By: mgorny

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

(cherry picked from commit e6d670dc)

Setting __FLT_EVAL_METHOD__ to -1 with fast-math will set
__GLIBC_FLT_EVAL_METHOD to 2 and long double ends up being used for
float_t and double_t. This creates some ABI breakage with various C libraries.
See details here: https://github.com/llvm/llvm-project/issues/60781

This reverts commit bbf0d193.

(cherry picked from commit 2f126426)

D145605 reverted two patches to fix a regression, this patch removes
them from the 16.x release notes.

This patch fixes the wrong use of `fopen`.

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

Reviewed By: jdoerfert

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

(cherry picked from commit 22cd105a)

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

(cherry picked from commit 48027f03)

GH58452 is a regression in the 16.0 release branch caused by both:
b8a1b698 and
3a0309c5

This patch reverts both of those to make the 'valid' code stop
diagnosing
at the expense of crashes on invalid + unclear diagnostics.

This patch also adds the tests from GH58452 to prevent any
re-application from breaking this again.

Revert "[clang] Improve diagnostics for expansion length mismatch"
This reverts commit 3a0309c5.
Revert "[clang] fix missing initialization of original number of expansions"
This reverts commit b8a1b698.

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

(cherry picked from commit acecf68c)

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

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

(cherry picked from commit 341dd607)

Without the definition, build fails on AArch64 with

> error: 'AT_HWCAP2' undeclared (first use in this function);
> did you mean 'AT_HWCAP'?

with old Glibc versions.

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

(cherry picked from commit 23fcca82)

If ignored, the subexpr is a UnaryOperator (&) which cannot be evaluated
(assertion failed).

  #define offsetof(type,memb) ((unsigned long)&((type*)0)->memb)

Patch By danix800!

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

(cherry picked from commit 53f75425)

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

(cherry picked from commit 8c74defc)