The order of operations in name resolution wasn't converting named
entities to objects by the time that they were subjected to the implicit
typing rules in the case of interface blocks. This led to entities
remaining untyped without error, leading to a crash in module file
generation.
Fixes https://github.com/llvm/llvm-project/issues/108975.
A derived type specification in semantics holds both its source name
(for location purposes) and its ultimate derived type symbol. But for
correct module file generation of a structure constructor using that
derived type spec, the original symbol may be needed so that USE
association can be exposed.
Save both the original symbol and its ultimate symbol in the
DerivedTypeSpec, and collect the right one when traversing expressions
(specifically for handling initialization in module files).
Fixes https://github.com/llvm/llvm-project/issues/108827.
As described in #107998, we were not handling the case well when length
of the character is not part of the type. This PR handles one of the
case when the length can be calculated by looking at the result of
corresponding `fir.unboxchar`.
The DIStringTypeAttr have a `stringLength` field that can be a variable.
We create an artificial variable that will hold the length and used as
value of `stringLength` field. The variable is then attached with
a `DbgValueOp`.
Fixes#107998.
The missing scope information led to a crash in OpenMP semantic checks
run before printing the error that was already discovered in the code.
The following block has to be skipped for this invalid code so that we
don't emit a second spurious error.
Fixes#82913
The associate name preserves the association with the selector
established in the associate statement. Therefore it is incorrect to
change the data-sharing attribute of the name.
Closes#58041
We pass a list of types when creating a subroutine type. The first one
is supposed to be return type and the rest are the argument types. A
subroutine does not have a return type so an argument type could be
confused as a return type. To fix this, if there is no return type, we
generate a null type as a place holder.
Fixes#108564.
The standards aren't clear about how IEEE-754 subnormal values interact
with the intrinsic function SPACING. Four compilers interpret the
standard such that SPACING(x) will return a value never less than
TINY(x); one compiler returns TINY(x) for ABS(x) <= TINY(x) but can
return SPACING(x) < TINY(x) for some ABS(x) > TINY(x); one other
compiler works similarly, but also oddly returns SPACING(x) < TINY(x)
for ABS(x) >= TINY(x)/2.
Follow the most common precedent.
Emit a warning when an impure function is referenced from a DO
CONCURRENT or FORALL concurrent-header that is not nested within another
such construct. (That nested case is already an error.)
The test code with ignore_tkr(tk) on character dummy passed by
fir.boxchar<> was crashing the compiler in [an
assert](2afe678f0a/flang/lib/Optimizer/Dialect/FIRType.cpp (L632))
in `changeElementType`.
It makes little sense to call changeElementType on a fir.boxchar since
this type is lossy (the shape is not part of it). Just skip it in the
code dealing with ignore(tk) when hitting this case
This patch removes from the list of allowed clauses for a handful of
compound constructs those that are specifically disallowed by the OpenMP
spec. In particular, the following restrictions are followed:
- (regarding combined constructs) If _directive-name-A_ is `target`, the
`copyin` clause must not be specified.
- (regarding composite constructs) If _directive-name-A_ is
`distribute`, the `ordered` clause must not be specified.
These restrictions are listed in the OpenMP Specification version 5.2,
sections 17.4 and 17.5. Since it's a similar case as PR #90754, I'm
adding people involved in that decision as reviewers here.
The new LLVM stack save/restore intrinsic operations are more convenient
than function calls because they do not add function declarations to the
module and therefore do not block the parallelisation of passes.
Furthermore they could be much more easily marked with memory effects
than function calls if that ever proved useful.
This builds on top of #107879.
Resolves#108016
This patch modifies the representation of `OpenMP_Clause` to allow
definitions to incorporate both required and optional arguments while
still allowing operations including them and overriding the
`assemblyFormat` to take advantage of automatically-populated format
strings.
The proposed approach is to split the `assemblyFormat` clause property
into `reqAssemblyFormat` and `optAssemblyFormat`, and remove the
`isRequired` template and associated `required` property. The
`OpenMP_Op` class, in turn, populates the new `clausesReqAssemblyFormat`
and `clausesOptAssemblyFormat` properties in addition to
`clausesAssemblyFormat`. These properties can be used by clause-based
OpenMP operation definitions to reconstruct parts of the
clause-inherited format string in a more flexible way when overriding
it.
Clause definitions are updated to follow this new approach and some
operation definitions overriding the `assemblyFormat` are simplified by
taking advantage of the improved flexibility, reducing code duplication.
The `verify-openmp-ops` tablegen pass is updated for the new
`OpenMP_Clause` representation.
Some MLIR and Flang unit tests had to be updated due to changes to the
default printing order of clauses on updated operations.
Mark the symbol with OmpShared, and then check that later in lowering to
avoid making a local loop index.
OpenMP 5.2 says: "Loop iteration variables of loops that are not associated
with any OpenMP directive maybe listed in data-sharing attribute clauses on
the surrounding teams, parallel or taskgenerating construct, and on enclosed
constructs, subject to other restrictions."
Tests updated to match the extra OmpShared attribute.
Add regression test for lowering to hlfir.
Closes#102961
---------
Co-authored-by: Tom Eccles <tom.eccles@arm.com>
Currently, Flang throws a "**not yet implemented: Unhandled clause
NONTEMPORAL in SIMD construct**" error when encountering nontemporal
clause. This patch adds support for this clause in SIMD construct.
An array that has one or more empty dimensions cannot have subscripts
unless there's a possibility that they constitute an empty array
section.
We previously only checked that constant subscripts are in bounds.
There's two entries in the intrinsic table for REAL; the first handles
the REAL(z) case of a COMPLEX argument, and the second handles the data
type/kind conversion case.
In the case of REAL(x,bad) with a bad or unsupported kind of REAL,
neither table entry was matching. In the event of an unrecognized
intrinsic function, the compiler emits the first error message that
resulted, which was confusing here because it was a complaint about
having too many arguments.
Reversing the order of the intrinsic table entries would fix the error
message, but would also have broken REAL(z) with a complex argument,
since it would then be treated as REAL(z,KIND=KIND(0.)) rather than
REAL(z,KIND=KIND(z)).
The fix is to let the second entry "hit" with improved error recovery.
It is a non-mandatory error to reference an external procedure via an
implicit interface declaration (EXTERNAL or PROCEDURE()) when the
external procedure has an interface that requires the presence of an
explicit interface to be called.
Until now, the compiler has issued a fatal error message from semantics
for this situation. But (1) there are situations, such as passing such
an EXTERNAL as an actual argument, or as the target of a procedure
pointer assignment, where little or no harm is done, (2) other compilers
don't/can't detect this error, even when the procedure's definition is
in the same source file, and (3) it shows up in some real applications.
So downgrade this error to a stern warning. Perhaps in the future the
compiler could resume emission of a hard error in the cases where the
EXTERNAL procedure is actually known to be called via its implicit
interface.
…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.
As described in #98883, we have to qualify a module variable name in
debugger to get its value. This PR tries to remove this limitation.
LLVM provides `DIImportedEntity` to handle such cases but the PR is made
more complicated due to the following 2 issues.
1. The MLIR attributes are readonly and we have a circular dependency
here. This has to be handled using the recursive interface provided by
the MLIR. This requires us to first create a place holder
`DISubprogramAttr` which is used in creating `DIImportedEntityAttr`.
Later another `DISubprogramAttr` is created which replaces the place
holder.
2. The flang IR does not provide any information about the 'used' module
so this has to be extracted by doing a pass over the
`DeclareOp` in the function. This presents certain limitation as 'only'
and module variable renaming may not be handled properly.
Due to the change in `DISubprogramAttr`, some tests also needed to be
adjusted.
Fixes#98883.
Use associated procedure pointers were eliciting bogus errors from
semantics if their modules also contained generic procedure interfaces
of the same name. (The compiler handles this case correctly when the
specific procedure of the same name is not a pointer.)
With this fix, the test case in
https://github.com/llvm/llvm-project/issues/107784
no longer experiences semantic errors; however, it now crashes
unexpectedly in lowering.
Don't emit a bogus error about being unable to forward an assumed-rank
dummy argument as an actual argument in the case of the KIND intrinsic
function.
Fixes https://github.com/llvm/llvm-project/issues/107782.
A defined assignment generic interface for a given LHS/RHS type & rank
combination may have a specific procedure with LHS dummy argument that
is neither allocatable nor pointer, or specific procedure(s) whose LHS
dummy arguments are allocatable or pointer. It is possible to have two
specific procedures if one's LHS dummy argument is allocatable and the
other's is pointer.
However, the runtime doesn't work with LHS dummy arguments that are
allocatable, and will crash with a mysterious "invalid descriptor" error
message.
Extend the list of special bindings to include
ScalarAllocatableAssignment and ScalarPointerAssignment, use them when
appropriate in the runtime type information tables, and handle them in
Assign() in the runtime support library.
Specification expressions may contain references to dummy arguments,
host objects, module variables, and variables in COMMON blocks, since
they will have values on entry to the scope. A local variable with a
initializer and the SAVE attribute (which will always be implied by an
explicit initialization) will also always work, and is accepted by at
least one other compiler, so accept it with a warning.
This was a subtle problem. When the shape of a function result is
explicit but not constant, it is characterized with bounds expressions
that use Extremum<SubscriptInteger> operations to force extents to 0
rather than be negative. These Extremum operations are formatted as
"max()" intrinsic functions in the module file. Upon being read from the
module file, they are not folded back into Extremum operations, but
remain as function references; and this then leads to expressions not
comparing equal when the procedure characteristics are compared to those
of a local procedure declared identically.
The real fix here would be for folding to just always change max and min
function references into Extremum<> operations, constant operands or
not, and I tried that, but it lead to test failures and crashes in
lowering that I couldn't resolve. So, until those can be fixed, here's a
change that will read max/min operations in module file declarations
back into Extremum operations to solve the compatibility checking
problem, but leave other non-constant max/min operations as function
calls.
The standard requires that a generic interface with the same name as a
derived type contain only functions. We generally allow a generic
interface to contain both functions and subroutines, since there's never
any ambiguity at the point of call; these is helpful when the specific
procedures of two generics are combined during USE association. Emit a
warning instead of a hard error when a generic interface with the same
name as a derived type contains a subroutine to improve portability of
code from compilers that don't check for this condition.
When a module file has been compiled with CUDA enabled, don't emit
spurious errors about non-interoperable types when that module is read
by a USE statement in a later non-CUDA compilation.
cuf.data_transfer was wrongly generated when calling the `size`
intrinsic on a device allocatable variable. Since the descriptor is
available on the host, there is no transfer needed.
Add `DescriptorInquiry` in the `CollectCudaSymbolsHelper` to filter out
symbols that are not needed for the transfer decision to be made.
Mostly NFC, I was bothered by the declaration that were always made even
if unsued, and I think using LLVM Ops is nicer anyway with regards to
side effects here.
```
func.func private @llvm.stacksave.p0() -> !fir.ref<i8>
func.func private @llvm.stackrestore.p0(!fir.ref<i8>)
```
There are other places in lowering that are using the calls instead of
the LLVM intrinsics, but I will deal with them another time (the issue
there is mostly to get the proper address space for the llvm.ptr type).
This is an extension of CUDA Fortran. The iso_c_binding intrinsic can
accept a `TYPE(c_devptr)` as its first argument. This patch relax the
semantic check to accept it and update the lowering to unwrap the cptr
field from the c_devptr.
Because of the way visibility is implemented in Options.td, options that
are aliases do not inherit the visibility of the option being aliased.
Therefore, explicitly set the visibility of the alias to be the same as
the aliased option.
This partially addresses
https://github.com/llvm/llvm-project/issues/89888
When using `--save-temps`, flang-new emits (among other things) an
`<input>.i` file. These `.i` files are pre-processed Fortran files
containing information about the modules referenced by the input source
(these files are emitted by: `Parsing::EmitPreprocessedSource`).
This diff allows `.i` files emitted by flang-new to be treated as valid
files in the pre-processing phase. This, in turn, allows flang-new to
add pre-processing options (e.g. `-I`) when launching compilation jobs
for these files.
This solves a bug when using `--save-temps` with source files that
include modules from non-standard directories, for example:
```
flang-new -c --save-temps -I/tmp/module_dir -fno-integrated-as \
/tmp/ModuleUser.f90
```
The problem was that `.i` files were treated as "binary" files and
therefore the return value for `types::getPreprocessedType(InputType)`
in `Flang::ConstructJob(...)` was `types::TY_INVALID`.
Add a builtin type for c_devptr since it will need some special handling
for some function like c_f_pointer.
`c_ptr` is defined as a builtin type and was raising a semantic error if
you try to use it in a I/O statement. This patch add a check for c_ptr
and c_devptr to bypass the semantic check and allow the variables of
these types to be used in I/O.
This version of the patch keeps the semantic error when -pedantic is
enabled to align with gfortran.
This generates `warning: REAL(KIND=16) is not an enabled type for this
target` if that type is used in a build not correctly configured to
support this type. Uses of `selected_real_kind(30)` return -1.
Relanding #102147 because the test errors turned out to be specific to a
downstream configuration.
This patch fixes the mapping and lowering of arrays with dynamic extents
and adds a new test for the same. The fix discards the incomplete the
dynamic extent information and replacing it with just the base type.
When lowering to llvm later, the bounds information is used instead.
