[flang] Accept L0 (#121998)

Accept a zero field width for formatted logical output (L0),
interpreting it as if it had been L1.

[flang][doc] refine zero initialization extension documentation (#121956)

Following-up on [comments
](https://github.com/llvm/llvm-project/issues/62432#issuecomment-2555316522)
in the issue that m

[flang][doc] refine zero initialization extension documentation (#121956)

Following-up on [comments
](https://github.com/llvm/llvm-project/issues/62432#issuecomment-2555316522)
in the issue that motivated this extension.

show more ...

[flang] Modifications to ieee_support_halting (#120747)

The F23 standard requires that a call to intrinsic module procedure
ieee_support_halting be foldable to a constant at compile time in some
c

[flang] Modifications to ieee_support_halting (#120747)

The F23 standard requires that a call to intrinsic module procedure
ieee_support_halting be foldable to a constant at compile time in some
contexts. See for example F23 Clause 10.1.11 [Specification expression]
list item (13), Clause 1.1.12 [Constant expression] list item (11), and
references to specification and constant expressions elsewhere, such as
constraints C1012, C853, and C704.

Some Arm processors allow a user to control processor behavior when an
arithmetic exception is signaled, and some Arm processors do not have
this capability. An Arm executable will run on either type of processor,
so it is effectively unknown at compile time whether or not this support
will be available at runtime. This in conflict with the standard
requirement.

This patch addresses this conflict by implementing ieee_support_halting
calls on Arm processors to check if this capability is present at
runtime. A call to ieee_support_halting in a constant context, such as
in the specification part of a program unit, will generate a compile
time "cannot be computed as a constant value" error. The expectation is
that such calls are unlikely to appear in production code.

Code generation for other processors will continue to generate a compile
time constant result for ieee_support_halting calls.

show more ...

[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] Extension: accept "var*length(bounds)" (#117399)

A character length specifier in an entity declaration or a component
declaration is required by the standard to follow any array bounds or

[flang] Extension: accept "var*length(bounds)" (#117399)

A character length specifier in an entity declaration or a component
declaration is required by the standard to follow any array bounds or
coarray bounds that are present. Several Fortran compilers allow the
character length specifier to follow the name and appear before the
bounds.

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

show more ...

[flang] Support "PRINT namelistname" (#112024)

Nearly every Fortran compiler supports "PRINT namelistname" as a synonym
for "WRITE (*, NML=namelistname)". Implement this extension via parse
tree r

[flang] Support "PRINT namelistname" (#112024)

Nearly every Fortran compiler supports "PRINT namelistname" as a synonym
for "WRITE (*, NML=namelistname)". Implement this extension via parse
tree rewriting.

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

show more ...

[flang] add nsw to operations in subscripts (#110060)

This patch adds nsw to operations when lowering subscripts.

See also the discussion in the following discourse post.
https://discourse.llvm.

[flang] add nsw to operations in subscripts (#110060)

This patch adds nsw to operations when lowering subscripts.

See also the discussion in the following discourse post.
https://discourse.llvm.org/t/rfc-add-nsw-flags-to-arithmetic-integer-operations-using-the-option-fno-wrapv/77584/9

show more ...

[flang] Accept initialized SAVE local in specification expression (#107656)

Specification expressions may contain references to dummy arguments,
host objects, module variables, and variables in COM

[flang] Accept initialized SAVE local in specification expression (#107656)

Specification expressions may contain references to dummy arguments,
host objects, module variables, and variables in COMMON blocks, since
they will have values on entry to the scope. A local variable with a
initializer and the SAVE attribute (which will always be implied by an
explicit initialization) will also always work, and is accepted by at
least one other compiler, so accept it with a warning.

show more ...

[flang] Relax error into a warning (#107489)

The standard requires that a generic interface with the same name as a
derived type contain only functions. We generally allow a generic
interface to c

[flang] Relax error into a warning (#107489)

The standard requires that a generic interface with the same name as a
derived type contain only functions. We generally allow a generic
interface to contain both functions and subroutines, since there's never
any ambiguity at the point of call; these is helpful when the specific
procedures of two generics are combined during USE association. Emit a
warning instead of a hard error when a generic interface with the same
name as a derived type contains a subroutine to improve portability of
code from compilers that don't check for this condition.

show more ...

[flang] Warn about automatic data in main program, disallow in BLOCK … (#102045)

…DATA

We allow automatic data objects in the specification part of the main
program; add an optional portability

[flang] Warn about automatic data in main program, disallow in BLOCK … (#102045)

…DATA

We allow automatic data objects in the specification part of the main
program; add an optional portability warning and documentation. Don't
allow them in BLOCK DATA. They're already disallowed as module
variables.

show more ...

[flang][NFC] Document an intentional violation of the standard (#99073)

The Fortran standard committees passed an "interp" request at their June
2024 meetings that is distinct from nearly every oth

[flang][NFC] Document an intentional violation of the standard (#99073)

The Fortran standard committees passed an "interp" request at their June
2024 meetings that is distinct from nearly every other Fortran compiler
that I tried (6) in an an ambiguous case (parent component naming when
the base type has been renamed via USE association). Document this case
in flang/docs/Extensions.md as an intentional instance of
non-conformance chosen for portability and better usability.

show more ...

[flang] Support BIND(C, NAME="...", CDEFINED) extension (#94402)

This CDEFINED keyword extension to a language-binding-spec signifies
that static storage for an interoperable variable will be alloc

[flang] Support BIND(C, NAME="...", CDEFINED) extension (#94402)

This CDEFINED keyword extension to a language-binding-spec signifies
that static storage for an interoperable variable will be allocated
outside of Fortran, probably by a C/C++ external object definition.

show more ...

[flang] Add warnings about undefinable actuals for ASYNCHRONOUS/VOLAT… (#93851)

…ILE dummies

There's language in the standard (F'2023 15.5.2.5 p21) disallowing an
actual argument with a vector s

[flang] Add warnings about undefinable actuals for ASYNCHRONOUS/VOLAT… (#93851)

…ILE dummies

There's language in the standard (F'2023 15.5.2.5 p21) disallowing an
actual argument with a vector subscript from associating with a dummy
argument with either the ASYNCHRONOUS or VOLATILE attributes. This is a
bug in the standard, as (1) these attributes are actually relevant only
over the scope of the called procedure, (2) they can be applied in
nested scopes (internal subprograms and BLOCK) within the called
procedure, and (3) can be implicit within the called procedure and its
nested scopes in the case of ASYNCHRONOUS as a side effect of using a
dummy argument in an asynchronous data transfer statement. So issue a
warning. This new warning about undefinable actual arguments being
associated with ASYNCHRONOUS and VOLATILE dummy arguments subsumes an
existing warning about passing a constant actual to a VOLATILE dummy.

Resolves https://github.com/llvm/llvm-project/issues/93600.

show more ...

[flang] Relax constraints on PURE/ELEMENTAL dummy arguments (#93748)

The standard requires that dummy arguments to PURE functions be
INTENT(IN) or VALUE, but PURE subroutines are allowed to have mo

[flang] Relax constraints on PURE/ELEMENTAL dummy arguments (#93748)

The standard requires that dummy arguments to PURE functions be
INTENT(IN) or VALUE, but PURE subroutines are allowed to have modifiable
dummy arguments. This makes it impossible to declare atomic operations
as PURE functions, which consequently makes such atomic operations
ineligible for use in parallel constructs and DO CONCURRENT.

This patch downgrades this error to a warning by default, which can be
seen with -pedantic & al. and remain an error with -Werror.

show more ...

[flang] Adjust "doubled operator" expression extension (#93353)

Most Fortran compilers accept "doubled operators" as a language
extension. This is the use of a unary '+' or '-' operator that is not

[flang] Adjust "doubled operator" expression extension (#93353)

Most Fortran compilers accept "doubled operators" as a language
extension. This is the use of a unary '+' or '-' operator that is not
the first unparenthesized operator in an expression, as in 'x*-y'.

This compiler has implemented this extension, but in a way that's
different from other compilers' behavior. I interpreted the unary
'+'/'-' as a unary operator in the sense of C/C++, giving it a higher
priority than any binary (dyadic) operator.

All other compilers with this extension, however, give a unary '+'/'-' a
lower precedence than exponentiation ('**'), a binary operator that
C/C++ lacks. And this interpretation makes more sense for Fortran,
anyway, where the standard conforming '-x**y' must mean '-(x**y)'
already.

This patch makes 'x*-y**z' parse as 'x*-(y**z)', not 'x*(-y)**z)', and
adds a test to ensure that it does.

show more ...

[flang] Extension: associating polymorphic pointer/allocatable actual… (#93211)

… with monomorphic dummy

The relevant standard requires (F'2023 15.5.2.6 p2) that when a pointer
or allocatable ac

[flang] Extension: associating polymorphic pointer/allocatable actual… (#93211)

… with monomorphic dummy

The relevant standard requires (F'2023 15.5.2.6 p2) that when a pointer
or allocatable actual argument is associated with an
identically-attributed dummy argument, either both are polymorphic or
neither is. We already relax this requirement in the case of an
INTENT(IN) dummy argument, since a change of type cannot occur. Further,
like other compilers do, we can also relax this requirement in the case
of a limited polymorphic actual argument being associated with a
monomorphic dummy, as our implementation always passes a reference to
the actual descriptor, where any change of type that occurs during the
call due to reallocation will be properly recorded.

show more ...

[flang] Accept interoperable types without BIND(C) (#91363)

A derived type that meets (most of) the requirements of an interoperable
type but doesn't actually have the BIND(C) attribute can be acce

[flang] Accept interoperable types without BIND(C) (#91363)

A derived type that meets (most of) the requirements of an interoperable
type but doesn't actually have the BIND(C) attribute can be accepted as
an interoperable type, with optional warnings.

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] Update Extensions.md for supported BIND(C) LOGICAL kind. (#88159)

Flang also supports non-scalar logical dummy argument with a different
KIND from C_BOOL to a bind(c) routine as well as a c

[Flang] Update Extensions.md for supported BIND(C) LOGICAL kind. (#88159)

Flang also supports non-scalar logical dummy argument with a different
KIND from C_BOOL to a bind(c) routine as well as a component in a
bind(c) derived type. Update the document.

```
subroutine sub(arg)
logical(4) :: arg(4)
end
```

```
type dt
logical(4) :: comp
end type
end
```

show more ...

[flang] Don't allow non-standard data conversions of potentially abse… (#87391)

…nt arguments

Arguments to the intrinsic functions MAX and MIN after the first two are
optional. When these actual

[flang] Don't allow non-standard data conversions of potentially abse… (#87391)

…nt arguments

Arguments to the intrinsic functions MAX and MIN after the first two are
optional. When these actual arguments might not be present at run time,
emit a compilation time error if they require data conversion (a
non-standard but nearly universal language extension); such a conversion
would crash if the argument was absent.

Other compilers either disallow data conversions entirely on MAX/MIN or
crash at run time if a converted argument is absent.

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

show more ...

[flang][NFC] document BOZ error in DIM, MOD, MODULO, and SIGN (#87779)

It is highly ambiguous to what type BOZ should be resolved in DIM, MOD,
MODULO, and SIGN intrinsic arguments. Some other compi

[flang][NFC] document BOZ error in DIM, MOD, MODULO, and SIGN (#87779)

It is highly ambiguous to what type BOZ should be resolved in DIM, MOD,
MODULO, and SIGN intrinsic arguments. Some other compilers accept them,
but none agree. See table below.

List them explicitly as non supported extensions (semantics already
reject them, this is an NFC).

Table listing the resolved types of the intrinsic results when there is
a BOZ argument:

| | gfortran | nvfortran | ifort | nagfor | xlf |
| ------------------- | -------- | --------- | ----- | ------ | ------ |
| DIM(INT4, BOZ) | INT16 | INT4 | INT8 | crash | INT4 |
| DIM(BOZ, REAL4) | error | INT8 | error | error | REAL4 |
| DIM(REAL4, BOZ) | error | REAL4 | error | error | REAL4 |
| DIM(BOZ, INT4) | INT16 | INT8 | INT8 | INT8 | INT4 |
| DIM(BOZ, BOZ) | INT16 | INT8 | INT8 | INT8 | REAL4 |
| MOD(INT4, BOZ) | INT16 | INT4 | INT8 | crash | INT4 |
| MOD(BOZ, REAL4) | error | INT8 | error | error | REAL4 |
| MOD(REAL4, BOZ) | error | REAL4 | error | error | REAL4 |
| MOD(BOZ, INT4) | INT16 | INT8 | INT8 | INT8 | INT4 |
| MOD(BOZ, BOZ) | INT16 | INT8 | INT8 | INT8 | INT4 |
| MODULO(INT4, BOZ) | INT16 | INT4 | INT8 | crash | INT4 |
| MODULO(BOZ, REAL4) | error | INT8 | error | error | REAL4 |
| MODULO(REAL4, BOZ) | error | REAL4 | error | error | REAL4 |
| MODULO(BOZ, INT4) | INT16 | INT8 | INT8 | INT8 | INT4 |
| MODULO(BOZ, BOZ) | INT16 | INT8 | INT8 | INT8 | INT8 |
| SIGN(INT4, BOZ) | error | INT4 | INT8 | INT4 | INT4 |
| SIGN(BOZ, REAL4) | error | INT8 | error | error | REAL4 |
| SIGN(REAL4, BOZ) | error | REAL4 | error | error | REAL4 |
| SIGN(BOZ, INT4) | error | INT8 | INT8 | INT8 | INT4 |
| SIGN(BOZ, BOZ) | INT16 | INT8 | INT8 | INT8 | REAL4 |

show more ...

[flang] Deallocate structure constructor allocatable components (#83824)

Allocatable components of structure constructors were not deallocated.
Deallocate them without calling final subroutines.
T

[flang] Deallocate structure constructor allocatable components (#83824)

Allocatable components of structure constructors were not deallocated.
Deallocate them without calling final subroutines.
This was already properly done for array constructors.

show more ...

[flang] Support INDEX as a procedure interface (#83073)

The specific intrinsic function INDEX should work as a PROCEDURE
interface in the declaration of a procedure pointer or dummy procedure,
and

[flang] Support INDEX as a procedure interface (#83073)

The specific intrinsic function INDEX should work as a PROCEDURE
interface in the declaration of a procedure pointer or dummy procedure,
and it should be compatible with a user-defined interface.

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

show more ...

[flang] Handle implied ASYNCHRONOUS attribute (#82638)

The standard states that data objects involved in an asynchronous data
transfer statement gain the ASYNCHRONOUS attribute implicitly in the
s

[flang] Handle implied ASYNCHRONOUS attribute (#82638)

The standard states that data objects involved in an asynchronous data
transfer statement gain the ASYNCHRONOUS attribute implicitly in the
surrounding subprogram or BLOCK scope. This attribute affects the checks
in call semantics, as an ASYNCHRONOUS actual object associated with an
ASYNCHRONOUS dummy argument must not require data copies in or out.

(Most compilers don't implement implied ASYNCHRONOUS attributes
correctly; XLF gets these right, and GNU is close.)

show more ...

[flang] Turn "error" cases into warning for "indistinguishable" specific procedures (#79621)

When a generic procedure interface, either declared or the result of
merging two use-associated gene

[flang] Turn "error" cases into warning for "indistinguishable" specific procedures (#79621)

When a generic procedure interface, either declared or the result of
merging two use-associated generics, has two specific procedures
that are not distinguishable according to the rules in F'2023
subclause 15.4.3.4.5, emit a portability warning rather than a
hard error message. The rules in that subclause are not adequate
to detect pairs of specific procedures that admit an ambiguous
reference, as demonstrated by a case that arose in pFUnit. Further,
these distinguishability checks, even if sufficient to the task
of detecting pairs of specifics capable of ambiguous references,
should only apply to pairs where *every* reference would have to
be ambiguous -- and this can and is validated at every reference
anyway. Last, only XLF enforces these incomplete and needless
distinguishability rules -- every other compiler seems to just
check that each procedure reference resolves to exactly one
specific procedure.

If the standard were to complete lose subclause 15.4.3.4.5 and
its related note (C.11.6) -- which admits that the rules are
incomplete! -- and simply require that each generic procedure
reference resolve unambiguously to exactly one specific, nobody
would miss them. This patch changes this compiler to give them
lip service when requested, but they are now otherwise ignored.

show more ...