Bug 33139 - array pointer assignment gives incorrect dimensions
Summary: array pointer assignment gives incorrect dimensions
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.1.1
: P3 normal
Target Milestone: 4.3.0
Assignee: Tobias Burnus
URL:
Keywords: wrong-code
: 33264 (view as bug list)
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2007-08-21 20:43 UTC by Dave Grote
Modified: 2007-08-31 13:56 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.1.3 4.2.1 4.3.0
Last reconfirmed: 2007-08-24 15:03:54


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Grote 2007-08-21 20:43:52 UTC
In some cases, when doing a pointer assignment with a arrays, the upper and lower bounds on the pointer are not the same as on the pointee. This happens in the convoluted case of a pointer declared in a module that is assigned to in a subroutine. In the caller of that subroutine, the bounds of that pointer are coming out incorrect. Below is a sample code showing the problem. It can be built without any compiler options. I get this with the most recent version of gfortran on linux (FC5).
$ gfortran --version
GNU Fortran (GCC) 4.3.0 20070821 (experimental) [trunk revision 127658]

Here is the sample program
-----------------------
module Lattice
integer:: ndrft
real(kind=8),pointer:: drftzs(:)
end module Lattice
program badpointerdims
use Lattice
real(kind=8),pointer:: p(:)
ndrft = 100
allocate(p(0:100))
call topsetpointerdrftzs(p)
print*,"p bounds ",lbound(p),ubound(p)
print*,"drftzs bounds ",lbound(drftzs),ubound(drftzs)
stop
end badpointerdims
subroutine setpointerdrftzs(p)
use Lattice
real(kind=8),target::p(0:ndrft)
drftzs => p
return
end setpointerdrftzs
-----------------------

The program prints the following output
 p bounds            0         100
 d bounds            1         101
I would expect that the d bounds be the same as the p bounds.

Thanks for your help!
   Dave
Comment 1 Tobias Burnus 2007-08-22 06:36:24 UTC
Minimal example:
  implicit none
  real, TARGET :: a(0:100)
  real, pointer :: p(:)
  p => a
  print *, lbound(a), ubound(a)
  print *, lbound(p), ubound(p)
  end

Prints:
           0         100
           1         101
instead of (ifort, NAG f95, g95):
 0 100
 0 100

"7.4.2.1 Data pointer assignment"

"If no bounds-remapping-list is specified, the extent of a dimension of data-pointer-object is the extent of the corresponding dimension of data-target. [...] the lower bound of each dimension is the result of the intrinsic function LBOUND (13.7.60) applied to the corresponding dimension of data-target. The upper bound of each dimension is one less than the sum of the lower bound and the extent."
Comment 2 Francois-Xavier Coudert 2007-08-22 11:23:33 UTC
>   real, TARGET :: a(0:100)
>   real, pointer :: p(:)
>   p => a
>   print *, lbound(a), ubound(a)
>   print *, lbound(p), ubound(p)
>   end

This generates the following code:

  struct array1_real4 p;
  real4 a[101];

  p.data = 0B;
  p.dtype = 281;
  p.dim[0].lbound = 1;
  p.dim[0].ubound = 101;
  p.dim[0].stride = 1;
  p.data = (void *) &a[0];
  p.offset = -1;
Comment 3 Tobias Burnus 2007-08-22 14:41:17 UTC
Note: for a(:) and thus also for "p=>a(:)" the lbound starts at 1 (this is somewhere hidden in "6.2.2.3 Array sections") - this part works.

Partial patch. Note: This patch is incomplete as one also needs to set the offset to 10.

--- trans-array.c       (revision 127689)
+++ trans-array.c       (working copy)
@@ -4766,6 +4766,4 @@ gfc_conv_expr_descriptor (gfc_se * se, g
-         /* If we have an array section or are assigning to a pointer,
-            make sure that the lower bound is 1.  References to the full
-            array should otherwise keep the original bounds.  */
-         if ((!info->ref
-              || info->ref->u.ar.type != AR_FULL
-              || se->direct_byref)
+         /* If we have an array section make sure that the lower bound is 1.
+            References to the full array should otherwise keep the original
+            bounds.  */
+         if ((!info->ref || info->ref->u.ar.type != AR_FULL)



! { dg-do run }
!
! PR fortran/33139
!
program prog
  implicit none
  real, target :: a(-10:10)
  real, pointer :: p(:)
  integer :: i
  do i = -10, 10
    a(i) = real(i)
  end do
  p => a
  if(lbound(p,dim=1) /= -10 .and. ubound(p,dim=1) /= 10) &
    call abort()
  do i = -10, 10
    if(p(i) /= real(i)) call abort()
  end do
  p => a(:)
  if(lbound(p,dim=1) /= 1 .and. ubound(p,dim=1) /= 21) &
   call abort()
end program prog
Comment 4 patchapp@dberlin.org 2007-08-24 14:46:00 UTC
Subject: Bug number PR33139

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01651.html
Comment 5 Tobias Burnus 2007-08-24 15:01:58 UTC
Subject: Bug 33139

Author: burnus
Date: Fri Aug 24 15:00:59 2007
New Revision: 127770

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127770
Log:
2007-08-24  Tobias Burnus  <burnus@net-b.de>

	PR fortran/33139
	* trans-array.c (gfc_conv_expr_descriptor): Copy bounds for
	whole-array pointer assignments.

2007-08-24  Tobias Burnus  <burnus@net-b.de>

	PR fortran/33139
	* gfortran.dg/pointer_assign_4.f90: New.
	* gfortran.dg/shape_2.f90: Fix test case.
	* gfortran.dg/char_result_4.f90: Ditto.


Added:
    trunk/gcc/testsuite/gfortran.dg/pointer_assign_4.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/char_result_4.f90
    trunk/gcc/testsuite/gfortran.dg/shape_2.f90

Comment 6 Tobias Burnus 2007-08-24 15:03:54 UTC
FIXED for gfortran 4.3.0.
Comment 7 Tobias Burnus 2007-08-24 15:04:24 UTC
I said: FIXED.
Comment 8 Dave Grote 2007-08-24 16:29:49 UTC
Subject: Re:  array pointer assignment gives incorrect
 dimensions


Great! Thanks for fixing this!
   Dave

burnus at gcc dot gnu dot org wrote:
> ------- Comment #7 from burnus at gcc dot gnu dot org  2007-08-24 15:04 -------
> I said: FIXED.
>
>
>   
Comment 9 Francois-Xavier Coudert 2007-08-31 13:56:44 UTC
*** Bug 33264 has been marked as a duplicate of this bug. ***