Compilation-time subscript value range checking should emit a warning,
not an error, when the indexed array is a dummy argument; there's
old-school codes out there that should have used assumed-size dummy
arguments but didn't.

Per the spec, "Before version 1.4, results are only computed per
component." So using scalar condition to select composite needs SPIR-V
v1.4 at least.

Fortran free form line continuation with '&' works with this compiler
even across the end of an included source file, as it does with most
other Fortran compilers. This extension should be documented.

I explicitly skipped definability checking for construct entities under
a RANK() clause. I don't know what I was thinking at the time; it's
obviously incorrect! Fix, and add tests.

https://github.com/llvm/llvm-project/issues/72157

These should have been part of e0e0891d

typeIs and LegalizeMutation::changeTo instead of implementing our own lambdas
that do the same thing.

During function-like macro expansion in a standard C/C++ preprocessor,
the macro being expanded is disabled from recursive macro expansion. The
implementation in this compiler's preprocessor, however, was too broad;
the macro expansion needs to be disabled for the "rescanning" phase
only, not for actual argument expansion.

(Also corrects an obsolete comment elsewhere that was noticed during
reduction of an original test case.)

A NULL() pointer without MOLD= cannot be allowed to be associated with
an assumed-rank dummy argument, as its rank is not well-defined and
neither the RANK() intrinsic function or the SELECT RANK construct will
work in the callee.

When the bounds of a substring reference are known during compilation,
and are outside the valid range for the character base object, issue an
error message.

In Fortran, a format automatically repeats, with a line break, until all
the data items of a data transfer statement have been consumed. PRINT
"(3I4)", 1, 2, 3, 4, 5, 6 prints two lines, for example, three values
each.

When there are nested parentheses in a format, the rightmost set of
parentheses at the top level are used for automatic repetition. PRINT
"(I4,2(I4))" 1, 2, 3, 4, 5, 6, 7 print three lines, with three values on
the first and two each on the later ones.

Fix a bug in format interpretation that causes the detection of the
"rightmost" set of parentheses to take place on each pass, leading to
problems when parentheses are even further nested.

…forwarded to CONTIGUOUS dummy

No object with the ASYNCHRONOUS or VOLATILE attribute can go through the
copy-in/copy-out protocol necessary for argument association with a
contiguous dummy array argument. The check for this constraint missed
the case of an assumed-rank array without an explicit CONTIGUOUS
attribute being forwarded on to a CONTIGUOUS dummy argument.

This reverts commit 7b94744e.

This breaks the expensive checks bot: https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-expensive/26026/

We didn't notice because it was broken for other reasons I think.

When NOP instructions are used to reserve space in the code, e.g. for
patching, it becomes critical to preserve their original size while
emitting the code. On x86, we rely on "Size" annotation for NOP
instructions size, as the original instruction size is lost in the
disassembly/assembly process.

This change makes instruction size a first-class annotation and is
affectively NFCI. A follow-up diff will use the annotation for code
emission.

An assumed-rank array may not be a coarray and may not have the VALUE
attribute.

The SIZE= specifier may not appear on a list-directed or namelist READ
statement.

These intrinsic functions are not particularly valuable -- one can just
compare a value to IOSTAT_END or IOSTAT_EOR directly -- but they are in
the standard and are allowed to appear in constant expressions, so
here's code to fold them.

This uses YAML anchors to deduplicate a lot of the pipeline LOC.

This makes it a lot easier to navigate through the file and to make modifications.

The dummy argument names used for the interface to C_ASSOCIATED() were
wrong.

Looks like an incomplete fixup was done after copying the umin/umax tests.

Fixed #71825.

CXXDeductionGuideDecl inherits from FunctionDecl. For FunctionDecls,
the JSONVisitor includes a call to visit NamedDecl in order to provide
mangled names in the dump. This did not correctly exclude
CXXDeductionGuideDecl, which resulted in an assert being hit.

Semantics is emitting an error when an actual argument to a procedure
that has an implicit interface has a polymorphic type. This is too
general; while TYPE(*) and CLASS(*) unlimited polymorphic items require
the presence of an explicit procedure interface, CLASS(T) data can be
passed over an implicit interface to a procedure expecting a
corresponding dummy argument with TYPE(T), so long as T is not
parameterized.

(Only XLF handles this usage correctly among other Fortran compilers.)

(Making this work in the case of an actual CLASS(T) array may well
require additional changes in lowering to copy data to/from a temporary
buffer to ensure contiguity when the actual type of the array is an
extension of T.)

This patch adds support for enter attribute in declare target. As the
enter attribute is a replacement for `to` attribute, it has the same
tests.

The semantics and encodings for these instructions are described by the
Hexagon V67 Programmer's Reference Manual:

https://developer.qualcomm.com/downloads/qualcomm-hexagon-v67-programmer-s-reference-manual

Opaque ptr cleanup effort (NFC).

Prior to this, clang would always report

```
compile with '-ffixed-point' to enable fixed point types
```

whenever it sees `_Accum`, `_Fract`, or `_Sat` when fixed point
arithmetic is not enabled. This can break existing code that uses these
as variable names and doesn't use fixed point arithmetic like in some
microsoft headers

(https://github.com/llvm/llvm-project/pull/67750#issuecomment-1775264907).

Fixed point should not raise this error for these cases, so this removes
the error altogether and defaults to the usual error clang gives where
it can see these keywords as either unknown types or regular variables.

In our default SelectionDAG where i32 isn't legal, the zext will become
and i64 AND and often get optimized out on its own. With i32 legal, we
need to turn it in into sext.w and rely on RISCVOptWInstrs to remove it.

Coerce the register bank based on the users of the G_LOAD or the
defining instruction for the G_STORE.

s64 on rv32 is handled by forcing the FPRB register bank.

…ffine subscript expressions.

This upstreams more of the Clang API Notes functionality that is
currently implemented in the Apple fork:
https://github.com/apple/llvm-project/tree/next/clang/lib/APINotes

This patch extracts the logic to create a static variable member decl
into a helper. We will use this in an upcoming patch which will need to
call exactly the same logic from a separate part of the DWARF parser.

The base ISA does not support these operations. A future patch will
enable them for Zbb.

Refine FIXMEs in added tests, the problematic case only materializes if
there's either both a read and write from an indirect address.

GCC is able to check that the signatures of the builtins are as expected
and this shows some incorrect signatures on ld80 platforms (i.e. x86).
The *tf* functions should take 128-bit arguments but until the latest fixes
they used 80-bit long double.

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

The DWARF 5 specification says that:

> The name index must contain an entry for each debugging information
entry that
> defines a named [...] label [...].

The verifier currently verifies this, but the AsmPrinter does not add
entries for TAG_labels in debug_names. This patch addresses the issue by
ensuring we add labels in the accelerator tables once we have a fully
completed DIE for the TAG_label entry.

We also respect the spec as follows:
> DW_TAG_label debugging information entries without an address
attribute
> (DW_AT_low_pc, DW_AT_high_pc, DW_AT_ranges, or DW_AT_entry_pc) are
excluded.

The effect of this on the size of accelerator tables is minimal, as
TAG_labels are usually created by C/C++ labels (see example in test),
which are typically paired with "goto" statements.