[flang] Remove needless "anyIntrinsicDefinedOps", fixing iterative expr analysis

The flag "anyIntrinsicDefinedOps" is always set nowadays, as there are intrinsic
modules that define operator(==) and

[flang] Remove needless "anyIntrinsicDefinedOps", fixing iterative expr analysis

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

show more ...

[flang] Allow reference to earlier generic in later interface

Name resolutions defers all resolution and checking of specific procedures
in non-type-bound generic interfaces to the end of the specif

[flang] Allow reference to earlier generic in later interface

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

show more ...

[flang] Foil attempt to READ a NAMELIST with an undefinable member

Detect and emit errors about undefinable NAMELIST group members in READ statements.

Fixes llvm-test-suite/Fortran/gfortran/regress

[flang] Foil attempt to READ a NAMELIST with an undefinable member

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

show more ...

[flang] Fix bogus error on recursive ENTRY

An incorrect "Implicit declaration of function '...' has a different result type
than in previous declaration" is being emitted for ENTRY names used
recurs

[flang] Fix bogus error on recursive ENTRY

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

show more ...

[flang] Extension: unrestricted intrinsics as specifics in generics

At least one other Fortran compiler supports the use of unrestricted intrinsic
functions as specific procedures in generic interfa

[flang] Extension: unrestricted intrinsics as specifics in generics

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

show more ...

[flang] Correct handling of non-default lower bounds in ASSOCIATE with named constants

Work through several issues with LBOUND() and UBOUND() of ASSOCIATE
construct entities that have been associate

[flang] Correct handling of non-default lower bounds in ASSOCIATE with named constants

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

show more ...

[flang] Support implicit global external as procedure pointer target

A name that has been used to reference an undeclared global external
procedure should be accepted as the target of a procedure po

[flang] Support implicit global external as procedure pointer target

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

show more ...

[flang] Extension: allow DATA to precede declaration under IMPLICIT NONE(TYPE)

It is not standard conforming under IMPLICIT NONE(TYPE) for a name to
appear in a DATA statement prior to its explicit

[flang] Extension: allow DATA to precede declaration under IMPLICIT NONE(TYPE)

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.

show more ...

[flang] Correct disambiguation of possible statement function definitions

The statement "A(J) = expr" could be an assignment to an element of an
array A, an assignment to the target of a pointer-val

[flang] Correct disambiguation of possible statement function definitions

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

show more ...

[Flang][OpenMP] Add source range for a few directives

The sourcerange was missing for a few directives when
they were the first directive to appear in a program
without a program statement.

Reviewe

[Flang][OpenMP] Add source range for a few directives

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

show more ...

[flang] Prevent lowering crash by properly updating symbol pointer

Kind of an edge case. When a MODULE FUNCTION or SUBROUTINE
interface is defined by a MODULE PROCEDURE in the same program
unit, en

[flang] Prevent lowering crash by properly updating symbol pointer

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

show more ...

[flang] add nested DEC STRUCTURE in DerivedTypeDetails component names

Currently, when a (legacy) DEC structure contained other DEC structure
declarations, the related component names were not added

[flang] add nested DEC STRUCTURE in DerivedTypeDetails component names

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

show more ...

[flang] Fix bug with generic and homonymous specific module procedure

An unconditional EraseSymbol() call was deleting a generic interface symbol
when the generic had a module procedure of the same

[flang] Fix bug with generic and homonymous specific module procedure

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

show more ...

[flang] Fix USE with homonymous renaming

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 reso

[flang] Fix USE with homonymous renaming

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

show more ...

[flang] Rework name resolution of Cray pointer declarations

The current code has redundancy with the infrastructure for
declaration checking that can be replaced by better usage of
the parse tree wa

[flang] Rework name resolution of Cray pointer declarations

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

show more ...

wip

[flang] rename PPC specific intrinsic modules (NFC)

[flang] Add PowerPC vec_add, vec_and, vec_mul, vec_sub and vec_xor intrinsics

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

[flang] CUDA Fortran - part 5/5: statement semantics

Canonicalize !$CUF KERNEL DO loop nests, similar to OpenACC/OpenMP
canonicalization. Check statements and expressions in device contexts
for usa

[flang] CUDA Fortran - part 5/5: statement semantics

Canonicalize !$CUF KERNEL DO loop nests, similar to OpenACC/OpenMP
canonicalization. Check statements and expressions in device contexts
for usage that isn't supported. Add more tests, and include some
tweaks to standard modules needed to build CUDA Fortran modules.

Depends on https://reviews.llvm.org/D150159,
https://reviews.llvm.org/D150161, https://reviews.llvm.org/D150162, &
https://reviews.llvm.org/D150163.

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

show more ...

[flang] CUDA Fortran - part 2/5: symbols & scopes

Add representations of CUDA Fortran data and subprogram attributes
to the symbol table and scopes of semantics. Set them in name
resolution, and em

[flang] CUDA Fortran - part 2/5: symbols & scopes

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

show more ...

[flang] CUDA Fortran - part 1/5: parsing

Begin upstreaming of CUDA Fortran support in LLVM Flang.

This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature en

[flang] CUDA Fortran - part 1/5: parsing

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

show more ...

[flang] Support for PowerPC vector type

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

[flang] Support for PowerPC vector type

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

show more ...

[flang] Better error handling and testing of generics with homonymous specifics or derived types

Fortran allows a generic procedure interface to have the same name as a derived
type in the same scop

[flang] Better error handling and testing of generics with homonymous specifics or derived types

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

show more ...

[flang] Don't complain about dummy subroutine under IMPLICIT NONE

The compiler emits a bogus 'No explicit type declared for...' error
when a dummy procedure turns out to be a subroutine (or at least

[flang] Don't complain about dummy subroutine under IMPLICIT NONE

The compiler emits a bogus 'No explicit type declared for...' error
when a dummy procedure turns out to be a subroutine (or at least not
a function or object) under control of IMPLICIT NONE.

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

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

show more ...

[flang] Allow redudant attributes on use-/host- associated names

Constraint C815 in F'2018 allows a name to acquire an attribute at
most once per scope. For some attributes, the attribute may have

[flang] Allow redudant attributes on use-/host- associated names

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

show more ...