[module.unit]p1 specifies that module and import are invalid components
of a module name, that module names cannot contain reserved
identifiers, and that std followed by zero or more digits is reserved.

The first issue (module and import pseudo-keywords) requires a
diagnostic, the second issue (use of reserved identifiers) does not
require a diagnostic. We diagnose both the same -- the code is ill-
formed unless the module declaration is in a system "header". This
allows STL implementations to use the reserved module names while
preventing users from stealing them out from under us.

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

Reviewed By: aaron.ballman

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

Use existing ConstantInt::getTrue/getFalse functionality instead of
custom getScalarConstOrSplat as suggested by @nikic.

The earlier available datalyaout allows MLIR to LLVM-IR transformation
to use the datalayout for decisions, such as comparing sizes for
different types of integers.

This should solve https://github.com/llvm/llvm-project/issues/57230

Reviewed By: awarzynski, vzakhari

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

The documentation of the patch https://reviews.llvm.org/D132131 looks
disorganized on the website
https://clang.llvm.org/docs/ClangFormatStyleOptions.html.
This patch tries to fix that.

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

They were annotated with TrailingAnnotation, which they are not. And
that resulted in some quirky formatting in some cases.

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

Without the patch UnwrappedLineFormatter::analyzeSolutionSpace just ran
out of possible formattings and would put everything just on one line.
The problem was that the the line break was forbidden, but putting the
conditional colon on the same line is also forbidden.

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

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

Add the DIAssignID metadata attachment boilerplate. Includes a textual-bitcode
roundtrip test and tests that the verifier and parser catch badly formed IR.

This piece of metadata links together stores (used as an attachment) and the
yet-to-be-added llvm.dbg.assign debug intrinsic (used as an operand).

Reviewed By: jmorse

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

The problem with GCNDownwardRPTracker::advanceBeforeNext is that it doesn't allow to get register pressure
after the last instruction in a MBB.

However when we track RP through the boundary of a MBB we need the state that is after the last instruction
of the MBB and before the first instruction of the successor MBB. Currently we stop traking RP in the state
 'at' the last instruction of the MBB which is incorrect.

This patch fixes 27 lit tests with EXPENSIVE_CHECKS enabled.

Reviewed By: rampitec, arsenm

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

Only add the option processing and store the result. No attributes are
added to FIR yet.

This patch follows Clang in forwarding -fno-honor-infinities as
-menable-no-infs.

Reviewed By: kiranchandramohan awarzynski vzakhari

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

Cortex-A715 is an Armv9-A AArch64 CPU.

This patch introduces support for Cortex-A715.

Technical Reference Manual: https://developer.arm.com/documentation/101590/latest.

Reviewed By: vhscampos

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

We currently only forward store -> load, but could do the same
for memset as well.

This patch is to solve this:
    https://lab.llvm.org/buildbot#builders/36/builds/26801
Created by this patch: a20112a7

[AArch64]SME2 instructions that use ZTO operand

Having AllEnumtypes to be a vector of TrackingMDNodeRef makes it possible
to reflect changes in metadata in the vector if they took place before DIBuilder
being finalized.

Otherwise, we end up with heap-use-after-free because AllEnumTypes contains
metadata that no longer valid.

Consider a case where we have a class containing a definition of a enum,
so this enum has the class as a scope. For some reason (doesn't matter for
the current issue), we create a temporary debug metadata for this class, and
then resolve it while finalizing CGDebugInfo.

In the case of collision during uniqifying the temporary, we then need
to replace its uses with a new pointer. If a temporary's user is unique
(this is the enum mentioned above), we may need re-uniquefying it,
which may return a new pointer in the case of another collision.
If so, the pointer we stored in AllEnumTypes vector become dangling.
Making AllEnumTypes hodling TrackingMDNodeRef should solve this problem
(see debug-info-enum-metadata-collision.cpp test for details).

Reviewed By: dblaikie

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

Diffing phi nodes was recently added to llvm-diff.
However, there currently is a limitation where equivalent values
cannot be detected as such, leading to false positive diff reports.

If a phi node refers a value defined in a basic block dominated by
the current basic block, for example a phi node in a loop header referring
a value defined in the loop body, we cannot prove equivalence of the referred
values, because the basic block containing the variable definition has
not yet been processed.

This commit adds a test case showing this behavior, serving as a precommit
for an upcoming fix of the above.

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

Allows for better matching of VOP3 mods.

Reviewed By: arsenm

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

This reverts commit 957eed0b.

arm_neon_sve_bridge.h is not generated, so the rules which ensure the
generated files get copied into the installation prefix don't apply to
this one.

Add it to the aarch64_only_files set instead, which ensures it ends up
both in the build directory and the installation directory.

Tested with build targets `clang-resource-headers` and
`install-clang-resource-headers`.

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

As now errors in file operation are handled, check for file existence
must be done prior to check for recursion, otherwise reported errors are
misleading.

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

This patch adds the assembly/disassembly for the following instructions:
  ZERO (ZT0): Zero ZT0.
  LDR (ZT0): Load ZT0 register.
  STR (ZT0): Store ZT0 register.
  MOVT (scalar to ZT0): Move 8 bytes from general-purpose register to ZT0.
       (ZT0 to scalar): Move 8 bytes from ZT0 to general-purpose register.
 Consecutive:
   LUTI2 (single): Lookup table read with 2-bit indexes.
         (two registers): Lookup table read with 2-bit indexes.
         (four registers): Lookup table read with 2-bit indexes.
   LUTI4 (single): Lookup table read with 4-bit indexes.
         (two registers): Lookup table read with 4-bit indexes.
         (four registers): Lookup table read with 4-bit indexes.

The reference can be found here:

https://developer.arm.com/documentation/ddi0602/2022-09

This patch also adds a new register class and operand for zt0
and a another index operand uimm3s8

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

This reverts commit b756096b.
See regression https://github.com/llvm/llvm-project/issues/58774

This change-set defines the LoweringOptions the same way
other options are defined in Flang.

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

This patch fixes codegen for `[su]itofp` instructions.

In LoongArch, a legal int-to-float conversion is done in two steps:

1. Move the data from `GPR` to `FPR`. (FRLen >= GRLen)
2. Conversion in `FPR`. (the data in `FPR` is treated as a signed value)

Based on the above features, when the type's BitWidth meets the
requirements, all `SINT_TO_FP` are legal, all `UINT_TO_FP` are expand
and lowered to libcall when appropriate.
The only special case is, LoongArch64 with `+f,-d` features. At this
point, custom processing is required for `[SU]INT_TO_FP`. Of course, we
can also ignore it and use libcall directly.

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

CMPSXADD will modify memory, so we can't use `IntrArgMemOnly` here.
Found it during review D137250.

Fix a brown paper bag error made by me in D129418.  I didn't set
ASAN_INTERCEPT_VFORK correctly for loongarch64, but created an all-zero
object for __interception::real_vfork.  This caused anything calling
vfork() to die instantly.

Fix this issue by setting ASAN_INTERCEPT_VFORK and remove the bad
all-zero definition.  Other ports have an all-zero common definition but
we don't need it at least for now.

And, enable ASAN vfork test for loongarch64 to prevent regression in the
future.

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

Instrumentation passes now use the proper shadow offset. There will be many
asan test failures without this patch. For example:

```
$ ./lib/asan/tests/LOONGARCH64LinuxConfig/Asan-loongarch64-calls-Test
AddressSanitizer:DEADLYSIGNAL
=================================================================
==651209==ERROR: AddressSanitizer: SEGV on unknown address 0x1ffffe2dfa9b (pc 0x5555585e151c bp 0x7ffffb9ec070 sp 0x7ffffb9ebfd0 T0)
==651209==The signal is caused by a UNKNOWN memory access.
```

Before the patch:

```
$ make check-asan
Testing Time: 36.13s
  Unsupported      : 205
  Passed           :  83
  Expectedly Failed:   1
  Failed           : 239
```

After the patch:
```
$ make check-asan
Testing Time: 58.98s
  Unsupported      : 205
  Passed           : 421
  Expectedly Failed:   1
  Failed           :  89
```

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

This enables odr indicators on all platforms and private aliases on non-Windows.
Note that GCC also uses private aliases: this fixes bogus
`The following global variable is not properly aligned.` errors for interposed global variables

Fix https://github.com/google/sanitizers/issues/398
Fix https://github.com/google/sanitizers/issues/1017
Fix https://github.com/llvm/llvm-project/issues/36893 (we can restore D46665)

Global variables of non-hasExactDefinition() linkages (i.e.
linkonce/linkonce_odr/weak/weak_odr/common/external_weak) are not instrumented.
If an instrumented variable gets interposed to an uninstrumented variable due to
symbol interposition (e.g. in issue 36893, _ZTS1A in foo.so is resolved to _ZTS1A in
the executable), there may be a bogus error.

With private aliases, the register code will not resolve to a definition in
another module, and thus prevent the issue.

Cons: minor size increase. This is mainly due to extra `__odr_asan_gen_*` symbols.
(ELF) In addition, in relocatable files private aliases replace some relocations
referencing global symbols with .L symbols and may introduce some STT_SECTION symbols.

For lld, with -g0, the size increase is 0.07~0.09% for many configurations I
have tested: -O0, -O1, -O2, -O3, -O2 -ffunction-sections -fdata-sections
-Wl,--gc-sections. With -g1 or above, the size increase ratio will be even smaller.

This patch obsoletes D92078.

Don't migrate Windows for now: the static data member of a specialization
`std::num_put<char>::id` is a weak symbol, as well as its ODR indicator.
Unfortunately, link.exe (and lld without -lldmingw) generally doesn't support
duplicate weak definitions (weak symbols in different TUs likely pick different
defined external symbols and conflict).

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

This document aims to give insights at the representation of procdure
pointers in FIR.

Reviewed By: PeteSteinfeld, jeanPerier, kiranchandramohan

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

It's not necessary to redo the source file preprocessing for reproducing linker
crashes because we must have successfully created the object file by this point.
Skip this step, and also don't report the preprocessed source file or create
the clang invocation shell script. The latter is no longer sensible without the
preprocessed source, or helpful given the linker reproducer will have it's own
shell script.

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

Materializing scalable vectors with boolean values is not implemented
yet. Skip those cases for now and leave a TODO.

Per discussions in D128745, remove ClangABICompat checks for implementations
of DR692/DR1395/DR1432. This is a potentially breaking changes, so the release
note is updated accordingly.

Reviewed By: aaron.ballman

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

Fixes null dereference in emitFunctionBodyStart for 64-bit

The empty set will be default constructed if this wasn't
in the map already.