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)

Previously, given a pointer-to-member type such as `Foo const Bar::*`,
clang-format would see the `const Bar::` part as a regular type name
with scope resolution operators, and with `QualifierAlignment: Right` it
would attempt to "fix" it, resulting in `Foo Bar::const *`, a syntax
error.

This patch no longer allows qualifiers to be moved across `::*`.

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

Reviewed By: owenpan, MyDeveloperDay, HazardyKnusperkeks

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

(cherry picked from commit 393e197c)

This is guarding a check for isTypeLegal so it should check is
LegalTypes.

Fixes PR61111.

Reviewed By: RKSimon

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

(cherry picked from commit c546f13f)

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

(cherry picked from commit c510c387)

Currently, there are bugs in Clang's intrinsics for type traits when
handling Objective-C++ `id` (e.g. in `add_pointer`). As a temporary
workaround, don't use these intrinsics in the Objective-C++ mode.

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

(cherry picked from commit 87cf39aa)

move all range iterators back in class, as out of class iterators
requires extra template parameters, which changes ADL

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

(cherry picked from commit 4c2ad195)

(cherry picked from commit 3b059cd2)

Since binary ID lookup makes CLI object arguments optional, it should be
possible to pass a list of source files without a binary. Unfortunately,
the current syntax will always interpret the first source file as a
binary. This change adds a `-sources` option to cause all later
positional arguments to be considered sources.

Reviewed By: gulfem

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

(cherry picked from commit 8007bcc1)

Fix assertion failure "PathDiagnosticSpotPiece's must have a valid location." in ReturnPtrRange checker on builtin functions

Builtin functions (such as `std::move`, `std::forward`, `std::as_const`)
have a body generated during the analysis not related to any source file
so their statements have no valid source locations.
`ReturnPtrRange` checker should not report issues for these builtin
functions because they only forward its parameter and do not create any
new pointers.

Fixes #55347

Patch by Arseniy Zaostrovnykh.

Reviewed By: NoQ

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

(cherry picked from commit 98d55095)

Up to C++20, hasDefaultConstructor and !hasNonTrivialDefaultConstructor together implied
hasTrivialDefaultConstructor. In C++20, a constructor might be ineligible and can set
hasDefaultConstructor without setting hasNonTrivialDefaultConstructor.

Fix this by querying hasTrivialDefaultConstructor instead of hasDefaultConstructor.

I'd like to backport this to Clang 16.
I only change isTrivialType and in a way that should only affect code that uses
constrained constructors, so I think this is relatively safe to backport.

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

Reviewed By: aaron.ballman

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

(cherry picked from commit ac67ec3a)

Was observing test failure. Relanding the test

(cherry picked from commit 0ec4cae1)

Previously, while calculating register usage due to invariants, it was assumed that invariant would always be part of widening
instructions. This resulted in calculating vector register types for vectors which cant be legalized(check the newly added test for more details).

An invariant might not always need a vector register. For e.g., invariant might just be used for iteration check.

This patch checks if the invariant is part of any widening instruction and considers register usage accordingly. Fixes issue 60493

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

(cherry picked from commit 4f9a5447)