[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.

[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.

show more ...

[flang] Handle common block with different sizes in same file

Semantics is not preventing a named common block to appear with
different size in a same file (named common block should always have
the

[flang] Handle common block with different sizes in same file

Semantics is not preventing a named common block to appear with
different size in a same file (named common block should always have
the same storage size (see Fortran 2018 8.10.2.5), but it is a common
extension to accept different sizes).

Lowering was not coping with this well, since it just use the first
common block appearance, starting with BLOCK DATAs to define common
blocks (this also was an issue with the blank common block, which can
legally appear with different size in different scoping units).

Semantics is also not preventing named common from being initialized
outside of a BLOCK DATA, and lowering was dealing badly with this,
since it only gave an initial value to common blocks Globals if the
first common block appearance, starting with BLOCK DATAs had an initial
value.

Semantics is also allowing blank common to be initialized, while
lowering was assuming this would never happen, and was never creating
an initial value for it.

Lastly, semantics was not complaining if a COMMON block was initialized
in several scoping unit in a same file, while lowering can only generate
one of these initial value.

To fix this, add a structure to keep track of COMMON block properties
(biggest size, and initial value if any) at the Program level. Once the
size of a common block appearance is know, the common block appearance
is checked against this information. It allows semantics to emit an error
in case of multiple initialization in different scopes of a same common
block, and to warn in case named common blocks appears with different
sizes. Lastly, this allows lowering to use the Program level info about
common blocks to emit the right GlobalOp for a Common Block, regardless
of the COMMON Block appearances order: It emits a GlobalOp with the
biggest size, whose lowest bytes are initialized with the initial value
if any is given in a scope where the common block appears.

Lowering is updated to go emit the common blocks before anything else so
that the related GlobalOps are available when lowering the scopes where
common block appear. It is also updated to not assume that blank common
are never initialized.

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

show more ...

[flang] Emit a portability warning for padding in COMMON

When padding is required in a COMMON block to ensure alignment
of a component, emit a portability warning.

Differential Revision: https://re

[flang] Emit a portability warning for padding in COMMON

When padding is required in a COMMON block to ensure alignment
of a component, emit a portability warning.

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

show more ...

[flang][NFC] rename IsKindParameterizedDerivedType and fix comment typos

Following post-review feedback on https://reviews.llvm.org/D120804 and
https://reviews.llvm.org/D120801 about type descriptor

[flang][NFC] rename IsKindParameterizedDerivedType and fix comment typos

Following post-review feedback on https://reviews.llvm.org/D120804 and
https://reviews.llvm.org/D120801 about type descriptor changes, fix typos in
comments and rename IsKindParameterizedDerivedType to
IsDerivedTypeWithKindParameter. Remove a useless `;`.

Reviewed By: clementval, PeteSteinfeld

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

show more ...

[flang] Generate PDT runtime type info in the type definition scope

This patches modifies PDT runtime type info generation so that it is
easier to handle derived type descriptor in lowering. It chan

[flang] Generate PDT runtime type info in the type definition scope

This patches modifies PDT runtime type info generation so that it is
easier to handle derived type descriptor in lowering. It changes three
aspects:

1. The symbol name suffix of runtime type info for PDT instantiation is
changed from a serial number unrelated to the types to an encoding of
the instantiated KIND parameters.
2. New runtime type info is not created for each instantiation of PDT without
KIND parameters (only length parameters). Instead, the runtime type
info of the type definition is always used. It is updated to contain
the component descriptions.
3. Runtime type info of PDT instantiation is now always generated in the
scope where the type is defined. If several PDT type instantiation
are made in different scope with the same kind parameters, they will
use the same runtime type info.

Rational of the change:

In lowering, derived type descriptors are not mapped when instantiating derived
type objects. They are mapped later when symbol knowledge is not available anymore.
This mapping is based on the FIR representation of derived types. For
PDT, the FIR type information does not allow deducing the instantiation
scope, it only allows retrieving the type name, the type _definition_
scope, and the kind parameter values. Therefore, in order to be able to
retrieve the derived type descriptor from a FIR type, the derived type
descriptor must be generated in the definition scope and must reflect
the kind parameters. This justifies the need for changes 1. and 3.
above (suffix and scope change). Changes 2. comes from the fact that
all runtime type info of type without kind parameters can be generated
from the type definition, and that because of the suffix change, the
symbol name for type definition and type instantiation are the same.

Although this change is first motivated by how lowering handles derived
types, I believe it is also an improvement from a functional point of
view since this change will allow reducing the number of generated
runtime type info for PDTs, since redundant information (different
instantiations with same kind parameters) will only be generated once.

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

show more ...

[flang] Fix common block size extension mistake in D109156

https://reviews.llvm.org/D109156 did not properly update the case where
the equivalence symbol appearing in the common statement is the
"ba

[flang] Fix common block size extension mistake in D109156

https://reviews.llvm.org/D109156 did not properly update the case where
the equivalence symbol appearing in the common statement is the
"base symbol of an equivalence group" (this was the only case that previously
worked ok, and the patch broke it).

Fix this and add a test that actually uses this code path.

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

show more ...

[flang] Move runtime API headers to flang/include/flang/Runtime

Move the closure of the subset of flang/runtime/*.h header files that
are referenced by source files outside flang/runtime (apart from

[flang] Move runtime API headers to flang/include/flang/Runtime

Move the closure of the subset of flang/runtime/*.h header files that
are referenced by source files outside flang/runtime (apart from unit tests)
into a new directory (flang/include/flang/Runtime) so that relative
include paths into ../runtime need not be used.

flang/runtime/pgmath.h.inc is moved to flang/include/flang/Evaluate;
it's not used by the runtime.

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

show more ...

[flang] Extend common block size to cover equivalence storage

The size of common block should be extended to cover any storage
sequence that are storage associated with the common block via
equivale

[flang] Extend common block size to cover equivalence storage

The size of common block should be extended to cover any storage
sequence that are storage associated with the common block via
equivalences (8.10.2.2 point 1 (2)).

In symbol size and offset computation, the size of the common block
was not always extended to cover storage association. It was only done
if the "base symbol of an equivalence group"(*) appeared in a common block
statement. Correct this to cover all cases where a symbol appearing in a
common block statement is storage associated.

(*) the base symbol of an equivalence group is the symbol whose storage
starts first in a storage association (if several symbols starts first,
the base symbol is the last one visited by the algorithm going through
the equivalence sets).

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

show more ...

[flang] Include default component initialization in static initializers

The combined initializers constructed from DATA statements and explicit
static initialization in declarations needs to include

[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

show more ...

[flang] Run-time derived type initialization and destruction

Use derived type information tables to drive default component
initialization (when needed), component destruction, and calls to
final su

[flang] Run-time derived type initialization and destruction

Use derived type information tables to drive default component
initialization (when needed), component destruction, and calls to
final subroutines. Perform these operations automatically for
ALLOCATE()/DEALLOCATE() APIs for allocatables, automatics, and
pointers. Add APIs for use in lowering to perform these operations
for non-allocatable/automatic non-pointer variables.
Data pointer component initialization supports arbitrary constant
designators, a F'2008 feature, which may be a first for Fortran
implementations.

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

show more ...

[flang] Refine symbol sorting

Replace semantics::SymbolSet with alternatives that clarify
whether the set should order its contents by source position
or not. This matters because positionally-orde

[flang] Refine symbol sorting

Replace semantics::SymbolSet with alternatives that clarify
whether the set should order its contents by source position
or not. This matters because positionally-ordered sets must
not be used for Symbols that might be subjected to name
replacement during name resolution, and address-ordered
sets must not be used (without sorting) in circumstances
where the order of their contents affects the output of the
compiler.

All set<> and map<> instances in the compiler that are keyed
by Symbols now have explicit Compare types in their template
instantiations. Symbol::operator< is no more.

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

show more ...

[flang] Add TypeAndShape::MeasureElementSizeInBytes()

Split up MeasureSizeInBytes() so that array element sizes can be
calculated accurately; use the new API in some places where
DynamicType::Measur

[flang] Add TypeAndShape::MeasureElementSizeInBytes()

Split up MeasureSizeInBytes() so that array element sizes can be
calculated accurately; use the new API in some places where
DynamicType::MeasureSizeInBytes() was being used but the new
API performs better due to TypeAndShape having precise CHARACTER
length information.

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

show more ...

[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 extens

[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

show more ...

[flang] Implement derived type description table encoding

Define Fortran derived types that describe the characteristics
of derived types, and instantiations of parameterized derived
types, that are

[flang] Implement derived type description table encoding

Define Fortran derived types that describe the characteristics
of derived types, and instantiations of parameterized derived
types, that are of relevance to the runtime language support
library. Define a suite of corresponding C++ structure types
for the runtime library to use to interpret instances of the
descriptions.

Create instances of these description types in Semantics as
static initializers for compiler-created objects in the scopes
that define or instantiate user derived types.

Delete obsolete code from earlier attempts to package runtime
type information.

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

show more ...

[flang] Don't attempt to compute element size if no DynamicType

If an error has occurred a symbol may have a DeclTypeSpec but no
valid DynamicType. There is no need to compute the size of erroneous

[flang] Don't attempt to compute element size if no DynamicType

If an error has occurred a symbol may have a DeclTypeSpec but no
valid DynamicType. There is no need to compute the size of erroneous
symbols.

Also, we only need to process object entities and procedure entities.
All other kinds of symbols can be skipped.

This fixes another problem revealed by https://bugs.llvm.org/show_bug.cgi?id=47265

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

show more ...

[flang] Fix bug accessing implicit variable in specification expression

A specification expression can reference an implicitly declared variable
in the host procedure. Because we have to process spe

[flang] Fix bug accessing implicit variable in specification expression

A specification expression can reference an implicitly declared variable
in the host procedure. Because we have to process specification parts
before execution parts, this may be the first time we encounter the
variable. We were assuming the variable was implicitly declared in the
scope where it was encountered, leading to an error because local
variables may not be referenced in specification expressions.

The fix is to tentatively create the implicit variable in the host
procedure because that is the only way the specification expression can
be valid. We mark it with the flag `ImplicitOrError` to indicate that
either it must be implicitly defined in the host (by being mentioned in
the execution part) or else its use turned out to be an error.
We need to apply the implicit type rules of the host, which requires
some changes to implicit typing.

Variables in common blocks are allowed to appear in specification expressions
(because they are not locals) but the common block definition may not appear
until after their use. To handle this we create common block symbols and object
entities for each common block object during the `PreSpecificationConstruct`
pass. This allows us to remove the corresponding code in the main visitor and
`commonBlockInfo_.curr`. The change in order of processing causes some
different error messages to be emitted.

Some cleanup is included with this change:
- In `ExpressionAnalyzer`, if an unresolved name is encountered but
no error has been reported, emit an internal error.
- Change `ImplicitRulesVisitor` to hide the `ImplicitRules` object
that implements it. Change the interface to pass in names rather
than having to get the first character of the name.
- Change `DeclareObjectEntity` to have the `attrs` argument default
to an empty set; that is the typical case.
- In `Pre(parser::SpecificationPart)` use "structured bindings" to
give names to the pieces that make up a specification-part.
- Enhance `parser::Unwrap` to unwrap `Statement` and `UnlabeledStatement`
and make use of that in PreSpecificationConstruct.

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

show more ...

[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.

Diff

[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

show more ...

[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

[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

show more ...

[flang] Fix bug with intrinsic in type declaration stmt

When an instrinsic function is declared in a type declaration statement
we need to set the INTRINSIC attribute and (per 8.2(3)) ignore the
spe

[flang] Fix bug with intrinsic in type declaration stmt

When an instrinsic function is declared in a type declaration statement
we need to set the INTRINSIC attribute and (per 8.2(3)) ignore the
specified type.

To simplify the check, add IsIntrinsic utility to BaseVisitor.

Also, intrinsics and external procedures were getting assigned a size
and offset and they shouldn't be.

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

show more ...

[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 offs

[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

show more ...

[flang] DATA stmt processing (part 1/4): designator folding

Summary:
Add code to resolve constant Designators at compilation time
into a base Symbol, byte offset, and field size. This is used in
la

[flang] DATA stmt processing (part 1/4): designator folding

Summary:
Add code to resolve constant Designators at compilation time
into a base Symbol, byte offset, and field size. This is used in
later DATA statement processing to identify the static storage being
initialized by each object in a DATA statement. Also implement
the reverse mapping so that Designators can be reconstructed for
use in error messages about (e.g.) duplicate initializers.

Reviewers: tskeith, PeteSteinfeld, sscalpone, jdoerfert, DavidTruby

Reviewed By: PeteSteinfeld

Subscribers: mgorny, llvm-commits, flang-commits

Tags: #flang, #llvm

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

show more ...

[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

[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

show more ...

[flang][NFC] Replace "align" with "alignment"

In the places it is used as a noun, replace "align" with "alignment".

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

[flang] Handle EQUIVALENCE and COMMON in size and offset computations

Objects in common blocks have offsets relative to the start of the
common block, independent of the enclosing scope, so they are

[flang] Handle EQUIVALENCE and COMMON in size and offset computations

Objects in common blocks have offsets relative to the start of the
common block, independent of the enclosing scope, so they are processed
first. Add alignment to CommonBlockDetails to record the required
alignment of the common block.

For equivalence sets, each object depends on the one that is forced to
occur first in memory. The rest are recorded in the dependents_ map and
have offsets assigned after the other symbols are done.

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

show more ...

[flang] Compute sizes and offsets for symbols

Summary:
Add size and offset properties to symbols, representing their byte size
and offset within their enclosing scope.

Add size and align properties

[flang] Compute sizes and offsets for symbols

Summary:
Add size and offset properties to symbols, representing their byte size
and offset within their enclosing scope.

Add size and align properties to scopes so that they are available for
scopes representing derived types.

Add ComputeOffsets pass over the symbol table to fill in those fields.

Compute descriptor size based on rank and length parameters. Extract
DerivedTypeSpec::NumLengthParameters from DynamicType::RequiresDescriptor
to share the code.

Add Scope::GetSymbols to get symbols in canonical order.
compute-offsets.cpp and mod-file.cpp both need to process symbols in the
order in which they are declared. Move the collecting of those symbols
into Scope so that it can be shared.

Add symbol size and offset to output of `-fdebug-dump-symbols` and use
that in some tests.

Still to do:
- make size and alignment rules configurable based on target
- use offsets to check EQUIVALENCE statements

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

show more ...