Created attachment 18189 [details]
module definition

This is the module definition file for the bug report.

Created attachment 18190 [details]
module use file for bug report

Compile this module use with the other attachment module definition

Confirm (kind of) with GCC 4.3.2 on i686-linux. With -DBIGMOD one gets:

/tmp/ccmoM1rS.o: In function `tf_ad_splitting_driver_plane_':
t.F90:(.text+0xad): undefined reference to `span.1'
t.F90:(.text+0x15c): undefined reference to `span.0'
t.F90:(.text+0x20b): undefined reference to `span.2'
t.F90:(.text+0x2ba): undefined reference to `span.3'
t.F90:(.text+0x369): undefined reference to `span.4'

(In reply to comment #0)


In the original SPECmpi source code, 
I was able to make the compile-time bug go away with this source workaround:

change e.g.

         Ro => Hydro_vars( first_cell:last_cell, j, k)%cell_var( ro_var)

to

         tRo => Hydro_vars( first_cell:last_cell, j, k)%cell_var( ro_var)
         call copy_pointer(Ro, tRo)

with earlier declarations for tRo and copy_pointer

< subroutine copy_pointer(p, q)
<    
<       use TF_NUMBER_KIND
< 
<       implicit none
<       real(r8), pointer, dimension( :) :: p, q
< 
<       p => q
<       return
< 
< end subroutine

<    use TF_NUMBER_KIND
< 
<    implicit none
< 
<    real(r8), pointer, dimension( :),save ::        tRo


However execution was unsuccessful, though not necessarily due to a problem
in this part of the code.     Compilation and execution of this modified
code were successful on
the same linux system using Sun Studio 12u1, but not using gfortran 4.4.0
on a sparc solaris system...   so the root cause of failure is unknown.

Reduced test case. The crucial part is the span ("1:2") in the assignment - and that "Ro" is use-associated.


Dump:

tf_ad_splitting_driver_plane ()
{  [...]
  extern integer(kind=8) span.0 = 0;
   [...]
    span.0 = 4;


module testmod
  implicit none
  type VARIABLES_MAILLE
      real :: cell_var
  end type VARIABLES_MAILLE
  type (VARIABLES_MAILLE), pointer, dimension( :) :: Hydro_vars
  real, pointer, dimension(:) :: Ro
end module testmod

program TF_AD_SPLITTING_DRIVER_PLANE
  use testmod
  implicit none
  Ro => Hydro_vars(1:2)%cell_var
end program

Paul, do you immediately see what goes wrong here? If not, I can also dig myself.

My current understanding is that "span" is only created (in gfc_get_symbol_decl)
  if (sym->attr.subref_array_pointer)
is true - and is then assumed to live at the same place as the symbol (array descriptor) itself. But this fails for use association (and maybe also for host association).

Solution 1: Always create that variable if they symbols is a pointer to an array.
Solution 2: Defer it until we have the proper array descriptor, which handles this.

Created attachment 18732 [details]
Potential patch to fix pr40737

Here is a patch from Adhemerval Zanella from our IBM LTC Performance team, that "fixes" the problem for me and bootstraps (powerpc64-linux) and regtests with no regressions.  Can someone else give this a try on their system?

(In reply to comment #8)
> Created an attachment (id=18732) [edit]
> Potential patch to fix pr40737
> 
> Here is a patch from Adhemerval Zanella from our IBM LTC Performance team, that
> "fixes" the problem for me and bootstraps (powerpc64-linux) and regtests with
> no regressions.  Can someone else give this a try on their system?
> 

With the patch installed and running either of the following commands:

gfortran -S testmod.F90 testuse.F90 -UBIGMOD -m64
gfortran -S testmod.F90 testuse.F90 -DBIGMOD -m64

shows no instances of 'scan' in the resulting .s files of x86_64-*-freebsd.
Don't know if this is the result that you are looking for.

(In reply to comment #8)
> Created an attachment (id=18732) [edit]
> Potential patch to fix pr40737
> 
> Here is a patch from Adhemerval Zanella from our IBM LTC Performance team,
> that "fixes" the problem for me and bootstraps (powerpc64-linux) and
> regtests with no regressions.  Can someone else give this a try on their
> system?

I think it only paper bags the problem. The problem is that the span information needs to be available in all places where the pointer is available - also if the module a separate file from the one where the assignment is done which can be again separate from the place where the pointer is used.

Thus, as written, I only see two solutions:

Solution 1: Always create that variable if they symbols is a pointer to an
array.
Solution 2: Defer it until we have the proper array descriptor, which handles
this.

I think in 4.6 we will finally go for solution 2.

Nevertheless, one should check whether the patch improves the situation for 4.5 and should thus be applied as interim solution.

(In reply to comment #10)

> > Here is a patch from Adhemerval Zanella from our IBM LTC Performance team,
> > that "fixes" the problem for me and bootstraps (powerpc64-linux) and
> > regtests with no regressions.  Can someone else give this a try on their
> > system?

I can compile now the original source SPECmpi 129.tera_tf
but I still don't execute correctly.    The variables Ro and Ets get undefined
somehow.     Has anybody used any version of gfortran successfully to compile
and correctly execute all of SPECmpi ?

Isn't this the same as PR34640?

(In reply to comment #10)
> Isn't this the same as PR34640?

I think so, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339#c11 .

Seems like this issue is still present in the GCC 4.6 branch, at least in GCC 4.6.0 and a checkout on 20110617 of the 4.6 branch.

I can confirm that patching the tera_tf source as suggested by David fixes the issue, but the runtime still fails: the benchmark seems stuck in an infinite loop or something when compiled with "-Ofast -march=native -mtune=native -floop-strip-mine -floop-interchange -floop-block" at least. Not sure if the failing runtime is caused by this issue though.

Is the patch that has been proposed insufficient?

Any of you know whether anyone has been able to build whole of SPEC MPI2007 using (a recent) GCC?

For another test case - using CLASS(*) - see PR 55763 comment 0 (last example); see also the analysis to that example in PR 55763 comment 6.

*** Bug 64555 has been marked as a duplicate of this bug. ***

I think the problem I'm seeing is the same issue; I'm posting it here for an additional test case:

$ cat scan_bug.f90 
   module test_mod
!
   type t1
      character(8)  :: string
   end type t1
!
   type t2
     type(t1), pointer :: fp(:)
   end type t2
!
   type t3
      type(t2), pointer :: as
   end type t3
!
   type(t3), pointer :: as_typ(:)=>null()
!
   character(8),  pointer, public :: p(:)
!
   contains
!
   subroutine as_set_alias (i)
!
   implicit none
!
   integer, intent(in)    :: i
!
     p => as_typ(i)%as%fp(:)%string
!
   end subroutine as_set_alias
!
   end module test_mod

   program test_prog
   use test_mod
   call as_set_alias(1)
   end program test_prog

$ gfortran scan_bug.f90 
/tmp/cccR3cNH.o: In function `__test_mod_MOD_as_set_alias':
scan_bug.f90:(.text+0x139): undefined reference to `span.0'
collect2: error: ld returned 1 exit status

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/joshua2/opt/gcc/linux-64/gcc-5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/joshua2/opt/gcc/linux-64/gcc-5.1.0-src/configure --prefix=/home/joshua2/opt/gcc/linux-64/gcc-5.1.0
Thread model: posix
gcc version 5.1.0 (GCC)

FYI, compiling example from comment 17 together with -flto :


$ gfortran-6 -flto -c pr40737_c17.f90
pr40737_last.f90:23:0: internal compiler error: in get_partitioning_class, at symtab.c:1794


$ gfortran-5.3.1 -flto -c pr40737_c17.f90
pr40737_last.f90:23:0: internal compiler error: in write_symbol, at lto-streamer-out.c:2547

Author: pault
Date: Sun Sep 10 17:02:53 2017
New Revision: 251949

URL: https://gcc.gnu.org/viewcvs?rev=251949&root=gcc&view=rev
Log:
2017-09-10  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/34640
	PR fortran/40737
	PR fortran/55763
	PR fortran/57019
	PR fortran/57116

	* expr.c (is_subref_array): Add class pointer array dummies
	to the list of expressions that return true.
	* trans-array.c: Add SPAN_FIELD and update indices for
	subsequent fields.
	(gfc_conv_descriptor_span, gfc_conv_descriptor_span_get,
	gfc_conv_descriptor_span_set, is_pointer_array,
	get_array_span): New functions.
	(gfc_get_descriptor_offsets_for_info): New function to preserve
	API for access to descriptor fields for trans-types.c.
	(gfc_conv_scalarized_array_ref): If the expression is a subref
	array, make sure that info->descriptor is a descriptor type.
	Otherwise, if info->descriptor is a pointer array, set 'decl'
	and fix it if it is a component reference.
	(build_array_ref): Simplify handling of class array refs by
	passing the vptr to gfc_build_array_ref rather than generating
	the pointer arithmetic in this function.
	(gfc_conv_array_ref): As in gfc_conv_scalarized_array_ref, set
	'decl'.
	(gfc_array_allocate): Set the span field if this is a pointer
	array. Use the expr3 element size if it is available, so that
	the dynamic type element size is used.
	(gfc_conv_expr_descriptor): Set the span field for pointer
	assignments.
	* trans-array.h: Prototypes for gfc_conv_descriptor_span_get
	gfc_conv_descriptor_span_set and
	gfc_get_descriptor_offsets_for_info added.
	trans-decl.c (gfc_get_symbol_decl): If a non-class pointer
	array, mark the declaration as a GFC_DECL_PTR_ARRAY_P. Remove
	the setting of GFC_DECL_SPAN.
	(gfc_trans_deferred_vars): Set the span field to zero in thge
	originating scope.
	* trans-expr.c (gfc_conv_procedure_call): Do not use copy-in/
	copy-out to pass subref expressions to a pointer dummy.
	(gfc_trans_pointer_assignment): Remove code for setting of
	GFC_DECL_SPAN. Set the 'span' field for non-class pointers to
	class function results. Likewise for rank remap. In the case
	that the target is not a whole array, use the target array ref
	for remap and, since the 'start' indices are missing, set the
	lbounds to one, as required by the standard.
	* trans-intrinsic.c (conv_expr_ref_to_caf_ref): Pick up the
	'token' offset from the field decl in the descriptor.
	(conv_isocbinding_subroutine): Set the 'span' field.
	* trans-io.c (gfc_trans_transfer): Always scalarize pointer
	array io.
	* trans-stmt.c (trans_associate_var): Set the 'span' field.
	* trans-types.c (gfc_get_array_descriptor_base): Add the 'span'
	field to the array descriptor.
	(gfc_get_derived_type): Pointer array components are marked as
	GFC_DECL_PTR_ARRAY_P.
	(gfc_get_array_descr_info): Replaced API breaking code for
	descriptor offset calling gfc_get_descriptor_offsets_for_info.
	* trans.c (get_array_span): New function.
	(gfc_build_array_ref): Simplify by calling get_array_span and
	obtain 'span' if 'decl' or 'vptr' present.
	* trans.h : Rename DECL_LANG_FLAG_6, GFC_DECL_SUBREF_ARRAY_P,
	as GFC_DECL_PTR_ARRAY_P.


2017-09-10  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/34640
	* gfortran.dg/associate_24.f90: New test.
	* gfortran.dg/assumed_type_2.f90: Adjust some of the tree dump
	checks.
	* gfortran.dg/no_arg_check_2.f90: Likewise.
	* gfortran.dg/pointer_array_1.f90: New test.
	* gfortran.dg/pointer_array_2.f90: New test.
	* gfortran.dg/pointer_array_7.f90: New test.
	* gfortran.dg/pointer_array_8.f90: New test.
	* gfortran.dg/pointer_array_component_1.f90: New test.
	* gfortran.dg/pointer_array_component_2.f90: New test.
	* gfortran.dg/goacc/kernels-alias-4.f95: Bump up both tree scan
	counts by 1.

	PR fortran/40737
	* gfortran.dg/pointer_array_3.f90: New test.

	PR fortran/57116
	* gfortran.dg/pointer_array_4.f90: New test.

	PR fortran/55763
	* gfortran.dg/pointer_array_5.f90: New test.

	PR fortran/57019
	* gfortran.dg/pointer_array_6.f90: New test.

2017-09-10  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/34640
	* libgfortran/libgfortran.h: Add span field to descriptor.
	* libgfortran/libtool-version : Bump up version number to 5:0:0.

Added:
    trunk/gcc/testsuite/gfortran.dg/associate_24.f90
    trunk/gcc/testsuite/gfortran.dg/pointer_array_1.f90
    trunk/gcc/testsuite/gfortran.dg/pointer_array_2.f90
    trunk/gcc/testsuite/gfortran.dg/pointer_array_3.f90
    trunk/gcc/testsuite/gfortran.dg/pointer_array_4.f90
    trunk/gcc/testsuite/gfortran.dg/pointer_array_5.f90
    trunk/gcc/testsuite/gfortran.dg/pointer_array_6.f90
    trunk/gcc/testsuite/gfortran.dg/pointer_array_7.f90
    trunk/gcc/testsuite/gfortran.dg/pointer_array_8.f90
    trunk/gcc/testsuite/gfortran.dg/pointer_array_component_1.f90
    trunk/gcc/testsuite/gfortran.dg/pointer_array_component_2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-array.h
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/fortran/trans-io.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/fortran/trans.c
    trunk/gcc/fortran/trans.h
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/assumed_type_2.f90
    trunk/gcc/testsuite/gfortran.dg/goacc/kernels-alias-4.f95
    trunk/gcc/testsuite/gfortran.dg/no_arg_check_2.f90
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/libgfortran.h
    trunk/libgfortran/libtool-version

Fixed on trunk.

I am sorry that it has taken so long.

Thanks for the report.

Paul