[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[dfranke at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

Daniel Franke <dfranke at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu.org
      Known to fail|                            |

--- Comment #12 from Daniel Franke <dfranke at gcc dot gnu.org> 2010-12-28 22:30:16 UTC ---
Isn't this the same as PR34640?

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

--- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-01-22 22:37:05 UTC ---
(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 .

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[kenneth.hoste at elis dot ugent.be]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

Kenneth Hoste <kenneth.hoste at elis dot ugent.be> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kenneth.hoste at elis dot
                   |                            |ugent.be

--- Comment #14 from Kenneth Hoste <kenneth.hoste at elis dot ugent.be> 2011-06-23 07:36:41 UTC ---
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?

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #15 from Tobias Burnus <burnus at gcc dot gnu.org> 2013-01-06 14:56:34 UTC ---
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 fortran/40737] Pointer references sometimes fail to define "span" symbols

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thfanning at gmail dot com

--- Comment #16 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 64555 has been marked as a duplicate of this bug. ***

[Bug fortran/40737] New: Pointer references sometimes fail to define "span" symbols

[dh458 at oakapple dot net]

This bug appears in gfortran 4.4.0 on sparc-solaris, x86-solaris, and
x86-linux.
The attached test case is extracted from SPECmpi 2007 129.tera_tf

The two test files testmod.F90 and testuse.F90 define and use pointer types.
With -DBIGMOD certain variables are defined in the module; with -UBIGMOD,
in the user.   Correct results are obtained with the latter; the code generated
for the lines

         Ro => Hydro_vars( first_cell:last_cell, j, k)%cell_var( ro_var)
         Ets => Hydro_vars( first_cell:last_cell, j, k)%cell_var( ets_var)
         Um => Hydro_vars( first_cell:last_cell, j, k)%cell_var( u_var)
         Um_p1 => Hydro_vars( first_cell:last_cell, j, k)%cell_var( up1_var)
         Um_p2 => Hydro_vars( first_cell:last_cell, j, k)%cell_var( up2_var)

both uses and defines various symbols like

testuse.s:      sethi   %h44(span.1.696), %g1
testuse.s:      or      %g1, %m44(span.1.696), %g1
testuse.s:      or      %g1, %l44(span.1.696), %g1

testuse.s:      .local  span.1.696
testuse.s:      .common span.1.696,8,8


but with -UBIGMOD, the symbols are referred to but nowhere defined.

Compile e.g.

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

Same results for -m32


-- 
           Summary: Pointer references sometimes fail to define "span"
                    symbols
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dh458 at oakapple dot net
  GCC host triplet: sparc-sun-solaris2.10


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[dh458 at oakapple dot net]

------- Comment #1 from dh458 at oakapple dot net  2009-07-13 21:39 -------
Created an attachment (id=18189)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18189&action=view)
module definition

This is the module definition file for the bug report.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[dh458 at oakapple dot net]

------- Comment #2 from dh458 at oakapple dot net  2009-07-13 21:40 -------
Created an attachment (id=18190)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18190&action=view)
module use file for bug report

Compile this module use with the other attachment module definition


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2009-07-14 07:50 -------
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'


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   GCC host triplet|sparc-sun-solaris2.10       |
           Keywords|                            |wrong-code
      Known to fail|                            |4.3.2 4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[dh458 at oakapple dot net]

------- Comment #4 from dh458 at oakapple dot net  2009-07-21 15:19 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2009-07-22 07:10 -------
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


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
      Known to fail|4.3.2 4.4.0                 |4.3.2 4.4.0 4.5.0
   Last reconfirmed|0000-00-00 00:00:00         |2009-07-22 07:10:56
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[burnus at gcc dot gnu dot org]

------- Comment #6 from burnus at gcc dot gnu dot org  2009-07-22 07:12 -------
Paul, do you immediately see what goes wrong here? If not, I can also dig
myself.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[burnus at gcc dot gnu dot org]

------- Comment #7 from burnus at gcc dot gnu dot org  2009-07-22 09:20 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[bergner at gcc dot gnu dot org]

------- Comment #8 from bergner at gcc dot gnu dot org  2009-10-06 22:03 -------
Created an attachment (id=18732)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18732&action=view)
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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[kargl at gcc dot gnu dot org]

------- Comment #9 from kargl at gcc dot gnu dot org  2009-10-06 23:10 -------
(In reply to comment #8)
> Created an attachment (id=18732)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18732&action=view) [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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[burnus at gcc dot gnu dot org]

------- Comment #10 from burnus at gcc dot gnu dot org  2009-10-07 08:20 -------
(In reply to comment #8)
> Created an attachment (id=18732)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18732&action=view) [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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737

[Bug fortran/40737] Pointer references sometimes fail to define "span" symbols

[dh458 at oakapple dot net]

------- Comment #11 from dh458 at oakapple dot net  2009-10-07 22:42 -------
(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 ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40737