…project into fir-dev

Getting ready to merge changes for the CSHIFT intrinsic.

This change implements the lowering runtime portion of the CSHIFT
intrinsic.  The implementation of the runtime was done in revision
D106292.

[flang] Implement the lowering portion of the CSHIFT intrinsic

…roduct

Add lowering for the DOT_PRODUCT intrinsic

I confirmed that it builds and runs without issue (regression tests pass and an end-to-end dot product test runs correctly too). Thanks @banach-space !

Initial implementation with assumption that rank will be always 2

In processing the UNPACK intrinsic, my implementation had an unneeded
extra call to createBox().  This change removes it.

-> Handle case where rank of one the matrices is 1.
-> Add test for the above case with logical type.
-> Remove return value from the matmul call.

This change fixes a bug in  the runtime portion of the CSHIFT intrinsic
that happens when the value of the SHIFT argument is negative.

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

[flang] Remove an unneeded call to createBox

…soc-review-comments

[NFC] address comments from flang-compiler#907

When instantiating variables, identify the ones that must be default
initialized at runtime (locals and intent(out) dummies). Call the
default initialization runtime routine to perform the initialization.

Global variables that have no explicit initialization and have a default
initialization are left TODO. The runtime cannot be used for them, the
fir.global generation will need to be updated for these variables (it was
generating an undefined undefined until now). For now, simply catch and
add a hard TODO for these cases. For information, it is firing 13 times
in NAG F95 tests.

Runtime interface for finalization is added, but nothing is done with it
yet (Final procedures are not F95).

…-type-init-2

Lower default initialization of local and dummy entities

[OpenMP][Flang]Add support for modifiers monotonic and non-monotonic

Also insert casts in fir.array_coor op (error revealed by the first fix).

…issue

Fix fir.alloca codegen for array with dynamic type parameters

It does not make sense to embox a box. Instead we can convert the box's
signature with a fir.convert, which is idempotent on the boxed value.

…faces

Since BOZ literal arguments are typeless, we cannot know how to pass them as
actual arguments to procedures with implicit interfaces.  This change avoids
the problem by emitting an error message in such situations.

This change stemmed from the following issue --
  flang-compiler#794

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

According to C7109, "A boz-literal-constant shall appear only as a
data-stmt-constant in a DATA statement, or where explicitly allowed in
16.9 as an actual argument of an intrinsic procedure."  This change
enforces that constraint for output list items.

I also added a general interface to determine if an expression is a BOZ
literal constant and changed all of the places I could find where it
could be used.

I also added a test.

This change stemmed from the following issue --
  https://gitlab-master.nvidia.com/fortran/f18-stage/issues/108

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

When a WRITE overwrites an endfile record, we need to forget
that there was an endfile record.  When doing a BACKSPACE
after an explicit ENDFILE statement, the position afterwards
must be upon the endfile record.

Attempts to join list-directed delimited character input across
record boundaries was due to a bad reading of the standard
and has been deleted, now that the requirements are better understood.
This problem would cause a read attempt past EOF if a delimited
character input value was at the end of a record.

It turns out that delimited list-directed (and NAMELIST) character
output is required to emit contiguous doubled instances of the
delimiter character when it appears in the output value.  When
fixed-size records are being emitted, as is the case with internal
output, this is not possible when the problematic character falls
on the last position of a record.  No two other Fortran compilers
do the same thing in this situation so there is no good precedent
to follow.

Because it seems least wrong, with this patch we now emit one copy
of the delimiter as the last character of the current record and
another as the first character of the next record.  (The
second-least-wrong alternative might be to flag a runtime error,
but that seems harsh since it's not an explicit error in the standard,
and the output may not have to be usable later as input anyway.)
Consequently, the output is not suitable for use as list-directed or
NAMELIST input.

If a later standard were to clarify this case, this behavior will of
course change as needed to conform.

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

NAMELIST I/O formatting uses the runtime infrastructure for
list-directed I/O.  List-directed input processing has same state
that requires reinitialization for each successive NAMELIST input
item.  This patch fixes bugs with "null" items and repetition counts
on NAMELIST input items after the first in the group.

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

cherry pick runtime I/O fixes for namelist array input, backspace, rewind

Fix issue flang-compiler#917.

Lowering for the Matmul Intrinsic

All tests from flang/test/Lower/intrinsic-procedures.f90 are moved to
dedicated files (with the exception of `lge`, `lgt`, `lle` and `llt`).
With this change, every filename clearly defines which intrinsic
procedure is being tested.

After the initial split, we discovered that some tests were invalid
(e.g.  `! CHECK` was used instead of `! CHECK:`). These tests are now
fixed. Some tests are additionally hardened (e.g. some `CHECK-DAG`
directives was replaced with `CHECK`). Some tests are updated with
checks generated with mlir/utils/generate-test-checks.py. In other
words, this patch _moves_ and _reformats_ the tests.

The documentation is updated accordingly (with some extra
clarifications, as suggested by the reviewers).

Please see the following PRs for a complete discussion:
* flang-compiler#927
* flang-compiler#914

…ate_tests

[flang][nfc] Move tests from intrinsic-procedures.f90 to dedicated files

Fix the verify test.

…he builder elided those extents.

Fixes flang-compiler#942.

Delete code that was redundantly removing the elided extents before t…

…r with

a scalar result.

See the following Phabricator review for more information:

https://reviews.llvm.org/D106820

Cherry pick from llvm-main, the runtime error fixes for MAXLOC

…d WHERE

construct assignments.

This patch includes changes to the bridge, array expression lowering, the array
value copy transformation, some FIR ops, and tests. Code generation was tested
end to end with the NAG F95 tests.

The implementation raises (nested) FORALL constructs (statements) into array
expression form. This means that array expressions and FORALL constructs will
be presented to the optimizer with the same structure. There are some notable
differences between FORALLs and array expressions that required extending the
array framework.

  - An array expression is isomorphic between the iteration space and the
    access expressions. FORALL need not be.
  - An array expression is limited by the standard to operate upon exactly
    one ranked component in a designator. A FORALL assignment is, generally,
    not limited in this way.
  - WHERE constructs contain array expressions both as masks and in the
    construct blocks. FORALL constructs may contain scalar assignments,
    array assignments, other FORALL constructs, and WHERE constructs.
  - WHERE constructs have a cascading disjunctional conditional execution
    structure over entire array assignments on an elemental basis. The if-else
    cascade is evaluated in program order. FORALL masks have a conjunctional
    conditional structure and do not, generally, have an elemental
    application but are a function of the user-defined iteration space. These
    two execution structures can be mixed with the FORALL case having
    priority.

Despite these differences, these Fortran constructs share the "copy-in
copy-out" execution model. See the standard for more information.

After the array copy value transformation runs, FIR code will have the same
fundamental structure for array assignments, WHERE constructs, FORALL
constructs, FORALL/WHERE constructs, and DO CONCURRENT loops. (That is,
the nominal "parallel" execution forms.)

This patch does not address FORALL and assignment to POINTERs/ALLOCATABLEs. It
also does not fix bugs in arrays of CHARACTER or derived types.

+ Respond to review comments.

Lowering FORALL statement and FORALL construct with scalar, array, an…

Fix the external-io unittest under Windows.

In particular, fixes the following issues:

 1.  When creating a temporary file, open it with read+write permissions
     using the _O_RDWR flag. _S_IREAD and _S_IWRITE are for the file
     permissions of the created file.

 2. _chsize returns 0 on success (just like ftruncate).

 3. To set a std::optional, use its assign-operator overload instead of
    getting a reference to its value and overwrite that. The latter is
    invalid if the std::optional has no value, and is caught by
    msvc's debug STL.

The non-GTest unittest is currently not executed under Windows because
of the added .exe extension to the output file: external-io.text.exe.
llvm-lit skips the file because .exe is not in the lists of test
suffixes (.test is). D105315 is going to change that by converting it
to a GTest-test.

Reviewed By: awarzynski

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

…faces

Since BOZ literal arguments are typeless, we cannot know how to pass them as
actual arguments to procedures with implicit interfaces.  This change avoids
the problem by emitting an error message in such situations.

This change stemmed from the following issue --
  flang-compiler#794

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

We used to test that end > start, but it can well be >= (otherwise the
loop doesn't make sense).

According to C7109, "A boz-literal-constant shall appear only as a
data-stmt-constant in a DATA statement, or where explicitly allowed in
16.9 as an actual argument of an intrinsic procedure."  This change
enforces that constraint for output list items.

I also added a general interface to determine if an expression is a BOZ
literal constant and changed all of the places I could find where it
could be used.

I also added a test.

This change stemmed from the following issue --
  https://gitlab-master.nvidia.com/fortran/f18-stage/issues/108

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

…alar

result descriptor (e.g., maxloc, minloc, maxval, minval, all, any, count,
parity, findloc, etc.)

Also add a scalar case for these intrinsic unit tests.

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

accidentally used int64 when they should have been int32. This lead to
a Windows build unit test error (Linux did not catch the problem).

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

…build

to fail due to warnings as errors. Note that I could not reproduce the
problem locally, but based on the messages, I think this change will fix
the errors.

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

The result expression for the analysis of a Component is not (longer)
valid in the expression traversal framework used by IsSimplyContiguousHelper
now that it has a tri-state result.  Fix so that any result of
analyzing the component symbol is required to be true, not just
present.

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

Dummy procedures can be defined as subprograms with explicit
interfaces, e.g.

  subroutine subr(dummy)
    interface
      subroutine dummy(x)
        real :: x
      end subroutine
    end interface
    ! ...
  end subroutine

but the symbol table had no means of marking such symbols as dummy
arguments, so predicates like IsDummy(dummy) would fail.  Add an
isDummy_ flag to SubprogramNameDetails, analogous to the corresponding
flag in EntityDetails, and set/test it as needed.

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

This file was previously included transitively via `mlir/Transforms/Passes.h`, but the include has been removed from that file.

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

Add fir lowering for PACK intrinsic

Replace unneeded CHECK-DAG with CHECK in pack regression test.

Add fir lowering for PACK intrinsic

…pick-all-fe-changes

Cherry pick all changes in flang folder since last cherry-picking

Common blocks without explicit initialization are initialized with an
mlir::VectorType initializer, which must have a strictly positive size:

  real nada(1:0)
  common /empty/ nada

  fir.global common @_QBempty(dense<0> : vector<0xi8>) : !fir.array<0xi8>

  error: vector types must have positive constant sizes

An alternative is to instead initialize with a fir::SequenceType, but
that leads to a tco error:

  fir.global common @_QBempty : !fir.array<0xi8> {
    %0 = fir.undefined !fir.array<0xi8>
    fir.has_value %0 : !fir.array<0xi8>
  }

  'common' global must have a zero initializer!
  [0 x i8]* @_QBempty
  error: could not emit LLVM-IR

Work around these issues by forcing zero size common blocks to have one
byte:

  fir.global common @_QBempty(dense<0> : vector<1xi8>) : !fir.array<1xi8>

Note:  There is an additional front end bug where most zero size arrays
are incorrectly given non-zero size.  This additional bug needs to be
addressed to allow correct compilation of common blocks containing
those arrays.

Add a genDefaultInitializerValue method in variable lowering that
generates the body of the global op that must be default initialized.

Default initialized defers from explicit initialization because all the
component may not have an initialization, therefore the front-end is not
providing a top level ev::Expr that can be lowered for the derived type.

Hence, lowering visits each components and lower any default
initialization if present or leave the component undefined otherwise.

genDefaultInitializerValue is recursive because component without a
default initialization value can be of a derived type whose component
have default initialization.

Default initialization also applies to variable in equivalences. The
standard is not 100% clear about the possibility of mixing overlapping
default and explicit initialization. This PR support full overlaps (the
default initialization is completely overridden by explicit
initialization of other equivalence members), no overlap (the default
initialization is fully apply to the equivalence storage). It however
does not support mixing pieces of explicit initialization from other
equivalence members over part of the default initialization (the
situation is detected and a TODO emitted). Not all compilers support
this last case (nagfor, ifort and nvfortran support this, gfortran refuses it,
and xlf silently ignores the explicit initialization).

…-type-init-global-4

Lower default initialization of module and saved variables

Assumed-rank entities are not yet handled.

No runtime call was needed.  Also, all situations where the DIM argument
is not present are handled by the front end converting calls to SIZE
with values of the DIM argument that correspond to the rank of the ARRAY
argument.  Thus, if ARRAY has rank 1, a call to "SIZE(ARRAY)" is changed
to "SIZE(ARRAY, 1)".  If ARRAY has rank 2, the call is changed to the
expression "SIZE(ARRAY, 1) * SIZE(ARRAY, 2)".  Thus, the only thing I
needed to do was convert the value of the DIM argument to be 1-based and
make the appropriate call to BoxDimsOp.

I also added a test.

[flang] Implement lowering for the SIZE intrinsic

Scalars were args were lowered to value in elemental calls where they needed
to be passed by reference. Lower scalar to a reference when the elemental function
takes a reference. In case the elemental arg is passed by value, lower the arg by
value and store the value in a temp that is passed to the call.

This fixes the error "'llvm.call' op operand type mismatch for operand 1" in
nag_f08_95 l7.f90 (similar error remains coming from non elemental context in
some other tests)

It is not 100% clear to me that the by address case is OK from an aliasing point
of view (e.g. in `i = foo(j, i(10))` the current passing the raw address of i(10)
at every iteration).

Add an implementation for the runtime functions related to SYSTEM_CLOCK.
As with CPU_TIME, this is based on std::clock(), which should be
available everywhere, but it is highly recommended to add
platform-specific implementations for systems where std::clock() behaves
poorly (e.g. POSIX).

The documentation for std::clock() doesn't specify a maximum value and
in fact wrap around behaviour is non-conforming.  Therefore, this
implementation of SYSTEM_CLOCK is not guaranteed to wrap around either,
and after std::clock reaches its maximum value we will likely just
return failure rather than wrap around. If this happens often on your
system, please add a new platform-specific implementation.

We define COUNT_MAX as either the maximum value that can be stored in
a std::clock_t or in a 64-bit integer (whichever is smaller), and
COUNT_RATE as CLOCKS_PER_SEC. For POSIX systems, the value of
CLOCKS_PER_SEC is hardcoded to 10^6 and irrelevant for the values
returned by std::clock.

Reviewed By: jeanPerier

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

This is very similar to CPU_TIME, except that we return nanoseconds
rather than seconds. This means we're potentially dealing with rather
large numbers, so we'll have to wrap around to avoid overflows.

Reviewed By: jeanPerier

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

…mental-call-mismatch

Ensure scalar args are lowered to ref if needed in elemental calls

This also includes some renaming to keep implicit and explicit iteration
spaces more clearly distinct.

Implement FORALL with allocatables.

Fixes nag_f95_syntax 210a211 issue.
The ExtendedValue in genRecordAssignment can very well be fir::BoxValue.
Handle this case correctly.

…ick-system-clock

Cherry pick system clock implementation patch from phabricator

…wer bounds

When the upper bound is less than the lower bound, the extent is zero.  This is
specified in section 8.5.8.2, paragraph 3.

Note that similar problems exist in the lowering code.  This change only fixes
the problem for the front end.

I also added a test.

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

The front-end shape analysis can't be used in all cases.

Fixes assertion 'idx < size()' in tests.

- added basic implementation for lowering of the SCALE intrinsic
- added tests for lowering of SCALE intrinsic

Address review comments:

- change TODO to fir::emitFatalError
- simplify creation of arguments list using Fortran::lower::createArguments
- clang-format files

With the latest change to the front end, extent calculations are
constant folded which affects the expressions that get lowered.  This
means that the tests that contain the constant folded expressions need
to be updated.

…ick-extents

Ps cherry pick extents

SCALE instrinsic lowering

…a211

Support fir.box in genRecordAssignment

…seDetails

https://reviews.llvm.org/D105464 did not correctly cover the case
where the symbol from the host procedure is use associated. Outside
of the mis-parsed ArrayRef case, flang was also creating a symbol with
HostAssociated details inside the internal procedure (pointing to the
use associated symbol in the host). That is what lowering expects.
This patch ensures the same logic is applied in the mis-parsed array-ref name
resolution (and the pointer target name resolution).

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

When an internal procedure is defined inside a module procedure, it may
access the module variables. These access are not materialized by
associated symbols in the internal procedure scope, so lowering must
instantiate all the module variables before lowering the internal
procedure so that any reference to the module symbols can be resolved.

Also update the case where the internal procedure is not in a module
procedure but simply in a procedure that uses module variables. This
case compiled and worked, but the module variable was passed via the
host tuple when it can simply be instantiated directly from the module
address inside the internal procedure.

I found this file does not exist anymore in upstream fir-dev branch, so I will remove this file.

Ensure used module variables are mapped when lowering internal procedures.

…ering.

…project into fir-dev

…o fir-dev

std::clock_t can be an unsigned value on some platforms like MacOS and
therefore needs a cast when initializing an std::clock_t value with -1.

Reviewed By: klausler

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

Lowering of EXPONENT, FRACTION, SET_EXPONENT intrinsic

[Flang] Fix build failure on MacOS

[NFC] Remove unused warning

…lder.cpp

…teral-name-helper

[NFC] move LiteralNameHelper to remove front-end dependency in FIRBuilder

Like the similar legacy extension FLOAT(), DFLOAT() represents a
conversion from default integer to DOUBLE PRECISION.  Rewrite
into a conversion operation.

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

The algorithm for Fw.d output will drive binary to decimal conversion for
an initial fixed number of digits, then adjust that number based on the
result's exposent.  For value close to a power of ten, this adjustment
process wouldn't terminate; e.g., formatting 9.999 as F10.2 would start
with 1e2, boost the digits to 2, get 9.99e1, decrease the digits, and loop.
Solve by refusing to boost the digits a second time.

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

Define an API for, and implement, runtime support for arbitrary
assignment of one descriptor's data to another, with full support for
(re)allocation of allocatables with finalization when necessary,
user-defined derived type assignment TBP calls, and intrinsic (default)
componentwise assignment of derived type instances with allocation of
automatic components.  Also clean up API and implementation of
finalization/destruction using knowledge gained while studying
edge cases for assignment in the 2018 standard.

The look-up procedure for special procedure bindings in derived
types has been optimized from O(N) to O(1) since it will probably
matter more.  This required some analysis in runtime derived type
description table construction in semantics and some changes to the
table schemata.

Executable Fortran tests have been developed; they'll be added
to the test base once they can be lowered and run by f18.

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

Some build environments complain about unused data members in some
C++ translations of Fortran derived types; those members don't really
need to be present, so remove them.

Fix pushed w/o review to get build bots running again.

A repeated null value at the end of an input record with a count > 1
would incorrectly advance to the next record when resumed.  Fix.

Improve some poor naming and code flow noticed while debugging, so
next time will be easier.

Extend a unit test to check this case.

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

Recent work in runtime assignments failed an assertion in fir-dev
while running tests (flang/test/Semantics/defined-ops.f90).  This
test didn't fail in llvm-project/main because only the "new" Arm
driver is used now, and that only builds runtime derived type information
tables when some debug dumping options are enabled.

So add a reproducing test case to another test that is run with
-fdebug-dump-symbols, and fix the crash by emitting special procedure
binding information only for type-bound generic ASSIGNMENT(=) bindings
that are relevant to the runtime support library for use in intrinsic
assignment of derived types.

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

Flang uses positional arguments for `messages::say()`, such as "%1$s" which is only supported in MS Compilers with the `_*printf_p` form of the function. This uses a conditional macro to convert the existing `vsnprintf` used to the one needed in MS-World.

7 tests in D107575 rely on this change.

Reviewed By: Meinersbur

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

SET_EXPONENT is returning values that are too large by a factor
of two.

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