(Re)allocation of allocatable arrays on assignment - F2003

[Paul Richard Thomas]

Dominique,

Thanks a lot - I'll get onto it.

Paul

On Thu, Nov 4, 2010 at 3:19 PM, Dominique Dhumieres <dominiq@lps.ens.fr> wrote:
> Paul,
>
> First the good news:
> (1) regstrapped without regression,
> (2) the reported problems have been fixed.
>
> Now the bad news:
> (1) the last patch woke up one bug of my collection (pr28849)
> with another bound problem:
>
> [macbook] f90/bug% cat pr28849_db.f90
> program gfc_bounds_check
>  implicit none
>
>  real, parameter   :: v(2) = (/ 1., 2. /)
>  real, allocatable :: a(:,:), b(:,:)
>
>  allocate (a(1,2), b(2,1))
>
>  print *, "Assignments with correct shapes after RESHAPE..."
>  a(:,:) = reshape (v(:), (/ 1, 2 /) )
>  b(:,:) = reshape (v(:), (/ 2, 1 /) )
>  ! Verify correctness of assignments
>  print *, lbound(a), ubound(a)
>  print *, "a(:,1) =", a(:,1)
>  print *, lbound(b), ubound(b)
>  print *, "b(:,1) =", b(:,1)
>
>  print *, "...and with wrong shape (should fail with bounds checking on)"
>  a(:,:) = reshape (v(:), (/ 2, 1 /) )
>  b(:,:) = reshape (v(:), (/ 1, 2 /) )
>  print *, "a(:,1) =", a(:,1)
>  print *, lbound(a), ubound(a)
>  print *, "b(:,1) =", b(:,1)
>  print *, lbound(b), ubound(b)
>
>  print *, "Must have missed an array bound violation after RESHAPE..."
>
> end program gfc_bounds_check
> [macbook] f90/bug% gfc -fcheck=all pr28849_db.f90
> [macbook] f90/bug% a.out
>  Assignments with correct shapes after RESHAPE...
>           1           1           1           2
>  a(:,1) =   1.0000000
>           1           1           2           1
>  b(:,1) =   1.0000000       2.0000000
>  ...and with wrong shape (should fail with bounds checking on)
>  a(:,1) =   1.0000000
>           1           1           1           2
>  b(:,1) =   1.0000000       2.0000000
>           1           1           2           1
>  Must have missed an array bound violation after RESHAPE...
>
> So either a is relocated as a(2,1) (b as b(1,2)) and the bounds
> are inconsistent, or it is not and there should be a run time
> error as when compiled with -std=f95.
>
> (2) More serious rnflow is miscompiled (again in evlrnf).
> When compiled with -OO, I get
>
>  0: 0: 0.001 -> Read sequence
>  0: 0: 0.466 -> extract extrema
>  0: 0: 0.479 -> Generate raw transitions counts
>  0: 0: 0.499 -> Compute Markov matrix
>  0: 0: 0.500 -> Calculate theoretical rainflow
> a.out(47494) malloc: *** mmap(size=562941464334336) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
>
> When compiled with optimization strting at -O1, the test run, but the final
> output is obviously wrong (a regression from the previous patch).
>
> Cheers,
>
> Dominique
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy