|
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 ...
|