Implement the UNSIGNED extension type and operations under control of a
language feature flag (-funsigned).
This is nearly identical to the UNSIGNED feature that has been available
in Sun Fortran for years, and now implemented in GNU Fortran for
gfortran 15, and proposed for ISO standardization in J3/24-116.txt.
See the new documentation for details; but in short, this is C's
unsigned type, with guaranteed modular arithmetic for +, -, and *, and
the related transformational intrinsic functions SUM & al.
…INCLUDE lines
The compiler current treats an INCLUDE line as essentially a synonym for
a preprocessing #include directive. The causes macros that have been
defined at the point where the INCLUDE line is processed to be replaced
within the text of the included file.
This behavior is surprising to users who expect an INCLUDE line to be
expanded into its contents *after* preprocessing has been applied to the
original source file, with no further macro expansion.
Change INCLUDE line processing to use a fresh instance of Preprocessor
containing no macro definitions except _CUDA in CUDA Fortran
compilations and, if the original file was being preprocessed, the
standard definitions of __FILE__, __LINE__, and so forth.
Moves definitions of the kind arrays into a Fortran MODULE to not only
emit the MOD file, but also compile that MODULE file into an object
file. This file is then linked into libFortranRuntime.so.
Eventually this workaround PR shoud be redone and a proper runtime build
should be setup that will then also compile Fortran MODULE files.
Fixes#89403
---------
Co-authored-by: Valentin Clement (バレンタイン クレメン) <clementval@gmail.com>
Co-authored-by: Michael Kruse <github@meinersbur.de>
Address TODOs in the intrinsic module ISO_FORTRAN_ENV, and extend the
implementation of NUMERIC_STORAGE_SIZE so that the calculation of its
value is deferred until it is needed so that the effects of
-fdefault-integer-8 or -fdefault-real-8 are reflected. Emit a warning
when NUMERIC_STORAGE_SIZE is used from the module file and the default
integer and real sizes do not match.
Fixes https://github.com/llvm/llvm-project/issues/87476.
This resolves bug #78953. Intrinsics used by the MODULE definition are
being declared PRIVATE, so that they do not leak into the namespace of
the code that USEs the modules.
Add `notify-type` to `iso_fortran_env` module. Add `notify-wait-stmt` to
the parser and add checks for constraints on the statement, `C1177` and
`C1178`, from the Fortran 2023 standard. Add three semantics tests for
`notify-wait-stmt`.
The I/O runtime's API allows -1 to be passed for a unit number in a
READ, WRITE, or PRINT statement, where it gets replaced by 5 or 6 as
appropriate. This turns out to have been a bad idea, as it prevents the
I/O runtime from detecting and reporting a program's invalid attempt to
use -1 as an I/O unit number. So just pass 5 or 6 as appropriate.
The compiler doesn't USE-associate names of intrinsic procedures from
modules (in the absence of ONLY:), so that the associating scope doesn't
get populated with names of intrinsics that were used only in
declarations (e.g., SELECTED_REAL_KIND). A recent bug report (below)
shows that we should modify that policy in the case of names that appear
in explicit INTRINSIC attribute statements. The behaviors of other
Fortran compilers are not consistent and the requirements of the
standard are not clear; this fix follows the precedent set by gfortran
and nvfortran.
Fixes https://github.com/llvm/llvm-project/issues/72084.
This revision implements the Fortran intrinsic procedures COMPILER_VERSION and COMPILER_OPTIONS from the iso_fortran_env module.
To be able to set the COMPILER_OPTIONS string according to the original compiler driver invocation, a string is passed to the frontend driver using the environment variable FLANG_COMPILER_OPTIONS_STRING, for lack of a better mechanism.
Fixes#59233
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D140524
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
Intrinsic procedures in intrinsic modules that have (or better, *are*) generic interfaces
must not have specific procedures with the same name according to the Fortran
standard (17.11.1); i.e., a user program is allowed to define a procedure
of the same name as one of these generic interfaces, even when the generic is
in scope.
Differential Revision: https://reviews.llvm.org/D131108
The f18 standard defines several intrinsic modules containing definitions
and declarations for various constants, types, and procedures. This PR adds
declarations for missing procedures in these modules.
This is a near-universal language extension; external unit 0
is preconnected to the standard error output.
Differential Revision: https://reviews.llvm.org/D114298
Move the closure of the subset of flang/runtime/*.h header files that
are referenced by source files outside flang/runtime (apart from unit tests)
into a new directory (flang/include/flang/Runtime) so that relative
include paths into ../runtime need not be used.
flang/runtime/pgmath.h.inc is moved to flang/include/flang/Evaluate;
it's not used by the runtime.
Differential Revision: https://reviews.llvm.org/D109107
Some parameters of 128-bit IEEE floating-point numbers were
incorrect, leading to a failure to define REAL128 to 16.
Differential Revision: https://reviews.llvm.org/D95387
Use internal units for internal I/O state
Replace use of virtual functions
reference_wrapper
Internal formatted output to array descriptor
Delete dead code
Begin list-directed internal output
Refactorings and renamings for clarity
List-directed external I/O (character)
COMPLEX list-directed output
Control list items
First cut at unformatted I/O
More OPEN statement work; rename class to ExternalFileUnit
Complete OPEN (exc. for POSITION=), add CLOSE()
OPEN(POSITION=)
Flush buffers on crash and for terminal output; clean up
Documentation
Fix backquote in documentation
Fix typo in comment
Begin implementation of input
Refactor binary floating-point properties to a new header, simplify numeric output editing
Dodge spurious GCC 7.2 build warning
Address review comments
Original-commit: flang-compiler/f18@9c4bba11cf
Reviewed-on: https://github.com/flang-compiler/f18/pull/982
Make compilation of other predefined module files depend on
__fortran_builtins.mod. Currently only iso_c_binding.f90 and
iso_fortran_env.f90 depend on it but others could in the future.
Create the .f18.mod files by copying from the .mod files so that
we don't have to worry about dependencies for those.
Original-commit: flang-compiler/f18@8209ad3d32
Reviewed-on: https://github.com/flang-compiler/f18/pull/899
This changes the license information in many of the flang source files.
- Renamed LICENSE to LICENSE.txt.
- NVIDIA Copyright lines have been removed.
- Initial lines for files follow the LLVM coding convention (file name on the first line; Emacs mode information on the first line).
- License references have been replaced with the abridged LLVM text.
- License information was removed from the test files.
- No file header was placed on test files (these weren't in most LLVM test files).
- License information was added to documentation files where it was missing.
We did not add brief file summaries to the initial line.
See http://llvm.org/docs/DeveloperPolicy.html#new-llvm-project-license-framework
for a description of the new license.
See http://llvm.org/docs/CodingStandards.html#file-headers
for a description of the new LLVM standard file header.
Original-commit: flang-compiler/f18@add6cde724
Reviewed-on: https://github.com/flang-compiler/f18/pull/887
There were many places in tests and predefined modules that had
incorrect code that we weren't detecting until now.
Most of the problems were deferred-shape arrays that should have
been implied-shape. For example:
`real, parameter :: a(:) = [1.0, 2.0]`
should have `(*)` rather than `(:)`.
There were also a few places with deferred-shape arrays that were
not allocatable/pointer or explicit-shape ones that were.
Original-commit: flang-compiler/f18@0a959ce1d8
Reviewed-on: https://github.com/flang-compiler/f18/pull/630
