Commit Graph

196 Commits

Author SHA1 Message Date
Peter Klausler 46c49e66d8 [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
2022-08-09 12:01:45 -07:00
Peter Klausler 37a0022aaa [flang] Don't lose homonymous specific when copying generic
Defined generic procedure interfaces are allowed to shadow non-generic
procedures of the same name in the same scope (whether or not
that non-generic procedure is a specific procedure of the generic).
When making a copy of a generic interface symbol so that it can
be locally modified or be merged with another generic, don't forget
about the homonymous non-generic procedure that it might shadow.

Differential Revision: https://reviews.llvm.org/D131103
2022-08-09 07:44:52 -07:00
Peter Klausler e1ee20d574 [flang] Ignore inaccessible components when extending types or constructing structures
Inaccessible components -- those declared PRIVATE in another module -- should
be allowed to be redeclared in extended types, and should be ignored if
they appear as keywords in structure constructors.

Differential Revision: https://reviews.llvm.org/D131102
2022-08-09 07:44:02 -07:00
Peter Klausler a9782fead3 [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
2022-07-23 10:46:54 -07:00
Peter Klausler e03664d40c [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
2022-07-22 16:54:46 -07:00
Peter Klausler b7f8314270 [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
2022-07-13 16:58:26 -07:00
Peter Klausler 0406c0cda6 [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
2022-07-13 16:36:25 -07:00
Peter Klausler 23c2bedfd9 [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.
2022-07-06 10:25:34 -07:00
Peter Klausler f161964e1c [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
2022-06-29 11:34:51 -07:00
Peixin-Qiao 779d2470a4 [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
2022-06-29 11:25:19 +08:00
Peter Klausler cfd474e0d0 [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
2022-06-28 11:00:12 -07:00
Peixin Qiao 3fa62efdbb [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
2022-06-23 00:04:24 +08:00
Peixin-Qiao 3151fb5ef7 [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
2022-06-15 15:39:13 +08:00
Peixin-Qiao dafd3cf8b1 [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
2022-06-14 10:34:38 +08:00
Peter Klausler 8eebf46964 [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
2022-06-13 16:15:47 -07:00
PeixinQiao 1f17a8978c [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
2022-06-09 00:43:30 +08:00
Peter Klausler 0c190575eb [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
2022-05-28 09:33:53 -07:00
Peter Klausler ddd692e9d5 [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
2022-05-25 17:14:59 -07:00
Peter Klausler 6b99dc29c6 [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
2022-05-25 14:47:50 -07:00
Peter Klausler d52a6e75b0 [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
2022-05-24 14:00:20 -07:00
Peter Klausler cd2a8df891 [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
2022-05-24 13:34:58 -07:00
Peter Klausler 7f680b260f [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
2022-05-23 21:48:35 -07:00
Peter Klausler 9f33dd733f [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
2022-05-23 18:21:42 -07:00
Peter Klausler 8c407f4a11 [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
2022-05-09 19:12:23 -07:00
Peter Klausler 8594b051fb [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
2022-05-09 18:37:09 -07:00
Peter Klausler 3382edf9b9 [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
2022-05-09 17:49:47 -07:00
Jean Perier ed0341788a [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
2022-05-09 09:50:17 +02:00
Peixin-Qiao c207e36025 [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
2022-05-09 10:48:06 +08:00
Daniil Dudkin 2c27d5b36a [flang] Fix internal error with DATA-statement style initializers
The code below causes flang to crash with an exception.
After fixing the crash flang with an internal error "no symbol found for 'bar'"
This change fixes all the issues.

  program name
    implicit none
    integer, parameter :: bar = 1
    integer foo(bar) /bar*2/
  end program name

Reviewed By: kiranchandramohan, klausler

Differential Revision: https://reviews.llvm.org/D124914
2022-05-06 18:21:34 +03:00
Peter Steinfeld d134442200 [flang][nfc] Use a message class for "not yet implemented" messages
Following a previous suggestion from Peter Klausler.

Differential Revision: https://reviews.llvm.org/D124972
2022-05-05 07:12:22 -07:00
Peter Klausler 787ee99d4f [flang] Allow for host association in ConvertTo(Object|Proc)Entity
Name resolution fails with a bogus "is not a variable" error message
when a host-associated object appears in a NAMELIST group.  The root
cause is that ConvertToObjectEntity() returns false for host-associated
objects.  Fix that, and also apply a similar fix to ConvertToProcEntity()
nearby.

Differential Revision: https://reviews.llvm.org/D124541
2022-04-27 12:30:03 -07:00
Peter Klausler 72904a990c [flang] Avoid global name conflict when BIND(C,NAME=) is used
At the top level of program units in a source file, two subprograms
are allowed to have the same name if at least one of them has a
distinct interoperable binding name.  F18's symbol table requires
(most) symbols in a scope to have distinct names, though.  Solve
by using compiler-created names for the symbols of global scope
subprograms that have interoperable binding names.

Differential Revision: https://reviews.llvm.org/D124295
2022-04-25 09:25:44 -07:00
Peter Klausler bf8f9b35c1 [flang] Fix regression from generic fix
A recent change that corrected the name resolution of a generic interface
when the same name was visible in scope incorrectly prevented a local
generic from shadowing an outer name that is not a generic, subprogram,
or derived type -- e.g., a simple variable -- leading to an inappropriate
error message.

Differential Revision: https://reviews.llvm.org/D124276
2022-04-22 12:26:44 -07:00
Peter Klausler cd03e96f00 [flang] Add & use a better visit() (take 2)
Adds flang/include/flang/Common/log2-visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit().  Modifies most use sites in
the front-end and runtime to use common::visit().

The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.

Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().

Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.

This change is enabled only for GCC builds with GCC >= 9;
an earlier attempt (D122441) ran into bugs in some versions of
clang and was reverted rather than simply disabled; and it is
not well tested with MSVC. In non-GCC and older GCC builds,
common::visit() is simply an alias for std::visit().
2022-04-16 16:00:48 -07:00
Peter Klausler 9f5f2eb2a1 [flang] Accept %KIND type parameter inquiries on %RE,%IM, &c.
The x%KIND inquiry needs to be supported when 'x' is itself
a complex part reference or a type parameter inquiry.

Differential Revision: https://reviews.llvm.org/D123733
2022-04-15 20:22:03 -07:00
Peter Klausler de6e88ef5a [flang] Allow POINTER attribute statement on procedure interfaces
A POINTER attribute statement is allowed to add the POINTER attribute
to a procedure entity that has already been declared, e.g. with an
INTERFACE block.

Differential Revision: https://reviews.llvm.org/D123732
2022-04-15 20:20:56 -07:00
Peter Klausler 9e7eef9989 [flang] Handle parameter-dependent types in PDT initializers
For parameterized derived type component initializers whose
expressions' types depend on parameter values, f18's current
scheme of analyzing the initialization expression once during
name resolution fails.  For example,

  type :: pdt(k)
    integer, kind :: k
    real :: component = real(0.0, kind=k)
  end type

To handle such cases, it is necessary to re-analyze the parse
trees of these initialization expressions once for each distinct
initialization of the type.

This patch adds code to wipe an expression parse tree of its
typed expressions, and update those of its symbol table pointers
that reference type parameters, and then re-analyze that parse
tree to generate the properly typed component initializers.

Differential Revision: https://reviews.llvm.org/D123728
2022-04-15 16:20:41 -07:00
Peter Klausler 7c71ce97e7 [flang] Defer NAMELIST group item name resolution
Items in NAMELIST groups might be host-associated implicitly-typed
variables, but name resolution can't know that when the NAMELIST
appears in a specification part and the host's execution part has
not yet been analyzed.  So defer NAMELIST group item name resolution
to the end of the execution part.  This is safe because nothing
else in name resolution depends on whether a variable is in a
NAMELIST group or not.

Differential Revision: https://reviews.llvm.org/D123723
2022-04-14 17:50:03 -07:00
Peter Klausler 625dedc3fe [flang] Allow modification of construct entities
Construct entities from ASSOCIATE, SELECT TYPE, and SELECT RANK
are modifiable if the are associated with modifiable variables
without vector subscripts.  Update WhyNotModifiable() to accept
construct entities that are appropriate.

A need for more general error reporting from one overload of
WhyNotModifiable() caused its result type to change to
std::optional<parser::Message> instead of ::MessageFixedText,
and this change had some consequences that rippled through
call sites.

Some test results that didn't allow for modifiable construct
entities needed to be updated.

Differential Revision: https://reviews.llvm.org/D123722
2022-04-14 16:58:08 -07:00
Peter Klausler 95199af4ae [flang] Local generics must not shadow host-associated generics
It is possible for generic interfaces of equivalent (but not necessarily
identical -- operator(.eq.) is equivalent to operator(==)) names to
be declared in a host scope and a nested scope, and the nested declaration
should function as an extension of the host's.

Differential Revision: https://reviews.llvm.org/D123719
2022-04-14 15:43:59 -07:00
Peter Klausler 8065e48218 [flang] Inner INTRINSIC must not shadow host generic
A generic interface (however spelled) can have the same name as
an intrinsic procedure in the same scope.  When an explicit INTRINSIC
attribute statement appears in a nested scope, semantics was
unconditionally declaring a new symbol that hid the generic entirely.
Catch this case and create instead a host association symbol for
the generic that can then be decorated with the INTRINSIC attribute.

Differential Revision: https://reviews.llvm.org/D123718
2022-04-14 15:42:44 -07:00
Peter Klausler eb14135e35 [flang] Correct interaction between generics and intrinsics
Fortran allows a generic interface to have he same name as an
intrinsic procedure.  If the intrinsic is explicitly marked with
the INTRINSIC attribute, restrictions apply (C848) - the generic
must contain only functions or subroutines, depending on the
intrinsic.  Explicit or not, the generic overrides the intrinsic,
but the intrinsic behavior must still be available for calls
whose actual arguments do not match any of the specific procedures.

Semantics was not checking constraint C848, and it didn't allow
an explicit INTRINSIC attribute on a name of a generic interface.

Differential Revision: https://reviews.llvm.org/D123713
2022-04-14 13:56:04 -07:00
Peter Klausler 6111ddedc8 [flang] Defer all function result type processing
When a type specification appears in the prefix of a FUNCTION statement,
defer its processing as late as possible so that any symbols in the
tpe specification can be resolved in the function's scope to local
declarations, including use-associated symbols.  f18 was already doing
this deferral in a limited form for derived types, and this patch
makes it work for intrinsic type parameter values as well.

In short, "real(kind(x)) function foo(x)" now works as it should.

"As late as possible" means the end of the specification part, or
the first appearance of the function result name in the specification
part.

Differential Revision: https://reviews.llvm.org/D123705
2022-04-14 10:25:57 -07:00
Peter Klausler 9b200074b1 [flang] Fix combining cases of USE association & generic interfaces
Fortran admits a few ways to have multiple symbols with the
same name in the same scope.  Two of them involve generic
interfaces (from INTERFACE or GENERIC, the syntax doesn't matter);
these are allowed to inhabit a scope with either a derived type or
a subprogram that is also a specific procedure of the generic.
(But not both a derived type and a subprogram; they could not
cohabit a scope anyway, generic or not.)

In cases of USE association, f18 needs to be capable of combining
use-associated generic interfaces with other use-associated entities.
Two generics get merged (this case was nearly correct); a generic
and a derived type can merge into a GenericDetails with a shadowed
derivedType(); and a generic can replace or ignore a use-associated
procedure of the same name so long as that procedure is already
one of its specifics.

Further, these modifications to the use-associated generic
interface must be made to a local copy of the symbol.  The previous
code was messing directly with the symbol in the module's scope.

The fix is basically a reimplementation of the member function
DoAddUse() in name resolution.

Differential Revision: https://reviews.llvm.org/D123704
2022-04-14 08:59:52 -07:00
Peter Klausler ef141aec3c [flang] Improve appearance of message attachments
Error messages can have a list of attachments; these are used to point
to related source locations, supply additional information, and to
encapsulate error messages that were *not* emitted in a given context
to explain why a warning was justified.

This patch adds a message severity ("Because") for that last case,
and extends to AttachTo() API to provide a means for overriding
the severity of an attached message.

Some existing message attachments had their severities adjusted,
now that we're printing them.  And operator==() for Message was
cleaned up while debugging after I noticed that it was recursively
O(N**2) and subject to returning a false positive.

Differential Revision: https://reviews.llvm.org/D123710
2022-04-14 07:34:50 -07:00
Mike Kashkarov d2bcb0a129 [flang] Allow IMPLICIT NONE(EXTERNAL) with GenericDetails
Restrictions of IMPLICIT NONE(EXTERNAL) prohibits usage of c_associated from
iso_c_binding (with explicit interface) without external definiton - relax
associated check.

Reviewed By: klausler

Differential Revision: https://reviews.llvm.org/D120971
2022-04-14 12:45:21 +03:00
Andrzej Warzynski 4ca111d4cb Revert "[flang] Add & use a better visit()"
This reverts commit 2ab9990c9e. It has
caused multiple build failures:
*  https://lab.llvm.org/buildbot/#/builders/177/builds/4346
*  https://lab.llvm.org/buildbot/#/builders/180/builds/3803
*  https://lab.llvm.org/buildbot/#/builders/175/builds/10419
*  https://lab.llvm.org/buildbot/#/builders/191/builds/4318
*  https://lab.llvm.org/buildbot/#/builders/173/builds/4274
*  https://lab.llvm.org/buildbot/#/builders/181/builds/4297

All these bots failed with a time-out:
```
command timed out: 1200 seconds without output running [b'ninja', b'-j', b'32'], attempting to kill
```
I'm guessing that that's due to template instantiations failing at some
point (https://reviews.llvm.org/D122441 introduced a custom
implementation of std::visit). Everything seems fine when either:
* building on X86 with GCC or Clang (tested with GCC 9.3 and Clang 12)
* building on AArch64 with GCC (tested with GCC 11)
2022-03-28 10:46:47 +00:00
Peter Klausler 2ab9990c9e [flang] Add & use a better visit()
Adds flang/include/flang/Common/visit.h, which defines
a Fortran::common::visit() template function that is a drop-in
replacement for std::visit().  Modifies most use sites in
the front-end and runtime to use common::visit().

The C++ standard mandates that std::visit() have O(1) execution
time, which forces implementations to build dispatch tables.
This new common::visit() is O(log2 N) in the number of alternatives
in a variant<>, but that N tends to be small and so this change
produces a fairly significant improvement in compiler build
memory requirements, a 5-10% improvement in compiler build time,
and a small improvement in compiler execution time.

Building with -DFLANG_USE_STD_VISIT causes common::visit()
to be an alias for std::visit().

Calls to common::visit() with multiple variant arguments
are referred to std::visit(), pending further work.

Differential Revision: https://reviews.llvm.org/D122441
2022-03-25 13:15:20 -07:00
Peter Steinfeld df209b8038 [flang] Make not yet implemented messages more consistent
To make it easier to find things that are not yet implemented, I'm changing the
messages that appear in the compiler's output to all have the string "not yet
implemented:".

These changes apply to files in the front end.  I have another set of changes
to files in the lowering code.

Differential Revision: https://reviews.llvm.org/D122355
2022-03-24 15:19:40 -07:00
Peter Klausler 54d19ba208 [flang] Fix crash: ENTRY with generic interface of the same name
Name resolution was crashing while processing the ENTRY statement
due to a lack of special-case code necessary to handle the indirection
needed when the generic has the same name as the ENTRY.

Differential Revision: https://reviews.llvm.org/D122050
2022-03-22 11:10:30 -07:00