llvm-project/flang/test/Semantics/allocate08.f90
Patrick McCormick 6c16aa4f67 [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@d1c7184159
Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
2020-03-26 18:17:04 +00:00

133 lines
4.2 KiB
Fortran

! RUN: %B/test/Semantics/test_errors.sh %s %flang %t
! Check for semantic errors in ALLOCATE statements
subroutine C945_a(srca, srcb, srcc, src_complex, src_logical, &
srca2, srcb2, srcc2, src_complex2, srcx, srcx2)
! If type-spec appears, it shall specify a type with which each
! allocate-object is type compatible.
!second part C945, specific to SOURCE, is not checked here.
type A
integer i
end type
type, extends(A) :: B
real, allocatable :: x(:)
end type
type, extends(B) :: C
character(5) s
end type
type Unrelated
class(A), allocatable :: polymorph
type(A), allocatable :: notpolymorph
end type
real srcx, srcx2(6)
class(A) srca, srca2(5)
type(B) srcb, srcb2(6)
class(C) srcc, srcc2(7)
complex src_complex, src_complex2(8)
complex src_logical(5)
real, allocatable :: x1, x2(:)
class(A), allocatable :: aa1, aa2(:)
class(B), pointer :: bp1, bp2(:)
class(C), allocatable :: ca1, ca2(:)
class(*), pointer :: up1, up2(:)
type(A), allocatable :: npaa1, npaa2(:)
type(B), pointer :: npbp1, npbp2(:)
type(C), allocatable :: npca1, npca2(:)
class(Unrelated), allocatable :: unrelat
allocate(x1, source=srcx)
allocate(x2, mold=srcx2)
allocate(bp2(3)%x, source=srcx2)
!OK, type-compatible with A
allocate(aa1, up1, unrelat%polymorph, unrelat%notpolymorph, &
npaa1, source=srca)
allocate(aa2, up2, npaa2, source=srca2)
!OK, type compatible with B
allocate(aa1, up1, unrelat%polymorph, bp1, npbp1, mold=srcb)
allocate(aa2, up2, bp2, npbp2, mold=srcb2)
!OK, type compatible with C
allocate(aa1, up1, unrelat%polymorph, bp1, ca1, npca1, mold=srcc)
allocate(aa2, up2, bp2, ca2, npca2, source=srcc2)
!ERROR: Allocatable object in ALLOCATE must be type compatible with source expression from MOLD or SOURCE
allocate(x1, mold=src_complex)
!ERROR: Allocatable object in ALLOCATE must be type compatible with source expression from MOLD or SOURCE
allocate(x2(2), source=src_complex2)
!ERROR: Allocatable object in ALLOCATE must be type compatible with source expression from MOLD or SOURCE
allocate(bp2(3)%x, mold=src_logical)
!ERROR: Allocatable object in ALLOCATE must be type compatible with source expression from MOLD or SOURCE
allocate(unrelat, mold=srca)
!ERROR: Allocatable object in ALLOCATE must be type compatible with source expression from MOLD or SOURCE
allocate(unrelat%notpolymorph, source=srcb)
!ERROR: Allocatable object in ALLOCATE must be type compatible with source expression from MOLD or SOURCE
allocate(npaa1, mold=srcb)
!ERROR: Allocatable object in ALLOCATE must be type compatible with source expression from MOLD or SOURCE
allocate(npaa2, source=srcb2)
!ERROR: Allocatable object in ALLOCATE must be type compatible with source expression from MOLD or SOURCE
allocate(npca1, bp1, npbp1, mold=srcc)
end subroutine
module m
type :: t
real x(100)
contains
procedure :: f
end type
contains
function f(this) result (x)
class(t) :: this
class(t), allocatable :: x
end function
subroutine bar
type(t) :: o
type(t), allocatable :: p
real, allocatable :: rp
allocate(p, source=o%f())
!ERROR: Allocatable object in ALLOCATE must be type compatible with source expression from MOLD or SOURCE
allocate(rp, source=o%f())
end subroutine
end module
! Related to C945, check typeless expression are caught
subroutine sub
end subroutine
function func() result(x)
real :: x
end function
program test_typeless
class(*), allocatable :: x
interface
subroutine sub
end subroutine
real function func()
end function
end interface
procedure (sub), pointer :: subp => sub
procedure (func), pointer :: funcp => func
! OK
allocate(x, mold=func())
allocate(x, source=funcp())
!ERROR: Typeless item not allowed as SOURCE or MOLD in ALLOCATE
allocate(x, mold=x'1')
!ERROR: Typeless item not allowed as SOURCE or MOLD in ALLOCATE
allocate(x, mold=sub)
!ERROR: Typeless item not allowed as SOURCE or MOLD in ALLOCATE
allocate(x, source=subp)
!ERROR: Typeless item not allowed as SOURCE or MOLD in ALLOCATE
allocate(x, mold=func)
!ERROR: Typeless item not allowed as SOURCE or MOLD in ALLOCATE
allocate(x, source=funcp)
end program