[flang] Fix bogus error under IMPLICIT NONE(EXTERNAL)

Don't emit an error message for a possible implicit use of an
external procedure when it is known that the symbol is not
a procedure (e.g., an a

[flang] Fix bogus error under IMPLICIT NONE(EXTERNAL)

Don't emit an error message for a possible implicit use of an
external procedure when it is known that the symbol is not
a procedure (e.g., an array).

Fixes https://github.com/llvm/llvm-project/issues/62047

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

show more ...

[flang] Finer control over warnings

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 freq

[flang] Finer control over warnings

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

show more ...

[flang] Apply default module accessibility rules a second time (bug#62598)

Apply the default PUBLIC/PRIVATE accessibility of a module to its symbols
a second time after it is known that all symbols,

[flang] Apply default module accessibility rules a second time (bug#62598)

Apply the default PUBLIC/PRIVATE accessibility of a module to its symbols
a second time after it is known that all symbols, including implicitly typed
names from NAMELIST groups and specification expressions in module subprograms,
have been created in its scope.

Fixes https://github.com/llvm/llvm-project/issues/62598.

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

show more ...

[OpenMP][Flang][Semantics] Add semantics support for USE_DEVICE_PTR clause on OMP TARGET DATA directive.

Initial support for USE_DEVICE_PTR clause on OMP TARGET DATA directive.

Reviewed By: kiranch

[OpenMP][Flang][Semantics] Add semantics support for USE_DEVICE_PTR clause on OMP TARGET DATA directive.

Initial support for USE_DEVICE_PTR clause on OMP TARGET DATA directive.

Reviewed By: kiranchandramohan

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

show more ...

[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

[flang] Resolve USE vs IMPORT conflicts

When the same name is pulled into a scope more than once via
USE and IMPORT, emit an error if its resolutions are ambiguous,
or (as an extension like some oth

[flang] Resolve USE vs IMPORT conflicts

When the same name is pulled into a scope more than once via
USE and IMPORT, emit an error if its resolutions are ambiguous,
or (as an extension like some other compilers) emit a portability
warning when the names all resolve to the same symbol.

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

show more ...

[flang] Move SAVE attribute checks to declaration checking

Constraint checking for explicit SAVE attributes is more
accurate when done along with other declaration checking, rather
than on the fly d

[flang] Move SAVE attribute checks to declaration checking

Constraint checking for explicit SAVE attributes is more
accurate when done along with other declaration checking, rather
than on the fly during name resolution. This allows us to
catch attempts to attach explicit SAVE attributes to anything
that can't have one (constraints C859, C860).

Also delete `IsSave()`, whose few remaining uses were changed to the
more general `IsSaved()` predicate that seems more correct for
those uses, returning true for both explicit and implied SAVE
attributes.

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

show more ...

[flang] Reimplement C1406 check as a warning

Constraint C1406 in Fortran 2018 prohibits the USE of the same module
name as both an intrinsic module and a non-intrinsic module in a scope.
The current

[flang] Reimplement C1406 check as a warning

Constraint C1406 in Fortran 2018 prohibits the USE of the same module
name as both an intrinsic module and a non-intrinsic module in a scope.
The current check misinterprets the constraint as applying only to
explicitly INTRINSIC or NON_INTRINSIC module natures.

Change the check to also apply to non-explicit module natures, and
also downgrade it to a portability warning, since there is no ambiguity
and I suspect that we need to accept this usage when building f18's
own intrinsic modules.

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

show more ...

[flang] Correct handling of USE-associated generic override in nested scope

As the new test here shows by failing with the current compiler with
a bogus error message about indistinguishable specifi

[flang] Correct handling of USE-associated generic override in nested scope

As the new test here shows by failing with the current compiler with
a bogus error message about indistinguishable specific procedures in
a generic interface, name resolution needs to take care to not
copy a USE-associated generic into the current scope for extension
when the USE association is actually into an enclosing scope.

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

show more ...

[flang] Fix checking of TBP bindings

Non-DEFERRED procedure binding checking can't blindly accept
all procedures defined in modules -- they can't be ABSTRACT
interfaces. And GetUltimate() must be u

[flang] Fix checking of TBP bindings

Non-DEFERRED procedure binding checking can't blindly accept
all procedures defined in modules -- they can't be ABSTRACT
interfaces. And GetUltimate() must be used rather than
FindSubprogram(); the latter will resolve to a procedure's
interface in the case of "procedure(interface) :: external",
not "external".

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

show more ...

[flang] Forward references to COMMON from specification expr under IMPLICIT NONE

As a near-universal extension, Fortran compilers permit forward references
to dummy arguments and variables in COMMON

[flang] Forward references to COMMON from specification expr under IMPLICIT NONE

As a near-universal extension, Fortran compilers permit forward references
to dummy arguments and variables in COMMON blocks from specification expressions
before an explicit type-declaration-stmt appears for those variables
under IMPLICIT NONE, so long as those variables are later explicitly typed
with the types that regular implicit typing rules would have given them
(usually default INTEGER).

F18 implemented this extension for dummy arguments, but not variables in
COMMON blocks. Extend the extension to also accept variables in COMMON.

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

show more ...

[flang] Fix CONTIGUOUS attribute for construct entities

Currently, the selector of a construct entity (e.g., ASSOCIATE(x=>a(1:20)))
is inheriting the CONTIGUOUS attribute from its associated variabl

[flang] Fix CONTIGUOUS attribute for construct entities

Currently, the selector of a construct entity (e.g., ASSOCIATE(x=>a(1:20)))
is inheriting the CONTIGUOUS attribute from its associated variable
even if it has subscripts that make it noncontiguous (a(1:20:2)).
Add construct entities to the dynamic contiguity predicate instead.

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

show more ...

[flang] Move check for statement function in BLOCK construct

A BLOCK construct may not contain a statement function definition;
but it may of course contain an assignment statement with an array
ele

[flang] Move check for statement function in BLOCK construct

A BLOCK construct may not contain a statement function definition;
but it may of course contain an assignment statement with an array
element on its left-hand side that looks like a statement function
definition. These misparsed statement functions are converted
into assignment statements during semantics once it is clear what
they are. Move the C1107 check for a statement function definition
in a block construct into declaration checking, which is where it
probably should have been in the first place anyway.

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

show more ...

[flang] Catch name conflict between generic TBP and inherited non-generic

A generic procedure binding in an extended derived type may not have the
same name as a symbol inherited from an ancestor ty

[flang] Catch name conflict between generic TBP and inherited non-generic

A generic procedure binding in an extended derived type may not have the
same name as a symbol inherited from an ancestor type unless that inherited
symbol is also a generic TBP. Since generic names can be things like
"ASSIGNMENT(=)", name resolution doesn't use OkToAddComponent() for
generic TBPs, which would have caught this error as it does for other
symbols in derived types, so it must be special-cased.

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

show more ...

[flang] BIND(C,NAME=...) corrections

The Fortran standard's various restrictions on the use of BIND(C)
often depend more on the presence or absence of an explicit NAME=
specification rather than on

[flang] BIND(C,NAME=...) corrections

The Fortran standard's various restrictions on the use of BIND(C)
often depend more on the presence or absence of an explicit NAME=
specification rather than on its value, but semantics and module
file generation aren't making distinctions between explicit NAME=
specifications that happen to match the default name and declarations
that don't have NAME=. Tweak semantics and module file generation
to conform, and also complain when named BIND(C) attributes are
erroneously applied to entities that can't support them, like
ABSTRACT interfaces.

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

show more ...

[Flang] Add PowerPC intrinsics

This patch adds a subset of PowerPC intrinsics - fmadd,
fmsub, fnmadd and fnmsub.

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

[flang] Fix USE rename

Fix USE rename when use-name and local-name are the same.
Previously, the associated symbol was being removed from scope.

Operator rename implementation needed no change, bec

[flang] Fix USE rename

Fix USE rename when use-name and local-name are the same.
Previously, the associated symbol was being removed from scope.

Operator rename implementation needed no change, because, as it
doesn't call AddUseRename(), symbol erasure is skipped.

Fixes #60223

Reviewed By: klausler

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

show more ...

[flang] Catch repeated BIND(C) attribute specifications for a symbol

A BIND(C) attribute statement or type-declaration-stmt attribute, just
like most attributes, can only appear once. Name resoluti

[flang] Catch repeated BIND(C) attribute specifications for a symbol

A BIND(C) attribute statement or type-declaration-stmt attribute, just
like most attributes, can only appear once. Name resolution was excluding
the BIND(C) attribute from its check for duplicated attributes, but I
don't see a reason that remains to do so.

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

show more ...

[flang] Allow for user-defined intrinsic operators (regression)

The recent code that uses an iterative rather than recursive walk
over the parse tree when processing expressions needs to allow for
t

[flang] Allow for user-defined intrinsic operators (regression)

The recent code that uses an iterative rather than recursive walk
over the parse tree when processing expressions needs to allow for
the rare case in which an intrinsic operator (e.g., +) is extended
by a generic interface in the program.

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

show more ...

[flang] Avoid infinite recursion in common block check

Don't call CheckCommonBlockDerivedType() recursively if the
derived type symbol is the same symbol that is already being
processed. This can ha

[flang] Avoid infinite recursion in common block check

Don't call CheckCommonBlockDerivedType() recursively if the
derived type symbol is the same symbol that is already being
processed. This can happen when a component is a pointer of the
same type as its parent component, for instance.

Fixes #60230

Reviewed By: klausler

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

show more ...

[flang] Handle forward references to modules

When a USE of a module precedes its definition in the same source
file, ensure that the module is processed by name resolution before
the USE statement.

[flang] Handle forward references to modules

When a USE of a module precedes its definition in the same source
file, ensure that the module is processed by name resolution before
the USE statement. This prevents the risk of the USE statement using
an obsolete module file that is later overwritten during the same
compilation.

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

show more ...

[flang] Warn about construct names that are not distinct in the inclusive scope

f18 implements BLOCK scoping for construct names, like most but not all Fortran
compilers, but in the 2018 standard su

[flang] Warn about construct names that are not distinct in the inclusive scope

f18 implements BLOCK scoping for construct names, like most but not all Fortran
compilers, but in the 2018 standard such names are defined to be local identifiers
whose scope is the inclusive scope -- i.e., the subprogram or main program.
Detect usage that depends on this extension and emit a portability warning.

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

show more ...

[Flang] [Semantics] More descript warning message for same named external statements and interfaces

For issue: https://github.com/llvm/llvm-project/issues/56605. Previous error messages are not desc

[Flang] [Semantics] More descript warning message for same named external statements and interfaces

For issue: https://github.com/llvm/llvm-project/issues/56605. Previous error messages are not descriptive of problem. Issuing warnings instead that do not halt compilation but offer better description of problem.

Reviewed By: klausler

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

show more ...

[flang] Check for global name conflicts (19.2)

Global names should be checked for conflicts even when not BIND(C).

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

[flang] Catch bad inquiries in specification expressions

When a descriptor inquiry or inquiry function's result is
not constant and is known to be impossible to correctly determine
at runtime, raise

[flang] Catch bad inquiries in specification expressions

When a descriptor inquiry or inquiry function's result is
not constant and is known to be impossible to correctly determine
at runtime, raise an error. For example, LEN(X) when X is
a local allocatable variable with deferred length.

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

show more ...