Instead, make it a static array that's part of the FlagParser. The advantage
this has is helping reduce fragmentation from needing to anonymously mmap
this array via the LowLevelAllocator. This will instead place the array on
the stack. Functionally, the only difference is that the array will not be
zero-initialized, but all used elements are explicitly initialized via the
flag handlers.

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

Another shell-quoting issue.

Seen in <https://lab.llvm.org/buildbot/#/builders/216/builds/26442>.

For `llvm/utils/lit/tests/shtest-output-printing.py`, the executable
in `%{python}` wasn't properly shell-quoted for windows.  This caused
the 127 exit code mentioned in f254bbf2.  Fix quoting and expect
exit code 1 again.

Fix shell-quoting issue in a few more file names in
`llvm/utils/lit/tests/shtest-shell.py`, missed in f254bbf2.

Test failures seen in
<https://lab.llvm.org/buildbot/#/builders/216/builds/26436>.

[Clang] Modify Parser::ParseLambdaExpressionAfterIntroducer to check whether the lambda-declarator is valid

We had a couple of crashes due to invalid lambda trailing return types that
were diagnosed but not treated as errors during parsing. So now in
Parser::ParseLambdaExpressionAfterIntroducer(...) after ActOnStartOfLambdaDefinition(...)
we also check if the lambda-declarator is invalid and if so we end up in ActOnLambdaError(...).

Fixes: https://github.com/llvm/llvm-project/issues/64962
https://github.com/llvm/llvm-project/issues/28679

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

This reverts commit 024f562d.

Forgot to update flang

Add a c23 module feature for `requires`.

Reviewed By: ChuanqiXu, v.g.vassilev, aaron.ballman

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

Assemblers change certain relocations referencing a local symbol to
reference the section symbol instead. This conversion is disabled for
many conditions (`shouldRelocateWithSymbol`), e.g. TLS symbol, for most
targets (including AArch32, x86, PowerPC, and RISC-V) GOT-generating
relocations.

However, AArch64 encodes the GOT-generating intent in MCValue::RefKind
instead of MCSymbolRef::Kind (see commit
0999cbd0 (2014)), therefore not affected
by the code `case MCSymbolRefExpr::VK_GOT:`. As GNU ld and ld.lld
create GOT entries based on the symbol, ignoring addend, the two ldr
instructions will share the same GOT entry, which is not expected:
```
ldr     x1, [x1, :got_lo12:x]  // converted to .data+0
ldr     x1, [x1, :got_lo12:y]  // converted to .data+4

.data
// .globl x, y  would suppress STT_SECTION conversion
x:
.zero 4
y:
.long 42
```

This patch changes AArch64 to suppress local symbol to S...

This is necessary to allow testing pre-commit CI from GH PRs before
the repo-lockdown script is removed entirely.

The current implementation is not very ergonomic or descriptive: It uses `std::optional<unsigned>` where `std::nullopt` represents the parent op and `unsigned` is the region number.
This doesn't give us any useful methods specific to region control flow and makes the code fragile to changes due to now taking the region number into account.

This patch introduces a new type called `RegionBranchPoint`, replacing all uses of `std::optional<unsigned>` in the interface. It can be implicitly constructed from a region or a `RegionSuccessor`, can be compared with a region to check whether the branch point is branching from the parent, adds `isParent` to check whether we are coming from a parent op and adds `RegionSuccessor::parent` as a descriptive way to indicate branching from the parent.

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

[DAG] visitSHL - use FoldConstantArithmetic to fold constants in (shl (add x, c1), c2) -> (add (shl x, c2), c1 << c2) fold

Matches what we do in the (shl (mul x, c1), c2) -> (mul x, c1 << c2) fold as well as inside visitShiftByConstant

This reverts commit cf403c10.

This is breaking Android sanitizer buildbots (see the discussion on
https://reviews.llvm.org/D158793).

Disable the new test flang/test/Evaluate/test-out_of_range.f90
on targets and systems that do not support the kinds of REAL
that it exercises.

Pushed without review to clear up broken build-bots.

This basically inlines the logic that was previously located in
https://github.com/google/llvm-premerge-checks so it is part of
the monorepo. This has the benefit of making it extremely easy
for individual projects to understand and modify this logic for
their own needs, unlike the current model where this logic lives
in a separate non-LLVM repository.

It also allows testing changes to the CI configuration using a simple
Phabricator review, since the code that defines the CI pipeline is taken
from the patch under review.

This (or something equivalent) is necessary if we want to retain the
current monolithic pre-commit CI throughout the GitHub PR transition.
Since triggering the monolithic CI is currently attached to the system
we use for triggering CI pipelines from Phabricator, we will lose that
part of the CI when we move to GitHub PRs if we don't do anything.

I've decided to rewrite the code as a shell script because the logic
was fairly simple an...

Handle the case when shell quotes are not necessary.

Label resolution gets into an infinite loop trying to emit an inappropriate
error or warning for a GOTO whose target is on an enclosing END IF
statement with an intervening ELSE or ELSE IF.  The scope tracking mechanism
viewed the END IF as being part of the ELSE block's scope.

Fix with the same means that was used to fix a similar bogus error
on GOTOs to END SELECT in SELECT CASE blocks: nest the THEN/ELSE IF/ELSE
blocks one level deeper than before, so that the END IF is in the IF
block but not in any of its parts.

Fixes https://github.com/llvm/llvm-project/issues/64654 for
llvm-test-suite/Fortran/gfortran/regression/goto_5.f90.

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

This was mention in D150044 and D154995 that this would be useful.
This addresses the last review coment of D150044.

Reviewed By: #libc, ldionne

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

This adds more information regarding the libc++ coding style and
reference that are useful when working on a standard library
implementation.

This information is based on review comments and tips I give to new
contributors an information I wish I'd know when I started working on
libc++.

Depends on D156051

Reviewed By: #libc, jloser, var-const, ldionne

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

Process and fold the new F'2023 intrinsic function SELECTED_LOGICAL_KIND.

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

Failures were seen at
<https://lab.llvm.org/buildbot/#/builders/216/builds/26431>.

All but one failure is due to different shell-quoting of file names
because they contain special characters under windows.  Generalize
associated FileCheck patterns.

`llvm/utils/lit/tests/shtest-output-printing.py` fails because the
exit code was 127 instead of the expected 1.  Unfortunately, this CI
config doesn't pass `-dump-input-filter=all` to FileCheck, so we
cannot see the rest of the lit execution trace.  For now, generalize
the FileCheck pattern to accept any non-zero exit code to get past
this error.

Invoking compiler-rt function __truncsfbf2 to convert a zero 32-bit float
0x00000000 to a 16-bit bfloat value currently generates the denormal value
0x0040, rather than value 0x0000. Negative zero 0x80000000 is converted
to denormal 0x8040 rather than 0x8000.

This behavior is seen in flang code under development (not yet integrated)
that converts bfloat/REAL(KIND=3) argument values to float/REAL(KIND=4)
values and then converts those values back to bfloat/REAL(KIND=3). There
are other instances of the problem. A round-trip type conversion using
__truncsfbf2 of a denormal generates a different denormal, and an sNaN
is converted to a qNaN.

The problem is addressed in generic conversion function fp_trunc_impl.inc
by removing trailing 0 significand bits when the source and destination
type formats are identical except for the significand size. This condition
is met only for float -> bfloat conversions.

Round-trip conversions for at least some other type pairs have the same
problem. A solution in those cases would need to account for exponent
size differences. Those cases are not relevant to flang compilations
and are not addressed here. A broader solution might subsume this fix,
or this fix might remain useful as is.

There are no existing tests of bfloat conversion functionality in the
compiler-rt test directory. Tests for other conversions use a common
infrastructure that does not currently have support for bfloat conversions.
This patch does not attempt to add that infrastructure for this new case.
CodeGen test bfloat.ll checks bfloat adds and other operations that invoke
__truncsfbf2.

This patch is the follow-up improvement of D122152.
Fixes https://github.com/llvm/llvm-project/issues/64558.

`select (a | c), a, b -> select a, true, (select ~c, b, false)` where `c` is free to invert
`select (c & ~b), a, b -> select b, true, (select c, a, false)`
Alive2: https://alive2.llvm.org/ce/z/KwxtMA

Reviewed By: nikic

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

This adds a comparison operation to EmitC which supports ==, !=, <=, <, >=, >, <=>.

Reviewed By: jpienaar

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

Fold the F'2018 intrinsic function OUT_OF_RANGE(), which returns .TRUE.
when a conversion of an integer or real value to an integer or real type
would yield an overflow or (for real->integer only) invalid operand
exception.  Test all type combinations, with both rounding possibilities
for the real->integer cases.

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

Currently all of this logic expects to include and link with the headers
in the `linux/` directory. This patch adds a wrapper macro to optionally
add the appropriate dependency if it exists. This is preliminary to
adding some GPU specific versions of these files.

Reviewed By: lntue

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

Leading zeros should appear only for Iw.m output formatting.
Gw, Gw.d, and Gw.dEe output editing all map to Iw with no ".m"
(Fortran 202X 13.7.5.2.2).

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

This is NFCI as far as I can tell, but I see no reason not to do it.

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

[RISCV] Improve splatPartsI64WithVL for fixed vector constants where Hi and Lo are the same and the VL is constant.

If doubling the VL will fit in a vsetivli, use it. It will be cheap
to change and cheap to change back.

This improves codegen from D158896.

Reviewed By: reames

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

[SelectionDAG][RISCV] Teach getConstant to use SPLAT_VECTOR_PARTS if vXi64 SPLAT_VECTOR is legal but i64 scalars are not.

That matches how such a SPLAT_VECTOR would have been type legalized
so assume it is ok to use for creating constants after type legalization.

Still need some improvements to SPLAT_VECTOR lowering.

This overlaps with some of what D158742 was trying to fix.

Reviewed By: luke

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

Some compilers accept `!$acc end loop` associated with an `!$acc loop`
directive. This patch updates the acc loop parser to accept it as well.
The parser is also updated to be stricter on the following statement
to match the OpenACC combined construct parser.
The rewrite canonicalization is not a rewrite anymore and the naming
will be updated in a follow up patch for the Loop and Combined constructs.

Reviewed By: razvanlupusoru

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

Earlier work allowed a specification expression to reference a generic function
that was defined earlier, so long as the relevant specific procedure of the
generic had been defined before the generic.  This patch extends that work
so that the generic can also be used in cases where the relevant specific
procedure has been defined after the generic and before the reference.

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

This patch and D154984 were discussed in
<https://discourse.llvm.org/t/rfc-improving-lits-debug-output/72839>.

Motivation
----------

D154984 removes the "Script:" section that lit prints along with a
test's output, and it makes -v and -a imply -vv.  For example, after
D154984, the "Script:" section below is never shown, but -v is enough
to produce the execution trace following it:

```
 Script:
 --
 : 'RUN: at line 1'; echo hello | FileCheck bogus.txt && echo success
 --
 Exit Code: 2

 Command Output (stdout):
 --
 $ ":" "RUN: at line 1"
 $ "echo" "hello"
 # command output:
 hello

 $ "FileCheck" "bogus.txt"
 # command stderr:
 Could not open check file 'bogus.txt': No such file or directory

 error: command failed with exit status: 2

 --
```

In the D154984 review, some reviewers point out that they have been
using the "Script:" section for copying and pasting a test's shell
commands to a terminal window.  The shell commands as printed in the
execution trace can be harder to copy and paste for the following
reasons:

- They drop redirections and break apart RUN lines at `&&`, `|`, etc.
- They add `$` at the start of every command, which makes it hard to
  copy and paste multiple commands in bulk.
- Command stdout, stderr, etc. are interleaved with the commands and
  are not clearly delineated.
- They don't always use proper shell quoting.  Instead, they blindly
  enclose all command-line arguments in double quotes.

Changes
-------

D154984 plus this patch converts the above example into:

```
 Exit Code: 2

 Command Output (stdout):
 --
 # RUN: at line 1
 echo hello | FileCheck bogus-file.txt && echo success
 # executed command: echo hello
 # .---command stdout------------
 # | hello
 # `-----------------------------
 # executed command: FileCheck bogus-file.txt
 # .---command stderr------------
 # | Could not open check file 'bogus-file.txt': No such file or directory
 # `-----------------------------
 # error: command failed with exit status: 2

 --
```

Thus, this patch addresses the above issues as follows:

- The entire execution trace can be copied and pasted in bulk to a
  terminal for correct execution of the RUN lines, which are printed
  intact as they appeared in the original RUN lines except lit
  substitutions are expanded.  Everything else in the execution trace
  appears in shell comments so it has no effect in a terminal.
- Each of the RUN line's commands is repeated (in shell comments) as
  it executes to show (1) that the command actually executed (e.g.,
  `echo success` above didn't) and (2) what stdout, stderr, non-zero
  exit status, and output files are associated with the command, if
  any.  Shell quoting in the command is now correct and minimal but is
  not necessarily the original shell quoting from the RUN line.
- The start and end of the contents of stdout, stderr, or an output
  file is now delineated clearly in the trace.

To help produce some of the above output, this patch extends lit's
internal shell with a built-in `@echo` command.  It's like `echo`
except lit suppresses the normal execution trace for `@echo` and just
prints its stdout directly.  For now, `@echo` isn't documented for use
in lit tests.

Without this patch, libcxx's custom lit test format tries to parse the
stdout from `lit.TestRunner.executeScriptInternal` (which runs lit's
internal shell) to extract the stdout and stderr produced by shell
commands, and that parse no longer works after the above changes.
This patch makes a small adjustment to
`lit.TestRunner.executeScriptInternal` so libcxx can just request
stdout and stderr without an execution trace.

(As a minor drive-by fix that came up in testing: lit's internal `not`
command now always produces a numeric exit status and never `True`.)

Caveat
------

This patch only makes the above changes for lit's internal shell.  In
most cases, we do not know how to force external shells (e.g., bash,
sh, window's `cmd`) to produce execution traces in the manner we want.

To configure a test suite to use lit's internal shell (which is
usually better for test portability than external shells anyway), add
this to the test suite's `lit.cfg` or other configuration file:

```
config.test_format = lit.formats.ShTest(execute_external=False)
```

Reviewed By: MaskRay, awarzynski

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

This patch and D156954 were discussed in
<https://discourse.llvm.org/t/rfc-improving-lits-debug-output/72839>.

**Motivation**: -a shows output from all tests, and -v shows output
from just failed tests.  Without this patch, that output from each
test includes a section called "Script:", which includes all shell
commands that lit has computed from RUN directives and will attempt to
run for that test.  The effect of -vv (which also implies -v if
neither -a or -v is specified) is to extend that output with shell
commands as they are executing so you can easily see which one failed.

For example, when using lit's internal shell and -vv:

```
Script:
--
: 'RUN: at line 1'; echo hello world
: 'RUN: at line 2'; 3c40 hello world
: 'RUN: at line 3'; echo hello world
--
Exit Code: 127

Command Output (stdout):
--
$ ":" "RUN: at line 1"
$ "echo" "hello" "world"
hello world

$ ":" "RUN: at line 2"
$ "3c40" "hello" "world"
'3c40': command not found
error: command failed with exit status: 127

--
```

Notice that all shell commands that actually execute appear in the
output twice, once for "Script:" and once for -vv.  Especially for
tests with many RUN directives, the result is noisy.  When searching
through the output for a particular shell command, it is easy to get
lost and mistake shell commands under "Script:" for shell commands
that actually executed.

**Change**: With this patch, a test's output changes in two ways.
First, the "Script:" section is never shown.  Second, omitting -vv no
longer disables printing of shell commands as they execute.  That is,
-a and -v imply -vv, and so -vv is deprecated as it is just an alias
for -v.

**Secondary motivation**: We are also working to introduce a PYTHON
directive, which can appear between RUN directives.  How should PYTHON
directives be represented in the "Script:" section, which has
previously been just a shell script?  We could probably think of
something, but adding info about PYTHON directive execution in the -vv
trace seems more straight-forward and more useful.

(This patch also removes a confusing point in the -vv documentation:
at least when using bash as an external shell, -vv echoes commands to
the shell's stderr not stdout.)

Reviewed By: awarzynski, Endill, ldionne, MaskRay

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

When checking that a module procedure definition is unique, allow for
the possibility that a submodule may contain a module procedure
interface that shadows a module procedure of the same name in its
(sub)module parent.   In other words, module procedure definitions
need only be unique in the tree of submodules rooted at the (sub)module
containing the relevant module procedure interface.

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

This moves the sema checking of the entrypoint sensitive HLSL
attributes all into one place. This ended up being kind of large for a
couple of reasons:

- I had to move the call to CheckHLSLEntryPoint later in
  ActOnFunctionDeclarator so that we do this after redeclarations and
  have access to all of the attributes.

- We need to transfer the target shader stage onto the specified entry
  point before doing the checking.

- I removed "library" from the HLSLShader attribute value enum and
  just go through a string to convert from the triple - the other way
  was confusing and brittle.

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

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

The handling of accessibility attributes on GENERIC statements outside
derived type definitions is incorrect in name resolution.  Change it to
use the usual BeginAttrs()/EndAttrs() infrastructure.

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

This patch should fix the build failures introduced by f0731d5b

.

This removes the use of the `STRING_EXTENSION_OUTSIDE` swig macro in SB
classes that don't implement a `GetDescription` method.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

When resolving names in a specification part, unknown names that appear
in a specification expression before any local declaration are assumed
to be implicitly declared objects in the host scope.  Objects in
EQUIVALENCE sets are not part of specification expressions, so ensure
that they do not receive this treatment; besides being wrong and
unimplementable, it will lead to a later crash during offset assignment.

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