Before emitting a warning message, code should check that the usage in
question should be diagnosed by calling ShouldWarn(). A fair number of
sites in the code do not, and can emit portability warnings
unconditionally, which can confuse a user that hasn't asked for them
(-pedantic) and isn't terribly concerned about portability *to* other
compilers.
Add calls to ShouldWarn() or IsEnabled() around messages that need them,
and add -pedantic to tests that now require it to test their portability
messages, and add more expected message lines to those tests when
-pedantic causes other diagnostics to fire.
Name resolution takes a quick pass over the executable part of a
(sub)program in search of symbols that appear to be called as
procedures, so that those names don't get mistakenly converted into
objects when finishing up specification part processing. This pass
doesn't currently cope with symbol shadowing by nested declarations in
executable constructs. This patch ensures that nested declarations for
symbols that could be used in contexts that might have been parsed as
function references properly shadow symbols of the same name in outer
scopes.
A recent fix (https://github.com/llvm/llvm-project/pull/66232) to
interpret a hitherto unknown name whose first appearance is as the
target of a procedure pointer initializer as an external procedure has
led to some inapproprite warning messages if the name is later defined
as an external subroutine ("X was already declared as an external").
Ensure that the EXTERNAL attribute is correctly noted as being implicit,
and that it's okay that neither the Subroutine nor Function flag has yet
been set for the implicit external.
Some compilers allow the `$acc routine(<name>)` to be placed at the
program unit level. To be compatible, this patch enables the use of acc
routine at this level. These acc routine directives must have a name.
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.
Name resolution creates symbols for submodules in their parents' scopes.
This can lead to bogus errors about name clashes between submodule names
and other entities in the parents' scopes.
Create symbols for submodules but do not add them to a scope's
dictionary.
When a MODULE SUBROUTINE or MODULE FUNCTION is implemented in the same
scope as its interface and appears in a generic with the same name, the
parse::Name of the implementation was not correctly reset and remained
the SubprogramNameDetails symbol after semantics, causing a crash in
lowering that picks up the procedure symbols on the parser names.
Reset the parser::Name symbol before the new symbol is created.
1. Deal with BIND(C,NAME="")
BIND(C,NAME="") is different from BIND(C). The latter implies that there
us a binding label which is the Fortran symbol name (no Fortran mangling
must be added like underscores). The former implies there is no binding
label (the name in the object file must be the same as if it there was
no BIND(C) attribute at all).
This is correctly implemented in the front-end, but lowering mistakenly
overrode this in the code dealing with the case where BIND(C) is
inherited from a procedure interface. Handling of this last case is moved into name
resolution.
2. Deal with BIND(C) internal procedure
Also according to 18.10.2, BIND(C) does not give a p prevent name
resolution from adding a label to them, otherwise,
bindc_internal_proc.f90 was not going through semantics (bogus error
about conflicting global names). Nothing TODO in lowering other than
removing the TODO.
Example:
```
subroutine global_sub()
integer, dimension(4) :: iarr4=(/1,2,3,4/)
integer, dimension(4) :: jarr4
equivalence(iarr4,jarr4)
call sub1
print *, iarr4
contains
subroutine sub1
iarr4=jarr4((/4:1:-1/))
end subroutine sub1
end subroutine global_sub
```
`iarr4` and `jarr4` are equivalenced via a global aggregate storage,
but the references inside `sub1` are lowered differently.
`iarr4` is accessed via the global aggregate storage, while `jarr4`
is accessed via the argument tuple. This confuses the FIR alias
analysis,
that claims that a host associated entity cannot alias with a global
(if they have different source and do not have Target/Pointer
attributes deduced by the alias analysis).
I am not convinced that there is an issue in the alias analysis yet.
I think we'd better lower the accesses uniformly, i.e. if one variable
from an equivalence is lowered via the global aggregate storage, then
any other variable from this equivalence should be lowered the same way
(even if they are used via host association).
This patch makes sure that all symbols from an EQUIVALENCE get
and implicit SAVE attribute, if they do not have it already and
any symbol from the EQUIVALENCE is SAVEd (explicitly or implicitly).
This makes the further lowering consistent.
Derived-type-spec (such as `type(t)`) typically cause the instantiation
of a class which is also used to define the offsets of its data
components and the size of the class.
Fortran derived types are always "completely" defined (i.e., no
incomplete / opaque derived types exist on which we can build a pointer
to them like in C/C++) so they can have their offsets always computed.
However, we must be careful not to instantiate a derived type while it
is being defined. This can happen due to cycles introduced by forward
references, such as the one below.
```lang=fortran
type t1
type(t2), pointer :: b ! (A)
end type t1
type :: t2 ! (B)
type(t1), pointer :: a ! (C)
end type t2 ! (D)
```
At `(A)`, flang determines that this is a forward declaration so no
instantiation happens.
At `(B)`, flang determines `t2` is not a forward declaration anymore,
because we are defining it.
At `(C)`, flang chooses to instantiate `t1`. Instantiation of `t1` finds
the field `b` at `(A)`. Now `t2` is not a forward declaration anymore,
so it can be instantiated. But at this point the field `a` has not been
added to `t2`, so we compute the size of an empty class. Because this
computation is done just once, we end emitting a wrong derived type
descriptor with a `sizeinbytes` field set to 0.
Because these kind of cycles can only happen via forward referenced
derived types specifiers, the idea here is to avoid instantiating the
derived type being defined (i.e. `t2`) until `(D)`. Keeping the
attribute "is forward reference" set until `(D)` avoids that.
Fixes https://github.com/llvm/llvm-project/issues/64973
Differential Revision: https://reviews.llvm.org/D159117
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.
A RANK(*) case in a SELECT RANK construct selects the case of an
assumed-rank dummy argument whose effective actual argument is an
assumed-size array. In this case, the attributes of the selector are
those of a rank-1 assumed-size array, and the selector cannot be
allocatable or a pointer.
Ensure that the representation of a SELECT RANK construct's per-case
AssocEntityDetails can distinguish RANK(n), RANK(*), and RANK DEFAULT,
and clean up various code sites and tests where the distinctions matter.
…ocedure
When an previously unknown name appears as the target of an assignment
to a known procedure pointer, create an external symbol for it rather
than an implicitly-typed object symbol.
Re-land commit 3787fd942f3927345320cc97a479f13e44355805
This patch adds support for storing OpenMP REQUIRES information in the
semantics symbols for programs/subprograms and modules/submodules, and
populates them during directive resolution. A pass is added to name resolution
that makes sure this information is also propagated across top-level programs,
functions and subprograms.
Storing REQUIRES information inside of semantics symbols will also allow
supporting the propagation of this information across Fortran modules. This
will come as a separate patch.
The `bool DirectiveAttributeVisitor::Pre(const parser::SpecificationPart &x)`
method is removed since it resulted in specification parts being visited twice.
This is patch 3/5 of a series splitting D149337 to simplify review.
Differential Revision: https://reviews.llvm.org/D157983
Changes in this commit make some gfortran tests crash the compiler. It is
likely trying to dereference undefined symbol pointers.
This reverts commit 3787fd942f3927345320cc97a479f13e44355805.
This patch adds support for storing OpenMP REQUIRES information in the
semantics symbols for programs/subprograms and modules/submodules, and
populates them during directive resolution. A pass is added to name resolution
that makes sure this information is also propagated across top-level programs,
functions and subprograms.
Storing REQUIRES information inside of semantics symbols will also allow
supporting the propagation of this information across Fortran modules. This
will come as a separate patch.
The `bool DirectiveAttributeVisitor::Pre(const parser::SpecificationPart &x)`
method is removed since it resulted in specification parts being visited twice.
This is patch 3/5 of a series splitting D149337 to simplify review.
Differential Revision: https://reviews.llvm.org/D157983
Unlike other executable constructs with associating selectors, the
selector of a SELECT RANK construct can have the ALLOCATABLE or POINTER
attribute, and will work as an allocatable or object pointer within
each rank case, so long as there is no RANK(*) case.
Getting this right exposed a correctness risk with the popular
predicate IsAllocatableOrPointer() -- it will be true for procedure
pointers as well as object pointers, and in many contexts, a procedure
pointer should not be acceptable. So this patch adds the new predicate
IsAllocatableOrObjectPointer(), and updates some call sites of the original
function to use the new one.
Differential Revision: https://reviews.llvm.org/D159043
When one of a derived type's FINAL procedures is in a submodule,
its separate module procedure interface must necessarily be a
forward reference from the FINAL statement, as its interface
could not appear before the definition of the type. The implementation
of FINAL procedure name resolution doesn't work for forward references;
replace it.
Differential Revision: https://reviews.llvm.org/D159035
Earlier work allowed a specification expression to reference a generic function
that was defined earlier, so long as the relevant specific procedure of the
generic had been defined before the generic. This patch extends that work
so that the generic can also be used in cases where the relevant specific
procedure has been defined after the generic and before the reference.
Differential Revision: https://reviews.llvm.org/D159034
The handling of accessibility attributes on GENERIC statements outside
derived type definitions is incorrect in name resolution. Change it to
use the usual BeginAttrs()/EndAttrs() infrastructure.
Differential Revision: https://reviews.llvm.org/D159032
When resolving names in a specification part, unknown names that appear
in a specification expression before any local declaration are assumed
to be implicitly declared objects in the host scope. Objects in
EQUIVALENCE sets are not part of specification expressions, so ensure
that they do not receive this treatment; besides being wrong and
unimplementable, it will lead to a later crash during offset assignment.
Differential Revision: https://reviews.llvm.org/D159030
The flag "anyIntrinsicDefinedOps" is always set nowadays, as there are intrinsic
modules that define operator(==) and (!=). This disables the iterative
expression analysis mechanism, also unnecessarily, and it is possible to
overflow the stack when analyzing very deep expression trees like the ones
that show up in artificial stress tests. Remove the flag.
Differential Revision: https://reviews.llvm.org/D159022
Name resolutions defers all resolution and checking of specific procedures
in non-type-bound generic interfaces to the end of the specification part.
This prevents expression analysis of references to generic functions in
specification expressions in interfaces from resolving.
Example (now a new test case in modfile07.f90):
```
module m12
interface generic
module procedure specific
end interface
interface
module subroutine s(a1,a2)
character(*) a1
character(generic(a1)) a2 ! <--
end
end interface
contains
pure integer function specific(x)
character(*), intent(in) :: x
specific = len(x)
end
end
```
The solution is to partially resolve specific procedures as they are
defined for each generic, when they can be resolved, with the final
pass at the end of the specification part to finish up any forward
references and emit the necessary error messages.
Making this fix caused some issues in module file output, which have
all been resolved by making this simplifying change: generics are
now all emitted to module file specification parts as their own
group of declarations at the end of the specification part,
followed only by namelists and COMMON blocks.
Differential Revision: https://reviews.llvm.org/D157346
Detect and emit errors about undefinable NAMELIST group members in READ statements.
Fixes llvm-test-suite/Fortran/gfortran/regression/namelist_2.f90.
Differential Revision: https://reviews.llvm.org/D157344
An incorrect "Implicit declaration of function '...' has a different result type
than in previous declaration" is being emitted for ENTRY names used
recursively. The predicate used to check for recursive use only allowed
for scopes of functions, not ENTRYs.
Fixes llvm-test-suite/Fortran/gfortran/regression/whole_file_9.f90.
Differential Revision: https://reviews.llvm.org/D157337
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
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
A name that has been used to reference an undeclared global external
procedure should be accepted as the target of a procedure pointer
assignment statement.
Fixes llvm-test-suite/Fortran/gfortran/regression/proc_ptr_45.f90.
Differential Revision: https://reviews.llvm.org/D155963
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.
The statement "A(J) = expr" could be an assignment to an element of an
array A, an assignment to the target of a pointer-valued function A, or
the definition of a new statement function in the local scope named A,
depending on whether it appears in (what might still be) the specification
part of a program or subprogram and what other declarations and definitions
for A might exist in the local scope or have been imported into it.
The standard requires that the name of a statement function appear in
an earlier type declaration statement if it is also the name of an
entity in the enclosing scope. Some other Fortran compilers mistakenly
enforce that rule in the case of an assignment to the target of a
pointer-valued function in the containing scope, after misinterpreting
the assignment as a new local statement function definition.
This patch cleans up the handling of the various possibilities and
resolves what was a crash in the case of a statement function definition
whose name was the same as that of a procedure in the outer scope whose
result is *not* a pointer.
Differential Revision: https://reviews.llvm.org/D155493
The sourcerange was missing for a few directives when
they were the first directive to appear in a program
without a program statement.
Reviewed By: DavidTruby
Differential Revision: https://reviews.llvm.org/D153634
Kind of an edge case. When a MODULE FUNCTION or SUBROUTINE
interface is defined by a MODULE PROCEDURE in the same program
unit, ensure that the symbol table pointer in the parse tree is
updated to point to the SubprogramDetails symbol for the
interface, and not left pointing to what should soon become
a dead SubprogramNameDetails symbol.
Differential Revision: https://reviews.llvm.org/D154380
Currently, when a (legacy) DEC structure contained other DEC structure
declarations, the related component names were not added to the
containing DerivedTypeDetails component_names. This lead to bugs in
later phase when visiting the components (like in when lowering the
type to FIR/MLIR).
When an EntityDecl is visited and the scope is a DEC structure, add
the entity to the component names of this DEC structure.
Differential Revision: https://reviews.llvm.org/D154216
An unconditional EraseSymbol() call was deleting a generic interface symbol
when the generic had a module procedure of the same name as a specific
procedure, and the module procedure's definition appeared in the same
module. Also clean up some applications of the MODULE attribute to
symbols created along the way.
Differential Revision: https://reviews.llvm.org/D153478
Fortran requires that a USE with renaming prevent the USE'd symbol
from also being associated into a scope without renaming. The
implementation in name resolution gets confused in the case of
a USE with renaming using the same name ("x => x"). Clean things
up. Fixes LLVM bug https://github.com/llvm/llvm-project/issues/63397.
Differential Revision: https://reviews.llvm.org/D153452
The current code has redundancy with the infrastructure for
declaration checking that can be replaced by better usage of
the parse tree walking framework. This also fixes LLVM flang
bug #58971.
Differential Revision: https://reviews.llvm.org/D153385
Add representations of CUDA Fortran data and subprogram attributes
to the symbol table and scopes of semantics. Set them in name
resolution, and emit them to module files.
Depends on https://reviews.llvm.org/D150159.
Differential Revision: https://reviews.llvm.org/D150161
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
Fortran allows a generic procedure interface to have the same name as a derived
type in the same scope or the same name as one of its specific procedures.
(It can't have both since a derived type and specific procedure can't have the
same name in a scope.)
Some popular compilers allow generic interfaces with distinct accessible homonymous
specific procedures to be merged by USE association. Thsi compiler does not,
and for good reason: it leads to ambiguity in cases where a procedure name appears
outside a reference, such as in a PROCEDURE declaration statement as the procedure's
interface, the target of a procedure pointer assignment statement, or as an
actual argument.
This patch cleans up the code that handles these cases, improves some error
messages, and adds more tests.
Resolves https://github.com/llvm/llvm-project/issues/60228.
Differential Revision: https://reviews.llvm.org/D150915
Constraint C815 in F'2018 allows a name to acquire an attribute at
most once per scope. For some attributes, the attribute may have
already been inherited, and the compiler was emitting a bogus error
message for a redundant application of the same attribute in another
scope.
Fixes https://github.com/llvm/llvm-project/issues/60274
Differential Revision: https://reviews.llvm.org/D150819
Establish a set of optional usage warnings, and enable some
only in "-pedantic" mode that, in our subjective experience
with application codes, seem to issue frequently without
indicating usage that really needs to be corrected. By default,
with this patch the compiler should appear to be somewhat less
persnickety but not less informative.
Differential Revision: https://reviews.llvm.org/D150710
