#
5718a425 |
| 26-Jul-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Catch insufficient actual elements/characters associated with longer dummy argument
Check for cases of storage sequence association in which an element or substring is an actual argument ass
[flang] Catch insufficient actual elements/characters associated with longer dummy argument
Check for cases of storage sequence association in which an element or substring is an actual argument associated with a dummy argument array that can be detected as being larger than the remaining elements or characters in the actual argument's storage sequence.
Differential Revision: https://reviews.llvm.org/D156757
show more ...
|
#
f7e43041 |
| 20-Jul-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Strengthen procedure compatibility checking
Add more checks to procedure compatibility testing for procedure pointer assignments, actual procedure arguments, &c. Specifically, don't allow c
[flang] Strengthen procedure compatibility checking
Add more checks to procedure compatibility testing for procedure pointer assignments, actual procedure arguments, &c. Specifically, don't allow corresponding dummy data objects to differ in their use of polymorphism, assumed size arrays, or assumed shape arrays.
Differential Revision: https://reviews.llvm.org/D155974
show more ...
|
#
6ceba01a |
| 28-Jun-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] More actual argument warnings
Emit warnings when CHARACTER lengths or array sizes of actual and dummy arguments mismatch in risky ways.
Differential Revision: https://reviews.llvm.org/D1543
[flang] More actual argument warnings
Emit warnings when CHARACTER lengths or array sizes of actual and dummy arguments mismatch in risky ways.
Differential Revision: https://reviews.llvm.org/D154370
show more ...
|
#
f513bd80 |
| 06-May-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] CUDA Fortran - part 4/5: definability and characteristics
Extend the definability and procedure characteristics checking infrastructure in semantics to check for context-dependent CUDA objec
[flang] CUDA Fortran - part 4/5: definability and characteristics
Extend the definability and procedure characteristics checking infrastructure in semantics to check for context-dependent CUDA object definability violations and problems with CUDA attribute incompatibility in procedure interfaces.
Depends on https://reviews.llvm.org/D150159, https://reviews.llvm.org/D150161, & https://reviews.llvm.org/D150162.
Differential Revision: https://reviews.llvm.org/D150163
show more ...
|
#
e5ccfbbf |
| 17-May-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Respect !DIR$ IGNORE_TKR in generic matching
Generic matching needs to relax argument compatibility checks when dummy arguments have !DIR$ IGNORE_TKR directives.
Differential Revision: http
[flang] Respect !DIR$ IGNORE_TKR in generic matching
Generic matching needs to relax argument compatibility checks when dummy arguments have !DIR$ IGNORE_TKR directives.
Differential Revision: https://reviews.llvm.org/D150806
show more ...
|
#
a88cee1f |
| 21-Apr-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Semantics for ISO_C_BINDING's C_LOC()
Make __builtin_c_loc() into an intrinsic function and verify the special semantic requirements on its actual arguments.
Differential Revision: https://
[flang] Semantics for ISO_C_BINDING's C_LOC()
Make __builtin_c_loc() into an intrinsic function and verify the special semantic requirements on its actual arguments.
Differential Revision: https://reviews.llvm.org/D149988
show more ...
|
#
864cb2aa |
| 10-Apr-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Semantics for !DIR$ IGNORE_TKR
Implement semantics for the IGNORE_TKR directive as it is interpreted by the PGI / NVFORTRAN compiler.
Differential Revision: https://reviews.llvm.org/D148643
|
#
ae426a05 |
| 07-Mar-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Detect obvious argument shape incompatibility when checking procedure compatibility
The compiler presently detects different dummy object array ranks; extend the compatibility check to also
[flang] Detect obvious argument shape incompatibility when checking procedure compatibility
The compiler presently detects different dummy object array ranks; extend the compatibility check to also note discrepancies in corresponding constant dummy argument extents.
Differential Revision: https://reviews.llvm.org/D145748
show more ...
|
#
bdbebef8 |
| 17-Feb-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Warn about inconsistent implicit interfaces
When a global procedure has no explicit interface, emit warnings when its references are inconsistent implicit procedure interfaces.
Differential
[flang] Warn about inconsistent implicit interfaces
When a global procedure has no explicit interface, emit warnings when its references are inconsistent implicit procedure interfaces.
Differential Revision: https://reviews.llvm.org/D145097
show more ...
|
#
a3c6a7d5 |
| 21-Feb-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Stricter interface compatibility checking for TBP overrides
The compiler currently ignores attributes for PASS dummy arguments that are incompatible between a type-bound procedure in an exte
[flang] Stricter interface compatibility checking for TBP overrides
The compiler currently ignores attributes for PASS dummy arguments that are incompatible between a type-bound procedure in an extended type and the binding of the same name that it overrides in an ancestor type, if any. Strengthen this checking so that discrepancies between attributes and intents are caught, and add some tests.
Differential Revision: https://reviews.llvm.org/D145110
show more ...
|
#
c6b9df0f |
| 15-Feb-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Refine procedure compatibility checking
The test for compatible function results needs to be nearly strict equality of their types, not the usual actual/dummy type compatibility test used in
[flang] Refine procedure compatibility checking
The test for compatible function results needs to be nearly strict equality of their types, not the usual actual/dummy type compatibility test used in other situations. The exceptional case is that assumed length CHARACTER function results are compatible with explicit length results of the same kind. In particular, a function returning a polymorphic pointer is not compatible with a function returning a monomorphic pointer even of the same declared type.
Differential Revision: https://reviews.llvm.org/D145094
show more ...
|
#
f28c1a9d |
| 11-Feb-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Conform with standard (mostly) for character length mismatches on arguments
Fortran 2018 defines some flavors of dummy arguments to require exact matching of character lengths between dummy
[flang] Conform with standard (mostly) for character length mismatches on arguments
Fortran 2018 defines some flavors of dummy arguments to require exact matching of character lengths between dummy and actual arguments; these situations tend to be those in which the interface must be explicit and a descriptor is involved: assumed shape, assumed rank, allocatable, and pointer.
Fortran allows an actual argument in other cases to have a longer length than the dummy argument; as a common extension, we support a shorter actual argument as well by means of blank padding, but should emit a warning.
Differential Revision: https://reviews.llvm.org/D143821
show more ...
|
#
50960e93 |
| 03-Jan-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Catch character length errors in pointer associations
When character lengths are known at compilation time, report an error when a data target with a known length does not match the explicit
[flang] Catch character length errors in pointer associations
When character lengths are known at compilation time, report an error when a data target with a known length does not match the explicit length of a pointer that is being associated with it; see 10.2.2.3 paragraph 5.
Differential Revision: https://reviews.llvm.org/D142755
show more ...
|
#
042c964d |
| 13-Jan-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Fix defined I/O semantics crash & missing errors that exposed it
Semantics crashes when emitting runtime derived type information tables for a type that has user-defined I/O procedures decla
[flang] Fix defined I/O semantics crash & missing errors that exposed it
Semantics crashes when emitting runtime derived type information tables for a type that has user-defined I/O procedures declared outside the type with explicit INTERFACE blocks (as opposed to a GENERIC binding within the type). This is due to the runtime table constructor adding a table entry for each specific procedure of any explicit interface of the right kind (e.g., READ(UNFORMATTED)) that it found, rather than just the ones that pertain to the derived type in question. But semantics also wasn't checking such interfaces for distinguishable specific procedures, either.
Clean these up, improve the spelling of defined I/O procedure kinds in error messages ("read(formatted)" rather than "READFORMATTED"), and make error messages stemming from macro expansions only have one "error:" prefix on the original message so that a new test would work.
Differential Revision: https://reviews.llvm.org/D142769
show more ...
|
#
036701a1 |
| 01-Jan-2023 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Correct procedure pointer (or dummy) compatibility check
Fix a subtle bug in procedure compatibility checking with base derived types vs. their extensions to ensure that a procedure expectin
[flang] Correct procedure pointer (or dummy) compatibility check
Fix a subtle bug in procedure compatibility checking with base derived types vs. their extensions to ensure that a procedure expecting an extended type cannot be associated with a pointer (or dummy procedure) to a procedure expecting a base type.
subroutine s1(base); ... subroutine s2(extended) procedure(s1), pointer :: p p => s2 ! <- must be caught as an error
Differential Revision: https://reviews.llvm.org/D142753
show more ...
|
#
635656f4 |
| 16-Dec-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Expunge needless semantics::ProcInterface
The ProcInterface structure is used only by ProcEntityDetails; it represents what a program might have put in parentheses in a procedure-declaration
[flang] Expunge needless semantics::ProcInterface
The ProcInterface structure is used only by ProcEntityDetails; it represents what a program might have put in parentheses in a procedure-declaration-stmt, either the name of a procedure interface or a declaration-type-spec.
If a procedure entity has an implicit interface, the function result type (if any) can be kept in EntityDetails::type_, which already exists and is currently redundant for ProcEntityDetails symbols.
All that is really needed is a nullable Symbol pointer in ProcEntityDetails to point to the procedure's explicit interface, when it has one.
Also, catch the case where a procedure has an explicit interface and a program attempts to also give it a type.
Differential Revision: https://reviews.llvm.org/D140134
show more ...
|
#
9114ce4d |
| 09-Nov-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Take character function length into account when testing compatibility
When a character-valued function is passed as an actual argument, and both the actual function and the dummy argument h
[flang] Take character function length into account when testing compatibility
When a character-valued function is passed as an actual argument, and both the actual function and the dummy argument have explicit result lengths, take them into account when testing for compatibility.
Differential Revision: https://reviews.llvm.org/D139129
show more ...
|
#
bcba39a5 |
| 11-Nov-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Restore ENUM_CLASS() to be compilation-time code
Rework some recent changes to the ENUM_CLASS() macro so that all of the construction of enumerator-to-name string mapping data structures is
[flang] Restore ENUM_CLASS() to be compilation-time code
Rework some recent changes to the ENUM_CLASS() macro so that all of the construction of enumerator-to-name string mapping data structures is again performed at compilation time.
Differential Revision: https://reviews.llvm.org/D137859
show more ...
|
#
74d5c3c0 |
| 02-Nov-2022 |
Peter Steinfeld <psteinfeld@nvidia.com> |
[Flang] Run clang-format on all flang files
This will make it easier for me to do reviews.
Differential Revision: https://reviews.llvm.org/D137291
|
#
66fdfff7 |
| 24-Oct-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Require explicit interface for some dummy procedures
Some of the circumstances that require that a procedure have an explicit interface at a point of call due to a characteristic of a dummy
[flang] Require explicit interface for some dummy procedures
Some of the circumstances that require that a procedure have an explicit interface at a point of call due to a characteristic of a dummy argument apply to dummy procedures, too.
Differential Revision: https://reviews.llvm.org/D136994
show more ...
|
#
3850edd9 |
| 03-Sep-2022 |
Kazu Hirata <kazu@google.com> |
Use llvm::count_if (NFC)
|
#
c1a77839 |
| 18-Aug-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Avoid spurious error message in function result compatibility
When checking function interface compatibility for procedure pointer assignment/initialization or actual/dummy procedure associa
[flang] Avoid spurious error message in function result compatibility
When checking function interface compatibility for procedure pointer assignment/initialization or actual/dummy procedure association, don't emit a diagnositic about function result shape incompatibility unless the interfaces differ in rank or have distinct constant extents on a dimension. Function results whose dimensions are determined by dummy arguments or host-associated variables are not necessarily incompatible.
Differential Revision: https://reviews.llvm.org/D132162
show more ...
|
#
46c49e66 |
| 09-Aug-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Extend characterization & checking for procedure bindings
Procedure bindings with explicit interfaces don't work when the interface is shadowed by a generic interface of the same name, and c
[flang] Extend characterization & checking for procedure bindings
Procedure bindings with explicit interfaces don't work when the interface is shadowed by a generic interface of the same name, and can produce spurious semantic error messages. Extend the characterization and checking code for such things, and the utility functionns on which they depend, to dig through generics when they occlude interface-defining subprograms. This is done on demand in checking code, not once during name resolution, because the procedures in question may also be forward-referenced.
Differential Revision: https://reviews.llvm.org/D131105
diff --git a/flang/include/flang/Semantics/symbol.h b/flang/include/flang/Semantics/symbol.h index e79f8ab6503e..0b03bf06eb73 100644 --- a/flang/include/flang/Semantics/symbol.h
show more ...
|
#
5e8094ba |
| 27-Jul-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Don't inherit ELEMENTAL attribute from intrinsics for TBP bindings
Type-bound procedure bindings that specify intrinsic procedures as their interfaces should not acquire the ELEMENTAL attrib
[flang] Don't inherit ELEMENTAL attribute from intrinsics for TBP bindings
Type-bound procedure bindings that specify intrinsic procedures as their interfaces should not acquire the ELEMENTAL attribute from the purposes of compatibility checking between inherited bindings and their overrides in extended derived types.
Differential Revision: https://reviews.llvm.org/D131104
show more ...
|
#
95f4ca7f |
| 22-Jul-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Allow restricted specific intrinsic functions as implicitly-interfaced procedure pointer targets
The predicate "CanBeCalledViaImplicitInterface()" was returning false for restricted specific
[flang] Allow restricted specific intrinsic functions as implicitly-interfaced procedure pointer targets
The predicate "CanBeCalledViaImplicitInterface()" was returning false for restricted specific intrinsic functions (e.g., SIN) because their procedure characteristics have the elemental attribute; this leads to a bogus semantic error when one attempts to use them as proc-targets in procedure pointer assignment statements when the left-hand side of the assignment is a procedure pointer with an implicit interface. However, these restricted specific intrinsic functions have always been allowed as special cases for such usage -- it is as if they are elemental when it is necessary for them to be so, but not when it's a problem.
Differential Revision: https://reviews.llvm.org/D130386
show more ...
|