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
Per Fortran 2018, "NAN" and "NAN()" are to be translated into quiet
NaNs, and the other forms are implementation-dependent; I've made
them quiet NaNs too. Also process signs on input NaNs, which seems
wrong but other compilers all do it, and fix some misleading template
argument names noticed along the way.
Differential Revision: https://reviews.llvm.org/D147071
The present I/O infrastructure for user-defined derived type I/O
subroutines works fine for type-bound I/O generic bindings. It also works
for explicit INTERFACE blocks and GENERIC statements that define
UDDIO subroutines in the same scope as the definition of the derived type,
so long as the specific procedures in those bindings are module procedures
or external procedures.
For non-type-bound UDDTIO specific procedures that are dummy procedures,
thunks of inner procedures, or procedure pointers, or that are defined with
interfaces or GENERIC outside the scope of the definition of the derived
type, a new runtime I/O API is needed so that lowering can generate
a call that supplies the appropriate procedure as well as the defined
type instance.
This patch specifies and implements this new runtime API and provides
utility routines for lowering to use to determine whether it should be
called for any particular OutputItem or InputItem in the parse tree.
Differential Revision: https://reviews.llvm.org/D146571
`AllocatableInitIntrinsic`, `AllocatableInitCharacter` and
`AllocatableInitDerived` are meant to be used to initialize a
descriptor when it is instantiated and not to be used multiple
times in a scope.
Add `AllocatableInitDerivedForAllocate`, `AllocatableInitCharacterForAllocate`
and `AllocatableInitDerivedForAllocate` to be used for the allocation
in allocate statement.
These new functions are meant to be used on an initialized descriptor
and will return directly if the descriptor is allocated so the
error handling is done by the call to `AllocatableAllocate`.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D146290
This fused operation should run a lot faster than first transposing the
lhs array and then multiplying the matrices separately.
Based on flang/runtime/matmul.cpp
Depends on D145959
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D145960
The runtime's I/O error handler was not crashing the program on an
end-of-file condition that arises for a data transfer statement with
at least one of ERR= or IOMSG= and none of END= or IOSTAT= control
items. This turns out to be incorrect (per subclause 12.11);
an EOF is recoverable only for END= and/or IOSTAT=, and an
non-advancing end-of-record is recoverable only for EOR= and/or IOSTAT=.
Differential Revision: https://reviews.llvm.org/D145754
The code in DoElementalDefinedAssignment() needs to establish its
to & from per-element descriptors with Establish() rather than
copying an array's descriptor and then setting its rank to zero;
the current technique loses the information in the addendum.
Differential Revision: https://reviews.llvm.org/D145753
A handful of I/O statements (OPEN, CLOSE, positioning) are not allowed
on units during child I/O; catch violations and report errors.
Also finesse error handling during FORMAT runtime parsing of DT
derived type edit descriptors, and ensure that formatted child
I/O is nonadvancing.
Differential Revision: https://reviews.llvm.org/D145751
The runtime check for infinite unlimited format repetition is missing
the case of implicit unlimited format repetition at the top level
without finding the next data edit descriptor that corresponds with
a data list item.
Replace the check with a Boolean flag that detects unlimited
repetition hitting a right parenthesis and restarting, and fail
when it happens the second time.
Differential Revision: https://reviews.llvm.org/D145745
Unlimited polymorphic entities can have an intrinsic dynamic type. Update the
code of extends_type_of to compare the CFI_type in these case.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D145722
In the calculation of derived type component byte sizes, ensure
that CLASS(*) unlimited polymorphic components have space allocated
for their addenda.
Differential Revision: https://reviews.llvm.org/D145248
Only apply the change made in D145604 for derived-type.
zero-sized character for example are supposed to give a false result
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D145675
Restore the behavior changed in D145384 and add proper
unit tests.
Unallocated unlimited poymorphic allocatable and disassociated
unlimited polymorphic pointer should return false.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D145674
When a derived-type as no component, its elem_len will be set to
zero when emboxed. Update the function to let empty derived-type
pointer/target succeed the test.
Example extracted from gfortran test pointer_init_8
```
module m
type :: c
end type c
type, extends(c) :: d
end type d
type(c), target :: x
end module
use m
class(c), pointer :: px => x
if (.not. associated(px, x)) STOP 1
end
```
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D145604
Unallocated unlimited polymorphic entities do not have a dynamic type set
and do not have declared type. The standard notes that the result is
processor dependent when one of the arguments of same_type_as is in this
case. Align the result to other compiler (gfortran, nvfortran).
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D145384
Some build bots have not been updated to the new minimal CMake version.
Reverting for now and ping the buildbot owners.
This reverts commit 44c6b905f8527635e49bb3ea97dea315f92d38ec.
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.
Reviewed By: mehdi_amini, MaskRay, ChuanqiXu, to268, thieta, tschuett, phosek, #libunwind, #libc_vendors, #libc, #libc_abi, sivachandra, philnik, zibi
Differential Revision: https://reviews.llvm.org/D144509
When the left-hand side of an allocatable assignment has an explicit character length,
rather than a deferred length that might imply reallocation, handle any discrepancy
in lengths via truncation or blank padding.
Differential Revision: https://reviews.llvm.org/D145111
