Hi,
This patch implements support for the following directives :
- `!DIR$ NOUNROLL_AND_JAM` to disable unrolling and jamming on a DO
LOOP.
- `!DIR$ NOUNROLL` to disable unrolling on a DO LOOP.
- `!DIR$ NOVECTOR` to disable vectorization on a DO LOOP.
This patch implements support for the UNROLL_AND_JAM directive to enable
or disable unrolling and jamming on a `DO LOOP`.
It must be placed immediately before a `DO LOOP` and applies only to the
loop that follows. N is an integer that specifying the unrolling factor.
This is done by adding an attribute to the branch into the loop in LLVM
to indicate that the loop should unrolled and jammed.
This patch implements support for the UNROLL directive to control how
many times a loop should be unrolled.
It must be placed immediately before a `DO LOOP` and applies only to the
loop that follows. N is an integer that specifying the unrolling factor.
This is done by adding an attribute to the branch into the loop in LLVM
to indicate that the loop should unrolled.
The code pushed to support the directive `VECTOR ALWAYS` has been
modified to take account of the fact that several directives can be used
before a `DO LOOP`.
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.
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.
When a DEC legacy STRUCTURE definition appears within another, its
STRUCTURE statement must also declare some components of the enclosing
structure.
Fixes https://github.com/llvm/llvm-project/issues/99288.
This patch implements support for the VECTOR ALWAYS directive, which
forces
vectorization to occurr when possible regardless of a decision by the
cost
model. This is done by adding an attribute to the branch into the loop
in LLVM
to indicate that the loop should always be vectorized.
This patch only implements this directive on plan structured do loops
without labels. Support for unstructured loops and array
expressions is planned for future patches.
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.
…grams
The parser only recognizes compiler directives that appear within
internal / module subprograms, not those that might appear between them.
Extend to allow them between subprograms as well.
Some applications have alignment directives for members inside types.
This allows those to be present, but generally getting ignored [with a warning]
later on in the processing. This is just to allow the compilation to complete.
When parsing a deeply-nested expression like
A1(A2(A3(A4(A5(A6(...A99(i)...))))))
the parser can get into an exponential state due to the need to consider
the possibility that each "An(...)" might be the beginning of a
reference to a procedure component ("An(...)%PROC(...)") so that
alternative has to be attempted first before proceeding to try parsing
"An(...)" as a function reference or as an array element designator. The
parser for a structure component, which is used by the procedure
designator parser, was not protected with the usual failure memoization
technique, leading to exponentially bad behavior parsing a deeply-nested
expression. Fix by exploiting the instrumented() parser combinator so
that failed structure component parsers aren't repeated.
Fixes https://github.com/llvm/llvm-project/issues/76477.
Begin upstreaming of CUDA Fortran support in LLVM Flang.
This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature enum value for CUDA Fortran
- driver change to enable that feature for *.cuf and *.CUF source files
- parse tree representation of CUDA Fortran syntax
- dumping and unparsing of the parse tree
- the actual parsers for CUDA Fortran syntax
- prescanning support for !@CUF and !$CUF
- basic sanity testing via unparsing and parse tree dumps
... along with any minimized changes elsewhere to make these
work, mostly no-op cases in common::visitors instances in
semantics and lowering to allow them to compile in the face
of new types in variant<> instances in the parse tree.
Because CUDA Fortran allows the kernel launch chevron syntax
("call foo<<<blocks, threads>>>()") only on CALL statements and
not on function references, the parse tree nodes for CallStmt,
FunctionReference, and their shared Call were rearranged a bit;
this caused a fair amount of one-line changes in many files.
More patches will follow that implement CUDA Fortran in the symbol
table and name resolution, and then semantic checking.
Differential Revision: https://reviews.llvm.org/D150159
The following PowerPC vector type syntax is added:
VECTOR ( element-type-spec )
where element-type-sec is integer-type-spec, real-type-sec or unsigned-type-spec.
Two opaque types (__VECTOR_PAIR and __VECTOR_QUAD) are also added.
A finite set of functionalities are implemented in order to support the new types:
1. declare objects
2. declare function result
3. declare type dummy arguments
4. intrinsic assignment between the new type objects (e.g. v1=v2)
5. reference functions that return the new types
Submit on behalf of @tislam @danielcchen
Authors: @tislam @danielcchen
Differential Revision: https://reviews.llvm.org/D150876
Modify the prescanner to allow compiler directives to appear in
macro expansions, and adjust the parser to accept a semicolon
as a directive terminator.
Differential Revision: https://reviews.llvm.org/D150780
Implement semantics for the IGNORE_TKR directive as it is interpreted
by the PGI / NVFORTRAN compiler.
Differential Revision: https://reviews.llvm.org/D148643
In free form, don't silently skip over an invalid space between
an underscore and a kind parameter.
Differential Revision: https://reviews.llvm.org/D142760
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 a multi-statement construct should end with a particular END statement
like "END SELECT", and that construct's END statement is missing or
unrecognizable, the error recovery productions should not misinterpret
a program unit END statement that follows and consume it as a misspelled
construct END statement. Doing so leads to cascading errors or a failed parse.
Differential Revision: https://reviews.llvm.org/D136896
A generic-spec can appear on a module accessibility control statement
even if it has not been declared as a generic interface, because there's
nothing else that it could be.
While here, simplify the parse tree and parser for AccessId, since
one of its alternatives is ambiguous with the other.
Differential Revision: https://reviews.llvm.org/D134471
A type-param-inquiry of %KIND or %LEN applies to a designator, and
so must also be allowed for a substring. F18 presently (mis)parses
instances of a type-param-inquiry as structure component references
and then fixes them in expression semantics when types are known and
we can distinguish them. But when the base of a type-param-inquiry is
a substring of an array element, as in "charArray(i)(j:k)%len",
parsing fails.
Adjust the grammar to parse these cases, and extend expression semantics
to process the new production.
Differential Revision: https://reviews.llvm.org/D130375
To avoid clashing with names of user derived types, the redundant
syntax TYPE(intrinsic type spec) must be interpreted as a monomorphic
derived type when "intrinsic type spec" is a single word. This
affects TYPE(BYTE) and TYPE(DOUBLECOMPLEX), but not TYPE(DOUBLE COMPLEX)
in free form source.
Differential Revision: https://reviews.llvm.org/D123724
Extend "extension<LanguageFeature>()" to incorporate an explanatory
message better than the current generic "nonstandard usage:".
Differential Revision: https://reviews.llvm.org/D122035
EQUIVALENCE storage association of objects whose types are not
both default-kind numeric storage sequences, or not both default-kind
character storage sequences, are not standard conformant.
However, most Fortran compilers admit such usage, with warnings
in strict conformance mode. This patch allos EQUIVALENCE of objects
that have sequence types that are either identical, both numeric
sequences (of default kind or not), or both character sequences.
Non-sequence types, and sequences types that are not homogeneously
numeric or character, remain errors.
Differential Revision: https://reviews.llvm.org/D119848
Implements part of the legacy "DEC structures" feature from
VMS Fortran. STRUCTUREs are processed as if they were derived
types with SEQUENCE. DATA-like object entity initialization
is supported as well (e.g., INTEGER FOO/666/) since it was used
for default component initialization in structures. Anonymous
components (named %FILL) are also supported.
These features, and UNION/MAP, were already being parsed.
An omission in the collection of structure field names in the
case of nested structures with entity declarations was fixed
in the parser.
Structures are supported in modules, but this is mostly for
testing purposes. The names of fields in structures accessed
via USE association cannot appear with dot notation in client
code (at least not yet). DEC structures antedate Fortran 90,
so their actual use in applications should not involve modules.
This patch does not implement UNION/MAP, since that feature
would impose difficulties later in lowering them to MLIR types.
In the meantime, if they appear, semantics will issue a
"not yet implemented" error message.
Differential Revision: https://reviews.llvm.org/D117151
The parsing of I/O units uses look-ahead to discriminate between
keywords, variables and expressions as part of distinguishing internal
from external I/O. The look-ahead was inaccurate for variables that
appear as the initial parts of expressions.
Differential Revision: https://reviews.llvm.org/D95743
Remove resolved & moot TODO comments in Common/, Parser/,
and Evaluate/. Address a pending one relating to parsing
ambiguity in DATA statement constants, handling it with
symbol table information in Semantics and adding a test.
Differential Revision: https://reviews.llvm.org/D93323
Fortran defines "null-init" null pointer initializers as
being function references, syntactically, that have to resolve
to calls to the intrinsic function NULL() with no actual
arguments.
Differential revision: https://reviews.llvm.org/D91657
Allow compiler directives in the implicit-part and before USE statements
in the specification-part.
Differential Revision: https://reviews.llvm.org/D85693
Accept name=value as part of a !DIR$ compiler directive. These
are currently ignored in semantics, but we should recognize
more directive forms to facilitate testing. In due course,
these placeholding directive parsers will be replaced.
Reviewed By: sscalpone
Differential Revision: https://reviews.llvm.org/D84077
Implement rest of DATA statement semantics and conversion of
DATA statement initializations into static initializers of
objects in their symbol table entries.
Reviewed By: tskeith, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D82207
Rolls up small changes across the frontend to prepare for the large
forthcoming patch (part 4/4) that completes DATA statement processing
via conversion to initializers.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D82137
G++ 10.1 emits inappropriate "use of uninitialized data" warnings when
compiling f18. The warnings stem from two sites in templatized code
whose multiple instantiations magnified the number of warnings.
These changes dodge those warnings by making some innocuous changes to
the code. In the parser, the idiom defaulted(cut >> x), which yields a
parser that always succeeds, has been replaced with a new equivalent
pass<T>() parser that returns a default-constructed value T{} in an
arguably more readable fashion. This idiom was the only attestation of
the basic parser cut, so it has been removed and the remaining code
simplified. In Evaluate/traverse.h, a return {}; was replaced with a
return of a default-constructed member.
Differential Revision: https://reviews.llvm.org/D81747
Summary:
Updates recent work on DATA statement semantic checking in
flang/lib/Semantics/check-data.{h,cpp} to use the compiler's
internal representation for typed expressions rather than working
on the raw parse tree. Saves the analyzed expressions for DATA
statement values as parse tree decorations because they'll soon be
needed in lowering. Corrects wording of some error messages.
Fixes a bug in constant expression checking: structure constructors
are not constant expressions if they set an allocatable component
to anything other than NULL.
Includes infrastructure changes to make this work, some renaming
to reflect the fact that the implied DO loop indices tracked by
expression analysis are not (just) from array constructors, remove
some dead code, and improve some comments.
Reviewers: tskeith, sscalpone, jdoerfert, DavidTruby, anchu-rajendran, schweitz
Reviewed By: tskeith, anchu-rajendran, schweitz
Subscribers: llvm-commits, flang-commits
Tags: #flang, #llvm
Differential Revision: https://reviews.llvm.org/D78834
