[Bug fortran/82121] New: Unclassifiable statement during compilation when assigning to a Character array in a derived type contained in a ASSOCIATE statement

2017-09-06 Thread iain.miller at ecmwf dot int 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82121

Bug ID: 82121
   Summary: Unclassifiable statement during compilation when
assigning to a Character array in a derived type
contained in a ASSOCIATE statement
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iain.miller at ecmwf dot int
  Target Milestone: ---

Created attachment 42136
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42136&action=edit
Tarball of files showing issue and corresponding .s files

A bug has been introduced in gfortran 7+ when trying to use an ASSOCIATE
construct to associate a new variable name to a Character array held within a
derived type. The correct F03 code was previously compiled without issue in
gfortran 6.3.0 and earlier.

Addressing the array verbosely without using the associate variable compiles.
Addressing character arrays not in a derived type via an associate variable
compiles as well.

Output is:

sucddh.F90:17:0:

 CADHTLS(2)='SVGTLT'

Error: Unclassifiable statement at (1)

Files to reproduce (also attached for completeness):

#= yomcddh.F90 =#

MODULE YOMCDDH

IMPLICIT NONE

SAVE

TYPE :: TCDDH
CHARACTER(len=12),ALLOCATABLE :: CADHTLS(:)
END TYPE TCDDH

CHARACTER(len=12),ALLOCATABLE :: CADHTTS(:)

TYPE(TCDDH), POINTER :: YRCDDH => NULL()

END MODULE YOMCDDH

#= end of yomcddh.F90 =#

#= sucddh.F90 =#

SUBROUTINE SUCDDH()

USE YOMCDDH  , ONLY : YRCDDH,CADHTTS

IMPLICIT NONE

ALLOCATE (YRCDDH%CADHTLS(20))

ALLOCATE (CADHTTS(20))

ASSOCIATE(CADHTLS=>YRCDDH%CADHTLS, NORMCHAR=>CADHTTS)

! Direct reference to character array compiles correctly
YRCDDH%CADHTLS(1)='SVGTLF'

! Reference to associated variable name fails to compile
CADHTLS(2)='SVGTLT'

NORMCHAR(1)='SVLTTC'

END ASSOCIATE

END SUBROUTINE SUCDDH

#= end of sucddh.F90 =#

Build using following commands:

gfortran -c yomcddh.F90
gfortran -c -I. sucddh.F90

This has been confirmed on three separate x86_64 systems, two using SLES and
gfortran 7.2.0 and one using Fedora and gfortran 7.1.1.

Build details for SLES systems:
lxg38: vsimple $ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/group/usid/bin/compilers/lxg/gcc/7.2.0/libexec/gcc/x86_64-suse-linux/7.2.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../gcc-7.2.0/configure
--prefix=/home/group/usid/bin/compilers/lxg/gcc/7.2.0
--enable-languages=c,c++,objc,fortran,obj-c++ --enable-checking=release
--enable-ssp --disable-libssp --disable-plugin --disable-libgcj
--disable-libmudflap --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-cpu=generic
--build=x86_64-suse-linux --enable-linker-build-id --enable-linux-futex
--without-system-libunwind --disable-multilib --with-pkgversion='ECMWF build by
usid'
Thread model: posix
gcc version 7.2.0 (ECMWF build by usid) 

Build details for Fedora system:
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 7.1.1 20170622 (Red Hat 7.1.1-3) (GCC)

[Bug libgomp/69183] New: ICE when using OpenMP PRIVATE keyword in OMP DO loop not explicitly encapsulated in OMP PARALLEL region

2016-01-07 Thread iain.miller at ecmwf dot int 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69183

Bug ID: 69183
   Summary: ICE when using OpenMP PRIVATE keyword in OMP DO loop
not explicitly encapsulated in OMP PARALLEL region
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iain.miller at ecmwf dot int
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37250
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37250&action=edit
Source code producing ICE with compile line of "gfortran -c -fopenmp
allobs_mod.f90"

When compiling a Fortran90 subroutine that contains OpenMP Do pragmas but not
an explicit OpenMP Parallel region I get an ICE in build_outer_var_ref in
omp-low.c

!=== Start Test Case ===!

module allobs_mod

implicit none

contains

SUBROUTINE EQUIV_TL(NSETOT)

IMPLICIT NONE
INTEGER, INTENT(IN) :: NSETOT
INTEGER :: JSET, IDLEN, ILEN, IMXBDY, IHOFX
REAL,ALLOCATABLE :: ZHOFX(:)

!$OMP DO SCHEDULE(DYNAMIC,1) PRIVATE(JSET,ILEN,IDLEN,IMXBDY,ZHOFX)
DO JSET=1,NSETOT
  ILEN   = JSET
  IDLEN  =ILEN
  IF (MOD(ILEN,2) == 0) IDLEN=IDLEN+1
  IMXBDY = MAX(JSET,1)

  IHOFX=JSET+1
  ALLOCATE(ZHOFX(IHOFX))
  ZHOFX=JSET

  DEALLOCATE(ZHOFX)
ENDDO
!$OMP END DO


END SUBROUTINE EQUIV_TL

end module allobs_mod

!=== End Test Case ===!

Output from compilation:

> gfortran -v -save-temps -c -fopenmp allobs_mod.f90 

Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.3.0/configure --prefix=${HOME}/SuSE-gcc530/myinstall
--disable-multilib
Thread model: posix
gcc version 5.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-fopenmp' '-mtune=generic'
'-march=x86-64' '-pthread'
 ${HOME}/SuSE-gcc530/myinstall/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/f951
allobs_mod.f90 -quiet -dumpbase allobs_mod.f90 -mtune=generic -march=x86-64
-auxbase allobs_mod -version -fopenmp -fintrinsic-modules-path
${HOME}/SuSE-gcc530/myinstall/lib64/gcc/x86_64-unknown-linux-gnu/5.3.0/finclude
-o allobs_mod.s
GNU Fortran (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 5.1.2, MPFR version 3.1.2,
MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 5.1.2, MPFR version 3.1.2,
MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
allobs_mod.f90:18:0:

 !$OMP DO SCHEDULE(DYNAMIC,1) PRIVATE(JSET,ILEN,IDLEN,IMXBDY,ZHOFX)
 ^
internal compiler error: in build_outer_var_ref, at omp-low.c:1206
0x9a822c build_outer_var_ref
../../gcc-5.3.0/gcc/omp-low.c:1206
0x9b5d35 lower_rec_input_clauses
../../gcc-5.3.0/gcc/omp-low.c:3887
0x9b31df lower_omp_for
../../gcc-5.3.0/gcc/omp-low.c:10673
0x9b31df lower_omp_1
../../gcc-5.3.0/gcc/omp-low.c:11784
0x9b4ada lower_omp
../../gcc-5.3.0/gcc/omp-low.c:11916
0x9b232b lower_omp_1
../../gcc-5.3.0/gcc/omp-low.c:11769
0x9b4ada lower_omp
../../gcc-5.3.0/gcc/omp-low.c:11916
0x9b22ab lower_omp_1
../../gcc-5.3.0/gcc/omp-low.c:11760
0x9b4ada lower_omp
../../gcc-5.3.0/gcc/omp-low.c:11916
0x9b22ab lower_omp_1
../../gcc-5.3.0/gcc/omp-low.c:11760
0x9b4ada lower_omp
../../gcc-5.3.0/gcc/omp-low.c:11916
0x9b232b lower_omp_1
../../gcc-5.3.0/gcc/omp-low.c:11769
0x9b4ada lower_omp
../../gcc-5.3.0/gcc/omp-low.c:11916
0x9b5240 execute_lower_omp
../../gcc-5.3.0/gcc/omp-low.c:11954
0x9b5240 execute
../../gcc-5.3.0/gcc/omp-low.c:11991
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

> End

If the PRIVATE variable declaration is removed or the OpenMP region is
explicitly set to be a new PARALLEL region then the code compiles successfully,
but neither of these workarounds should be required nor is the behaviours they
cause desired.

Issue also seen in gfortran 5.2.0, 4.9.1 and 4.8.2 configured on different
systems.

[Bug libgomp/69183] ICE when using OpenMP PRIVATE keyword in OMP DO loop not explicitly encapsulated in OMP PARALLEL region

2016-01-08 Thread iain.miller at ecmwf dot int 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69183

--- Comment #2 from Iain Miller  ---
On further testing and investigation the ICE only appears when attempting to
allocate and use ZHOFX.

Removing all references to ZHOFX in the test case allows it the subroutine to
compile.