Before this patch, initialized class members would have the LifetimeKind
LK_MemInitializer, which does not allow for binding a temporary to a
reference. Binding to a temporary however is allowed in parenthesized
aggregate initialization, even if it leads to a dangling reference. To
fix this, we create a new EntityKind, EK_ParenAggInitMember, which has
LifetimeKind LK_FullExpression.

This patch does *not* attempt to diagnose dangling references as a
result of using this feature.

This patch also refactors TryOrBuildParenListInitialization(...) to
accomodate creating different InitializedEntity objects.

Fixes #61567

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0960r3.html

Reviewed By: shafik

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

We have to unbox the boxchar variables in order to get to
the raw address that can be used for emboxing.

Reviewed By: jeanPerier

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

We have to keep it as a box, since taking box_addr of the optional
box may be invalid.

Reviewed By: jeanPerier

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

This patch reverts rGae739aefd7473517d3f08b5c8d08a66c7f469198 to address performance regressions reported by our [CI](https://github.com/dtcxzyw/llvm-ci/issues/137) after rG2ec1d0f427c7822540352c0c14d057e7bfe4f77b.

For example:
```
define ptr @const_gep_chain(ptr %p, i64 %a) {
    %p1 = getelementptr inbounds i8, ptr %p, i64 %a
    %p2 = getelementptr inbounds i8, ptr %p1, i64 1
    %p3 = getelementptr inbounds i8, ptr %p2, i64 2
    %p4 = getelementptr inbounds i8, ptr %p3, i64 3
    ret ptr %p4
}
```
The last three GEPs will not be folded since rG2ec1d0f427c7822540352c0c14d057e7bfe4f77b.

I think it is appropriate to remove this code because there is no compile-time regression reported in our benchmarks.

Reviewed By: nikic

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

Previously, when checking whether an in-class initializer exists when
performing parenthesized aggregate initialization, Clang checks that the
output of FieldDecl::getInClassInitializer() is non-null. This is
incorrect; if the field is part of a templated type, then
getInClassInitializer() will return nullptr if we haven't called
Sem::BuildCXXDefaultInitExpr(...) before, even if
FieldDecl::hasInClassInitializer() returns true. The end result is that
Clang incorrectly ignores the in class initializer and
value-initializes the field. The fix therefore is to instead call
FieldDecl::hasInClassInitializer(), which is what we do for braced init
lists [0].

Before this patch, Clang does correctly recognize the in-class field
initializer in certain cases. This is Sema::BuildCXXDefaultInitExpr(...)
populates the in class initializer of the corresponding FieldDecl
object. Therefore, if that method was previously called with the same
FieldDecl object, as can happen with a decltype(...) or a braced list
initialization, FieldDecl::getInClassInitializer() will return a
non-null expression, and the field becomes properly initialized.

Fixes 62266

[0]: https://github.com/llvm/llvm-project/blob/be5f35e24f4c15caf3c4aeccddc54c52560c28a0/clang/lib/Sema/SemaInit.cpp#L685

Reviewed By: shafik

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

The llvm-lib tool is not yet supported on z/OS.

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

Fix a bug where after
github.com/llvm/llvm-project/commit/68dd5142
refactor where we are not passing -mabi=vec-extabi to th backend.

This was briefly mentioned as a possibility in review discussion on D149369.

One slightly surprising bit to call out - these interfaces can get invoked with non-vector typed arguments. LoopVectorizer likes to call the costing interfaces with scalar types when unrolling, but not vectorizing. I found that surprising, not sure if others do.

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

The argument isn't used. VPlan-based dead recipe removal can be used
instead.

This is an attempt to troubleshoot our excessive usage of network in
Clang jobs on Buildkite.

Addresses the issue found in:
https://lab.llvm.org/buildbot/#/builders/92/builds/43478

`BytecodeWriter.h` is now included in `IR.h`, and the corresponding dependency should be moved to `header_deps`. This change fixes Google's internal build, which seems to have a stricter layering check than bazel's, but it's still the right thing to do.

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

Previous one didn't have strict weak ordering guarantees.

This revision updates the description of
`__sanitizer_annotate_contiguous_container` in includes. Possibilites of
the function were changed in D132522 and it supports:
  - unaligned beginning,
  - shared first/last granule with other objects.

Reviewed By: vitalybuka

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

Can't return a well-formed IR output while enabling version to be bumped
up during emission. Previously it would return min version but
potentially invalid IR which was confusing, instead make it return
error and abort immediately instead.

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

More tests need updates.

This reverts commit e876ba5d.

The linker flag `--version-script` may not be supported by all linkers, such as
macOS's linker. `libomp` is already capable of detecting whether the linker supports
it and append the linker flag accordingly. Since currently we assume `libomptarget`
only works on Linux, we don't do the check accordingly. This patch simply adds
the check before adding it to linker flag. This will be the first patch to make
OpenMP target offloading work on macOS. Note that CMake files in `plugins` are
not touched before they are going to be removed pretty soon anyway.

Reviewed By: jhuber6

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

The documentation is still rather terse because it needs to fit
onto a single line of clang --help output.
But at least it lists what the user can specify and documents the
non-obvious syntax.

Reviewed By: craig.topper

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

This test is not autogenerated.

This is folloup to b5595836, which missed the
Replacemen variable.

Before b5595836 the code assumed that alloca
ptrs are not tagged so tagging is implemented
as simple OR.

So this patch completes support of tagged SP
by passing untagged alloca pointers into
tagPointer.

Removed builder is the same as default builder, with the added benefit that python bindings will be generated for the default builder.

Reviewed By: ftynse

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

Otherwise we could produce `br <2x i1>` which are of course not legal.

```
Branch condition is not 'i1' type!
  br <2 x i1> %cond.fr1, label %entry.split.us, label %entry.split
  %cond.fr1 = freeze <2 x i1> %cond
LLVM ERROR: Broken module found, compilation aborted!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: /home/vchuravy/builds/llvm/bin/opt -passes=simple-loop-unswitch<nontrivial> -S
```

Fixes change introduced by https://reviews.llvm.org/D138526

Reviewed By: caojoshua

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

We had the function `verilogGroupDecl` for that.  However, the type
name would be incorrectly annotated in `isStartOfName` when it was not
a C++ keyword and followed another identifier.

Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay

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

There doesn't seem to be an issue on GitHub.  But previously, a space
would be inserted before the goto colon in the code below.

    switch (x) {
    case 0:
    goto_0: {
      action();
      break;
    }
    }

Previously, the colon following a goto label would be annotated as
`TT_InheritanceColon`.  A goto label followed by an opening brace
wasn't recognized.  It is easy to add another line to have
`spaceRequiredBefore` function recognize the case, but I believed it
is more proper to avoid doing the same thing in `UnwrappedLineParser`
and `TokenAnnotator`.  So now the label colons would be labeled in
`UnwrappedLineParser`, and `spaceRequiredBefore` would rely on that.

Previously we had the type `TT_GotoLabelColon` intended for both goto
labels and case labels.  But since handling of goto labels and case
labels differ somewhat, I split it into separate types for goto and
case labels.

This patch doesn't change the behavior for case labels.  I added the
lines annotating case labels because they would previously be
mistakenly annotated as `TT_InheritanceColon` just like goto labels.
And since I added the annotations, the checks for the `case` and
`default` keywords in `spaceRequiredBefore` are not necessary anymore.

Reviewed By: MyDeveloperDay

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

In its place, add a description of a bug that the change introducing
the bug in question inadvertently fixed.

See BZ 62361 for more details.

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

The comment is stale, as UserVF is handled before selectVectorizationFactor
is called. Clarify the comment by remove the mention of UserVF.

Suggested as independent improvement in D143938.

LVP operates on the loop it stores in TheLoop. Use it instead of the
argument, to be in line with other member functions.

Suggested as independent improvement in D143938.

Add missing documentation for selectEpilogueVectorizationFactor.

Suggested as independent improvement in D143938.

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