llvm-project/flang/test/Semantics/dosemantics05.f90

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

100 lines
2.9 KiB
Fortran
Raw Normal View History

[flang] A rework of the cmake build components for in and out of tree builds. In general all the basic functionality seems to work and removes some redundancy and more complicated features in favor of borrowing infrastructure from LLVM build configurations. Here's a quick summary of details and remaining issues: * Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and MacOS/darwin. Architectures include x86_64 and Arm. Without access to Window nothing has been tested there yet. * As we change file and directory naming schemes (i.e., capitalization) some odd things can occur on MacOS systems with case preserving but not case senstive file system configurations. Can be painful and certainly something to watch out for as any any such changes continue. * Testing infrastructure still needs to be tuned up and worked on. Note that there do appear to be cases of some tests hanging (on MacOS in particular). They appear unrelated to the build process. * Shared library configurations need testing (and probably fixing). * Tested both standalone and 'in-mono repo' builds. Changes for supporting the mono repo builds will require LLVM-level changes that are straightforward when the time comes. * The configuration contains a work-around for LLVM's C++ standard mode passing down into Flang/F18 builds (i.e., LLVM CMake configuration would force a -std=c++11 flag to show up in command line arguments. The current configuration removes that automatically and is more strict in following new CMake guidelines for enforcing C++17 mode across all the CMake files. * Cleaned up a lot of repetition in the command line arguments. It is likely that more work is still needed to both allow for customization and working around CMake defailts (or those inherited from LLVM's configuration files). On some platforms agressive optimization flags (e.g. -O3) can actually break builds due to the inlining of templates in .cpp source files that then no longer are available for use cases outside those source files (shows up as link errors). Sticking at -O2 appears to fix this. Currently this CMake configuration forces this in release mode but at the cost of stomping on any CMake, or user customized, settings for the release flags. * Made the lit tests non-source directory dependent where appropriate. This is done by configuring certain test shell files to refer to the correct paths whether an in or out of tree build is being performed. These configured files are output in the build directory. A %B substitution is introduced in lit to refer to the build directory, mirroring the %S substitution for the source directory, so that the tests can refer to the configured shell scripts. Co-authored-by: David Truby <david.truby@arm.com> Original-commit: flang-compiler/f18@d1c7184159b2d3c542a8f36c58a0c817e7506845 Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-02-26 07:22:14 +08:00
! RUN: %B/test/Semantics/test_errors.sh %s %flang %t
! Test DO loop semantics for constraint C1130 --
! The constraint states that "If the locality-spec DEFAULT ( NONE ) appears in a
! DO CONCURRENT statement; a variable that is a local or construct entity of a
! scope containing the DO CONCURRENT construct; and that appears in the block of
! the construct; shall have its locality explicitly specified by that
! statement."
module m
real :: mvar
end module m
subroutine s1()
use m
integer :: i, ivar, jvar, kvar
real :: x
type point
real :: x, y
end type point
type, extends(point) :: color_point
integer :: color
end type color_point
type(point), target :: c
class(point), pointer :: p_or_c
p_or_c => c
jvar = 5
! References in this DO CONCURRENT are OK since there's no DEFAULT(NONE)
! locality-spec
associate (avar => ivar)
do concurrent (i = 1:2) shared(jvar)
ivar = 3
ivar = ivar + i
block
real :: bvar
avar = 4
x = 3.5
bvar = 3.5 + i
end block
jvar = 5
mvar = 3.5
end do
end associate
associate (avar => ivar)
!ERROR: DO CONCURRENT step expression may not be zero
do concurrent (i = 1:2:0) default(none) shared(jvar) local(kvar)
[flang] Changes to check for constraint C1140 This constraint prohibits deallocation of polymorphic entities in a DO CONCURRENT. Section 9.7.3.2 specifies the situations that might cause deallocation of a polymorphic entity. The ones that are applicable to a DO CONCURRENT are exiting from a block that declares such variables, intrinsic assignment, and an actual DEALLOCATE statement. This section also specifies (paragraph 8) that deallocation of a derived type causes deallocation of all of its allocatable subobjects. Section 10.2.1.3 specifies what happens during intrinsic assignment. Paragraph 3 states If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape, any corresponding length type parameter values of the variable and expr differ, or the variable is polymorphic and the dynamic type or any corresponding kind type parameter values of the variable and expr differ." Thus, an allocatable polymorphic variable on the left hand side of an assignment statement gets deallocated. Paragraph 13 states that "For a noncoarray allocatable component the following sequence of operations is applied. (1) If the component of the variable is allocated, it is deallocated." Thus, a variable on the left-hand side of an assignment statement might have noncorray allocatable components. Such components will be deallocated. Deallocation can be caused by exiting from a block where the entity is declared, from an assignment, and from direct deallocation. Original-commit: flang-compiler/f18@7d1932d344308d8266503268a7534532cebe6087 Reviewed-on: https://github.com/flang-compiler/f18/pull/814
2019-11-06 02:18:33 +08:00
!ERROR: Variable 'ivar' from an enclosing scope referenced in DO CONCURRENT with DEFAULT(NONE) must appear in a locality-spec
ivar = &
[flang] Changes to check for constraint C1140 This constraint prohibits deallocation of polymorphic entities in a DO CONCURRENT. Section 9.7.3.2 specifies the situations that might cause deallocation of a polymorphic entity. The ones that are applicable to a DO CONCURRENT are exiting from a block that declares such variables, intrinsic assignment, and an actual DEALLOCATE statement. This section also specifies (paragraph 8) that deallocation of a derived type causes deallocation of all of its allocatable subobjects. Section 10.2.1.3 specifies what happens during intrinsic assignment. Paragraph 3 states If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape, any corresponding length type parameter values of the variable and expr differ, or the variable is polymorphic and the dynamic type or any corresponding kind type parameter values of the variable and expr differ." Thus, an allocatable polymorphic variable on the left hand side of an assignment statement gets deallocated. Paragraph 13 states that "For a noncoarray allocatable component the following sequence of operations is applied. (1) If the component of the variable is allocated, it is deallocated." Thus, a variable on the left-hand side of an assignment statement might have noncorray allocatable components. Such components will be deallocated. Deallocation can be caused by exiting from a block where the entity is declared, from an assignment, and from direct deallocation. Original-commit: flang-compiler/f18@7d1932d344308d8266503268a7534532cebe6087 Reviewed-on: https://github.com/flang-compiler/f18/pull/814
2019-11-06 02:18:33 +08:00
!ERROR: Variable 'ivar' from an enclosing scope referenced in DO CONCURRENT with DEFAULT(NONE) must appear in a locality-spec
ivar + i
block
real :: bvar
[flang] Changes to check for constraint C1140 This constraint prohibits deallocation of polymorphic entities in a DO CONCURRENT. Section 9.7.3.2 specifies the situations that might cause deallocation of a polymorphic entity. The ones that are applicable to a DO CONCURRENT are exiting from a block that declares such variables, intrinsic assignment, and an actual DEALLOCATE statement. This section also specifies (paragraph 8) that deallocation of a derived type causes deallocation of all of its allocatable subobjects. Section 10.2.1.3 specifies what happens during intrinsic assignment. Paragraph 3 states If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape, any corresponding length type parameter values of the variable and expr differ, or the variable is polymorphic and the dynamic type or any corresponding kind type parameter values of the variable and expr differ." Thus, an allocatable polymorphic variable on the left hand side of an assignment statement gets deallocated. Paragraph 13 states that "For a noncoarray allocatable component the following sequence of operations is applied. (1) If the component of the variable is allocated, it is deallocated." Thus, a variable on the left-hand side of an assignment statement might have noncorray allocatable components. Such components will be deallocated. Deallocation can be caused by exiting from a block where the entity is declared, from an assignment, and from direct deallocation. Original-commit: flang-compiler/f18@7d1932d344308d8266503268a7534532cebe6087 Reviewed-on: https://github.com/flang-compiler/f18/pull/814
2019-11-06 02:18:33 +08:00
!ERROR: Variable 'avar' from an enclosing scope referenced in DO CONCURRENT with DEFAULT(NONE) must appear in a locality-spec
avar = 4
[flang] Changes to check for constraint C1140 This constraint prohibits deallocation of polymorphic entities in a DO CONCURRENT. Section 9.7.3.2 specifies the situations that might cause deallocation of a polymorphic entity. The ones that are applicable to a DO CONCURRENT are exiting from a block that declares such variables, intrinsic assignment, and an actual DEALLOCATE statement. This section also specifies (paragraph 8) that deallocation of a derived type causes deallocation of all of its allocatable subobjects. Section 10.2.1.3 specifies what happens during intrinsic assignment. Paragraph 3 states If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape, any corresponding length type parameter values of the variable and expr differ, or the variable is polymorphic and the dynamic type or any corresponding kind type parameter values of the variable and expr differ." Thus, an allocatable polymorphic variable on the left hand side of an assignment statement gets deallocated. Paragraph 13 states that "For a noncoarray allocatable component the following sequence of operations is applied. (1) If the component of the variable is allocated, it is deallocated." Thus, a variable on the left-hand side of an assignment statement might have noncorray allocatable components. Such components will be deallocated. Deallocation can be caused by exiting from a block where the entity is declared, from an assignment, and from direct deallocation. Original-commit: flang-compiler/f18@7d1932d344308d8266503268a7534532cebe6087 Reviewed-on: https://github.com/flang-compiler/f18/pull/814
2019-11-06 02:18:33 +08:00
!ERROR: Variable 'x' from an enclosing scope referenced in DO CONCURRENT with DEFAULT(NONE) must appear in a locality-spec
x = 3.5
bvar = 3.5 + i ! OK, bvar's scope is within the DO CONCURRENT
end block
jvar = 5 ! OK, jvar appears in a locality spec
kvar = 5 ! OK, kvar appears in a locality spec
[flang] Changes to check for constraint C1140 This constraint prohibits deallocation of polymorphic entities in a DO CONCURRENT. Section 9.7.3.2 specifies the situations that might cause deallocation of a polymorphic entity. The ones that are applicable to a DO CONCURRENT are exiting from a block that declares such variables, intrinsic assignment, and an actual DEALLOCATE statement. This section also specifies (paragraph 8) that deallocation of a derived type causes deallocation of all of its allocatable subobjects. Section 10.2.1.3 specifies what happens during intrinsic assignment. Paragraph 3 states If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape, any corresponding length type parameter values of the variable and expr differ, or the variable is polymorphic and the dynamic type or any corresponding kind type parameter values of the variable and expr differ." Thus, an allocatable polymorphic variable on the left hand side of an assignment statement gets deallocated. Paragraph 13 states that "For a noncoarray allocatable component the following sequence of operations is applied. (1) If the component of the variable is allocated, it is deallocated." Thus, a variable on the left-hand side of an assignment statement might have noncorray allocatable components. Such components will be deallocated. Deallocation can be caused by exiting from a block where the entity is declared, from an assignment, and from direct deallocation. Original-commit: flang-compiler/f18@7d1932d344308d8266503268a7534532cebe6087 Reviewed-on: https://github.com/flang-compiler/f18/pull/814
2019-11-06 02:18:33 +08:00
!ERROR: Variable 'mvar' from an enclosing scope referenced in DO CONCURRENT with DEFAULT(NONE) must appear in a locality-spec
mvar = 3.5
end do
end associate
select type ( a => p_or_c )
type is ( point )
do concurrent (i=1:5) local(a)
! C1130 This is OK because there's no DEFAULT(NONE) locality spec
a%x = 3.5
end do
end select
select type ( a => p_or_c )
type is ( point )
do concurrent (i=1:5) default (none)
[flang] Changes to check for constraint C1140 This constraint prohibits deallocation of polymorphic entities in a DO CONCURRENT. Section 9.7.3.2 specifies the situations that might cause deallocation of a polymorphic entity. The ones that are applicable to a DO CONCURRENT are exiting from a block that declares such variables, intrinsic assignment, and an actual DEALLOCATE statement. This section also specifies (paragraph 8) that deallocation of a derived type causes deallocation of all of its allocatable subobjects. Section 10.2.1.3 specifies what happens during intrinsic assignment. Paragraph 3 states If the variable is an allocated allocatable variable, it is deallocated if expr is an array of different shape, any corresponding length type parameter values of the variable and expr differ, or the variable is polymorphic and the dynamic type or any corresponding kind type parameter values of the variable and expr differ." Thus, an allocatable polymorphic variable on the left hand side of an assignment statement gets deallocated. Paragraph 13 states that "For a noncoarray allocatable component the following sequence of operations is applied. (1) If the component of the variable is allocated, it is deallocated." Thus, a variable on the left-hand side of an assignment statement might have noncorray allocatable components. Such components will be deallocated. Deallocation can be caused by exiting from a block where the entity is declared, from an assignment, and from direct deallocation. Original-commit: flang-compiler/f18@7d1932d344308d8266503268a7534532cebe6087 Reviewed-on: https://github.com/flang-compiler/f18/pull/814
2019-11-06 02:18:33 +08:00
!ERROR: Variable 'a' from an enclosing scope referenced in DO CONCURRENT with DEFAULT(NONE) must appear in a locality-spec
a%x = 3.5
end do
end select
select type ( a => p_or_c )
type is ( point )
do concurrent (i=1:5) default (none) local(a)
! C1130 This is OK because 'a' is in a locality-spec
a%x = 3.5
end do
end select
x = 5.0 ! OK, we're not in a DO CONCURRENT
end subroutine s1