[flang] Add UNSIGNED (#113504)

Implement the UNSIGNED extension type and operations under control of a
language feature flag (-funsigned).

This is nearly identical to the UNSIGNED feature that h

[flang] Add UNSIGNED (#113504)

Implement the UNSIGNED extension type and operations under control of a
language feature flag (-funsigned).

This is nearly identical to the UNSIGNED feature that has been available
in Sun Fortran for years, and now implemented in GNU Fortran for
gfortran 15, and proposed for ISO standardization in J3/24-116.txt.

See the new documentation for details; but in short, this is C's
unsigned type, with guaranteed modular arithmetic for +, -, and *, and
the related transformational intrinsic functions SUM & al.

show more ...

[flang] Tidy uses of raw_string_ostream (NFC)

As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly

( 65b13610a5226b84889b923bae884b

[flang] Tidy uses of raw_string_ostream (NFC)

As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly

( 65b13610a5226b84889b923bae884ba395ad084d for further reference )

Avoid unneeded calls to raw_string_ostream::str(), to avoid excess indirection.

show more ...

[flang] Better renaming in module files (#93106)

When a symbol from one module is used in another without an explicit USE
association, the module file output code may need to use another name
for

[flang] Better renaming in module files (#93106)

When a symbol from one module is used in another without an explicit USE
association, the module file output code may need to use another name
for it -- either with a name that is already available via USE
association with renaming, or by means of a new private USE association,
possibly with renaming to avoid a clash.

Module file output was dealing properly with names of derived types, but
wasn't accounting for symbols that appear in expressions other than
initializations. This was specifically a problem with an application
module that had a call to a NOPASS type-bound procedure in an array
bound specification expression, which semantics had resolved to the name
of a private module function.

This patch implements renaming, when necessary, for all symbols
appearing in expressions and type names, and replaces the previous
implementation of derived type renaming. It also gets a little smarter
about avoiding the creation of compiler-generated names when a name from
another module has been brought into scope already by means of USE
association with renaming.

show more ...

[flang] Don't crash on bad inherited implied DO type (#91073)

Fortran has an ambiguously defined rule about the typing of index
variables of implied DO loops in DATA statements and array constructo

[flang] Don't crash on bad inherited implied DO type (#91073)

Fortran has an ambiguously defined rule about the typing of index
variables of implied DO loops in DATA statements and array constructors
that omit an explicit type specification. Such indices have the type
that they would have "if they were variables" in the innermost enclosing
scope. Although this could, and perhaps should, be read to mean that
implicit typing rules active in that innermost enclosing scope should be
applied, every other Fortran compiler interprets that language to mean
that if there is a type declaration for that name that is visible from
the enclosing scope, it is applied, and it is an error if that type is
not integer.

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

show more ...

[flang] Fix mod file generation of derived type initializers... (#70511)

... when the derived type used in the structure constructor(s) is from
another module and not use-associated into the curren

[flang] Fix mod file generation of derived type initializers... (#70511)

... when the derived type used in the structure constructor(s) is from
another module and not use-associated into the current module.

This came up in a test with a derived type component default initializer
of "c_null_ptr", which is replaced with the expression
"__builtin_c_ptr(address=0_8)"; the derived type name "__builtin_c_ptr"
is not available in the current scope, and the module file would fail
semantic analysis when USE'd.

The best solution that I found was to extend module file generation to
detect this case and handle it by inserting the right USE association to
the ultimate derived type symbol, possibly with renaming to a
compiler-created name in the case of a conflict.

To implement this transformation, it was necessary to fix the utility
evaluate::CollectSymbols() to include the derived type symbol from a
structure constructor. This involved extending the expression traversal
framework to visit the derived type spec of a structure constructor.
Extending CollectSymbols() caused a lowering test to fail mysteriously,
so I tracked down the code in PFTBuilder that didn't expect to see a
DerivedTypeDetails symbol and dealt with it there.

show more ...

[flang] Implement legacy %VAL and %REF actual arguments (#70343)

Update evaluate::ActualArgument to propagate the %VAL and %REF markers
until lowering.
Semantic checks are added to %VAL to ensure

[flang] Implement legacy %VAL and %REF actual arguments (#70343)

Update evaluate::ActualArgument to propagate the %VAL and %REF markers
until lowering.
Semantic checks are added to %VAL to ensure the argument is a numerical
or logical scalar.

I did not push these markers into the characteristics because other
compilers do not complain about inconsistent usages (e.g. using %VAL in
a call on a procedure with an interface without VALUE dummies is not
flagged by any compilers I tested, and it is not an issue for lowering,
so I decided to stay simple here and minimize the footprint of these
legacy features).

Lowering retrieves these markers and does the right thing: pass %VAL in
registers and pass %REF by address without adding any extra arguments
for characters.

show more ...

[flang] Don't emit debugging output to module file

When a constant array value has a non-default lower bound, the current
expression formatting code uses a non-Fortran syntax to dump the lower
bound

[flang] Don't emit debugging output to module file

When a constant array value has a non-default lower bound, the current
expression formatting code uses a non-Fortran syntax to dump the lower
bounds. (There's no way in Fortran to explicitly specify such a constant value,
but they can be created through the use of named constants.) But we
don't want this lower bounds syntax from expression dumping to show up
in module files, since it can't be parsed back in. So disable that
part of expression formatting by default.

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

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

show more ...

[flang] Correct handling of non-default lower bounds in ASSOCIATE with named constants

Work through several issues with LBOUND() and UBOUND() of ASSOCIATE
construct entities that have been associate

[flang] Correct handling of non-default lower bounds in ASSOCIATE with named constants

Work through several issues with LBOUND() and UBOUND() of ASSOCIATE
construct entities that have been associated with named constants or
subobjects of named constants that are sporting non-default lower bounds.
Sometimes the non-default lower bounds matter, sometimes they don't.
Add a fairly exhaustive test to work through the possibilities.

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

show more ...

[flang] CUDA Fortran - part 4/5: definability and characteristics

Extend the definability and procedure characteristics checking
infrastructure in semantics to check for context-dependent CUDA objec

[flang] CUDA Fortran - part 4/5: definability and characteristics

Extend the definability and procedure characteristics checking
infrastructure in semantics to check for context-dependent CUDA object
definability violations and problems with CUDA attribute incompatibility
in procedure interfaces.

Depends on https://reviews.llvm.org/D150159,
https://reviews.llvm.org/D150161, & https://reviews.llvm.org/D150162.

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

show more ...

[flang] Correct procedure pointer (or dummy) compatibility check

Fix a subtle bug in procedure compatibility checking with base
derived types vs. their extensions to ensure that a procedure
expectin

[flang] Correct procedure pointer (or dummy) compatibility check

Fix a subtle bug in procedure compatibility checking with base
derived types vs. their extensions to ensure that a procedure
expecting an extended type cannot be associated with a pointer
(or dummy procedure) to a procedure expecting a base type.

subroutine s1(base); ... subroutine s2(extended)
procedure(s1), pointer :: p
p => s2 ! <- must be caught as an error

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

show more ...

[flang] Accommodate unknowable CHARACTER length in evaluate::ArrayConstructor<>

The internal representation for array constructors in expressions during semantic
analysis needs to be able to accommo

[flang] Accommodate unknowable CHARACTER length in evaluate::ArrayConstructor<>

The internal representation for array constructors in expressions during semantic
analysis needs to be able to accommodate circumstances (e.g. TRIM(), substrings)
in which the length of the elements in the array is either unknown or cannot be
represented as a context-free integer expression.

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

show more ...

[flang] Add & use a better visit() (take 2)

Adds flang/include/flang/Common/log2-visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit().

[flang] Add & use a better visit() (take 2)

Adds flang/include/flang/Common/log2-visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().

The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.

Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().

Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.

This change is enabled only for GCC builds with GCC >= 9;
an earlier attempt (D122441) ran into bugs in some versions of
clang and was reverted rather than simply disabled; and it is
not well tested with MSVC. In non-GCC and older GCC builds,
common::visit() is simply an alias for std::visit().

show more ...

Revert "[flang] Add & use a better visit()"

This reverts commit 2ab9990c9eb79682a4d4b183dfbc7612d3e55328. It has
caused multiple build failures:
* https://lab.llvm.org/buildbot/#/builders/177/build

Revert "[flang] Add & use a better visit()"

This reverts commit 2ab9990c9eb79682a4d4b183dfbc7612d3e55328. It has
caused multiple build failures:
* https://lab.llvm.org/buildbot/#/builders/177/builds/4346
* https://lab.llvm.org/buildbot/#/builders/180/builds/3803
* https://lab.llvm.org/buildbot/#/builders/175/builds/10419
* https://lab.llvm.org/buildbot/#/builders/191/builds/4318
* https://lab.llvm.org/buildbot/#/builders/173/builds/4274
* https://lab.llvm.org/buildbot/#/builders/181/builds/4297

All these bots failed with a time-out:
```
command timed out: 1200 seconds without output running [b'ninja', b'-j', b'32'], attempting to kill
```
I'm guessing that that's due to template instantiations failing at some
point (https://reviews.llvm.org/D122441 introduced a custom
implementation of std::visit). Everything seems fine when either:
* building on X86 with GCC or Clang (tested with GCC 9.3 and Clang 12)
* building on AArch64 with GCC (tested with GCC 11)

show more ...

[flang] Add & use a better visit()

Adds flang/include/flang/Common/visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most

[flang] Add & use a better visit()

Adds flang/include/flang/Common/visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit(). Modifies most use sites in
the front-end and runtime to use common::visit().

The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.

Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().

Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.

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

show more ...

[flang] Fix LBOUND rewrite on descriptor components

GetLowerBoundHelper rewrite in https://reviews.llvm.org/D121488 was
incorrect with POINTER/ALLOCATABLE components. The rewrite created a
descripto

[flang] Fix LBOUND rewrite on descriptor components

GetLowerBoundHelper rewrite in https://reviews.llvm.org/D121488 was
incorrect with POINTER/ALLOCATABLE components. The rewrite created a
descriptor inquiry to the component symbol only instead of the whole
named entity. The base information was lost, and not retrievable.
LBOUND(a(10)%p) became LBOUND(p).

Fix this regression, and also update DescriptorInquiry unparsing to
carry the kind information. DescriptorInquiries are KIND 8 expressions,
while LBOUND/SIZE/RANK, %LEN are default kind expressions.
This caused `print *,lbound(x,kind=8)` to unparse as `print*,lbound(x)` which is not
semantically the same (this unparsing issue was not an issue for
lowering, but I noticed it while writing my regression test).

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

show more ...

[flang] Fold SCALE()

Fold references to the intrinsic function SCALE().

(Also work around some MSVC headaches somehow exposed by
this patch: disable a bogus MSVC warning that began to appear
in unr

[flang] Fold SCALE()

Fold references to the intrinsic function SCALE().

(Also work around some MSVC headaches somehow exposed by
this patch: disable a bogus MSVC warning that began to appear
in unrelated source files, and avoid the otherwise-necessary
use of the "template" keyword in a call to a template member
function of a class template.)

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

show more ...

[flang] Extension: initialization of LOGICAL with INTEGER & vice versa

We already accept assignments of INTEGER to LOGICAL (& vice versa)
as an extension, but not initialization. Extend initializat

[flang] Extension: initialization of LOGICAL with INTEGER & vice versa

We already accept assignments of INTEGER to LOGICAL (& vice versa)
as an extension, but not initialization. Extend initialization
to cover those cases.

(Also fix misspelling in nearby comment as suggested by code reviewer.)

Decouple an inadvertent dependence cycle by moving two
one-line function definitions into a header file.

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

show more ...

[flang] Validate SIZE(x,DIM=n) dimension for assumed-size array x

Catch invalid attempts to extract the unknowable extent of the last
dimension of an assumed-size array dummy argument, and clean up

[flang] Validate SIZE(x,DIM=n) dimension for assumed-size array x

Catch invalid attempts to extract the unknowable extent of the last
dimension of an assumed-size array dummy argument, and clean up
problems with assumed-rank arguments in similar circumstances
exposed by testing the fix.

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

show more ...

[flang] [NFC] Repair build with GCC 7.3

Work around two problems with GCC 7.3.
One is its inability to implement "constexpr operator=(...) = default;"
in a class with a std::optional<> component; an

[flang] [NFC] Repair build with GCC 7.3

Work around two problems with GCC 7.3.
One is its inability to implement "constexpr operator=(...) = default;"
in a class with a std::optional<> component; another is a legitimate-
looking warning about an unused variable.

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

show more ...

[flang] Support known constant lengths in DynamicType

The constexpr-capable class evaluate::DynamicType represented
CHARACTER length only with a nullable pointer into the declared
parameters of type

[flang] Support known constant lengths in DynamicType

The constexpr-capable class evaluate::DynamicType represented
CHARACTER length only with a nullable pointer into the declared
parameters of types in the symbol table, which works fine for
anything with a declaration but turns out to not suffice to
describe the results of the ACHAR() and CHAR() intrinsic
functions. So extend DynamicType to also accommodate known
constant CHARACTER lengths, too; use them for ACHAR & CHAR;
clean up several use sites and fix regressions found in test.

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

show more ...

[flang] Improve constant folding for type parameter inquiries

We were not folding type parameter inquiries for the form 'var%typeParam'
where 'typeParam' was a KIND or LEN type parameter of a derive

[flang] Improve constant folding for type parameter inquiries

We were not folding type parameter inquiries for the form 'var%typeParam'
where 'typeParam' was a KIND or LEN type parameter of a derived type and 'var'
was a designator of the derived type. I fixed this by adding code to the
function 'FoldOperation()' for 'TypeParamInquiry's to handle this case. I also
cleaned up the code for the case where there is no designator.

In order to make the error messages correctly refer to both the points of
declaration and instantiation, I needed to add an argument to the function
'InstantiateIntrinsicType()' for the location of the instantiation.

I also changed the formatting of 'TypeParamInquiry' to correctly format this
case. I also added tests for both KIND and LEN type parameter inquiries in
resolve104.f90.

Making these changes revealed an error in resolve89.f90 and caused one of the
error messages in assign04.f90 to be different.

Reviewed By: klausler

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

show more ...

Revert "[flang] Improve constant folding for type parameter inquiries"

This reverts commit 8c7bf2f93da9b64b07509f67552d592a86260ff5.

[flang] Improve constant folding for type parameter inquiries

We were not folding type parameter inquiries for the form 'var%typeParam'
where 'typeParam' was a KIND or LEN type parameter of a derive

[flang] Improve constant folding for type parameter inquiries

We were not folding type parameter inquiries for the form 'var%typeParam'
where 'typeParam' was a KIND or LEN type parameter of a derived type and 'var'
was a designator of the derived type. I fixed this by adding code to the
function 'FoldOperation()' for 'TypeParamInquiry's to handle this case. I also
cleaned up the code for the case where there is no designator.

In order to make the error messages correctly refer to both the points of
declaration and instantiation, I needed to add an argument to the function
'InstantiateIntrinsicType()' for the location of the instantiation.

I also changed the formatting of 'TypeParamInquiry' to correctly format this
case. I also added tests for both KIND and LEN type parameter inquiries in
resolve104.f90.

Making these changes revealed an error in resolve89.f90 and caused one of the
error messages in assign04.f90 to be different.

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

show more ...

[flang] Fix bogus message on internal subprogram with alternate return

Internal subprograms have explicit interfaces. If an internal subprogram has
an alternate return, we check its explicit interf

[flang] Fix bogus message on internal subprogram with alternate return

Internal subprograms have explicit interfaces. If an internal subprogram has
an alternate return, we check its explicit interface. But we were not
putting the label values of alternate returns into the actual argument.

I fixed this by changing the definition of actual arguments to be able
to contain a common::Label and putting the label for an alternate return
into the actual argument.

I also verified that we were already doing all of the semantic checking
required for alternate returns and removed a "TODO" for this.

I also added the test altreturn06.f90.

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

show more ...

[flang] Unsplit COMPLEX operations

COMPLEX negation, addition, subtraction, conversions of kind, and
equality/inequality were represented as component-wise REAL
operations. It turns out to be easie

[flang] Unsplit COMPLEX operations

COMPLEX negation, addition, subtraction, conversions of kind, and
equality/inequality were represented as component-wise REAL
operations. It turns out to be easier for lowering if we
do not split and recombine these COMPLEX operations, and it
avoids a potential problem with COMPLEX valued function calls
in these contexts. So add this suite of operations to the
typed expression representation in place of the component-wise
transformations, and support them in folding.

Differential revision: https://reviews.llvm.org/D91443

show more ...