This patch updates lowering to produce the correct fir.class types for
various polymorphic and unlimited polymoprhic entities cases. This is only the
lowering. Some TODOs have been added to the CodeGen part to avoid errors since
this part still need to be updated as well.
The fir.class<*> representation for unlimited polymorphic entities mentioned in
the document has been updated to fir.class<none> to avoid useless work in pretty
parse/printer.
This patch is part of the implementation of the poltymorphic
entities.
https://github.com/llvm/llvm-project/blob/main/flang/docs/PolymorphicEntities.md
Depends on D134957
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D134959
Previously, AggregateStores were created for aggregates associated with common
blocks. As a) AggregateStoreMap uses scope and offset information to search for
aggregate stores and b) variables related to common blocks have their
offsets set relative to the common block itself, if there were multiple
equivalences and at least one involved variables defined in a common block there
was an opportunity for the scope/offset pairs to match between distinct
aggregate stores. As a result, entries in AggregateStoreMap could collide,
resulting in incorrect stores being returned for a particular variable.
To prevent these collisions, skip creating AggregateStores for aggregates which
are associated with common blocks. This information was already unused as
aggregates associated with common blocks are handled by instantiateCommon.
Fixes https://github.com/llvm/llvm-project/issues/57749
Differential Revision: https://reviews.llvm.org/D134828
As described in Issue #57642, `flang` currently lacks SPARC support in
`Optimizer/CodeGen/Target.cpp`, which causes a considerable number of tests
to `FAIL` with
error: flang/lib/Optimizer/CodeGen/Target.cpp:310: not yet implemented:
target not implemented
This patch fixes this by following GCC`s documentation of the ABI described
in the Issue.
Tested on `sparcv9-sun-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D133561
For TRIM and REPEAT calls, semantics was creating ProcedureDesignators
using the length parameter of the arguments. This caused bugs when
folding LEN(TRIM(char_explicit_constant_length)). The same did not
appeared in folding for REPEAT because it is rewritten at a higher
level to LEN(c)*N.
This is not only a folding issue since any place (like lowering) may
try to use the bad length parameter from the created ProcedureDesignator.
Update intrinsic resolution to not copy the length parameter for TRIM
and REPEAT.
Differential Revision: https://reviews.llvm.org/D134970
The real(10) is supported on x86_64. On aarch64, the value of
selected_real_kind(16) should be 16 rather than 10 since real(10)
is not supported on x86_64. Previously, the real type support check
is not target dependent. Support it now through the target triple
information.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D134021
The previous resolve only creates the host associated varaibles for
common block members, but does not replace the original objects with
the new created ones. Fix it and also compute the sizes and offsets
for the host common block members if they are host associated.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D127214
The real(10) is supported on x86_64. On aarch64, the value of
selected_real_kind(16) should be 16 rather than 10 since real(10)
is not supported on x86_64. Previously, the real type support check
is not target dependent. Support it now through the target triple
information.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D134021
This flips all of the remaining dialects to prefixed except for linalg, which
will be done in a followup.
Differential Revision: https://reviews.llvm.org/D134995
AffineMapAttr on fir.box type is not used. This patch
remove it. It can be added back later when needed.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D134955
Add the atomic subroutine, atomic_fetch_or, to the list of
intrinsic subroutines. Add new enumerators to deal with the rank
of the atom dummy argument, and the kind of atomic_int_kind. Use
check for a coindexed-object for the fourth dummy argument. Move
atomic_int_kind and atomic_logical_kind definitions from
iso_fortran_env module to the __fortran_builtins module to allow
for access to those values when analyzing `atomic_fetch_or`
calls in flang/lib/Evaluate/intrinsics.cpp.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D133174
Functions that implement expansion of response and config files depend
on many options, which are passes as arguments. Extending the expansion
requires new options, it in turn causes changing calls in various places
making them even more bulky.
This change introduces a class ExpansionContext, which represents set of
options that control the expansion. Its methods implements expansion of
responce files including config files. It makes extending the expansion
easier.
No functional changes.
Differential Revision: https://reviews.llvm.org/D132379
std::numeric_limits<__float128>::max/lowest return 0.0, so recreate
value of FLT128_MAX ourselves to avoid using quadmath.h's FLT128_MAX
that is currently causes warnings with GCC -Wpedantic.
Differential Revision: https://reviews.llvm.org/D134496
Add the collective subroutine, co_broadcast, to the list
of intrinsic subroutines. Add co_broadcast to the check
for coindexed objects for the first, third, and fourth dummy
arguments. Update the co_broadcast semantics test.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D134786
This patch changes the handling of complex number intrinsics that
have C libm equivalents to call into those instead of calling the
external pgmath library.
Currently complex numbers to integer powers are excluded as libm
has no powi equivalent function.
Differential Revision: https://reviews.llvm.org/D134655
Currently, lowering is promoting main program array and character
variables that are not saved into static memory.
This causes issues with equivalence initial value images because
semantics is relying on IsSaved to build the initial value of variables
in static memory. It seems more robust to have IsSaved be the place
deciding if a variable needs to be in static memory (except for common
block members).
Move the logic to decide if a main program variable must be in static
memory into evaluate::IsSaved and add two options to semantics to
replace the llvm options that were used in lowering:
- SaveMainProgram (off by default): save all main program variables.
- SaveBigMainProgramVariables (on by default): save all main program
variables that are bigger than 32 bytes.
The first options is required to run a few old programs that expect all
main program variables to be in bss (and therefore zero initialized).
The second option is added to allow performance testing: placing big
arrays in static memory seems a sane default to avoid blowing up the
stack with old programs that define big local arrays in the main
program, but since it is easier to prove that an alloca does not
escape/is not modified by calls, keeping big arrays on the stack could
yield improvements.
The logic of SaveBigMainProgramVariables is slightly changed compared to what
it was doing in lowering. The old code was placing all arrays and all
explicit length characters in static memory.
The new code is placing everything bigger than 32 bytes in static
memory. This has the advantages of being a simpler logic, and covering
the cases of scalar derived type with big array components or many
components. Small strings and arrays are now left on the stack (after
all, a character(1) can fit in register).
Note: I think it could have been nicer to add a single "integer" option
to set a threshold to place main program variables in static memory so
that this can be fine tuned by the drivers (SaveMainProgram would be
implemented by setting it to zero). But the language feature options are
not meant to carry integer options. Extending it for this seems an
overkill precedent, and placing it in SemanticsContext is weird (it is
a too low level option to be a bare member of SemanticsContext in my
opinion). So I just rolled my own dices and picked 32 for the sake of
simplicity.
Differential Revision: https://reviews.llvm.org/D134735
Add the collective subroutines, co_min and co_max, to the list
of intrinsic subroutines. Add those two subroutines to the check
for coindexed objects for the first, third, and fourth dummy
arguments. Update the co_min and co_max semantics tests.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D133526
This calls the corresponding runtime functions when appropriate. The implementation
follows the pattern of the SUM and PRODUCT intrinsics.
Differential Revision: https://reviews.llvm.org/D129616
Copy-in/copy-out was not triggered when calling a procedure with a
CONTIGUOUS assumed shape. The actual argument must be copied-in/out
if it is not contiguous.
The copy-in/copy-out takes care of argument optionality, and uses a
runtime check in order to only do the copy if the actual is not
contiguous at runtime.
This was already implemented for explicit shape dummy arguments. This
patch takes advantage of this implementation to deal with the copy-in
copy-out aspects. It only need add code to deals with wrapping the
created bare contiguous address into a fir.box (runtime descriptor),
taking care of the optional box aspects.
Using this existing code is only possible for actual argument that can
be passed via a bare address. Add a TODO for polymorphic entity, PDTs
and assumed rank where the existing copy-in/copy-out code may fail
(these copies are more complex) and that cannot be tested currently.
Differential Revision: https://reviews.llvm.org/D134543
NULL intrinsic with a MOLD argument can be used in a type constructor.
This patch handles this use case with a specific lowering that create
an unallocated box with the MOLD type.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D134554
BIND(C) Function returning character must return it by value and
not as hidden argument like done currently. This patch update the
code to return it by value for both use cases.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D134530
When a FUNCTION statement has both an explicit type in its prefix
and a RESULT clause in its suffix, semantics crashes due to the
redundant type; emit a nice error message instead.
Differential Revision: https://reviews.llvm.org/D134504
When a component array of a named constant is extracted as
a constant value, ensure that the lower bounds of the array
are properly acquired from the declaration of the component.
Differential Revision: https://reviews.llvm.org/D134499
I am building with clang, and I noticed for quite a while that
REAL(16) runtimes functions are not available. I did not know why
until I saw this typo.
Differential Revision: https://reviews.llvm.org/D134503
f18 emits an error message when two objects related by EQUIVALENCE
to a third are specified as members of a COMMON block. This is not
always a sign of an error, however; it is possible for multiple objects
in a COMMON block to all be equivalenced to distinct offsets in another
object in a way that is consistent. So refine the check.
Differential Revision: https://reviews.llvm.org/D134485
When a scalar expression is not expandable -- i.e., it would have to be
evaluated once and saved in a temporary to avoid changing the semantics
of the program if it were to be evaluated more than once -- it affects
some aspects of folding and expression semantics. In cases where
scalar expansion would not cause multiple evaluations due to the shape
of the result having but a single element, however, these "non-expandable"
scalar expressions can be safely allowed.
Differential Revision: https://reviews.llvm.org/D134476
A generic-spec can appear on a module accessibility control statement
even if it has not been declared as a generic interface, because there's
nothing else that it could be.
While here, simplify the parse tree and parser for AccessId, since
one of its alternatives is ambiguous with the other.
Differential Revision: https://reviews.llvm.org/D134471
At present, IS_CONTIGUOUS() can only either fold to .TRUE. or
remain unknown. The underlying analysis, however, is capable
of returning a tri-state result (true, false, or unknown).
Extend and expose it to folding so that IS_CONTIGUOUS() can
fold to .FALSE. as well as to .TRUE. when contiguity is
known.
Differential Revision: https://reviews.llvm.org/D134466
Any symbol in a module file will have been already shamed with
portability warnings when the module was compiled, so don't pile
on when compiling other program units that use the module.
This also silences warnings about some symbols whose names were
created or extended by the compiler to avoid clashes.
Differential Revision: https://reviews.llvm.org/D134455
When an explicit MODULE procedure is defined in the same (sub)module
as its interface, and the interface was defined in a generic
interface of the same name, bogus errors about symbols already
having been defined will ensue. Cleaning up this aspect of name
resolution and symbol table management requires marking the
place-holding SubprogramNameDetails symbols of explicit MODULE
subprograms as such, ensuring that that attribute is not inherited
if the SubprogramNameDetails symbol is recycled as a SubprogramDetails,
and gathering some code that should have been common between
BeginSubprogram() and BeginMpSubprogram() together in one
new routine.
Differential Revision: https://reviews.llvm.org/D134446
When a DynamicType for CHARACTER has a known length, correct a negative
length value to its effective length of zero so that all such types
compare equal in interface compatibility checking.
Differential Revision: https://reviews.llvm.org/D134405
Attributes like PURE, ELEMENTAL, &c. are specified on the interface of
a separate module procedure, so when the MODULE PROCEDURE is defined in
a submodule, it must acquire those attributes from the interface.
Differential Revision: https://reviews.llvm.org/D134403
The code snippet
module m
interface
module subroutine specific
end subroutine
end interface
interface generic
module procedure specific
end interface
end module
elicits a bogus semantic error about "specific" not being an acceptable
module procedure for the generic interface; fix.
Differential Revision: https://reviews.llvm.org/D134402
We apply special symbol table scoping to top-level subroutine
and function names that have interoperable binding names, so
that it's possible to define the same subroutine/function name
more than once at the top level so long as their binding names
are distinct. But we don't use those scoping techniques for
ENTRY statement symbols with interoperable binding names,
which can lead to bogus semantic errors when the same ENTRY
name is defined multiple times with distinct binding names.
Differential Revision: https://reviews.llvm.org/D134401
Some Fortran compilers accept user-defined ELEMENTAL procedures as actual
arguments corresponding to (necessarily) non-ELEMENTAL dummy procedures;
most do not, and f18 is one of them. Document the fact that this is not
a supported extension.
Differential Revision: https://reviews.llvm.org/D134399
There's code in name resolution that handles resolution of references
that appear in the definitions of derived types -- it checks for
existing components in the type being defined, as well as for
non-parent components in its ancestors. Special case code prevents
resolution of a name to the symbol of a procedure binding. This
code needs to be extended so that names of generic procedures
are similarly prevented from shadowing symbols in the scope around
the type.
Differential Revision: https://reviews.llvm.org/D134398
When a component reference to a named constant of derived type should
fold down to NULL() without a MOLD=, do so.
Differential Revision: https://reviews.llvm.org/D134395
When a subexpression does not have both constant elements and
a constant shape, folding is rewriting it into a vector of its
elements. This is of course wrong when the shape shows that
the result has rank greater than 1.
Differential Revision: https://reviews.llvm.org/D134392
Add TODO for whole array allocatable assignment inside FORALL
Whole allocatable array assignment inside FORALL are otherwise currently
hitting more cryptic asserts.
Add TODO in FORALL assignment when a designator appear with a part ref
that is an allocatable or pointer component (a(i)%pointer%k). The lowering
code does not handle this case well because of the pointer dereference.
Differential Revision: https://reviews.llvm.org/D134440
If a namelist item is an allocatable or pointer and is also part of a common
block, the box should be loaded from the common block ref.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D134470
Fortran is not clear about the semantics of
```
subroutine subr
integer n = 1
block
data n/2/
end block
end subroutine
```
which could be interpreted as having two variables, each
named 'n', or as having one variable 'n' with invalid double
initialization. Precedents from existing compilers are also
in disagreement.
The most common interpretation, however, agrees with a subtle
reading of the standard: BLOCK constructs scope names that have
local specifications, and a DATA statement is a declaration
construct, not a specification construct. So this example is
*not* acceptable.
Differential Revision: https://reviews.llvm.org/D134391
BytesFor() used to return KIND for the size, which is not always
correct, so I changed it to return the size of the actual CppType
corresponding to the given category and kind.
MinElemLen() used to calculate size incorrectly (e.g. CFI_type_extended_double
was sized 10, whereas it may occupy more bytes on a target), so I changed it
to call BytesFor().
Additional changes were needed to resolve new failures for transformational
intrinsics. These intrinsics used to work for not fully supported
data types (e.g. REAL(3)), but now stopped working because CppType
cannot be computed for those categories/kinds. The solution is to use
known element size from the source argument(s) for establishing
the destination descriptor - the element size is all that is needed
for transformational intrinsics to keep working.
Note that this does not help cases, where runtime still has to
compute the element size, e.g. when it creates descriptors for
components of derived types. If the component has unsupported
data type, BytesFor() will still fail. So these cases require
adding support for the missing types.
New regression unit test in Runtime/Transformational.cpp
demonstrates the case that will start working properly with
this commit.
The process of passing arguments to IO calls can cause allocations that
get referenced during EndIO calls. Calling "Finalize" causes these
allocations to be deallocated. This means that references to them in
the code in EndIO will be invalid. The fix is to delay the call to
"finalize" until after the call to EndIO.
This particularly causes problems with the IO items are strings that are
produced by calls to functions.
Differential Revision: https://reviews.llvm.org/D134383
Valentin Clement