Optional parameters with `defaultValue` set will be populated with that value if they aren't encountered during parsing. Moreover, parameters equal to their default values are elided when printing.

Depends on D118210

Reviewed By: rriddle

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

- Reader uses option values to override uint64_t values.

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

When compiling with Clang modules enabled, polly's use of using-directives
caused the global object `Target` in RegisterPasses.cpp to clash with
`llvm::Target`. By eliminating the using-directives, we're able to get
polly to play nicely with a modules build.

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

Calls to C_F_POINTER() without the optional SHAPE= third argument
were failing to be recognized as proper calls to the intrinsic,
but the failure was not generating any error message.  This led to
a crash in lowering, which rightfully expects a typed expression
to be associated with the call.

So (1) catch silent failures to convert CALL statements as internal
errors, as is done for expressions and assignment statements; and
(2) clean up C_F_POINTER intrinsic handling to cope with only two
arguments and to emit an error for a FPTR= argument with no type.

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

This change is needed when lowering alloca()-using code on targets
such as ROCDL that represent private scratch space as a separate
address space.

Reviewed By: ftynse

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

This is needed after b432eb5c to keep std::unexpected_handler
around (which libcxxabi uses from libcxx).

The `__builtin_pdepd` and `__builtin_pextd` are P10 builtins that are meant to
be used under 64-bit only. For instance, when the builtins are compiled under
32-bit mode:
```
$ cat t.c
unsigned long long foo(unsigned long long a, unsigned long long b) {
  return __builtin_pextd(a,b);
}

$ clang -c t.c -mcpu=pwr10 -m32
ExpandIntegerResult #0: t31: i64 = llvm.ppc.pextd TargetConstant:i32<6928>, t28, t29

fatal error: error in backend: Do not know how to expand the result of this operator!
```
This patch adds sema checking for these builtins to compile under 64-bit
mode only and on P10. The builtins will emit a diagnostic when they are compiled on
non-P10 compilations and on 32-bit mode.

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

EQUIVALENCE storage association of objects whose types are not
both default-kind numeric storage sequences, or not both default-kind
character storage sequences, are not standard conformant.
However, most Fortran compilers admit such usage, with warnings
in strict conformance mode.  This patch allos EQUIVALENCE of objects
that have sequence types that are either identical, both numeric
sequences (of default kind or not), or both character sequences.
Non-sequence types, and sequences types that are not homogeneously
numeric or character, remain errors.

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

Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/include/.

I've left `#include "include/x.h"` and `#include "../y.h"` alone
because I'm less sure that they're interchangeable, and they aren't
inconsistent with libcxx/include/ because libcxx/include/ never
does that kind of thing.

Also, use the `_LIBCPP_PUSH_MACROS/POP_MACROS` dance for `<__undef_macros>`,
even though it's technically unnecessary in a standalone .cpp file,
just so we have consistently one way to do it.

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

This reverts commits a30a7948 and 5d1c1a24, which broke the LLDB
data formatters tests because they build with modules in C++11 mode.

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

VE backend code expected all VP SDNode to have a mask parameter.  This
is not the case with vp.select|merge after D118981.

Following
https://discourse.llvm.org/t/psa-ods-generated-accessors-will-change-to-have-a-get-prefix-update-you-apis/4476

Mostly mechanical, avoiding function name conflicts.

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

`Shutdown.h` was transitively depending on two headers, but this isn't
allowed under a modules build, so they're now explicitly included.

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

Initialize m_pound_line_line to 0.

When a pointer assignment with bounds remapping has a function
reference as its right-hand side, don't check for array conformance.

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

https://maskray.me/blog/2022-01-16-archives-and-start-lib

For every definition in an extracted archive member, we intern the symbol twice,
once for the archive index entry, once for the .o symbol table after extraction.
This is inefficient.

Symbols in a --start-lib ObjFile/BitcodeFile are only interned once because the
result is cached in symbols[i].

Just handle an archive using the --start-lib code path. We can therefore remove
ArchiveFile and LazyArchive. For many projects, archive member extraction ratio
is high and it is a net performance win. Linking a Release build of clang is
1.01x as fast.

Note: --start-lib scans symbols in the same order that llvm-ar adds them to the
index, so in the common case the semantics should be identical. If the archive
symbol table was created in a different order, or is incomplete, this strategy
may have different semantics. Such cases are considered user error.

The `is neither ET_REL nor LLVM bitcode` error is changed to a warning.
Previously an archive may have such members without a diagnostic. Using a
warning prevents breakage.

* For some tests, the diagnostics get improved where we did not consider
  the archive member name: `b.a:` => `b.a(b.o):`.
* `no-obj.s`: the link is now allowed, matching GNU ld
* `archive-no-index.s`: the `is neither ET_REL nor LLVM bitcode` diagnostic is
  demoted to a warning.
* `incompatible.s`: even when an archive is unextracted, we may report an
  "incompatible with" error.

---

I recently decreased sizeof(SymbolUnion) by 8 and decreased memory usage quite a
bit, so retaining `symbols` for un-extracted archive members should not cause a
memory usage problem.

Reviewed By: peter.smith

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

8c54583b ported this only for libcxx, not libcxxabi.
As of 05337a75, it's needed for libcxxabi too.

Casting between scalable vectors and fixed-length vectors doesn't make
sense. If one of the operands is scalable, the other has to be scalable
to be able to guarantee they have the same shape at runtime.

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

Minor comment updates and use getVoidPtr helper instead of
builiding `i8*` type manually in codegen.

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

vp.select|merge both select lanes based on a condition mask.  Unlike
other VP intrinsics the lanes are defined where the condition mask is
false. Hence, the condition mask in vp.select|mask is not a mask in the
sense of VP intrinsics.  By doing not treating the condition mask
specially, vp.select becomes the canonical VP translation of the select
instruction.

Reviewed By: frasercrmck

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

Reviewed By: craig.topper

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

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

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

Reviewed By: HazardyKnusperkeks, owenpan

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

Simplify the logic when the exponent difference is at least MantissaLength + 2, while still maintaining correct rounding for all rounding modes.

Reviewed By: sivachandra

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

This avoids using an libc++ internal macro in our tests.

Reviewed By: #libc, philnik, ldionne

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

This is a more generic version of D119110 that uses MaskedValueIsZero
to do the matching and SimplifyDemandedBits to remove any unneeded
AND instructions.

Tests were taken from D119110.

Reviewed By: Chenbing.Zheng

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

Parsing errors aren't handled earlier in all cases. A simple
example is llc -mtriple=riscv64 -mattr=+zve32f. If F or Finx is
not also specified, this will hit a parse error.

Use a fatal_error so that the error is conveyed to the user.

Previously, Transformer would invoke the consumer once per file modified per
match, in addition to any errors encountered. The consumer is not aware of which
AtomicChanges come from any particular match. It is unclear which sets of edits
may be related or whether an error invalidates any previously emitted changes.

Modify the signature of the consumer to accept a set of changes. This keeps
related changes (i.e. all edits from a single match) together, and clarifies
that errors don't produce partial changes.

Reviewed By: ymandel

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

This should work now that we are using a matching libunwind.dylib when
we run the tests in back-deployment scenarios. The only restriction we
have now is to run on macOS x86_64, since that's what the old dylibs
were compiled for. This should allow us to move to newer AppleClangs
in the CI.

As a fly-by, fix missing availability annotations on optional's
monadic operations.

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

Incidentally, this removes some unqualified ADL calls to `begin` and `end`.

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

Reviewed By: mehdi_amini

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

NFC.

As suggested in D117966.
These conditional noexcepts are *permitted* by the Standard (as long
as there were no mistakes in them, I guess); but not *mandated*.
The Standard doesn't put any noexcept-specifications on these member functions.
The same logic would apply to `transform_view::iterator::operator*`
and `transform_view::iterator::operator[]`, but the Standard mandates
conditional noexcept on `iter_move(transform_view::iterator)`, and
I think it doesn't make much sense to say "moving from this iterator
is conditionally noexcept but not-moving from it is noexcept(false),"
so I'm leaving transform_view alone for now.

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

Based on original tests from D119839.

See https://github.com/llvm/llvm-project/issues/53853

A more general enhancement needs to add tests and make sure
that intrinsics that return structs are correct. There are also
target-specific intrinsics, and I'm not sure what behavior is
expected for those.

A more general enhancement needs to add tests and make sure
that intrinsics that return structs are correct. There are also
target-specific intrinsics, and I'm not sure what behavior is
expected for those.