…n actual argument is contiguous
When an element of a contiguous pointer array or assumed-shape array is
associated as an actual argument with an assumed-size dummy array, don't
flag the usage as an error.
…arrays
When comparing dummy array extents, cope with references to symbols
better (including references to other dummy arguments), and emit
warnings in dubious cases that are not equivalent but not provably
incompatible.
Move the code to check the arguments of references to the intrinsic
function REDUCE() into Semantics/check-calls.cpp, and add checks for
several requirements from the standard that weren't yet caught.
Before emitting a warning message, code should check that the usage in
question should be diagnosed by calling ShouldWarn(). A fair number of
sites in the code do not, and can emit portability warnings
unconditionally, which can confuse a user that hasn't asked for them
(-pedantic) and isn't terribly concerned about portability *to* other
compilers.
Add calls to ShouldWarn() or IsEnabled() around messages that need them,
and add -pedantic to tests that now require it to test their portability
messages, and add more expected message lines to those tests when
-pedantic causes other diagnostics to fire.
During function-like macro expansion in a standard C/C++ preprocessor,
the macro being expanded is disabled from recursive macro expansion. The
implementation in this compiler's preprocessor, however, was too broad;
the macro expansion needs to be disabled for the "rescanning" phase
only, not for actual argument expansion.
(Also corrects an obsolete comment elsewhere that was noticed during
reduction of an original test case.)
A NULL() pointer without MOLD= cannot be allowed to be associated with
an assumed-rank dummy argument, as its rank is not well-defined and
neither the RANK() intrinsic function or the SELECT RANK construct will
work in the callee.
…forwarded to CONTIGUOUS dummy
No object with the ASYNCHRONOUS or VOLATILE attribute can go through the
copy-in/copy-out protocol necessary for argument association with a
contiguous dummy array argument. The check for this constraint missed
the case of an assumed-rank array without an explicit CONTIGUOUS
attribute being forwarded on to a CONTIGUOUS dummy argument.
Semantics is emitting an error when an actual argument to a procedure
that has an implicit interface has a polymorphic type. This is too
general; while TYPE(*) and CLASS(*) unlimited polymorphic items require
the presence of an explicit procedure interface, CLASS(T) data can be
passed over an implicit interface to a procedure expecting a
corresponding dummy argument with TYPE(T), so long as T is not
parameterized.
(Only XLF handles this usage correctly among other Fortran compilers.)
(Making this work in the case of an actual CLASS(T) array may well
require additional changes in lowering to copy data to/from a temporary
buffer to ensure contiguity when the actual type of the array is an
extension of T.)
…mmy argument
Several compilers accept a null pointer (with or without a MOLD=) as an
actual argument for association with an INTENT(IN) allocatable dummy
argument. At runtime, the allocatable dummy argument appears to be in
the unallocated state. This seems useful, unambiguous, unlikely to
invalidate conforming code, and works with Intel, NAG, & XLF, so it
should be supported with an optional portability warning in this
compiler as well.
A NULL() pointer is an acceptable actual argument for association with
an (absent) optional allocatable dummy argument. Semantics was
unconditionally emitting an error that the actual argument is not
allocatable.
The POINTER= and TARGET= arguments to the intrinsic function
ASSOCIATED() can be the results of references to functions that return
object pointers or procedure pointers. NULL() was working well but not
program-defined pointer-valued functions. Correct the validation of
ASSOCIATED() and extend the infrastructure used to detect and
characterize procedures and pointers.
Unlike other executable constructs with associating selectors, the
selector of a SELECT RANK construct can have the ALLOCATABLE or POINTER
attribute, and will work as an allocatable or object pointer within
each rank case, so long as there is no RANK(*) case.
Getting this right exposed a correctness risk with the popular
predicate IsAllocatableOrPointer() -- it will be true for procedure
pointers as well as object pointers, and in many contexts, a procedure
pointer should not be acceptable. So this patch adds the new predicate
IsAllocatableOrObjectPointer(), and updates some call sites of the original
function to use the new one.
Differential Revision: https://reviews.llvm.org/D159043
This patch enables logical expressions to be used as arguments when the
default logical kind is changed (e.g. using -fdefault-integer-8) by
converting the type of the logical expression argument to the type of
the dummy argument in the function.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D157600
The TARGET= argument to the intrinsic function ASSOCIATED() must be
a valid target for the POINTER= argument, but we are missing some
cases, such as parenthesized expressions. Add more checking, and
restructure the logic a bit to make the case analysis structure
more clear.
Fixes llvm-test-suite/Fortran/gfortran/regression/associated_target_1.f90.
Differential Revision: https://reviews.llvm.org/D157341
Check for cases of storage sequence association in which an element or
substring is an actual argument associated with a dummy argument array
that can be detected as being larger than the remaining elements or characters
in the actual argument's storage sequence.
Differential Revision: https://reviews.llvm.org/D156757
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
A dummy argument with an assumed (*) character length or derived type parameter
value specification needs to be associated with an actual argument that can
supply a value for it, so make sure that a NULL without a MOLD= is not being
passed.
Differential Revision: https://reviews.llvm.org/D155971
When the left-hand side of an assignment, or any other context demanding
definability, comprises a designator with a vector subscript that is
known at compilation time to have one or more duplicated elements,
emit an error message.
Differential Revision: https://reviews.llvm.org/D155492
Emit warnings when CHARACTER lengths or array sizes of actual
and dummy arguments mismatch in risky ways.
Differential Revision: https://reviews.llvm.org/D154370
This patch lowers allocatables and pointers named in "private" OpenMP clause.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D148570
The soon-to-be-published next revision of the ISO Fortran language standard
contains a couple of breaking changes to previous specifications that may cause
existing programs to silently change their behavior.
For the change that introduces automatic reallocation of deferred length
allocatable character scalar variables when they appear as the targets
of internal WRITE statements, as IOMSG=/ERRMSG= variables, as outputs
of INQUIRE specifiers, or as INTENT(OUT) arguments to intrinsic
procedures, this patch adds an optional portability warning.
Differential Revision: https://reviews.llvm.org/D154242
Per 15.5.2.5 p2, when both a dummy data object and its associated
actual argument are ALLOCATABLE or POINTER, there are rules requiring
that both be unlimited polymorphic if either is, and that both be
polymorphic if either is. The justifications for the first restriction
is that the called procedure might change the type of an unlimited
polymorphic dummy argument, but as this cannot occur for a dummy
argument with INTENT(IN), we can relax the check to an optional
portability warning. The justification for the second restriction
is that some implementations would have to create a type descriptor
to associate a monomorphic allocatable/pointer actual argument with
a polymorphic dummy argument, and that doesn't apply to f18 since we
use descriptors for them anyways.
Relaxing these needless checks allows more library procedures to
use "class(*), dimension(..), pointer, intent(in)" dummy arguments
in explicit interfaces.
Differential Revision: https://reviews.llvm.org/D151941
This patch is to remove the conversion of the actual argument that
is associated with the dummy argument specified with the IGNORE_TKR
directive.
Commit on behalf of @danielcchen
Differential Revision: https://reviews.llvm.org/D151401
I just broke the test llvm-test-suite/Fortran/gfortran/torture/execute/st_function_1.f90
with a recent patch. The bug was obvious, as is the fix, which works, so
I'm just pushing it directly to make the build bots happy.
Establish a set of optional usage warnings, and enable some
only in "-pedantic" mode that, in our subjective experience
with application codes, seem to issue frequently without
indicating usage that really needs to be corrected. By default,
with this patch the compiler should appear to be somewhat less
persnickety but not less informative.
Differential Revision: https://reviews.llvm.org/D150710
Implement semantics for the IGNORE_TKR directive as it is interpreted
by the PGI / NVFORTRAN compiler.
Differential Revision: https://reviews.llvm.org/D148643
/data/llvm-project/flang/lib/Semantics/check-call.cpp:1234:29: error: comparison of integers of different signs: 'int' and 'size_type' (aka 'unsigned long') [-Werror,-Wsign-compare]
CHECK(index >= 0 && index < actuals.size());
~~~~~ ^ ~~~~~~~~~~~~~~
/data/llvm-project/flang/include/flang/Common/idioms.h:89:20: note: expanded from macro 'CHECK'
^
1 error generated.
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
Consolidate aspects of pointer assignment & structure constructor pointer component
checking from Semantics/assignment.cpp and /expression.cpp into /pointer-assignment.cpp,
and add a warning about data targets that are not definable objects
but not hard errors. Specifically, a structure component pointer component data
target is not allowed to be a USE-associated object in a pure context by a numbered
constraint, but the right-hand side data target of a pointer assignment statement
has no such constraint, and that's the new warning.
Differential Revision: https://reviews.llvm.org/D146581
A positional (non-keyword) actual argument or alternate return label is not
allowed to follow an actual argument with a keyword.
Differential Revision: https://reviews.llvm.org/D146575
When a parameterized derived type has FINAL subroutines, only
those FINAL subroutines whose dummy argument's type matches the
type parameter values of a particular instantiation are relevant
to that instantiation.
Differential Revision: https://reviews.llvm.org/D145741
The test for compatible function results needs to be nearly strict
equality of their types, not the usual actual/dummy type compatibility
test used in other situations. The exceptional case is that assumed
length CHARACTER function results are compatible with explicit length
results of the same kind. In particular, a function returning a
polymorphic pointer is not compatible with a function returning a
monomorphic pointer even of the same declared type.
Differential Revision: https://reviews.llvm.org/D145094
The actual argument associated with a dummy argument with the TARGET attribute is
not required to be itself a target or pointer, or even to be a variable, but in
those cases, any pointer that is associated with the dummy argument during the
execution of the procedure is either going to be invalid afterwards because it
points to temporary storage that has since been deallocated or an optimization
time bomb because it aliases an object that isn't a target. Add warnings for
these cases.
Differential Revision: https://reviews.llvm.org/D145089
There's several sets of circumstances in which a scalar actual argument can be
associated with a dummy argument array in Fortran, but they apply only to "ordinary"
dummy arguments, not those that are allocatables or pointers.
Differential Revision: https://reviews.llvm.org/D143836
When the source or mold of a reference to the intrinsic function TRANSFER()
has a derived type with a direct component that contains a descriptor,
such as an allocatable or a pointer, emit a warning. User programs
should never access descriptors directly.
Differential Revision: https://reviews.llvm.org/D143823
Fortran 2018 defines some flavors of dummy arguments to require exact
matching of character lengths between dummy and actual arguments;
these situations tend to be those in which the interface must be
explicit and a descriptor is involved: assumed shape, assumed rank,
allocatable, and pointer.
Fortran allows an actual argument in other cases to have a longer
length than the dummy argument; as a common extension, we support a
shorter actual argument as well by means of blank padding, but should
emit a warning.
Differential Revision: https://reviews.llvm.org/D143821
When character lengths are known at compilation time, report an error
when a data target with a known length does not match the explicit length
of a pointer that is being associated with it; see 10.2.2.3 paragraph 5.
Differential Revision: https://reviews.llvm.org/D142755
The standard's specification for the ASSOCIATED() intrinsic function
describes its optional second argument (TARGET=) as being required
to be a valid target for a pointer assignment statement in which the
first argument (POINTER=) was the left-hand side. Some Fortran compilers
apparently interpret this text as a requirement that the POINTER= argument
actually be a valid left-hand side to a pointer assignment statement,
and emit an error if it is not so. This particularly affects the
use of an explicit NULL pointer as the first argument.
Such usage is well-defined, benign, useful, and supported by at least
two other compilers, so we should continue to accept it. This patch
adds a portability warning and some documentation.
In order to implement the portability warning in the best way, the
special checks on calls to the ASSOCIATED() intrinsic function have
been moved from intrinsic processing to Semantics/check-calls.cpp,
whence they have access to semantics' toolchest. Special checks for
other intrinsic functions might also migrate in the future in order
to keep them all in one place.
Differential Revision: https://reviews.llvm.org/D142768
When an ELEMENTAL subroutine is erroneously declared with alternate return
arguments, don't crash when checking the ranks of the actual arguments.
Differential Revision: https://reviews.llvm.org/D140143
This patch implements @klausler's suggestion in `llvm-project` [issue #58973](https://github.com/llvm/llvm-project/issues/58973); encountering the `VOLATILE` attribute should produce a __warning__, not a __fatal error__.
When tested on the following Fortran program `snem0601_012_.f90`:
```fortran
module mod
contains
subroutine sub(m6,error)
integer,intent(inout) :: error
integer,volatile :: m6
if (any ((/m6/).ne.(/6/))) &
& then
error = 1
end if
end subroutine
end module
program fe1nvol12
use mod
integer :: error = 0
call sub(6,error)
if (error .ne. 0) then
print *,'NG: snem0601_012'
end if
print *,'pass: snem0601_012'
end program fe1nvol12
```
the following output is produced:
```bash
$ flang-new -fc1 snem0601_012_.f90
/noback/93u/Sandbox/issue_58973_volatile_dummy_arg/snem0601_012_.f90:21:12: warning: actual argument associated with VOLATILE dummy argument 'm6=' is not a variable
call sub(6,error)
^
```
Reviewed By: clementval, klausler
Differential Revision: https://reviews.llvm.org/D139134
Enforce detectable compilation-time violations of restrictions on the
arguments to the TRANSFER() intrinsic function (16.9.163) with
error messages, and mark other potential problems with warnings.
Differential Revision: https://reviews.llvm.org/D139157
19.6.8 forbids using an INTENT(IN) pointer dummy argument in a pointer association
context, and associated such a pointer with a dummy argument of INTENT(IN OUT) or
INTENT(OUT) is a circumstance that needs to be caught as an error.
Differential Revision: https://reviews.llvm.org/D139138
