Commit Graph

9 Commits

Author SHA1 Message Date
peter klausler 6965a776ee [flang] Fold LGE/LGT/LLE/LLT intrinsic functions
Fold the legacy intrinsic functions LGE, LGT, LLE, & LLT
by rewriting them into character relational expressions and
then folding those.  Also fix folding of comparisons of
character values of distinct lengths: the shorter value must
be padded with blanks.  (This fix exposed some bad test cases,
which are also fixed.)

Differential Revision: https://reviews.llvm.org/D111843
2021-10-14 15:24:03 -07:00
peter klausler d60a02201d [flang] Include default component initialization in static initializers
The combined initializers constructed from DATA statements and explicit
static initialization in declarations needs to include derived type
component default initializations, overriding those default values
without complaint with values from explicit DATA statement or declaration
initializations when they overlap.  This also has to work for objects
with storage association due to EQUIVALENCE.  When storage association causes
default component initializations to overlap, emit errors if and only
if the values differ (See Fortran 2018 subclause 19.5.3, esp. paragraph
10).

The f18 front-end has a module that analyzes and converts DATA statements
into equivalent static initializers for objects.  For storage-associated
objects, compiler-generated objects are created that overlay the entire
association and fill it with a combined initializer.  This "data-to-inits"
module already exists, and this patch is essentially extension and
clean-up of its machinery to complete the job.

Also: emit EQUIVALENCE to module files; mark compiler-created symbols
and *don't* emit those to module files; check non-static EQUIVALENCE
sets for conflicting default component initializations, so lowering
doesn't have to check them or emit diagnostics.

Differential Revision: https://reviews.llvm.org/D109022
2021-09-01 09:40:37 -07:00
Peter Steinfeld 571673ce39 [flang] Disallow BOZ literal constants as output list items
According to C7109, "A boz-literal-constant shall appear only as a
data-stmt-constant in a DATA statement, or where explicitly allowed in
16.9 as an actual argument of an intrinsic procedure."  This change
enforces that constraint for output list items.

I also added a general interface to determine if an expression is a BOZ
literal constant and changed all of the places I could find where it
could be used.

I also added a test.

This change stemmed from the following issue --
  https://gitlab-master.nvidia.com/fortran/f18-stage/issues/108

Differential Revision: https://reviews.llvm.org/D106893
2021-07-27 13:01:26 -07:00
peter klausler 6aa3591e98 [flang] Implement STORAGE_SIZE(), SIZEOF(), C_SIZEOF()
STORAGE_SIZE() is a standard inquiry intrinsic (size in bits
of an array element of the same type as the argument); SIZEOF()
is a common extension that returns the size in bytes of its
argument; C_SIZEOF() is a renaming of SIZEOF() in module ISO_C_BINDING.

STORAGE_SIZE() and SIZEOF() are implemented via rewrites to
expressions; these expressions will be constant when the necessary
type parameters and bounds are also constant.

Code to calculate the sizes of types (with and without alignment)
was isolated into Evaluate/type.* and /characteristics.*.
Code in Semantics/compute-offsets.* to calculate sizes and alignments
of derived types' scopes was exposed so that it can be called at type
instantiation time (earlier than before) so that these inquiry intrinsics
could be called from specification expressions.

Differential Revision: https://reviews.llvm.org/D93322
2020-12-15 17:26:20 -08:00
peter klausler 9a883bfa11 [flang] Clean up TODO comments and fix one (DATA constant ambiguity)
Remove resolved & moot TODO comments in Common/, Parser/,
and Evaluate/.  Address a pending one relating to parsing
ambiguity in DATA statement constants, handling it with
symbol table information in Semantics and adding a test.

Differential Revision: https://reviews.llvm.org/D93323
2020-12-15 13:36:07 -08:00
peter klausler 641ede93ef [flang] Improve initializer semantics, esp. for component default values
This patch plugs many holes in static initializer semantics, improves error
messages for default initial values and other component properties in
parameterized derived type instantiations, and cleans up several small
issues noticed during development.  We now do proper scalar expansion,
folding, and type, rank, and shape conformance checking for component
default initializers in derived types and PDT instantiations.
The initial values of named constants are now guaranteed to have been folded
when installed in the symbol table, and are no longer folded or
scalar-expanded at each use in expression folding.  Semantics documentation
was extended with information about the various kinds of initializations
in Fortran and when each of them are processed in the compiler.

Some necessary concomitant changes have bulked this patch out a bit:
* contextual messages attachments, which are now produced for parameterized
  derived type instantiations so that the user can figure out which
  instance caused a problem with a component, have been added as part
  of ContextualMessages, and their implementation was debugged
* several APIs in evaluate::characteristics was changed so that a FoldingContext
  is passed as an argument rather than just its intrinsic procedure table;
  this affected client call sites in many files
* new tools in Evaluate/check-expression.cpp to determine when an Expr
  actually is a single constant value and to validate a non-pointer
  variable initializer or object component default value
* shape conformance checking has additional arguments that control
  whether scalar expansion is allowed
* several now-unused functions and data members noticed and removed
* several crashes and bogus errors exposed by testing this new code
  were fixed
* a -fdebug-stack-trace option to enable LLVM's stack tracing on
  a crash, which might be useful in the future

TL;DR: Initialization processing does more and takes place at the right
times for all of the various kinds of things that can be initialized.

Differential Review: https://reviews.llvm.org/D92783
2020-12-07 14:40:41 -08:00
peter klausler 5349f99114 [flang] Correct handling of null pointer initializers
Fortran defines "null-init" null pointer initializers as
being function references, syntactically, that have to resolve
to calls to the intrinsic function NULL() with no actual
arguments.

Differential revision: https://reviews.llvm.org/D91657
2020-11-18 13:57:25 -08:00
peter klausler fad31d6032 [flang] Implement shape analysis of TRANSFER intrinsic function result
The shape (esp. the size) of the result of a call to TRANSFER
is implemented according to the definition in the standard.

Differential Revision: https://reviews.llvm.org/D85866
2020-08-13 09:56:24 -07:00
peter klausler 4ac617f490 [flang] Handle DATA initialization of EQUIVALENCE'd objects
Objects that are storage associated by EQUIVALENCE and
initialized with DATA are initialized by creating a
compiler temporary data object in the same scope,
assigning it an offset, type, and size that covers the
transitive closure of the associated initialized original
symbols, and combining their initializers into one common
initializer for the temporary.

Some problems with offset assignment of EQUIVALENCE'd objects
in COMMON were exposed and corrected, and some more error
cases are checked.

Remove obsolete function.
Small bugfix (nested implied dos).
Add a test.
Fix struct/class warning.

Differential Revision: https://reviews.llvm.org/D85560
2020-08-07 16:39:23 -07:00