…grams
The parser only recognizes compiler directives that appear within
internal / module subprograms, not those that might appear between them.
Extend to allow them between subprograms as well.
When the interface of a procedure is implicit at the point of call,
don't perform actual argument type conversion to the types of the dummy
arguments. This was inadvertently taking place in a case where the
procedure has an implicit interface but was also defined in the same
source file, so that its characteristics were known.
…lastprivate
OpenMP 5.2 standard (Section 5.3) defines privatization for list items.
Section 3.2.1 in the standard defines list items to exclude variables
that are part of other variables.
This patch adds the restriction to firstprivate and lastprivates, it was
previously added for privates.
Fixes https://github.com/llvm/llvm-project/issues/67227
Note: The specific checks that are added here are explicitly called out
in OpenMP 4.0
(https://www.openmp.org/wp-content/uploads/OpenMP4.0.0.pdf) Sections
2.14.3.4 and 2.14.3.5 but in later standards have become implicit
through other definitions.
When the characteristics of a procedure depend on a procedure that
hasn't yet been defined, the compiler currently emits an unconditional
error message. This includes the case of a procedure whose
characteristics depend, perhaps indirectly, on itself. However, in the
case where the characteristics of a procedure are needed to resolve a
generic, we should not emit an error for a hitherto undefined procedure
-- either the call will resolve to another specific procedure, in which
case the error is spurious, or it won't, and then an error will issue
anyway.
Fixes https://github.com/llvm/llvm-project/issues/88677.
When a statement function in a nested scope has a name that clashes with
a name that exists in the host scope, the compiler can handle it
correctly (with a portability warning)... unless the host scope acquired
the name via USE association. Fix.
Fixes https://github.com/llvm/llvm-project/issues/88678.
When a symbol is known to be a procedure due to its being referenced as
a function or subroutine, improve the error messages that appear if the
symbol is also used as an object by attaching the source location of its
procedural use. Also, for errors spotted in name resolution due to how a
given symbol has been used, don't unconditionally set the symbol's error
flag (which is otherwise generally a good idea, to prevent cascades of
errors), so that more unrelated errors related to usage will appear.
A recent patch added an error message for whole optional dummy argument
usage as optional arguments (third or later) to MAX and MIN when those
names required type conversion, since that conversion only works when
the optional arguments are present. This check shouldn't care about
character lengths. Make it so.
COMMON block names must be declared in the same scoping unit in
which the OpenMP directive or clause appears, but OpenMP
constructs must not be considered as scoping units. Instead,
consider only program units and block constructs as such.
In the presence of other semantic error, `GetAssignment` would return a
nullptr and therefore would make the rest of the check crash when trying
to collect symbols.
Exiting early when we have a nullptr so the compiler doesn't crash and
user can get the meaningful semantic error.
When a local variable inside a BLOCK construct is used as threadprivate
variable, llvm-flang throws below error:
> error: The THREADPRIVATE directive and the common block or variable in
it must appear in the same declaration section of a scoping unit
Accept the reduction modifier in the Flang parser. Issue a TODO message
during lowering.
OpenMP 5.0 introduced the reduction modifier. Details can be seen in
2.19.5.4 reductionClause.
OpenMP 5.2 relevant section is 5.5.8reductionClause.
This will help remove some of the parser errors highlighted in the
following post and also bring it to a well defined behaviour (produce
TODO errors for unsupported features, do not crash).
https://discourse.llvm.org/t/proposal-rename-flang-new-to-flang/69462/60
Add the "nowait" clause to the list of allowed clauses for the "workshare"
directive. This will make it consistent with other directives (which are
shared between C/C++ and Fortran).
The parser will still reject "nowait" on "!$omp workshare", so this has no
effect on accepting/rejecting Fortran source code.
Current semantic checks of default clause incorrectly update symbol
flags related to threadprivate symbols. This patch adds an additional
check to skip such updation should a symbol be already declared
threadprivate.
Fixes https://github.com/llvm/llvm-project/issues/78282
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.
…nt arguments
Arguments to the intrinsic functions MAX and MIN after the first two are
optional. When these actual arguments might not be present at run time,
emit a compilation time error if they require data conversion (a
non-standard but nearly universal language extension); such a conversion
would crash if the argument was absent.
Other compilers either disallow data conversions entirely on MAX/MIN or
crash at run time if a converted argument is absent.
Fixes https://github.com/llvm/llvm-project/issues/87046.
When a program attempts to use a non-object entity as the base of a
component reference or type parameter inquiry, the message is somewhat
uninformative and the position of the entity's declaration will not
reflect any updates made to the symbol during name resolution.
Includes some NFC C++17 style clean-up on some code noticed while
debugging (missing mandatory braces).
A derived type name in an IMPLICIT statement might be a host association
or it might be a forward reference to a local derived type, which may be
shadowing a host-associated name. Add a scan over the specification part
in search of derived type definitions to determine the right
interpretation.
Fixes https://github.com/llvm/llvm-project/issues/87215.
The specification allow list-directed PRINT and WRITE statements to
appear in device code. This patch relax the semantic check to allow
them.
3.6.11.
List-directed PRINT and WRITE statements to the default unit may be used
when compiling for compute capability 2.0 and higher; all other uses of
PRINT and WRITE are disallowed.
In section 3.4.2, some example of illegal data transfer using expression
are given. One of it is when multiple device objects are part of an
expression in the rhs. Current implementation allow a single device
object in such case. This patch adds a similar restriction.
…uous function.
Fix from [thtsikas](https://github.com/thtsikas) based on a discussion
in
[slack](https://flang-compiler.slack.com/archives/C5C58TT32/p1711124374836079).
Example:
```
Program test
Integer, Pointer, Contiguous :: cont(:)
Interface
Function f()
Integer, Pointer :: f(:)
End Function
End Interface
cont => f()
Print *, cont(3)
End Program
Function f()
Integer, Pointer :: f(:)
Allocate (f(4),Source=[1,1,42,1])
! f => f(4:1:-1) !! not contiguous, runtime error
End Function f
```
Understanding is that the standard intended to allow this pattern. The
restriction 10.2.2.3 p6 Data pointer assignment "If the pointer object
has the CONTIGUOUS attribute, the pointer target shall be contiguous."
is not associated with a numbered constraint. If there is a mechanism
for injecting runtime checks, this would be a place to do it. Absent
that, a warning is the best we can do.
No other compiler treats contigPtr => func() as an error when func() is
not CONTIGUOUS, so a warning would probably be better for consistency.
https://godbolt.org/z/5cM6roeEE
An apparent attempt to override a type-bound procedure is not allowed to
be interpreted as on override when the procedure is PRIVATE and the
override attempt appears in another module. However, if the TBP that
would have been overridden is a DEFERRED procedure in an abstract base
type, the override must take place. PRIVATE DEFERRED procedures must
therefore have all of their overrides appear in the same module as the
abstract base type.
A function uses "if constexpr" to consider all possible types in a
variant, but looks as if it can fall out without returning an
expression. Add a final "else" with a crash to make things more clear
and to protect against unlikely future extensions of the type.
Fixes https://github.com/llvm/llvm-project/issues/86391.
Fortran allows the INTRINSIC attribute to be specified with a distinct
attribute statement, and also as part of the attribute list of a
type-declaration-stmt. This is an odd case (especially as the declared
type is mandated to be ignored if it doesn't match the type of the
intrinsic function) that can lead to odd error messages and crashes,
since the rest of name resolution expects that intrinsics with explicit
declarations will have been declared with INTRINSIC attribute
statements. Resolve by handling an "inline" INTRINSIC attribute as a
special case while processing a type-declaration-stmt, so that
real, intrinsic :: acos, asin, atan
is processed exactly as if it had been
intrinsic acos, asin, atan; real acos, asin, atan
Fixes https://github.com/llvm/llvm-project/issues/86382.
Supports the REDUCE() transformational intrinsic function of Fortran
(see F'2023 16.9.173) in a manner similar to the existing support for
SUM(), PRODUCT(), &c. There are APIs for total reductions to scalar
results, and APIs for partial reductions that reduce the rank of the
argument by one.
This implementation requires more functions than other reductions
because the various possible types of the user-supplied OPERATION=
function need to be elaborated.
Once the basic API in reduce.h has been approved, later patches will
implement lowering.
REDUCE() is primarily for completeness, not portability; only one other
Fortran compiler implements this F'2018 feature today, and only some
types work correctly with it.
ConvertToObjectEntity() returns true for use- and host-associated object
symbols, too. Ensure in this case that the symbol really is a
non-associated object.
Fixes https://github.com/llvm/llvm-project/issues/85776.
Cray pointee symbols can be host associated from a module or host
procedure while the related cray pointer is not explicitly associated.
This caused the "not yet implemented: lowering symbol to HLFIR" to fire
when lowering a reference to the cray pointee and fetching the cray
pointer.
This patch:
- Ensures cray pointers are always instantiated when instantiating a
cray pointee.
- Fix internal procedure lowering to deal with cray pointee host
association like it does for pointers (the lowering strategy for cray
pointee is to create a pointer that is updated with the cray pointer
value before being fetched).
This should fix the bug reported in
https://github.com/llvm/llvm-project/issues/85420.
Reductions such as min are intrinsic procedures. This distinguishes them
from user defined reductions. Previously, the intrinsic attribute was
not set when visiting reduction clauses causing them to be missed.
wsloop-reduction-min.f90 (the other min reduction test) worked because
it contained "min" used as an intrinsic inside of the body of the
reduction. This allowed ResolveNamesVisitor::HandleProcedureName to set
the correct attribute on that Symbol.
flang/module/__fortran_type_info.mod uses __fortran_builtins.mod, but it
is also implicitly used when compiling __fortran_builtins.f90 (or
anything else). If __fortran_type_info.mod finds an old
__fortran_builtins.mod file, compilation can fail while building the new
one.
Break the dependence by *not* generating runtime derived type
information for __fortran_builtins.f90.
…d type
When the same name is used for a derived type and generic interface in a
module, and no explicit PUBLIC or PRIVATE statement appears for the name
but the derived type definition does have an explicit accessibility,
that accessibility must also apply to the generic interface.
https://github.com/llvm/llvm-project/pull/78593 changed expression
semantics to always include the names of parent components that were
necessary to access an inherited component. This turns out to have
broken calls to inherited NOPASS procedure bindings. Update the patch to
omit explicit parent components when accessing bindings, while retaining
them for component accesses (including procedure components).
