deep-recursion.c was disabled

(https://github.com/llvm/llvm-project/commit/c007e0f66ee3f96467fd12f6200218fb4c38c2c9)
because the test may get unlucky and end up with a zero-tagged variable,
leading to a false negative
(https://github.com/llvm/llvm-project/issues/69221

).

This patch re-enables the test and adds a workaround: it checks
if the variable is zero-tagged, and if so, it will instead use the
neighboring variable, which must have a different (hence non-zero)
tag.

Fixing the stack allocation tagging is left as an exercise for the
reader. It is non-trivial because, even if the stackTagBase is
non-zero, tags for subsequent allocations in the stack frame may wrap
around to zero; working around this would require adding multiple
instructions to each alloca.

---------

Co-authored-by: Thurston Dang <thurston@google.com>

The dependence of a template argument is not only determined by the
argument itself, but also by the type of the template parameter:

> Furthermore, a non-type
[template-argument](https://eel.is/c++draft/temp.names#nt:template-argument)
is dependent if the corresponding non-type
[template-parameter](https://eel.is/c++draft/temp.param#nt:template-parameter)
is of reference or pointer type and the
[template-argument](https://eel.is/c++draft/temp.names#nt:template-argument)
designates or points to a member of the current instantiation or a
member of a dependent
type[.](https://eel.is/c++draft/temp.dep#temp-3.sentence-1)

For example:

```cpp
struct A{};

template <const A& T>
const A JoinStringViews = T;

template <int V>
class Builder {
public:
    static constexpr A Equal{};
    static constexpr auto Val = JoinStringViews<Equal>;
};
```

The constant expression `Equal` is not dependent, but because the type
of the template parameter is a reference type and `Equal` is a member of
the current instantiation, the template argument of
`JoinStringViews<Equal>` is actually dependent, which makes
`JoinStringViews<Equal>` dependent.

When a template-id of a variable template is dependent,
`CheckVarTemplateId` will return an `UnresolvedLookupExpr`, but
`UnresolvedLookupExpr` calculates dependence by template arguments only
(the `ConstantExpr` `Equal` here), which is not dependent. This causes
type deduction to think that `JoinStringViews<Equal>` is `OverloadTy`
and treat it as a function template, which is clearly wrong.

This PR adds a `KnownDependent` parameter to the constructor of
`UnresolvedLookupExpr`. After canonicalization, if `CanonicalConverted`
contains any dependent argument, `KnownDependent` is set to `true`. This
fixes the dependence calculation of `UnresolvedLookupExpr` for dependent
variable templates.

Fixes #65153 .

This patch adds in support for building the LLVM documentation through a
Github actions job. This enables catching documentation build failures
earlier and also more easily as the job failure will show up directly on
pull requests. The job currently only builds the documentation for LLVM,
but the plan is to extend it to also build the documentation for other
subprojects when appropriate (i.e., the docs files have changed),
starting with clang.

Induced by variables that are only used in assertion statements. NFC.

Similar to #67577, Lower G_UMAX, G_UMIN, G_SMAX, G_SMIN.

Revert "[clang][Sema] Use original template pattern when declaring implicit deduction guides for nested template classes (#68379)"

This reverts commit dd0fba11.

It fails on nested classes that have both an explicit deduction guide and
a constructor that has an argument of the same type as the class (i.e. a copy constructor).

This patch supports STRICT_FP_ROUND and STRICT_FP_EXTEND when we only
have Zvfhmin but no Zvfh.

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

Reviewed By: yabinc, aaron.ballman, #clang-language-wg

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

Fortran requires that a DO construct with a construct name end with an
END DO statement bearing the same name. This is true even if the DO
construct begins with a label DO statement; e.g., "constrName: do 10
j=1,10" must end with "10 end do constrName".

The compiler presently basically ignores construct names that appear on
label DO statements, because only non-label DO statements can be parsed
as DO constructs. This causes us to miss some errors, and (worse) breaks
the usage of the construct name on CYCLE and EXIT statements.

To fix this, this patch changes the parse tree and parser so that a DO
construct name on a putative label DO statement causes it to be parsed
as a "non-label" DO statement... with a label. Only true old-style
labeled DO statements without construct names are now parsed as such.

I did not change the class name NonLabelDoStmt -- it's widely used
across the front-end, and is the name of a production in the standard's
grammar. But now it basically means DoConstructDoStmt.

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

The code that duplicates the interface of a separate module procedure
into its definition doesn't allow for a dummy procedure with an explicit
INTERFACE declaration. Extend the code to handle this case.

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

To ensure that the map from symbols to their initial images has an entry
for a particular symbol, use std::map<>::find() before
std::map<>::emplace() to avoid needless memory allocation and
deallocation. Also, combine adjacent intervals in the lists of
initialized ranges so that contiguous initializations don't require long
lists.

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

Fix Windows build after 910a4bf5
(the breakage was found by the buildbot
https://lab.llvm.org/buildbot/#/builders/127/builds/56796)

If the load ptrs can be decomposed into a common (Base + Index) with a
common constant stride, then return the constant stride.

This patch commits tests that can be optimized by improving
performCONCAT_VECTORCombine to do a better job at decomposing the base
pointer and recognizing a constant offset.

The array of all exceptions IEEE_ALL defined in the intrinsic module
IEEE_EXCEPTIONS should contain only what the standard mandates. Existing
code depends on it having only five elements. The legacy extension
exception flag IEEE_DENORM shouldn't be an element.

Full namespace qualification is needed on an identifier.

Previous to this fix, if we had a DW_TAG_subprogram that had a
DW_AT_linkage_name that was empty, it would attempt to use this name
which would cause an error to be emitted when saving the gsym file to
disk:

error: DWARF conversion failed: : attempted to encode invalid
FunctionInfo object

This patch fixes this issue and adds a unit test case.

This patch implements __extendxftf2 (long double -> f128) and
__trunctfxf2 (f128 -> long double) on x86_64.
This is a preparation to unblock https://reviews.llvm.org/D53608,
We intentionally do not modify compiler-rt/lib/builtins/fp_lib.h in this
PR
(in particular, to limit the scope and avoid exposing other functions on
X86_64 in this PR).
Instead, TODOs were added to use fp_lib.h once it is available.

Test plan:
1. ninja check-compiler-rt (verified on X86_64 and on Aarch64)
In particular, new tests (extendxftf2_test.c and trunctfxf2_test.c) were
added.
2. compared the results of conversions with what other compilers (gcc)
produce.

When an unrepresentable nonzero real input value with a very small
exponent is currently being read in as zero, don't neglect
ROUND=UP/DOWN; return the least nonzero subnormal value instead when
appropriate.

This patch adds tosa.variable, tosa.variable.read and
tosa.variable.write operators and tests.


Change-Id: I647e2e5c3762d7890b03f6aa7c09a29198b7d355

---------

Signed-off-by: Jerry Ge <jerry.ge@arm.com>
Co-authored-by: Jerry Ge <jerry.ge@arm.com>

The code that folds the relatively new NORM2 intrinsic function can
produce overflow in cases where it's not warranted. Rearrange to NORM2 =
M * SQRT((A(:)/M)**2) where M is MAXVAL(ABS(A)).

Fortran allows forward references to type names, which can lead to
ambiguity when coupled with host association, as in:

  module m
    type ambiguous; integer n; end type
   contains
    subroutine s
      type(ambiguous), pointer :: variable
      type t
        type(ambiguous), pointer :: component
      end type
      type ambiguous; real x; end type
    end
  end

Some other compilers resolve to a host association, some resolve to a
forward reference. This compiler will now emit an error.

After 144c5b6d, we still see this test
running in CI for aarch64-linux targets. This appears to be related to
the triple being `aarch64-unknown-linux-gnu`, or similar.

The bot link below includes 144c5b6d,
and fails the deep-recursion.c test, which should have been disabled.
https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-arm64/b8767065085790662609/overview

This cleans up all external entry points that will have to deal with
non-permutations, making any subsequent refactoring much more local to
the lib files.

A recent fix causes the TypeAndShape::Characterize() member function
templates for general expressions and designators to avoid using the
Characterize() member function for Symbols when the argument is a whole
component. This caused the corank of a component to no longer be
reflected in the returned TypeAndShape characteristics. Fix the
regression.

Previously, upon encountering an equals sign while parsing a lambda in
the UnwrappedLineParser, it would fall through and fail. This caused any
lambda template with a default argument for a template parameter to be
annotated as an ArraySubscriptLSquare.

This patch allows equals signs in the UnwrappedLineParser if we're
currently in a template parameter list. This resolved a FIXME that was
in the lambda parsing function.

This patch seems deceptively easy, it's likely it doesn't solve the
FIXME entirely, or causes other issues (the FIXME itself mentions
something about Objective-C, which I cannot comment about). However this
patch is sufficient to fix the below issue.

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



---------

Co-authored-by: Owen Pan <owenpiano@gmail.com>

Use a higher-frequency clock base when initializing the pseudo-random
number generator to implement
  CALL  RANDOM_INIT(REPEATABLE=.FALSE.)

The current implementation completely ignores argument attributes on
calls, discarding them completely when creating a statepoint from a call
instruction. This is problematic in some scenarios as the argument
attributes affect the ABI of the call, leading to undefined behavior if
called with the wrong ABI attributes. Note that this cannot be solved
either by just having the function declaration annotated with the right
parameter attributes as the call might be indirect, therefore requiring
them to be present on the arguments.

This PR simply copies all parameter attributes over from the original
call to the created statepoint.
Note that some argument attributes become invalid after the lowering as
they imply memory effects that no longer hold with the statepoints.
These do not need to be explicitly handled in this PR as they are
removed by the `stripNonValidDataFromBody`.

Name resolution creates symbols for submodules in their parents' scopes.
This can lead to bogus errors about name clashes between submodule names
and other entities in the parents' scopes.

Create symbols for submodules but do not add them to a scope's
dictionary.

Support the EX edit descriptor for hexadecimal real formatted output and
hexadecimal real input for all forms of formatted input.. (We're
possibly the first Fortran compiler to support this feature for input
editing; only one other can handle EX output editing.)

As true (not BOZ) hexadecimal floating-point constants are not supported
in Fortran source code, only in formatted input, the implementation
takes place in the I/O editing portion of the runtime, not as new
conversions in the Decimal library.

Add information about what fixes are provided by
the check, and how to enable them.

Issue: #55093

This is transforming the `stop_token` benchmark that Lewis Baker had
created into Google
Bench
https://reviews.llvm.org/D154702

Summary:
This step was incorrectly called 'fatbinary', so if it failed here it
would say 'fatbinary' was the cause of the failure. This is actually
'nvlink' so we should adjust this.

Recent testing has uncovered some hard-to-find bugs in printf's long
double support. This patch adds an extra long double path to the fuzzer
with minimal extra effort. While a more thorough long double fuzzer
would be useful, it would need to handle the non-standard cases of 80
bit long doubles such as unnormal and pseudo-denormal numbers. For that
reason, a standalone long double fuzzer is left for future development.

This reverts commit 8e2b2c41 to fix
a crash reported in https://lab.llvm.org/buildbot/#/builders/230/builds/19993.

…ent list

When a derived type value appears in NAMELIST input, its components'
values appear in sequence. This sequence can be truncated by a NAME=
that begins the next NAMELIST input item, or by the terminal '/' that
ends the NAMELIST group. Extend the mechanism already in place for
truncated array item lists in NAMELIST input so that it also applies to
derived type component sequences, and rename things appropriately.