This patch enables the Fortran runtime support library to be
built without native 128-bit integer support in the C++ compiler.
Experimental: do not merge yet.
Differential Revision: https://reviews.llvm.org/D154660
This patch mostly affects performance of the code produced by
HLIFR lowering. If MATMUL argument is an array slice, then
HLFIR lowering passes the slice to the runtime, whereas
FIR lowering would create a contiguous temporary for the slice.
Performance might be better than the generic implementation
for cases where the leading dimension is contiguous.
This patch improves CPU2000/178.galgel making HLFIR version
faster than FIR version (due to avoiding the temporary copies
for MATMUL arguments).
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D159134
Leading zeros should appear only for Iw.m output formatting.
Gw, Gw.d, and Gw.dEe output editing all map to Iw with no ".m"
(Fortran 202X 13.7.5.2.2).
Differential Revision: https://reviews.llvm.org/D159037
For nonexistent or inaccessible files, we're returning NO, which is
indeed true, but we should return UNKNOWN instead.
Differential Revision: https://reviews.llvm.org/D158653
When a FINAL subroutine is being invoked for a discontiguous array, which can
happen for INTENT(OUT) dummy arguments and for some left-hand side variables
in intrinsic assignment statements, it may be the case that the subroutine
being called was defined with a dummy argument that requires contiguous data.
Extend the derived type descriptions used by the runtime to signify when
a special procedure binding requires contiguity; set the flags accordingly;
check them in the runtime support library, and, when necessary, use a
temporary shallow copy of the finalized array data in the call to the
final subroutine.
Differential Revision: https://reviews.llvm.org/D156760
This update allows constant folding for many 128 bit floating point intrinsics
through the library quadmath, which is only available on some platforms.
Differential Revision: https://reviews.llvm.org/D156435
When creating a temporary for conflicting LHS and RHS we have to deep copy
the dynamic (allocatable, automatic) components from RHS to the temp.
Otherwise, the conflict may still be present between LHS and temp.
gfortran/regression/alloc_comp_assign_1.f90 is an example where the current
runtime code produces wrong result:
7b5b5dcbf9/Fortran/gfortran/regression/alloc_comp_assign_1.f90 (L50)
Reviewed By: klausler, tblah
Differential Revision: https://reviews.llvm.org/D156364
NORM2 is broken for arrays that start with a negative number
because it sets the initial running max_ value to that number
rather than to its absolute value.
Differential Revision: https://reviews.llvm.org/D155976
It is an error to open a new unit with OPEN(NEWUNIT=) and have
neither a file name nor a scratch status. Catch it, and report a
new error code.
Differential Revision: https://reviews.llvm.org/D155967
When MatmulTranpose reports incorrect shapes of the arguments
it cannot represent itself as MATMUL, because the reading
of the first argument's shape will be confusing.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D155911
I changed the set of files that are built for experimental CUDA/OMP
builds, i.e. the files with enabled device support are built
as such and the rest of the files are built just for the host target.
With this change we can build Flang runtime library that is fully functional
on the host target, so in-tree targets like check-flang become operational.
Reviewed By: klausler, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D155029
The implementation of BACKSPACE on a variable-length sequential formatted
file has a bug that prevents it from working on an empty record.
Differential Revision: https://reviews.llvm.org/D154750
OPEN statements can be used to change some, but not all, attributes
of units that have already been opened. The I/O runtime library
wasn't allowing ENCODING= to be changed. Every other Fortran compiler
permits this usage, and it's safe and useful, so allow it.
(Otherwise there's no good way to ensure that the preconnected
unit 6 is in UTF-8 mode.)
Differential Revision: https://reviews.llvm.org/D154379
These are initial changes to experiment with building the Fortran runtime
as a CUDA or OpenMP target offload library.
The initial patch defines a set of macros that have to be used consistently
in Flang runtime source code so that it can be built for different
offload devices using different programming models (CUDA, HIP, OpenMP target
offload). Currently supported modes are:
* CUDA: Flang runtime may be built as a fatlib for the host and a set
of CUDA architectures specified during the build. The packaging
of the device code is done by the CUDA toolchain and may differ
from toolchan to toolchain.
* OpenMP offload:
- host_device mode: Flang runtime may be built as a fatlib for the host
and a set of OpenMP offload architectures. The packaging
of the device code is done by the OpenMP offload compiler and may differ
from compiler to compiler.
OpenMP offload 'nohost' mode is a TODO to match the build setup
of libomptarget/DeviceRTL. Flang runtime will be built as LLVM Bitcode
library using Clang/LLVM toolchain. The host part of the library
will be "empty", so there will be two distributable object: the host
Flang runtime and dummy host library with device Flang runtime pieces
packaged using clang-offload-packager and clang.
In all supported modes, enabling parts of Flang runtime for the device
compilation can be done iteratively to make the patches observable.
Note that at any point in time the resulting library may have unresolved
references to not yet enabled parts of Flang runtime.
Example cmake/make commands for building with Clang for NVPTX target:
cmake \
-DFLANG_EXPERIMENTAL_CUDA_RUNTIME=ON \
-DCMAKE_CUDA_ARCHITECTURES=80 \
-DCMAKE_C_COMPILER=/clang_nvptx/bin/clang \
-DCMAKE_CXX_COMPILER=/clang_nvptx/bin/clang++ \
-DCMAKE_CUDA_COMPILER=/clang_nvptx/bin/clang \
/llvm-project/flang/runtime/
make -j FortranRuntime
Example cmake/make commands for building with Clang OpenMP offload:
cmake \
-DFLANG_EXPERIMENTAL_OMP_OFFLOAD_BUILD="host_device" \
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
-DFLANG_OMP_DEVICE_ARCHITECTURES="sm_80" \
../flang/runtime/
make -j FortranRuntime
Differential Revision: https://reviews.llvm.org/D151173
Component-by-component assignment must be able to handle unallocated
allocatable values in structure constructor. F2018 7.5.10 p. 7 states
that the component must have unallocated status as a result of such
construction. The structure constructor temporary is initialized
such that all the allocatable components are unallocated, so we just
need to make sure not to do the component assignment if RHS is deallocated.
Depends on D152482 (the same LIT test is affected)
Reviewed By: jeanPerier, tblah
Differential Revision: https://reviews.llvm.org/D152493
The TODO was left there to verify that Assign() runtime handles
overlaps of allocatable components. It did not, and this change-set
fixes it. Note that the same Assign() issue can be reproduced
without HLFIR. In the following example the LHS would be reallocated
before value of RHS (essentially, the same memory) is read:
```
program main
type t1
integer, allocatable :: a(:)
end type t1
type(t1) :: x, y
allocate(x%a(10))
do i =1,10
x%a(i) = 2*i
end do
x = x
print *, x%a
deallocate(x%a)
end program main
```
The test's output would be incorrect (though, this depends on the memory
reuse by malloc):
0 0 0 0 10 12 14 16 18 20
It is very hard to add a Flang unittest exploiting derived types.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D152306
12.10.2.17 defines that a INQUIRE statement's NEXTREC=n output value
for a unit that is not connected for direct access becomes undefined,
but the current I/O runtime can fail in a confusing manner by trying
to return uninitialized stack garbage.
Reported on Slack by Tarun Prabhu as an intermittent failure in
the gfortran regression test inquire_pre.f90.
Differential Revision: https://reviews.llvm.org/D152295
The output editing code paths for F and E/D output that handle
IEEE-754 infinities and NaNs fail to check for overflow of the
output field, which should cause the field to be filled with
asterisks instead. Catch these cases.
Differential Revision: https://reviews.llvm.org/D151738
If the path to the TEMP folder contains (non-ASCII) characters that cannot be
encoded in the current 8-bit locale of the user, openfile_mkstemp might fail
on Windows.
That is an unlikely scenario. But given that the path to the default TEMP
folder on Windows contains the Windows user name, it is still possible.
Use the wide character Windows API to avoid that (unlikely) issue.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D151571
This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6.
Adds the patch by @hans from
https://github.com/llvm/llvm-project/issues/62719
This patch fixes the Windows build.
d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews
D144509 [CMake] Bumps minimum version to 3.20.0.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
D150532 [OpenMP] Compile assembly files as ASM, not C
Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent)
when compiling a file which has been set as having the language
C. This behaviour change only takes place if "cmake_minimum_required"
is set to 3.20 or newer, or if the policy CMP0119 is set to new.
Attempting to compile assembly files with "-x c" fails, however
this is workarounded in many cases, as OpenMP overrides this with
"-x assembler-with-cpp", however this is only added for non-Windows
targets.
Thus, after increasing cmake_minimum_required to 3.20, this breaks
compiling the GNU assembly for Windows targets; the GNU assembly is
used for ARM and AArch64 Windows targets when building with Clang.
This patch unbreaks that.
D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump
The build uses other mechanism to select the runtime.
Fixes#62719
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D151344
The f18 clause 16.9.80 description of the FRACTION(X) intrinsic states:
Result Value. The result has the value ....
If X has the value zero, the result is zero.
If X is an IEEE NaN, the result is that NaN.
If X is an IEEE infinity, the result is an IEEE NaN.
This clause does not specify whether fraction(-0.0) should be -0.0 or +0.0.
However, a folded result and a runtime result should be consistent, and
returning -0.0 is more in line with the result for fraction(NaN).
For this test:
print '(2f6.1)', 0.0, fraction(0.0)
call f(0.0)
print '(2f6.1)', -0.0, fraction(-0.0)
call f(-0.0)
end
subroutine f(x)
print '(2f6.1)', x, fraction(x)
end
Current output is:
0.0 0.0
0.0 0.0
-0.0 -0.0
-0.0 0.0
Change that to:
0.0 0.0
0.0 0.0
-0.0 -0.0
-0.0 -0.0
SPACING() must return TINY() for zero arguments (which we do)
and also for subnormal values smaller than TINY() in absolute value,
which we get wrong. Fix folding and the runtime.
Differential Revision: https://reviews.llvm.org/D151272
There are several observations regarding the copy-in/copy-out:
* Actual argument associated with INTENT(OUT) dummy argument that
requires finalization (7.5.6.3 p. 7) may be read by the finalization
function, so a copy-in is required.
* A temporary created for the copy-in/copy-out must be destroyed
without finalization after the call (or after the corresponding copy-out),
otherwise, memory leaks may occur.
* The copy-out assignment must not perform finalization for the LHS.
* The copy-out assignment from the temporary to the actual argument
may or may not need to initialize the LHS.
This change-set introduces new runtime methods: CopyOutAssign and
DestroyWithoutFinalization. They are called by the compiler generated
code to match the behavior described above.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D151135
These functions will be used as part of the HLFIR lowering for
forall/where. The contents of the API were requested by @jeanPerier.
The API is designed around that use case, assuming that the caller knows
through some side channel what size to allocate for boxes returned from
the pop() function.
Differential Revision: https://reviews.llvm.org/D150050
Generate supporting data structures and calls to new runtime IO functions
for defined IO that accesses non-type-bound procedures, such as `wft` in:
module m1
type t
integer n
end type
interface write(formatted)
module procedure wft
end interface
contains
subroutine wft(dtv, unit, iotype, v_list, iostat, iomsg)
class(t), intent(in) :: dtv
integer, intent(in) :: unit
character(*), intent(in) :: iotype
integer, intent(in) :: v_list(:)
integer, intent(out) :: iostat
character(*), intent(inout) :: iomsg
iostat = 0
write(unit,*,iostat=iostat,iomsg=iomsg) 'wft was called: ', dtv%n
end subroutine
end module
module m2
contains
subroutine test1
use m1
print *, 'test1, should call wft: ', t(1)
end subroutine
subroutine test2
use m1, only: t
print *, 'test2, should not call wft: ', t(2)
end subroutine
end module
use m1
use m2
call test1
call test2
print *, 'main, should call wft: ', t(3)
end
This reverts commit 65429b9af6a2c99d340ab2dcddd41dab201f399c.
Broke several projects, see https://reviews.llvm.org/D144509#4347562 onwards.
Also reverts follow-up commit "[OpenMP] Compile assembly files as ASM, not C"
This reverts commit 4072c8aee4c89c4457f4f30d01dc9bb4dfa52559.
Also reverts fix attempt "[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump"
This reverts commit 7d47dac5f828efd1d378ba44a97559114f00fb64.
The temporary descriptor must be either Pointer or Allocatable,
otherwise its memory will not be freed.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D150534
Pointer components without default initialization pose some
difficult (or impossible) problems when they appear as right-hand
side targets in pointer assignment statements; they may contain
garbage or stale data that looks enough like a valid descriptor
to cause a crash. Solve the problem by avoiding it -- ensure
that pointers' descriptors are at least minimally established.
Differential Revision: https://reviews.llvm.org/D149979
If LHS is of derived type that needs initialization, then it must be
initialized before doing the assignment. Otherwise, the assignment
might behave incorrectly based on uninitialized components that are
descriptors themselves.
Differential Revision: https://reviews.llvm.org/D149681
When building the Fortran runtime on MinGW, `clock_gettime` is currently used. That function is provided by the `pthread` library on that platform. That means that all programs that link `libFortranRuntime` also require to be linked with `pthread` on that platform.
There is already a code path (for MSVC) that doesn't use `clock_gettime` in the implementation of the Fortran library.
Use the same code path also on MinGW by undefining `CLOCKID`.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D149051
Fortran runtime standalone build is broken after D140998
because of the missing CMake modules path. This is a fix.
Differential Revision: https://reviews.llvm.org/D149090
One piece of pointer arithmetic was adding the number of bytes instead
of the number of characters. This caused failures in CHARACTER(KIND>1)
that required padding.
This was caught using HLFIR that currently uses the runtime for array
assignment where the current lowering does everything inline.
Reviewed By: vzakhari, klausler
Differential Revision: https://reviews.llvm.org/D149062
I noticed _Complex was missing for the long double case.
I might be missing something, but it looks like the compiler
does not call the C wrappers directly. Do we need to keep
the complex-reduction.[ch] at all?
Differential Revision: https://reviews.llvm.org/D148479
A fairly recent introduction of runtime I/O APIs called OutputDerivedType()
and InputDerivedType() didn't cover NAMELIST I/O's need to access
non-type-bound generic interfaces for user-defined derived type I/O
when those generic interfaces are defined in some scope other than the
one that defines the derived type.
The patch adds a new data structure shared between lowering
and the runtime that can represent all of the cases that can
arise with non-type-bound defined I/O. It can represent
scopes in which non-type-bound defined I/O generic interfaces
are inaccessible, too, due to IMPORT statements.
The data structure is now an operand to OutputDerivedType() and
InputDerivedType() as well as a data member in the NamelistGroup
structure.
Differential Revision: https://reviews.llvm.org/D148257
When flushing output to a non-positionable tty or socket file, reset the
left tab limit. Otherwise, non-advancing output to that file will contain
an increasing amount of leading spaces in each flush. Also, detect
newline characters in stream output, and treat them as record
advancement.
Differential Revision: https://reviews.llvm.org/D148157
In the Fortran standard 2018 section 10.2.1.3 (13), it is mentioned
that all noncoarray allocatable component must follow this sequence of
operations:
1) If the component of the variable is allocated, it is deallocated.
2) If the component of the value of expr is allocated, the corresponding
component of the variable is allocated with the same dynamic type and
type parameters as the component of the value of expr. If it is an
array, it is allocated with the same bounds. The value of the
component of the value of expr is then assigned to the corresponding
component of the variable using defined assignment if the declared type
of the component has a type-bound defined assignment consistent with the
component, and intrinsic assignment for the dynamic type of that component
otherwise.
This patch updates the code to make use of the user defined assignment for
allocatable component and make sure the component is allocated correctly.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D147797
