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
This allows for incrementally updating the old API usages without
needing to update everything at once. These will be left on Both
for a little bit and then flipped to prefixed when all APIs have been
updated.
Differential Revision: https://reviews.llvm.org/D134386
In some case, the ENTRY statement in a procedure is including some
dummy argument. Until now, deallocation of intent(out) allocatable was
not checking for this and it could result in a segmentation fault.
This patch avoids deallocation when the value is not in the ENTRY stmt.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D134342
Parent component refers to the parent derived-type of an extended type.
The parent component is skipped when a specififc component is
referred to. This is fine since all the components in extended type
are available in the type itself. When the parent component is referred,
it need to be taken into account correctly.
This patch fixes the case when the parent component is referred. In a
box, an approriate slice is created or updated to point to the first
component of the parent component. For scalar, a simple conversion to
the parent component type is done.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D134170
The previous code was rewriting all shape inquires on associate
construct entities to inquires on the associated expression or variable.
This is is incorrect because at the point of inquiry, some statement
between the association and the inquiry may have modified the expression
operands or variable in a way that changes its shapes or bounds.
For instance, in the example below, expression rewrites was previously
replacing `size(x, 1)` by `size(p, 1)` which is invalid if p is a
pointer.
```
associate(x => p + 1)
call call_that_may_modify_p_shape()
print *, size(x, 1)
end associate
```
This change restricts rewrites of shape inquiries on associate construct entity
to use the associated expression shape and bounds if and only if the
shape/bounds are compile time constant. Otherwise, this may be invalid.
Differential Revision: https://reviews.llvm.org/D133857
Allocatable assignments were triggering lowering to clean-up
any WHERE mask temporaries, even if some assignments where left
in the WHERE construct.
This is because allocatable assignments lowering was being passed the
wrong statement context. Fix this by selecting the where/forall statement
context instead of a local one when there is one.
Differential Revision: https://reviews.llvm.org/D134197
The TARGET argument of ASSOCIATED has a special lowering to deal with
POINTER and ALLOCATABLE optional actual arguments because they may be
dynamically absent. The previous code was doing a ternary
(mlir::SelectOp) to deal with this case, but generated invalid
code for the unused argument (loading a nullptr fir.ref<fir.box>). This
was not detected until D133779 was merged and modified how fir.load are
lowered to LLVM for fir.box types.
Replace the select by a proper if to prevent the fir.load from being
reachable in context where it should not.
Differential Revision: https://reviews.llvm.org/D134174
Currently, the FORT_CONVERT environment variable has the highest priority when
setting the endianness conversion for unformatted files. In discussing the
appropriate priority for the fconvert option, convert specifiers were decided
to take highest priority.
This patch also initializes the open statement convert state to unknown
to disambiguate cases where the convert specifier was not provided from
cases where convert=native was set. This makes it possible to defer to the
environment setting where appropriate.
Differential Revision: https://reviews.llvm.org/D133237
Create simplified functions for each rank with "x<rank>" suffix
that implement multidimensional reductions. To enable this I had to fix
an issue with taking incorrect box shape in cases of sliced embox/rebox.
Differential Revision: https://reviews.llvm.org/D133820
I'm planning to deprecate and eventually remove llvm::empty.
Note that no use of llvm::empty requires the ability of llvm::empty to
determine the emptiness from begin/end only.
A simple sed doing these substitutions:
- `${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}\>` -> `${LLVM_LIBRARY_DIR}`
- `${LLVM_BINARY_DIR}/bin\>` -> `${LLVM_TOOLS_BINARY_DIR}`
where `\>` means "word boundary".
The only manual modifications were reverting changes in
- `runtimes/CMakeLists.txt`
because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing.
There are some `${LLVM_BINARY_DIR}/lib` without the `${LLVM_LIBDIR_SUFFIX}`, but these refer to the lib subdirectory of the source (`llvm/lib`). That `lib` is automatically appended to make the local `CMAKE_CURRENT_BINARY_DIR` value by `add_subdirectory`; since the directory name in the source tree is fixed without any suffix, the corresponding `CMAKE_CURRENT_BINARY_DIR` will also be. We therefore do not replace it but leave it as-is.
This picks up where D133828 left off, getting the occurrences with*out* `CMAKE_CFG_INTDIR`. But this is difficult to do correctly and so not done in the (retroactively) previous diff.
This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D132316
Tests don't work on PPC since `return` instruciton is't called `ret` (apparently)
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D133859
The test was added as a .mlir file, and this extension is not
in the lit.cfg.py, so it was never run. When running it, the
file would produce an error, as semicolon is not an MLIR comment.
This adds the extension and fixes the comment start by using C++
style comments.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D133792
`fir.box` and `fir.ref<fir.box>` are both lowered to LLVM as a
descriptor in memory. This is because fir.box of polymorphic and assumed
rank entities cannot be known at compile time, so fir.box cannot be
lowered to a struct value.
fir.load or fir.ref<fir.box> was previously lowered to a no-op,
propagating the operand descriptor storage as a result.
This is wrong because the operand descriptor storage may later be
modified, and these changes should not be visible in the loaded fir.box
that is an immutable SSA value.
Modify fir.load codegen for fir.box to make a copy into a new storage to
ensure the fir.box is immutable.
Differential Revision: https://reviews.llvm.org/D133779
Write a semantics test for the atomic intrinsic subroutine,
atomic_fetch_xor.
Reviewed By: rouson
Differential Revision: https://reviews.llvm.org/D133704
CompareToBlankPadding was doing signed compare on architecture where
`char` is signed. This caused `'abc'//char(128) > 'abc'` to evaluate
to false at runtime instead of true.
Differential Revision: https://reviews.llvm.org/D133693
Write a semantics test for the atomic intrinsic subroutine,
atomic_fetch_and.
Reviewed By: rouson
Differential Revision: https://reviews.llvm.org/D133506
Branch optimization in function rewriteIfGotos attempts to rewrite code
such as
<<IfConstruct>>
1 If[Then]Stmt: if(cond) goto L
2 GotoStmt: goto L
3 EndIfStmt
<<End IfConstruct>>
4 Statement: ...
5 Statement: ...
6 Statement: L ...
to eliminate a branch and a trivial basic block to get:
<<IfConstruct>>
1 If[Then]Stmt [negate]: if(cond) goto L
4 Statement: ...
5 Statement: ...
3 EndIfStmt
<<End IfConstruct>>
6 Statement: L ...
Among other requirements, this is invalid if any statement between the
GOTO and its target is an intermediate construct statement such as a
CASE or ELSE IF statement, like the CASE DEFAULT statement in:
select case(i)
case (:2)
n = i * 10
case (5:)
n = i * 1000
if (i <= 6) goto 9 ! exit over 'case default'; may not be rewritten
n = i * 10000
case default
n = i * 100
9 end select
Adds support for .and. reductions with logical types.
Because arith.addi doesn'to work with fir.logical<4> types
logical<4> must be converted to i1 prior to the operation.
This means that the pattern matched by integer reductions
(load -> op -> store) will not match logical reductions.
Instead, the pattern being searched for here is
load -> convert(logical<4> to i1) -> op -> convert(i1 to logical<4>) -> store
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D132228
Valentin Clement