Commit Graph

17 Commits

Author SHA1 Message Date
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
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 Klausler a53967cd55 [flang] Distinguish usage and portability warning messages
Using recently established message severity codes, upgrade
non-fatal messages to usage and portability warnings as
appropriate.

Differential Revision: https://reviews.llvm.org/D121246
2022-03-08 17:24:52 -08:00
Peter Klausler 2895771faf [flang] Add nonfatal message classes
F18 presently has fatal and non-fatal diagnostic messages.  We'd like
to make non-fatal warnings stand out better in the output of the compiler.

This will turn out to be a large change that affects many files.
This patch is just the first part.  It converts a Boolean isFatal_ data
member of the message classes into a severity code, and defines four
of these codes (Error, Warning, Portability, and a catch-all Other).

Later patches will result from sweeping over the parser and semantics,
changing most non-fatal diagnostic messages into warnings and portability
notes.

Differential Revision: https://reviews.llvm.org/D121228
2022-03-08 11:40:45 -08:00
Peter Klausler 6bd72fa661 [flang] Allow extension cases of EQUIVALENCE with optional warnings
EQUIVALENCE storage association of objects whose types are not
both default-kind numeric storage sequences, or not both default-kind
character storage sequences, are not standard conformant.
However, most Fortran compilers admit such usage, with warnings
in strict conformance mode.  This patch allos EQUIVALENCE of objects
that have sequence types that are either identical, both numeric
sequences (of default kind or not), or both character sequences.
Non-sequence types, and sequences types that are not homogeneously
numeric or character, remain errors.

Differential Revision: https://reviews.llvm.org/D119848
2022-02-15 10:21:38 -08:00
Peter Klausler 44bc97c834 [flang] Adjust names in Semantics that imply too much (NFC)
Some kinds of Fortran arrays are declared with the same syntax,
and it is impossible to tell from a shape (:, :) or (*) whether
the object is assumed shape, deferred shape, assumed size, implied
shape, or whatever without recourse to more information about the
symbol in question.  This patch softens the names of some predicate
functions (IsAssumedShape to CanBeAssumedShape) and makes others
more reflective of the syntax they represent (isAssumed to isStar)
in an attempt to encourage coders to seek and find definitive
predicate functions whose names deliver what they seem to mean.

Address TODO comments in IsSimplyContiguous() by using the
updated IsAssumedShape() predicate.

Differential Revision: https://reviews.llvm.org/D114829
2021-12-01 11:19:19 -08:00
Peter Klausler 996ef895cd [flang] Add -fno-automatic, refine IsSaved()
This legacy option (available in other Fortran compilers with various
spellings) implies the SAVE attribute for local variables on subprograms
that are not explicitly RECURSIVE.  The SAVE attribute essentially implies
static rather than stack storage.  This was the default setting in Fortran
until surprisingly recently, so explicit SAVE statements & attributes
could be and often were omitted from older codes.  Note that initialized
objects already have an implied SAVE attribute, and objects in COMMON
effectively do too, as data overlays are extinct; and since objects that are
expected to survive from one invocation of a procedure to the next in static
storage should probably be explicit initialized in the first place, so the
use cases for this option are somewhat rare, and all of them could be
handled with explicit SAVE statements or attributes.

This implicit SAVE attribute must not apply to automatic (in the Fortran sense)
local objects, whose sizes cannot be known at compilation time.  To get the
semantics of IsSaved() right, the IsAutomatic() predicate was moved into
Evaluate/tools.cpp to allow for dynamic linking of the compiler.  The
redundant predicate IsAutomatic() was noticed, removed, and its uses replaced.

GNU Fortran's spelling of the option (-fno-automatic) was added to
the clang-based driver and used for basic sanity testing.

Differential Revision: https://reviews.llvm.org/D114209
2021-11-22 10:06:38 -08:00
Peter Steinfeld bebbe64075 [flang] Fix creation of deferred shape arrays by POINTER statement
It's possible to  declare deferred shape array using the POINTER
statement, for example:

  POINTER :: var(:)

When analyzing POINTER declarations, we were not capturing the array
specification information, if present.  I fixed this by changing the
"Post" function for "parser::PointerDecl" to check to see if the
declaration contained a "DeferredShapeSpecList".  In such cases, I
analyzed the shape and used to information to declare an "ObjectEntity"
that contains the shape information rather than an "UnknownEntity".

I also added a couple of small tests that fail to compile without these
changes.

Differential Revision: https://reviews.llvm.org/D95080
2021-01-20 13:08:11 -08:00
Tim Keith 7082de56b7 [flang] Handle multiple names for same operator
Some operators have more than one name, e.g. operator(==), operator(.eq).
That was working correctly in generic definitions but they can also
appear in other contexts: USE statements and access statements, for
example.

This changes FindInScope to always look for each of the names for
a symbol. So an operator may be use-associated under one name but
declared private under another name and it will be the same symbol.
This replaces GenericSpecInfo::FindInScope which was only usable in
some cases.

Add a version of FindInScope() that looks in the current scope to
simplify many of the calls.

Differential Revision: https://reviews.llvm.org/D93344
2020-12-16 07:06:55 -08:00
Tim Keith 82edd428f1 [flang] Fix check for distinguishable operators/assignments
Change how generic operators and assignments are checked for
distinguishable procedures. Because of how they are invoked, available
type-bound generics and normal generics all have to be considered
together. This is different from how generic names are checked.

Move common part of checking into DistinguishabilityHelper so that it
can be used in both cases after the appropriate procedures have been
added.

Cache result of Procedure::Characterize(Symbol) in a map in
CheckHelper so that we don't have to worry about passing the
characterized Procedures around or the cost of recomputing them.

Add MakeOpName() to construct names for defined operators and assignment
for using in error messages. This eliminates the need for different
messages in those cases.

When the procedures for a defined operator or assignment are undistinguishable,
include the type name in the error message, otherwise it may be ambiguous.

Add missing check that procedures for defined operators are functions
and that their dummy arguments are INTENT(IN) or VALUE.

Differential Revision: https://reviews.llvm.org/D87341
2020-09-10 07:22:55 -07:00
peter klausler 31e6cd28a5 [flang] Implement cross-set EQUIVALENCE impossibility checking
Implement cross-set EQUIVALENCE impossibility checking; fixes
an infinite loop on an erroneous test.  Also fix substring
reference offset calculations in EQUIVALENCE discovered to
be incorrect during testing.

Reviewed By: tskeith

Differential Revision: https://reviews.llvm.org/D82993
2020-07-01 14:09:07 -07:00
Anchu Rajendran 70f1b4b412 [flang] Implemented 2 Semantic checks for DATA statement and fixed a few bugs
Summary
  - Implemented C876, C877
  - Fixed IsConstantExpr to check C879
  - Fixed bugs in few test cases - data01.f90, block-data01.f90,
  pre-fir-tree02.f90
  - Modified implementation of C8106 to identify all automatic objects
  and modified equivalence01.f90 to reflect the changes

Differential Revision: https://reviews.llvm.org/D78424
2020-06-03 10:33:26 +05:30
Tim Keith 14f49599cc [flang][NFC] Remove link-time dependency of Evaluate on Semantics
Summary:
Some Symbol-related functions used in Evaluate were moved to
Evaluate/tools.h. This includes changing some member functions that were
replaced by non-member functions `IsDummy`, `GetUsedModule`, and
`CountLenParameters`.

Some member functions were made inline in `Scope`, `Symbol`,
`ArraySpec`, and `DeclTypeSpec`. The definitions were preceded by a
comment explaining why they are inline.

`IsConstantShape` was expanded inline in `IsDescriptor` because it isn't
used anywhere else

After this change, at least when compiling with clang on macos,
`libFortranEvaluate.a` has no undefined symbols that are satisfied by
`libFortranSemantics.a`.

Reviewers: klausler, PeteSteinfeld, sscalpone, jdoerfert, DavidTruby

Reviewed By: PeteSteinfeld

Subscribers: llvm-commits

Tags: #flang, #llvm

Differential Revision: https://reviews.llvm.org/D80762
2020-05-29 16:39:14 -07:00
Tim Keith 1f8790050b [flang] Reformat with latest clang-format and .clang-format
Original-commit: flang-compiler/f18@9fe84f45d7
Reviewed-on: https://github.com/flang-compiler/f18/pull/1094
2020-03-28 21:00:16 -07:00
Caroline Concatto 8670e49901 [flang] [LLVMify F18] Replace the use std::ostream with LLVM streams llvm::ostream
This patch replaces the occurrence of std::ostream by llvm::raw_ostream.
In  LLVM Coding Standards[1] "All new code should use raw_ostream
instead of ostream".[1]

As a consequence, this patch also replaces the use of:
   std::stringstream by llvm::raw_string_ostream or llvm::raw_ostream*
   std::ofstream by llvm::raw_fd_ostream
   std::endl by '\n' and flush()[2]
   std::cout by llvm::outs()   and
   std::cerr by llvm::errs()

It also replaces  std::strerro by llvm::sys::StrError** , but NOT in  Fortran
runtime libraries

*std::stringstream were replaced by llvm::raw_ostream in all methods that
used std::stringstream as a parameter. Moreover, it removes the pointers to
these streams.

[1]https://llvm.org/docs/CodingStandards.html
[2]https://releases.llvm.org/2.5/docs/CodingStandards.html#ll_avoidendl

Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>

Running clang-format-7

Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>

Removing residue of ostream library

Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>

Original-commit: flang-compiler/f18@a3507d44b8
Reviewed-on: https://github.com/flang-compiler/f18/pull/1047
2020-03-19 07:54:36 +00:00
CarolineConcatto 64ab3302d5 [flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)
This patch renames the modules in f18 to use a capital letter in the
module name

Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>

Original-commit: flang-compiler/f18@d2eb7a1c44
Reviewed-on: https://github.com/flang-compiler/f18/pull/980
2020-02-25 07:11:52 -08:00