This is very similar to CPU_TIME, except that we return nanoseconds
rather than seconds. This means we're potentially dealing with rather
large numbers, so we'll have to wrap around to avoid overflows.
Differential Revision: https://reviews.llvm.org/D105970
Add an implementation for the runtime functions related to SYSTEM_CLOCK.
As with CPU_TIME, this is based on std::clock(), which should be
available everywhere, but it is highly recommended to add
platform-specific implementations for systems where std::clock() behaves
poorly (e.g. POSIX).
The documentation for std::clock() doesn't specify a maximum value and
in fact wrap around behaviour is non-conforming. Therefore, this
implementation of SYSTEM_CLOCK is not guaranteed to wrap around either,
and after std::clock reaches its maximum value we will likely just
return failure rather than wrap around. If this happens often on your
system, please add a new platform-specific implementation.
We define COUNT_MAX as either the maximum value that can be stored in
a std::clock_t or in a 64-bit integer (whichever is smaller), and
COUNT_RATE as CLOCKS_PER_SEC. For POSIX systems, the value of
CLOCKS_PER_SEC is hardcoded to 10^6 and irrelevant for the values
returned by std::clock.
Differential Revision: https://reviews.llvm.org/D105969
When the vector version of EOSHIFT was called, the BOUNDARY argument was being
ignored. I fixed that and added a test that would not pass without this fix.
Differential Revision: https://reviews.llvm.org/D108249
NAMELIST input needs to start with a call to BeginReadingRecord().
Internal unit input doesn't care (so unit tests were passing), but
external unit input does need the call and will assert without it.
Differential Revision: https://reviews.llvm.org/D108051
A recent runtime I/O change[1] was meant to improve the handling of
input from external files missing a terminal newline on their last
records; the change was "triggered" by the wrong circumstances and
causing reads that should have pulled more data into the buffer to be
treated as EOFs. So fix that, and also don't retain input data
in the buffer once an input record has been finished unless it's
known that list-directed or NAMELIST input of a repeated input item
may need to backspace a non-positionable external unit to return
to the beginning of the repeated item.
[1] 6578893a0453384346f149479f8574dfff977ace
Differential Revision: https://reviews.llvm.org/D108164
std::clock_t can be an unsigned value on some platforms like MacOS and
therefore needs a cast when initializing an std::clock_t value with -1.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D107972
A repeated null value at the end of an input record with a count > 1
would incorrectly advance to the next record when resumed. Fix.
Improve some poor naming and code flow noticed while debugging, so
next time will be easier.
Extend a unit test to check this case.
Differential Revision: https://reviews.llvm.org/D107917
Some build environments complain about unused data members in some
C++ translations of Fortran derived types; those members don't really
need to be present, so remove them.
Fix pushed w/o review to get build bots running again.
Define an API for, and implement, runtime support for arbitrary
assignment of one descriptor's data to another, with full support for
(re)allocation of allocatables with finalization when necessary,
user-defined derived type assignment TBP calls, and intrinsic (default)
componentwise assignment of derived type instances with allocation of
automatic components. Also clean up API and implementation of
finalization/destruction using knowledge gained while studying
edge cases for assignment in the 2018 standard.
The look-up procedure for special procedure bindings in derived
types has been optimized from O(N) to O(1) since it will probably
matter more. This required some analysis in runtime derived type
description table construction in semantics and some changes to the
table schemata.
Executable Fortran tests have been developed; they'll be added
to the test base once they can be lowered and run by f18.
Differential Revision: https://reviews.llvm.org/D107678
The algorithm for Fw.d output will drive binary to decimal conversion for
an initial fixed number of digits, then adjust that number based on the
result's exposent. For value close to a power of ten, this adjustment
process wouldn't terminate; e.g., formatting 9.999 as F10.2 would start
with 1e2, boost the digits to 2, get 9.99e1, decrease the digits, and loop.
Solve by refusing to boost the digits a second time.
Differential Revision: https://reviews.llvm.org/D107490
result descriptor (e.g., maxloc, minloc, maxval, minval, all, any, count,
parity, findloc, etc.)
Also add a scalar case for these intrinsic unit tests.
Differential Revision: https://reviews.llvm.org/D106820
Fix the external-io unittest under Windows.
In particular, fixes the following issues:
1. When creating a temporary file, open it with read+write permissions
using the _O_RDWR flag. _S_IREAD and _S_IWRITE are for the file
permissions of the created file.
2. _chsize returns 0 on success (just like ftruncate).
3. To set a std::optional, use its assign-operator overload instead of
getting a reference to its value and overwrite that. The latter is
invalid if the std::optional has no value, and is caught by
msvc's debug STL.
The non-GTest unittest is currently not executed under Windows because
of the added .exe extension to the output file: external-io.text.exe.
llvm-lit skips the file because .exe is not in the lists of test
suffixes (.test is). D105315 is going to change that by converting it
to a GTest-test.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D106726
When a WRITE overwrites an endfile record, we need to forget
that there was an endfile record. When doing a BACKSPACE
after an explicit ENDFILE statement, the position afterwards
must be upon the endfile record.
Attempts to join list-directed delimited character input across
record boundaries was due to a bad reading of the standard
and has been deleted, now that the requirements are better understood.
This problem would cause a read attempt past EOF if a delimited
character input value was at the end of a record.
It turns out that delimited list-directed (and NAMELIST) character
output is required to emit contiguous doubled instances of the
delimiter character when it appears in the output value. When
fixed-size records are being emitted, as is the case with internal
output, this is not possible when the problematic character falls
on the last position of a record. No two other Fortran compilers
do the same thing in this situation so there is no good precedent
to follow.
Because it seems least wrong, with this patch we now emit one copy
of the delimiter as the last character of the current record and
another as the first character of the next record. (The
second-least-wrong alternative might be to flag a runtime error,
but that seems harsh since it's not an explicit error in the standard,
and the output may not have to be usable later as input anyway.)
Consequently, the output is not suitable for use as list-directed or
NAMELIST input.
If a later standard were to clarify this case, this behavior will of
course change as needed to conform.
Differential Revision: https://reviews.llvm.org/D106695
NAMELIST I/O formatting uses the runtime infrastructure for
list-directed I/O. List-directed input processing has same state
that requires reinitialization for each successive NAMELIST input
item. This patch fixes bugs with "null" items and repetition counts
on NAMELIST input items after the first in the group.
Differential Revision: https://reviews.llvm.org/D106694
This change fixes a bug in the runtime portion of the CSHIFT intrinsic
that happens when the value of the SHIFT argument is negative.
Differential Revision: https://reviews.llvm.org/D106292
A field in DescriptorAddendum became unused during a recent
change but was not removed from the definition; it now elicits
a legitimate warning that's affecting some buildbots. Remove it.
F18 was sigalling an end-of-file error condition when reading an
unformatted sequential input file without an ultimate newline
(or CR-LF). Other Fortran implementations can handle it, so change
the runtime to support it.
Differential Revision: https://reviews.llvm.org/D106321
Use derived type information tables to drive default component
initialization (when needed), component destruction, and calls to
final subroutines. Perform these operations automatically for
ALLOCATE()/DEALLOCATE() APIs for allocatables, automatics, and
pointers. Add APIs for use in lowering to perform these operations
for non-allocatable/automatic non-pointer variables.
Data pointer component initialization supports arbitrary constant
designators, a F'2008 feature, which may be a first for Fortran
implementations.
Differential Revision: https://reviews.llvm.org/D106297
A rank-0 static descriptor needs to be a vector; it's for
"v-list" values in defined derived type formatted I/O.
(Pushed without pre-review due to high confidence and an
unwell buildbot.)
SYSTEM_CLOCK may take up to 3 optional parameters, all of which are
INTENT(OUT). The COUNT and COUNT_MAX parameters are integer scalars,
while COUNT_RATE may be a real or integer scalar.
This patch breaks up the interface into 3 different functions, one for
each parameter. All 3 return integers. It is up to lowering to convert
the results to the preferred type.
Differential Revision: https://reviews.llvm.org/D104851
Non-advancing I/O was failing; ExternalFileUnit was losing
track of what writes had been committed to the file. Fixed.
Also, support the common extension of $ and \ in a FORMAT
as being equivalent to ADVANCE=NO.
Differential Revision: https://reviews.llvm.org/D105046
With derived type description tables now available to the
runtime library, it is possible to implement the concept
of "child" I/O statements in the runtime and use them to
convert instances of derived type I/O data transfers into
calls to user-defined subroutines when they have been specified
for a type. (See Fortran 2018, subclauses 12.6.4.8 & 13.7.6).
- Support formatted, list-directed, and NAMELIST
transfers to internal parent units; support these, and unformatted
transfers, for external parent units.
- Support nested child defined derived type I/O.
- Parse DT'foo'(v-list) FORMAT data edit descriptors and passes
their strings &/or v-list values as arguments to the defined
formatted I/O routines.
- Fix problems with this feature encountered in semantics and
FORMAT valiation during development and end-to-end testing.
- Convert typeInfo::SpecialBinding from a struct to a class
after adding a member function.
Differential Revision: https://reviews.llvm.org/D104930
A recent change that extended semantic analysis for actual arguments
that associate with procedure dummy arguments exposed some bugs in
regression test suites due to points of confusion in symbol table
handling in situations where a generic interface contains a specific
procedure of the same name. When passing that name as an actual
argument, for example, it's necessary to take this possibility into
account because the symbol for the generic interface shadows the
symbol of the same name for the specific procedure, which is
what needs to be checked. So add a small utility that bypasses
the symbol for a generic interface in this case, and use it
where needed.
Differential Revision: https://reviews.llvm.org/D104929
argument instead of a result result object.
Change the reshape flang unit test to use the new interface. Also, add an
order argument to exercise the order subscript code in the rehsape runtime
routine.
Differential Revision: https://reviews.llvm.org/D104586
One of the buildbots uses a compiler (can't tell which) that
doesn't approve of a "default:" in a switch statement whose
cases appear to completely cover all possible values of an
enum class. But this switch is in raw data dumping code that
needs to allow for incorrect values in memory. So rewrite it
as a cascade of if statements; performance doesn't matter here.
This is *not* user-defined derived type I/O, but rather Fortran's
built-in capabilities for using derived type data in I/O lists
and NAMELIST groups.
This feature depends on having the derived type description tables
that are created by Semantics available, passed through compilation
as initialized static objects to which pointers can be targeted
in the descriptors of I/O list items and NAMELIST groups.
NAMELIST processing now handles component references on input
(e.g., "&GROUP x%component = 123 /").
The C++ perspectives of the derived type information records
were transformed into proper classes when it was necessary to add
member functions to them.
The code in Semantics that generates derived type information
was changed to emit derived type components in component order,
not alphabetic order.
Differential Revision: https://reviews.llvm.org/D104485
Use a "double-double" accumulator, a/k/a Kahan summation,
in the SUM intrinsic in the runtime for real & complex.
This seems to be the best-recommended technique for reducing
error, as opposed to the initial implementation of SUM's
distinct accumulators for positive and negative items.
Differential Revision: https://reviews.llvm.org/D104338
Implement constant folding for the reduction transformational
intrinsic functions MAXVAL and MINVAL.
In anticipation of more folding work to follow, with (I hope)
some common infrastructure, these two have been implemented in a
new header file.
Differential Revision: https://reviews.llvm.org/D104337
When chasing down another unrelated bug, I noticed that the
implementations of various character intrinsic functions assume
that the lower bounds of (some of) their arguments were 1.
This isn't necessarily the case, so I've cleaned them up, tweaked
the unit tests to exercise the fix, and regularized the allocation
pattern used for results to use SetBounds() before Allocate() rather
than the old original Descriptor::Allocate() wrapper around
CFI_allocate().
Since there were few other remaining uses of the old original
Descriptor::Allocate() wrapper, I also converted them to the
new one and deleted the old one.
Differential Revision: https://reviews.llvm.org/D104325
Flang diverges from the llvm coding style in that it requires braces
around the bodies of if/while/etc statements, even when the body is
a single statement.
This commit adds the readability-braces-around-statements check to
flang's clang-tidy config file. Hopefully the premerge bots will pick it
up and report violations in Phabricator.
We also explicitly disable the check in the directories corresponding to
the Lower and Optimizer libraries, which rely heavily on mlir and llvm
and therefore follow their coding style. Likewise for the tools
directory.
We also fix any outstanding violations in the runtime and in
lib/Semantics.
Differential Revision: https://reviews.llvm.org/D104100
Add an implementation for CPU_TIME using the POSIX function
clock_gettime. I think on most POSIX systems this will be included for
free via <ctime>, which corresponds to "time.h" (YMMV, we can fix the
code if the need arises).
Detecting that clock_gettime is available is tricky. For instance, commit
827407a86a used the following incantation in f18-parse-demo.cpp:
#if _POSIX_C_SOURCE >= 199309L && _POSIX_TIMERS > 0 && _POSIX_CPUTIME && \
defined CLOCK_PROCESS_CPUTIME_ID
This doesn't work on my AArch64 Ubuntu system, which provides
clock_gettime but doesn't define _POSIX_TIMERS. Since finding the right
combination of macros requires infinite time, patience and access to
sundry POSIX systems, we should probably try a different approach.
This patch attempts to use SFINAE instead of the preprocessor to choose
an implementation for CPU_TIME. We define a helper function template
which helps us check if clock_gettime is available (and has the
interface we expect). I hope the comments explain it well enough.
This approach has the advantage that it keeps the detection of
clock_gettime close to the code that uses it. An alternative would be to
use CMake to check for the symbol (I personally haven't used this before
so I don't know if there are any quirks).
Differential Revision: https://reviews.llvm.org/D104020
Add an implementation for CPU_TIME based on std::clock(), which should
be available on all the platforms that we support.
Also add a test that's basically just a sanity check to make sure we
return positive values and that the value returned at the start of some
amount of work is larger than the one returned after the end.
Differential Revision: https://reviews.llvm.org/D104019
CPU_TIME takes a single real scalar INTENT(OUT) argument. We can
therefore return a double and let lowering handle casting that to the
precision used for the default real kind.
Differential Revision: https://reviews.llvm.org/D103805
Rename the definitions of the character runtime functions Adjustl and
Adjustr (used to be AdjustL and AdjustR respectively).
Also add unit tests (and move some of the helpers to the top of the
file, since they're now used in more than one place).
Differential Revision: https://reviews.llvm.org/D103392
A recent commit (e00a170) inadvertently exposed the Reshape runtime
function as being extern "C", for which it is not yet ready, leading
to a valid warning from clang that we treat as an error. Patch.
Define APIs, naively implement, and add basic sanity unit tests for
the transformational intrinsic functions CSHIFT, EOSHIFT, PACK,
SPREAD, TRANSPOSE, and UNPACK. These are the remaining transformational
intrinsic functions that rearrange data without regard to type
(except for default boundary values in EOSHIFT); RESHAPE was already
in place as a stress test for the runtime's descriptor handling
facilities.
Code is in place to create copies of allocatable/automatic
components when transforming arrays of derived type, but it won't
do anything until we have derived type information being passed to the
runtime from the frontend.
Differential Revision: https://reviews.llvm.org/D102857
Define an API for the transformational intrinsic function MATMUL,
implement it, and add some basic unit tests. The large number of
possible argument type combinations are covered by a set of
generalized templates that are instantiated for each valid
pair of possible argument types.
Places where BLAS-2/3 routines could be called for acceleration
are marked with TODOs. Handling for other special cases (e.g.,
known-shape 3x3 matrices and vectors) are deferred.
Some minor tweaks were made to the recent related implementation
of DOT_PRODUCT to reflect lessons learned.
Differential Revision: https://reviews.llvm.org/D102652
API, implementation, and basic tests for the transformational
reduction intrinsic function DOT_PRODUCT in the runtime support
library.
Differential Revision: https://reviews.llvm.org/D102351
Implement the reduction transformational intrinsic function NORM2 in
the runtime, using infrastructure already in place for MAXVAL & al.
Differential Revision: https://reviews.llvm.org/D102024
Diana Picus