[flang] Add UNSIGNED (#113504)

Implement the UNSIGNED extension type and operations under control of a
language feature flag (-funsigned).

This is nearly identical to the UNSIGNED feature that h

[flang] Add UNSIGNED (#113504)

Implement the UNSIGNED extension type and operations under control of a
language feature flag (-funsigned).

This is nearly identical to the UNSIGNED feature that has been available
in Sun Fortran for years, and now implemented in GNU Fortran for
gfortran 15, and proposed for ISO standardization in J3/24-116.txt.

See the new documentation for details; but in short, this is C's
unsigned type, with guaranteed modular arithmetic for +, -, and *, and
the related transformational intrinsic functions SUM & al.

show more ...

[flang] Tidy uses of raw_string_ostream (NFC)

As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly

( 65b13610a5226b84889b923bae884b

[flang] Tidy uses of raw_string_ostream (NFC)

As specified in the docs,
1) raw_string_ostream is always unbuffered and
2) the underlying buffer may be used directly

( 65b13610a5226b84889b923bae884ba395ad084d for further reference )

Avoid unneeded calls to raw_string_ostream::str(), to avoid excess indirection.

show more ...

[flang] Change argument to const reference (#95048)

cppcheck recommends that a std::map being passed by value be changed to
a const reference.

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

[flang] Change argument to const reference (#95048)

cppcheck recommends that a std::map being passed by value be changed to
a const reference.

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

show more ...

[flang] Faster implementation of FindScope()

The utility semantics::SemanticsContext::FindScope() maps a contiguous
range of cooked source characters to the innermost Scope containing
them. Its imp

[flang] Faster implementation of FindScope()

The utility semantics::SemanticsContext::FindScope() maps a contiguous
range of cooked source characters to the innermost Scope containing
them. Its implementation is unacceptably slow on large (tens of
thousands of lines) source files with many program units; it traverses
each level of the scope tree linearly.

Replace this implementation with a single instance of std::multimap<>
used as an index from each Scope's source range back to the Scope.

Compilation time with "-fsyntax-only" on the 50,000-line test case
that motivated this change drops from 4.36s to 3.72s, and FindScope()
no longer stands out egregiously in the profile.

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

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] Catch (and fix) attempts to create an invalid source range for a Scope

When Scope::AddSourceRange() is called to extend the scope's source range to
include another snippet from a cooked char

[flang] Catch (and fix) attempts to create an invalid source range for a Scope

When Scope::AddSourceRange() is called to extend the scope's source range to
include another snippet from a cooked character stream, add a check to ensure
that the new range is part of the same cooked character stream as the rest
of the scope.

And fix the bug that was causing such invalid source ranges to be created:
a submodule's Scope is a children of its parent's in the Scope tree, but
it may or may not be part of the same source file, and it is certainly
not enclosed in the parent's source range. So don't propagate Scope
source range expansion from a submodule to its parent.

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

show more ...

[flang] Prohibit multiple separate module procedure definitions

Ensure that non-BIND(C) separate module procedures are not
defined more than once.

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

[flang] Prohibit multiple separate module procedure definitions

Ensure that non-BIND(C) separate module procedures are not
defined more than once.

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

show more ...

[Flang] fix a copy-paste error in scope.cpp

found by PVS-Studio.

Reviewed By: jeanPerier, klausler

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

[flang] Do not pass derived type by descriptor when not needed

A missing "!" in the call interface lowering caused all derived type
arguments without length parameters that require and explicit inte

[flang] Do not pass derived type by descriptor when not needed

A missing "!" in the call interface lowering caused all derived type
arguments without length parameters that require and explicit interface
to be passed via fir.box (runtime descriptor).

This was not the intent: there is no point passing a simple derived type
scalars or explicit shapes by descriptor just because they have an attribute
like TARGET. This would actually be problematic with existing code that is
not always 100% compliant: some code implicitly calls procedures with
TARGET dummy attributes (this is not something a compiler can enforce
if the call and procedure definition are not in the same file).

Add a Scope::IsDerivedTypeWithLengthParameter to avoid passing derived
types with only kind parameters by descriptor. There is no point, the
callee knows about the kind parameter values.

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

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] Distinguish intrinsic from non-intrinsic modules

For "USE, INTRINSIC", search only for intrinsic modules;
for "USE, NON_INTRINSIC", do not recognize intrinsic modules.
Allow modules of both

[flang] Distinguish intrinsic from non-intrinsic modules

For "USE, INTRINSIC", search only for intrinsic modules;
for "USE, NON_INTRINSIC", do not recognize intrinsic modules.
Allow modules of both kinds with the same name to be used in
the same source file (but not in the same scoping unit, a
constraint of the standard that is now enforced).

The symbol table's scope tree now has a single instance of
a scope with a new kind, IntrinsicModules, whose children are
the USE'd intrinsic modules (explicit or not). This separate
"top-level" scope is a child of the single global scope and
it allows both intrinsic and non-intrinsic modules of the same
name to exist in the symbol table. Intrinsic modules' scopes'
symbols now have the INTRINSIC attribute set.

The search path directories need to make a distinction between
regular directories and the one(s) that point(s) to intrinsic
modules. I allow for multiple intrinsic module directories in
the second search path, although only one is needed today.

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

show more ...

[flang] Support known constant lengths in DynamicType

The constexpr-capable class evaluate::DynamicType represented
CHARACTER length only with a nullable pointer into the declared
parameters of type

[flang] Support known constant lengths in DynamicType

The constexpr-capable class evaluate::DynamicType represented
CHARACTER length only with a nullable pointer into the declared
parameters of types in the symbol table, which works fine for
anything with a declaration but turns out to not suffice to
describe the results of the ACHAR() and CHAR() intrinsic
functions. So extend DynamicType to also accommodate known
constant CHARACTER lengths, too; use them for ACHAR & CHAR;
clean up several use sites and fix regressions found in test.

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

show more ...

[flang] Fix crashes due to failure to find a subprogram

In error recovery situations, the mappings from source locations
to scopes were failing in a way that tripped some asserts.
Specifically, Find

[flang] Fix crashes due to failure to find a subprogram

In error recovery situations, the mappings from source locations
to scopes were failing in a way that tripped some asserts.
Specifically, FindPureProcedureContaining() wasn't coping well
when starting at the global scope. (And since the global scope
no longer has a source range, clean up the Semantics constructor
to avoid confusion.)

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

show more ...

[flang] Enforce a limit on recursive PDT instantiations

For pernicious test cases with explicit non-constant actual
type parameter expressions in components, e.g.:

type :: t(k)
integer, kind

[flang] Enforce a limit on recursive PDT instantiations

For pernicious test cases with explicit non-constant actual
type parameter expressions in components, e.g.:

type :: t(k)
integer, kind :: k
type(t(k+1)), pointer :: p
end type

we should detect the infinite recursion and complain rather
than looping until the stack overflows.

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

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] Order Symbols by source provenance

In parser::AllCookedSources, implement a map from CharBlocks to
the CookedSource instances that they cover. This permits a fast
Find() operation based on

[flang] Order Symbols by source provenance

In parser::AllCookedSources, implement a map from CharBlocks to
the CookedSource instances that they cover. This permits a fast
Find() operation based on std::map::equal_range to map a CharBlock
to its enclosing CookedSource instance.

Add a creation order number to each CookedSource. This allows
AllCookedSources to provide a Precedes(x,y) predicate that is a
true source stream ordering between two CharBlocks -- x is less
than y if it is in an earlier CookedSource, or in the same
CookedSource at an earlier position.

Add a reference to the singleton SemanticsContext to each Scope.

All of this allows operator< to be implemented on Symbols by
means of a true source ordering. From a Symbol, we get to
its Scope, then to the SemanticsContext, and then use its
AllCookedSources reference to call Precedes().

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

show more ...

Making FindCommonBlock a const member
https://reviews.llvm.org/D97093

[flang] Support disabled alternative PARAMETER statement

Legacy Fortran implementations support an alternative form of the
PARAMETER statement; it differs syntactically from the standard's
PARAMETER

[flang] Support disabled alternative PARAMETER statement

Legacy Fortran implementations support an alternative form of the
PARAMETER statement; it differs syntactically from the standard's
PARAMETER statement by lacking parentheses, and semantically by
using the type and shape of the initialization expression to define
the attributes of the named constant. (GNU Fortran gets that part
wrong; Intel Fortran and nvfortran have full support.)

This patch disables the old style PARAMETER statement by default, as
it is syntactically ambiguous with conforming assignment statements;
adds a new "-falternative-parameter-statement" option to enable it;
and implements it correctly when enabled.

Fixes https://bugs.llvm.org/show_bug.cgi?id=48774, in which a user
tripped over the syntactic ambiguity.

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

show more ...

[flang] Fix CheckSpecificationExpr handling of associated names

Avoid a spurious error message about a dummy procedure reference
in a specification expression by restructuring the handling of
use-as

[flang] Fix CheckSpecificationExpr handling of associated names

Avoid a spurious error message about a dummy procedure reference
in a specification expression by restructuring the handling of
use-associated and host-associated symbols.

Updated to fix a circular dependence between shared library
binaries that was introduced by the original patch.

Differential revision: https://reviews.llvm.org/D91286

show more ...

[flang] Fix build issue with BUILD_SHARED_LIBS=ON

Define Fortran::Semantics::Scope::GetName in the header so it is available
to Fortran::Evaluate::Tool::AttachDeclaration without a circular dependen

[flang] Fix build issue with BUILD_SHARED_LIBS=ON

Define Fortran::Semantics::Scope::GetName in the header so it is available
to Fortran::Evaluate::Tool::AttachDeclaration without a circular dependency
introduced in 82edd42.

Reviewed By: tskeith

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

show more ...

[flang] Support multiple CookedSource instances

These are owned by an instance of a new class AllCookedSources.

This removes the need for a Scope to own a string containing
a module's cooked source

[flang] Support multiple CookedSource instances

These are owned by an instance of a new class AllCookedSources.

This removes the need for a Scope to own a string containing
a module's cooked source stream, and will enable errors to be
emitted when parsing module files in the future.

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

show more ...

[flang] Fix implicit declarations in statement functions

If a symbol (that is not a dummy argument) is implicitly declared inside
a statement function, don't create it in the statement function's sc

[flang] Fix implicit declarations in statement functions

If a symbol (that is not a dummy argument) is implicitly declared inside
a statement function, don't create it in the statement function's scope.
Instead, treat statement functions like blocks when finding the inclusive
scope and create the symbol there.

Add a new flag, StmtFunction, to symbols that represent statement functions.

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

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] Add accessors to equivalence and common blocks

Add a way to get mutable equivalence sets to Scope so that they can
have sizes and offsets assigned to them.

Change CommonBlockDetails to

[flang][NFC] Add accessors to equivalence and common blocks

Add a way to get mutable equivalence sets to Scope so that they can
have sizes and offsets assigned to them.

Change CommonBlockDetails to have mutable symbols so that they can have
sizes and offets assigned to them. This also allows the removal of some
`const_cast`s.

Add MutableSymbolRef and MutableSymbolVector as mutable analogs to
SymbolRef and SymbolVector. Replace uses of equivalent types with those
names.

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

show more ...