Fortran free form line continuation with '&' works with this compiler
even across the end of an included source file, as it does with most
other Fortran compilers. This extension should be documented.
A NULL() pointer without MOLD= cannot be allowed to be associated with
an assumed-rank dummy argument, as its rank is not well-defined and
neither the RANK() intrinsic function or the SELECT RANK construct will
work in the callee.
As an extension, accept the redundant use of the CONTIGUOUS attribute
when applied to scalars and to simply contiguous objects, with a
portability warning.
As is already supported as a common extension for intrinsic functions
like DIM, allow distinct kinds of integer actual arguments to the
MIL-STD bit intrinsic functions IAND, IEOR, and IOR, with the kind of
the result being the largest of the kinds of the operands. (Though one
could make a case that IAND should return the smallest kind of its
operands, that's not what other compilers do.)
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.
Follow up up of https://github.com/llvm/llvm-project/pull/67693
- Zero initialize uninitialized components of saved derived type entity
with a default initial value.
- Zero initialize uninitialized storage of common blocks with a member
with an initial value.
- Zero initialized uninitialized saved equivalence
This removes all the cases where fir.global are created with an initial
value that results in an undef in LLVM for part of the global, leading
in surprising LLVM optimizations at -O2 for Fortran folks that expects
there saved variables to be zero initialized if there is no explicit or
default initial value.
This is not standard but is vastly expected by existing code.
This was implemented by https://reviews.llvm.org/D149877 for simple
scalars, but MLIR lacked a generic way to deal with aggregate types
(arrays and derived type).
Support was recently added in
https://github.com/llvm/llvm-project/pull/65508. Leverage it to zero
initialize all types.
…mmy argument
Several compilers accept a null pointer (with or without a MOLD=) as an
actual argument for association with an INTENT(IN) allocatable dummy
argument. At runtime, the allocatable dummy argument appears to be in
the unallocated state. This seems useful, unambiguous, unlikely to
invalidate conforming code, and works with Intel, NAG, & XLF, so it
should be supported with an optional portability warning in this
compiler as well.
The Fortran standards require (F'2023 C745) that a derived type with the
SEQUENCE attribute have at least one component. No Fortran compiler
actually enforces this constraint. Accept this usage with a warning.
At least one other Fortran compiler supports the use of unrestricted intrinsic
functions as specific procedures in generic interfaces, and the usage seems
to be both useful and unambiguous. Support it with a portability warning.
Fixes llvm-test-suite/Fortran/gfortran/regression/pr95500.f90.
Differential Revision: https://reviews.llvm.org/D157333
A quotation mark can appear in a Fortran character literal by doubling
it; for example, PRINT *, "'""'" prints '"'. When those doubled
quotation marks are split by a free form line continuation, the
continuation line should have an ampersand before the second quotation
mark. But most compilers, including this one, allow the second
quotation mark to appear as the first character on the continuation
line, too.
So this works:
print *, "'"&
"'"
but it really should be written as:
print *, "'"&
&"'"
Emit a portability warning and document that we support this near-universal
extension.
Differential Revision: https://reviews.llvm.org/D155973
This implements the tand intrinsic by performing a multiplication
by pi/180 to the argument before calling tan inline.
This is a commonly provided extension that is used by OpenRadioss
Differential Revision: https://reviews.llvm.org/D154614
Fix some problems with INCLUDE line recognition pointed out by some
recently-added tests to the LLVM test suite.
Differential Revision: https://reviews.llvm.org/D155497
It is not standard conforming under IMPLICIT NONE(TYPE) for a name to
appear in a DATA statement prior to its explicit type declaration,
but it is benign, supported in other compilers, and attested in real
applications. Support it with an optional portability warning.
Fixes GitHub LLVM bug https://github.com/llvm/llvm-project/issues/63783.
OPEN statements can be used to change some, but not all, attributes
of units that have already been opened. The I/O runtime library
wasn't allowing ENCODING= to be changed. Every other Fortran compiler
permits this usage, and it's safe and useful, so allow it.
(Otherwise there's no good way to ensure that the preconnected
unit 6 is in UTF-8 mode.)
Differential Revision: https://reviews.llvm.org/D154379
We intentionally process NAMELIST groups in a scope after having
resolved all of the names in that scope. This means that a name
whose first appearance in a scope is in the NAMELIST group resolves
to a local object, if any, rather than to any host associated object.
The standard is unclear on this point, and there is no clear
precedent in other compilers.
This patch doesn't implement this choice -- that was done long ago --
but just documents the behavior in Extensions.md.
Differential Revision: https://reviews.llvm.org/D154375
Apply the default PUBLIC/PRIVATE accessibility of a module to its symbols
a second time after it is known that all symbols, including implicitly typed
names from NAMELIST groups and specification expressions in module subprograms,
have been created in its scope.
Fixes https://github.com/llvm/llvm-project/issues/62598.
Differential Revision: https://reviews.llvm.org/D150307
Instead of filling uninitialized global variables with "undef",
initialize them with 0. Only for Integer, Float or Logical type
variables. Complex, user defined data structures, arrays, etc
are not supported at this point.
This patch fixes the main problem of
https://github.com/llvm/llvm-project/issues/62432
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D149877
The extents, if any, of the HARVEST= actual argument must be known
at execution time for the call to be implemented.
Differential Revision: https://reviews.llvm.org/D147391
When the same name is pulled into a scope more than once via
USE and IMPORT, emit an error if its resolutions are ambiguous,
or (as an extension like some other compilers) emit a portability
warning when the names all resolve to the same symbol.
Differential Revision: https://reviews.llvm.org/D147388
Add an entry to the Extensions document describing how we
don't care about conflicts between module names and non-global
items. (This is a case where it would be a nontrivial amount
of work to catch an "error" that is only a standard conformance
issue, not anything that would prevent a program from working.)
Differential Revision: https://reviews.llvm.org/D147387
Flang was missing value normalization for logical<->integer conversions
which is required by Flang specification. The shrinking logical<->logical
conversions were also incorrectly truncating the input.
This change performs value normalization for all logical<->integer
conversions and logical<->logical conversions between different kinds.
Note that value normalization is not strictly required for
logical(kind=k1)->logical(kind=k2) conversions when k1 < k2.
Differential Revision: https://reviews.llvm.org/D147019
Presently, semantics doesn't check for discrepancies between known
constant corresponding LEN type parameters between the declared type
of an allocatable/pointer and either the type-spec or the SOURCE=/MOLD=
on an ALLOCATE statement.
This allows discrepancies between character lengths to go unchecked.
Some compilers accept mismatched character lengths on SOURCE=/MOLD=
and the allocate object, and that's useful and unambiguous feature
that already works in f18 via truncation or padding. A portability
warning should issue, however.
But for mismatched character lengths between an allocate object and
an explicit type-spec, and for any mismatch between derived type
LEN type parameters, an error is appropriate.
Differential Revision: https://reviews.llvm.org/D146583
Constraint C1406 in Fortran 2018 prohibits the USE of the same module
name as both an intrinsic module and a non-intrinsic module in a scope.
The current check misinterprets the constraint as applying only to
explicitly INTRINSIC or NON_INTRINSIC module natures.
Change the check to also apply to non-explicit module natures, and
also downgrade it to a portability warning, since there is no ambiguity
and I suspect that we need to accept this usage when building f18's
own intrinsic modules.
Differential Revision: https://reviews.llvm.org/D146576
Some Fortran compilers allow kinds of LOGICAL other than C_BOOL
for the types of dummy arguments to interoperable (BIND(C))
procedures. As any kind of LOGICAL can be converted to any
other without loss of information, this seems to be a useful
unambiguous extension that is attested in real codes; accept it
for scalars with a portability warning.
Differential Revision: https://reviews.llvm.org/D145968
Declaration checking in semantics was only examining symbols with
explicit BIND(C) attributes; extend it to also check dummy arguments
to such procedures.
Differential Revision: https://reviews.llvm.org/D145746
As a near-universal extension, Fortran compilers permit forward references
to dummy arguments and variables in COMMON blocks from specification expressions
before an explicit type-declaration-stmt appears for those variables
under IMPLICIT NONE, so long as those variables are later explicitly typed
with the types that regular implicit typing rules would have given them
(usually default INTEGER).
F18 implemented this extension for dummy arguments, but not variables in
COMMON blocks. Extend the extension to also accept variables in COMMON.
Differential Revision: https://reviews.llvm.org/D145743
The Fortran 2018 standard, perhaps as an attempt to prevent ambiguity
in older compilers, requires that a statement function appear in an
explicit type declaration statement if its name is also accessible
from a host scope. F18 processes the specification parts of inner
procedures first, so we don't need this requirement to prevent
ambiguity, and can only really check it retrospectively after name
resolution. Emit a portability warning when appropriate.
Differential Revision: https://reviews.llvm.org/D145100
f18 accepts statement labels in fixed form source even if they follow
a semicolon -- i.e., they're not in the fixed form's label field.
Emit a warning for such usage.
Differential Revision: https://reviews.llvm.org/D143817
When a USE of a module precedes its definition in the same source
file, ensure that the module is processed by name resolution before
the USE statement. This prevents the risk of the USE statement using
an obsolete module file that is later overwritten during the same
compilation.
Differential Revision: https://reviews.llvm.org/D143799
f18 implements BLOCK scoping for construct names, like most but not all Fortran
compilers, but in the 2018 standard such names are defined to be local identifiers
whose scope is the inclusive scope -- i.e., the subprogram or main program.
Detect usage that depends on this extension and emit a portability warning.
Differential Revision: https://reviews.llvm.org/D143776
The standard's specification for the ASSOCIATED() intrinsic function
describes its optional second argument (TARGET=) as being required
to be a valid target for a pointer assignment statement in which the
first argument (POINTER=) was the left-hand side. Some Fortran compilers
apparently interpret this text as a requirement that the POINTER= argument
actually be a valid left-hand side to a pointer assignment statement,
and emit an error if it is not so. This particularly affects the
use of an explicit NULL pointer as the first argument.
Such usage is well-defined, benign, useful, and supported by at least
two other compilers, so we should continue to accept it. This patch
adds a portability warning and some documentation.
In order to implement the portability warning in the best way, the
special checks on calls to the ASSOCIATED() intrinsic function have
been moved from intrinsic processing to Semantics/check-calls.cpp,
whence they have access to semantics' toolchest. Special checks for
other intrinsic functions might also migrate in the future in order
to keep them all in one place.
Differential Revision: https://reviews.llvm.org/D142768
Constraint C1529 requires that the base object of a type-bound procedure
reference be a scalar if the TBP has the NOPASS attribute. Most
compilers do not enforce this constraint and it does not appear to
have any implementation justification, so emit portability warning.
On the other hand, we fail to enforce C919 for references to
procedure pointer components, whose base objects must of course
be scalars in order to avoid ambiguity and empty arrays, whether
NOPASS is present or not.
Differential Revision: https://reviews.llvm.org/D140148
Most attributes apply to only object or only procedure entities,
and attempts to apply them to other kinds of symbol table entries
are caught in name resolution when ConvertToObjectEntity() or
ConvertToProcEntity() fails. However, the POINTER attribute can
be applied to both, and name resolution can't perform that conversion
yet, and as a result we don't catch many kinds of silly errors.
Fix by ensuring that the symbol is of a type that could eventually
become an object or procedure entity if it is not one already.
Differential Revision: https://reviews.llvm.org/D140137
Modules, submodules, main programs, and BLOCK DATA subprograms have names
that cannot be used within their scope, so we allow those names to be
used for other entities in the scope. This might not be entirely
conformant with the language standard, so warn about it.
Differential Revision: https://reviews.llvm.org/D139146
Standard Fortran allows type-bound procedure bindings to only
be called, and disallows them from being used in other contexts
where a procedure name can be: as the target of a procedure pointer
assignment statement, and as an actual argument that corresponds
to a dummy procedure. So long as the interfaces match, there's
no good reason for these uses to be errors, and there some obvious
use cases in polymorphic programming. So emit portability warnings
rather than errors, and document this usage as an extension.
Differential Revision: https://reviews.llvm.org/D139127
In a derived type definition, a type bound procedure declaration
statement with neither interface nor attributes is required by constraint
C768 to have the optional "::" between the PROCEDURE keyword and the
bindings if any binding has a renaming with "=>". The colons are
not actually necessary for a correct and unambiguous parse, so
emit a warning when they are missing.
Differential Revision: https://reviews.llvm.org/D139065
When checking the specific procedures of a generic interface for a
match against a given set of actual arguments, be sure to not match
a function against a subroutine call or vice versa. (We generally
catch and warn about attempts to declare mixed interfaces, but they
are usually conforming and can be inadvertently created when generics
are merged due to USE and host association.)
Differential Revision: https://reviews.llvm.org/D139059
f18 doesn't have any limit on continuation lines in fixed or free form
source (other than available memory), but the standard does. Emit
a portability warning when it is exceeded.
Differential Revision: https://reviews.llvm.org/D139055
The standard does *not* require that a real or imaginary part of a complex
literal constant be a scalar if it is a named constant. Downgrade a
recently installed check to a portability warning, and document it.
Differential Revision: https://reviews.llvm.org/D139046
We implemented 19.3.4p1 literally in name resolution:
A component name has the scope of its derived-type definition. Outside the type definition,
it may also appear within a designator of a component of a structure of that type or as a
component keyword in a structure constructor for that type.
and within the derived-type definition would resolve the "bare"
names of components in specification inquiries and other contexts to
those components, not to any symbols in the enclosing scopes.
It turns out that most Fortran compilers resolve only "bare" names thus
when they are type parameters, and the names of data and procedure components
do not shadow exterior symbols. Adjust name resolution to follow that
precedent rather than what seems to be clear language in the standard.
Differential Revision: https://reviews.llvm.org/D136984
An ASSOCIATE or SELECT TYPE statement's selector whose "right-hand side" is the result
of a reference to a function that returns a pointer must be usable as a valid target
(but not as a pointer).
Differential Revision: https://reviews.llvm.org/D135211
f18 emits an error message when the same name is used in a scope
for both a procedure and a generic interface, and the procedure is
not a specific procedure of the generic interface. It may be
questionable usage, and not portable, but it does not appear to
be non-conforming by a strict reading of the standard, and many
popular Fortran compilers accept it.
Differential Revision: https://reviews.llvm.org/D135205
Some Fortran compilers accept user-defined ELEMENTAL procedures as actual
arguments corresponding to (necessarily) non-ELEMENTAL dummy procedures;
most do not, and f18 is one of them. Document the fact that this is not
a supported extension.
Differential Revision: https://reviews.llvm.org/D134399
Fortran is not clear about the semantics of
```
subroutine subr
integer n = 1
block
data n/2/
end block
end subroutine
```
which could be interpreted as having two variables, each
named 'n', or as having one variable 'n' with invalid double
initialization. Precedents from existing compilers are also
in disagreement.
The most common interpretation, however, agrees with a subtle
reading of the standard: BLOCK constructs scope names that have
local specifications, and a DATA statement is a declaration
construct, not a specification construct. So this example is
*not* acceptable.
Differential Revision: https://reviews.llvm.org/D134391
