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)

Summary:
Currently, OpenMP and direct compilation uses an NVPTX toolchain to
directly invoke the CUDA tools from Clang to do the assembling and
linking of NVPTX codes. This breaks under `-save-temps` because of a
workaround. The `nvlink` linker does not accept `.o` files, so we need
to be selective when we output these. The previous logic keyed off of
presense in the temp files and wasn't a great solution. Change this to
just query the input args for `-c` to see if we stop at the assembler.

Fixes #60767

When building compiler-rt builtins for x86_64 they library will by default
also be built for i386. We unconditionally add the Float16 compile flags
since the check for Float16 support will be done using x86_64 compiler
flags, but i386 does not actually support it. Fix this by moving the
COMPILER_RT_HAS_FLOAT16 and COMPILER_RT_HAS_FLOAT16 checks to a
per-target-architecture check inside the loop (using
`check_c_source_compiles` and `cmake_{push,pop}_check_state`).

Many of the checks in the builtin-config-ix file should probably also be
changed to per-target-arch checks, but so far only the Float16 one has
caused issues. This is an alternative to D136044 which added a special case
for i386 FreeBSD.

Fixes: https://github.com/llvm/llvm-project/issues/57224
Differential Revision: https://reviews.llvm.org/D145237

(cherry picked from commit 489bda6a)

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

Change https://reviews.llvm.org/D140059 exposed the following crash in
Z3Solver, where bit widths were not checked consistently with that
change. This change makes the check consistent, and fixes the crash.

```
clang: <root>/llvm/include/llvm/ADT/APSInt.h:99:
  int64_t llvm::APSInt::getExtValue() const: Assertion
  `isRepresentableByInt64() && "Too many bits for int64_t"' failed.
...
Stack dump:
0. Program arguments: clang -cc1 -internal-isystem <root>/lib/clang/16/include
  -nostdsysteminc -analyze -analyzer-checker=core,unix.Malloc,debug.ExprInspection
  -analyzer-config crosscheck-with-z3=true -verify reproducer.c

 #0 0x00000000045b3476 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
  <root>/llvm/lib/Support/Unix/Signals.inc:567:22
 #1 0x00000000045b3862 PrintStackTraceSignalHandler(void*)
  <root>/llvm/lib/Support/Unix/Signals.inc:641:1
 #2 0x00000000045b14a5 llvm::sys::RunSignalHandlers()
  <root>/llvm/lib/Support/Signals.cpp:104:20
 #3 0x00000000045b2eb4 SignalHandler(int)
  <root>/llvm/lib/Support/Unix/Signals.inc:412:1
 ...
 #9 0x0000000004be2eb3 llvm::APSInt::getExtValue() const
  <root>/llvm/include/llvm/ADT/APSInt.h:99:5
  <root>/llvm/lib/Support/Z3Solver.cpp:740:53
  clang::ASTContext&, clang::ento::SymExpr const*, llvm::APSInt const&, llvm::APSInt const&, bool)
  <root>/clang/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConv.h:552:61
```

Reviewed By: steakhal

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

(cherry picked from commit f027dd55)

The m type in a range formatter may only be used when a pair or a tuple
with two elements is used. This was not correctly validated as reported
in llvm.org/PR60995.

Reviewed By: ldionne, #libc

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

(cherry picked from commit 347a65a1)

Fixes llvm.org/PR58714 reported by @jwakely and a similar issue
reported privately by @vitaut.

Reviewed By: ldionne, #libc

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

(cherry picked from commit 5eaba4a9)

Fixes #61160

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

(cherry picked from commit 33912468)

The l_brace of class/struct/union was incorrectly annotated as
TT_FunctionLBrace in the presence of attributes. This in turn
would cause the RemoveSemicolon option to remove the semicolon
at the end of the declaration, resulting in invalid code being
generated.

Fixes #61188.

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

(cherry picked from commit a02c3af9)

https://reviews.llvm.org/D130791 added an improvement that in case array
element has a trivial constructor, it is evaluated once and the result is
re-used for remaining elements. Make sure the constructor is evaluated
for single-elements arrays too.

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

Reviewed By: aaron.ballman

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

(cherry picked from commit af682f0d)

Allow a function with tail calls only to clobber its red zone.

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

Reviewed By: #bolt, yota9

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

(cherry picked from commit 1e1dfbb9)