On Linux, PowerPC defines `int_fast16_t` and `int_fast32_t` as `long`.
Need to update the corresponding type, `c_int_fast16_t` and
`c_int_fast32_t` in `iso_c_binding` module so they are interoparable.
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 PR changes the build system to use use the sources for the module
`omp_lib` and the `omp_lib.h` include file from the `openmp` runtime
project and not from a separate copy of these files. This will greatly
reduce potential for inconsistencies when adding features to the OpenMP
runtime implementation.
When the OpenMP subproject is not configured, this PR also disables the
corresponding LIT tests with a "REQUIRES" directive at the beginning of
the OpenMP test files.
---------
Co-authored-by: Valentin Clement (バレンタイン クレメン) <clementval@gmail.com>
Comparing c_ptr type for equality or inequality is raising an error.
```
not yet implemented: intrinsic module procedure: c_ptr_eq
```
or this one for inequality
```
not yet implemented: intrinsic module procedure: c_ptr_ne
```
This patch adds a lowering for them and fix the `__fortran_builtins.f90` module for inequality.
Reland after fix has landed for circular modules #85309
Comparing c_ptr type for equality or inequality is raising an error.
```
not yet implemented: intrinsic module procedure: c_ptr_eq
```
or this one for inequality
```
not yet implemented: intrinsic module procedure: c_ptr_ne
```
This patch adds a lowering for them and fix the `__fortran_builtins.f90`
module for inequality.
This PR continues the work started with PR #79006, by setting visibility
in MODULES to PRIVATE by default and explicitly exporting only the
desired symbols. `omp_lib` needs more work, as it should maybe be
compiled from `omp_lib.f90` in
`openmp/runtime/src/incluce/omp_lib.f90.var` instead of simply using an
INCLUDE for `omp_lib.h`
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.
When attempting to lower an intrinsic module procedure call, take into
account bind(c). Such procedures cannot be lowered as intrinsics since
their implementation is external to the module.
With this solution, the hardcoded "omp_lib" string can be removed when
checking if intrinsic module procedure since all procedure interfaces in
that module use bind(c).
The array of all exceptions IEEE_ALL defined in the intrinsic module
IEEE_EXCEPTIONS should contain only what the standard mandates. Existing
code depends on it having only five elements. The legacy extension
exception flag IEEE_DENORM shouldn't be an element.
Adding mma_lxvp and mma_stxvp, which are alias to already landed vec_lxvp and vec_stxvp respectively.
Differential Revision: https://reviews.llvm.org/D158274
The internal details of the C_PTR and C_FUNPTR types must be made private
so that user code can't try to access their components or attempt to use
their structure constructors.
Fixes llvm-test-suite/Fortran/fortran/c_ptr_tests_13.f90.
Differential Revision: https://reviews.llvm.org/D157343
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 patch includes the a subset of MMA intrinsics that are included in
the mma intrinsic module:
mma_assemble_acc
mma_assemble_pair
mma_build_acc
mma_disassemble_acc
mma_disassemble_pair
Submit on behalf of Daniel Chen <cdchen@ca.ibm.com>
Differential Revision: https://reviews.llvm.org/D155725
The ignore_tkr directive is applied to the third argument so that the number of
interfaces can be reduced.
Differential Revision: https://reviews.llvm.org/D155624
Rework the code used to check for calls to impure procedures in DO CONCURRENT
constructs. The current code wasn't checking the representation of the
procedure references in the strongly typed expressions, so it was missing
calls to impure subprograms made via generic interfaces. While here,
improve error messages, and fix some minor issues exposed by testing the
improved checks.
Differential Revision: https://reviews.llvm.org/D155489
This ensures that the __Fortran_builtins module is always used
as an intrinsic module by __Fortran_type_info, which avoids issues
when, for instance, the intrinsic modules dir is present in the
include paths.
Fixes https://github.com/llvm/llvm-project/issues/63592
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D154452
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 representations of CUDA Fortran data and subprogram attributes
to the symbol table and scopes of semantics. Set them in name
resolution, and emit them to module files.
Depends on https://reviews.llvm.org/D150159.
Differential Revision: https://reviews.llvm.org/D150161
The following PowerPC vector type syntax is added:
VECTOR ( element-type-spec )
where element-type-sec is integer-type-spec, real-type-sec or unsigned-type-spec.
Two opaque types (__VECTOR_PAIR and __VECTOR_QUAD) are also added.
A finite set of functionalities are implemented in order to support the new types:
1. declare objects
2. declare function result
3. declare type dummy arguments
4. intrinsic assignment between the new type objects (e.g. v1=v2)
5. reference functions that return the new types
Submit on behalf of @tislam @danielcchen
Authors: @tislam @danielcchen
Differential Revision: https://reviews.llvm.org/D150876
Make __builtin_c_loc() into an intrinsic function and verify the
special semantic requirements on its actual arguments.
Differential Revision: https://reviews.llvm.org/D149988
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
Implements the PowerPC mtfsf and mtfsfi intrinsics as well as introduces semantic error checking code for PowerPC intrinsics
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D144876
