History log of /llvm-project-15.0.7/flang/lib/Semantics/resolve-names.cpp (Results 1 – 25 of 193)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# a9782fea 22-Jul-2022 Peter Klausler <[email protected]>

[flang] Correct IsHostAssociated() to be true for BLOCK constructs

The predicate IsHostAssocited() was implemented in a way that would
return true only for cases of host association into a module or

[flang] Correct IsHostAssociated() to be true for BLOCK constructs

The predicate IsHostAssocited() was implemented in a way that would
return true only for cases of host association into a module or inner
subprogram. Technically, the use of a name in a BLOCK construct
that is not declared therein is considered in the Fortran standard
to also be a form of host association, and this matters when doing
error checking on DATA statements.

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

show more ...


# e03664d4 22-Jul-2022 Peter Klausler <[email protected]>

[flang] Fix parsing and semantics for array element substring%KIND/%LEN

A type-param-inquiry of %KIND or %LEN applies to a designator, and
so must also be allowed for a substring. F18 presently (mi

[flang] Fix parsing and semantics for array element substring%KIND/%LEN

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

show more ...


# b7f83142 11-Jul-2022 Peter Klausler <[email protected]>

[flang] Avoid crash from forward referenced derived type

Fortran permits forward references to derived types in contexts that don't
require knowledge of the derived type definition for semantic anal

[flang] Avoid crash from forward referenced derived type

Fortran permits forward references to derived types in contexts that don't
require knowledge of the derived type definition for semantic analysis,
such as in the declaration of a pointer or allocatable variable or component.
But when the forward-referenced derived type is used later for a component
reference, it is possible for the DerivedTypeSpec in he base variable or component
declaration to still have a null scope pointer even if the type has been defined,
since DerivedTypeSpec and TypeSpec objects are created in scopes of use
rather than in scopes of definition. The fix is to call
DerivedTypeSpec::Instantiate() in the name resolution of each component
name so that the scope gets filled in if it is still null.

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

show more ...


# 0406c0cd 08-Jul-2022 Peter Klausler <[email protected]>

[flang] Ensure name resolution visits "=>NULL()" in entity-decl

Most modern Fortran programs declare procedure pointers with a
procedure-declaration-stmt, but it's also possible to declare one
with

[flang] Ensure name resolution visits "=>NULL()" in entity-decl

Most modern Fortran programs declare procedure pointers with a
procedure-declaration-stmt, but it's also possible to declare one
with a type-declaration-stmt with a POINTER attribute. In this
case, e.g. "real, external, pointer :: p => null()" the initializer
is required to be a null-init. The parse tree traversal in name
resolution would visit the null-init if the symbol were an object
pointer only, leading to a crash in the case of a procedure pointer.

That explanation of the bug is longer than the fix. In short,
ensure that a null-init in an entity-decl is visited for both
species of pointers.

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

show more ...


# 23c2bedf 01-Jul-2022 Peter Klausler <[email protected]>

[flang] Establish a single source of target information for semantics

Create a TargetCharacteristics class to centralize the few items of
target specific information that are relevant to semantics.

[flang] Establish a single source of target information for semantics

Create a TargetCharacteristics class to centralize the few items of
target specific information that are relevant to semantics. Use the
new class for all target queries, including derived type component layout
modeling.

Future work will initialize this class with target information
provided or forwarded by the drivers, and use it to fold layout-dependent
intrinsic functions like TRANSFER().

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

Updates: Attempts to work around build issues on Windows.

show more ...


# f161964e 23-Jun-2022 Peter Klausler <[email protected]>

[flang] Better error recovery for bad submodules

When a submodule appears in a source file and the compiler can't find the
named ancestor module (and submodule, if one appears), crashes may occur
la

[flang] Better error recovery for bad submodules

When a submodule appears in a source file and the compiler can't find the
named ancestor module (and submodule, if one appears), crashes may occur
later due to the absence of a scope. For better resilience, a dummy
ancestral scope should be generated within which the submodule scope
can be created.

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

show more ...


# 779d2470 29-Jun-2022 Peixin-Qiao <[email protected]>

[flang] Support check for BIND statement entity

As Fortran 2018 8.6.4(1), the BIND statement specifies the BIND attribute
for a list of variables and common blocks.

Reviewed By: klausler

Different

[flang] Support check for BIND statement entity

As Fortran 2018 8.6.4(1), the BIND statement specifies the BIND attribute
for a list of variables and common blocks.

Reviewed By: klausler

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

show more ...


Revision tags: llvmorg-14.0.6
# cfd474e0 15-Jun-2022 Peter Klausler <[email protected]>

[flang] Enforce C1552, no binding labels allowed for internal procedures

If BIND(C) appears on an internal procedure, it must have a null binding
label, i.e. BIND(C,NAME="").

Also address conflicts

[flang] Enforce C1552, no binding labels allowed for internal procedures

If BIND(C) appears on an internal procedure, it must have a null binding
label, i.e. BIND(C,NAME="").

Also address conflicts with D127725 which was merged during development.

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

show more ...


# 3fa62efd 22-Jun-2022 Peixin Qiao <[email protected]>

[flang] Add semantic check for C1520

As Fortran 2018 C1520, if proc-language-binding-spec with NAME= is
specified, then proc-decl-list shall contain exactly one proc-decl,
which shall neither have t

[flang] Add semantic check for C1520

As Fortran 2018 C1520, if proc-language-binding-spec with NAME= is
specified, then proc-decl-list shall contain exactly one proc-decl,
which shall neither have the POINTER attribute nor be a dummy procedure.
Add this check.

Reviewed By: klausler

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

show more ...


# 3151fb5e 15-Jun-2022 Peixin-Qiao <[email protected]>

[flang] Change C889 from error into warning

This constraint is used in OMP2012 benchmark, and other compilers do not
enforce it. Change it into one warning. This addresses the issue
https://github.c

[flang] Change C889 from error into warning

This constraint is used in OMP2012 benchmark, and other compilers do not
enforce it. Change it into one warning. This addresses the issue
https://github.com/llvm/llvm-project/issues/56003.

Reviewed By: klausler, kiranchandramohan

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

show more ...


# dafd3cf8 14-Jun-2022 Peixin-Qiao <[email protected]>

[flang] Complement one-to-one association check of bind name and entity name

As Fortran 2018 C802 and C873, if bind name is specified, there can only
be only one entity. The check for common block i

[flang] Complement one-to-one association check of bind name and entity name

As Fortran 2018 C802 and C873, if bind name is specified, there can only
be only one entity. The check for common block is missed before. As
Fortran 2018 8.5.5 point 2, the bind name is one identifier, which is
unique. That is, one entity can not have multiple bind names. Also add
this check.

Reviewed By: klausler, Jean Perier

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

show more ...


Revision tags: llvmorg-14.0.5
# 8eebf469 08-Jun-2022 Peter Klausler <[email protected]>

[flang] Fix crash on USE error

Handle the case of a non-generic procedure that is USE associated
into a scope that has a generic interface of the same name with an
appropriate error rather than cras

[flang] Fix crash on USE error

Handle the case of a non-generic procedure that is USE associated
into a scope that has a generic interface of the same name with an
appropriate error rather than crashing.

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

show more ...


# 1f17a897 08-Jun-2022 PeixinQiao <[email protected]>

[flang] Add one missed semantic check for named constant in common block

As Fortran 2018 R874, common block object must be one variable name, which
cannot be one named constant. Add this check.

Rev

[flang] Add one missed semantic check for named constant in common block

As Fortran 2018 R874, common block object must be one variable name, which
cannot be one named constant. Add this check.

Reviewed By: klausler

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

show more ...


# 0c190575 26-May-2022 Peter Klausler <[email protected]>

[flang] Make generic resolution conform to 15.5.5.2 w/r/t host association

When two or more generic interfaces are available by declaration or
by USE association at different scoping levels, we need

[flang] Make generic resolution conform to 15.5.5.2 w/r/t host association

When two or more generic interfaces are available by declaration or
by USE association at different scoping levels, we need to search
the outer generic interfaces as well as the inner ones, but only after
the inner ones have failed to produce a specific procedure that matches
a given set of actual arguments. This means that it is possible for
a specific procedure of a generic interface of an inner scope to override
a conflicting specific procedure of a generic interface of an outer
scope.

Also cope with forward references to derived types when a generic
interface is also in scope.

Fixes LLVM bug https://github.com/llvm/llvm-project/issues/55240 and
LLVM bug https://github.com/llvm/llvm-project/issues/55300.

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

show more ...


# ddd692e9 25-May-2022 Peter Klausler <[email protected]>

[flang] Allow forward reference to ENTRY from generic interface

The CreateEntry() function in name resolution needs to allow for the name
of an alternate entry point already having been declared in

[flang] Allow forward reference to ENTRY from generic interface

The CreateEntry() function in name resolution needs to allow for the name
of an alternate entry point already having been declared in the outer scope
as the homonymous specific procedure of a generic interface; e.g.,

interface foo
module procedure foo
end interface
subroutine bar
entry foo
end subroutine

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

show more ...


# 6b99dc29 25-May-2022 Peter Klausler <[email protected]>

[flang] Fix crash from a blank BIND(C,NAME="") on subprogram

A recent change fixed the processing of BIND(C,NAME=expr) character
expressions so that they are evaluated as constants in the scope of
t

[flang] Fix crash from a blank BIND(C,NAME="") on subprogram

A recent change fixed the processing of BIND(C,NAME=expr) character
expressions so that they are evaluated as constants in the scope of
the subprogram. However, when the character name expression results
in an empty value after trimming, the compiler emits a warning message,
and this message is now causing a crash due to a lack of statement
context. To fix, extend the deferred processing of the BIND(C,NAME="")
so that a basic statement context exists.

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

show more ...


Revision tags: llvmorg-14.0.4
# d52a6e75 20-May-2022 Peter Klausler <[email protected]>

[flang] Process subprogram BIND(C,NAME=...) locally

The scalar-default-character-expression that defines the interoperable
name of a function or subroutine (or interface) must have its names
resolve

[flang] Process subprogram BIND(C,NAME=...) locally

The scalar-default-character-expression that defines the interoperable
name of a function or subroutine (or interface) must have its names
resolved within the context of the subprogram, despite its appearance
on a function-stmt or a subroutine-stmt. Failure to do so can lead
to bogus errors or to incorrect results.

The solution is to defer name resolution for function-stmt suffixes
(but not entry-stmt suffixes) and for subroutine-stmt language binding
specifications to EndSubprogram(). (Their resolution only need to be
deferred to the end of the specification part, but it's cleanest to
deal with it in EndSubprogram().)

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

show more ...


# cd2a8df8 19-May-2022 Peter Klausler <[email protected]>

[flang] Don't prematurely resolve subprogram names

Name resolution for subprograms checks whether the name is already
present in the enclosing scope as a generic interface, so that the
case of a gen

[flang] Don't prematurely resolve subprogram names

Name resolution for subprograms checks whether the name is already
present in the enclosing scope as a generic interface, so that the
case of a generic with the same name as one of its specifics can be
handled. The particular means by which the enclosing scope is searched
for the name would resolve the name (bind a symbol to it) as a side
effect. This turns out to be the wrong thing to do when the subprogram
is going to have its symbol created in another scope to cope with its
BIND(C,NAME="name") name, and its Fortran name is already present in the
enclosing scope for a subprogram of the same name but without
BIND(C,NAME="name").

A very long explanation for a one-line fix, sorry. In short, change
the code to look up the name but not resolve it at that point.

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

show more ...


# 7f680b26 17-May-2022 Peter Klausler <[email protected]>

[flang] Allow more forward references to ENTRY names

Forward references to ENTRY names to pass them as actual procedure arguments
don't work in all cases, exposing some basic ordering problems in
na

[flang] Allow more forward references to ENTRY names

Forward references to ENTRY names to pass them as actual procedure arguments
don't work in all cases, exposing some basic ordering problems in
name resolution for these symbols. Refactor; create all the
necessary procedure symbols, and either function result or host association
symbols (for subroutines), at the time that the subprogrma scope is
created, so that the names exist in the scope as text "before"
the ENTRY is processed in name resolution. Some processing
remains in PostEntryStmt() so that we can check that an ENTRY with
an explicit distinct RESULT doesn't also have declarations for the
ENTRY name.

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

show more ...


# 9f33dd73 11-May-2022 Peter Klausler <[email protected]>

[flang] Allow global scope names that clash with intrinsic modules

Intrinsic module names are not in the user's namespace, so they
are free to declare global names that conflict with intrinsic
modul

[flang] Allow global scope names that clash with intrinsic modules

Intrinsic module names are not in the user's namespace, so they
are free to declare global names that conflict with intrinsic
modules.

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

show more ...


# 8c407f4a 04-May-2022 Peter Klausler <[email protected]>

[flang] Allow ENTRY function result symbol usage before the ENTRY

In a function, ENTRY E without an explicit RESULT() creates a
function result entity also named E that is storage associated with
th

[flang] Allow ENTRY function result symbol usage before the ENTRY

In a function, ENTRY E without an explicit RESULT() creates a
function result entity also named E that is storage associated with
the enclosing function's result. f18 was emitting an incorrect error
message if that function result E was referenced without any
declaration prior to its ENTRY statement when it should have been
implicitly declared instead.

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

show more ...


# 8594b051 04-May-2022 Peter Klausler <[email protected]>

[flang] Accept POINTER followed by INTERFACE

As is already supported for dummy procedures, we need to also accept
declarations of procedure pointers that consist of a POINTER attribute
statement fol

[flang] Accept POINTER followed by INTERFACE

As is already supported for dummy procedures, we need to also accept
declarations of procedure pointers that consist of a POINTER attribute
statement followed by an INTERFACE block. (The case of an INTERFACE
block followed by a POINTER statement already works.)

While cleaning this case up, adjust the utility predicate IsProcedurePointer()
to recognize it (namely a SubprogramDetails symbol with Attr::POINTER)
and delete IsProcName(). Extend tests, and add better comments to
symbol.h to document the two ways in which procedure pointers are
represented.

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

show more ...


# 3382edf9 03-May-2022 Peter Klausler <[email protected]>

[flang] Allow implicit declaration of DATA objects in inner procedures

DATA statements in inner procedures were not treating undeclared objects
as implicitly declared variables if the DATA statement

[flang] Allow implicit declaration of DATA objects in inner procedures

DATA statements in inner procedures were not treating undeclared objects
as implicitly declared variables if the DATA statement appeared in a
specification part; they were treated as host-associated symbols instead.
This was incorrect. Fix DATA statement name resolution to always treat
DATA as if it had appeared in the executable part.

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

show more ...


# ed034178 09-May-2022 Jean Perier <[email protected]>

[flang] retain binding label of entry subprograms

When processing an entry-stmt in name resolution, attrs_ was
reset before SetBindNameOn was called, causing the symbol to lose
the binding label inf

[flang] retain binding label of entry subprograms

When processing an entry-stmt in name resolution, attrs_ was
reset before SetBindNameOn was called, causing the symbol to lose
the binding label information.

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

show more ...


# c207e360 09-May-2022 Peixin-Qiao <[email protected]>

[flang] Enforce a program not including more than one main program

As Fortran 2018 5.2.2 states, a program shall consist of exactly one
main program. Add this semantic check.

Reviewed By: klausler

[flang] Enforce a program not including more than one main program

As Fortran 2018 5.2.2 states, a program shall consist of exactly one
main program. Add this semantic check.

Reviewed By: klausler

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

show more ...


12345678