[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #10 from kargl at gcc dot gnu.org ---
Closing as fixed on trunk.  I've converted the
code in comment #7 to a testcase, and committed
it so hopefully it won't get unfixed.

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Mar 14 00:45:45 2018
New Revision: 258509

URL: https://gcc.gnu.org/viewcvs?rev=258509=gcc=rev
Log:
2018-03-13  Steven G. Kargl  

PR fortran/61775
* gfortran.dg/pr61775.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr61775.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #8 from Thomas Koenig  ---
(In reply to kargl from comment #7)

> I would like to close this as fixed after committing the following
> testcase
> 
> program pi
> real   , allocatable :: x(:)
> integer  :: n
> n  = 1
> x = [ (i,i=1,n) ]
> if (x(n) /= 1) stop 1
> end

Sure, go ahead.

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||kargl at gcc dot gnu.org

--- Comment #7 from kargl at gcc dot gnu.org ---
I think that this is now fixed on trunk.  Don't know which patch.

% gfcx -o z a.f90 && ./z
   1.
% gfcx -o z a.f90 -O2 -fcheck=all && ./z
   1.
% valgrind ./z
==85120== Memcheck, a memory error detector
==85120== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==85120== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==85120== Command: ./z
==85120== 
   1.
==85120== 
==85120== HEAP SUMMARY:
==85120== in use at exit: 0 bytes in 0 blocks
==85120==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==85120== 
==85120== All heap blocks were freed -- no leaks are possible
==85120== 
==85120== For counts of detected and suppressed errors, rerun with: -v
==85120== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I've read the tree dump for -fdump-tree-optimized and it appears to
do the right think with expanding the constructor, allocating, and
freeing memory.

Both 6-branch and 7-branch still fail
% gfc6 -o z a.f90 -O2 -fcheck=all && ./z
 Segmentation fault (core dumped)
% gfc7 -o z a.f90 -O2 -fcheck=all && ./z
Segmentation fault (core dumped)

I would like to close this as fixed after committing the following
testcase

program pi
real   , allocatable :: x(:)
integer  :: n
n  = 1
x = [ (i,i=1,n) ]
if (x(n) /= 1) stop 1
end

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[lkrupp at gcc dot gnu.org]

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

lkrupp at gcc dot gnu.org changed:

   What|Removed |Added

 CC||lkrupp at gcc dot gnu.org

--- Comment #6 from lkrupp at gcc dot gnu.org ---
I started looking at this until I read all of the comments and realized that
someone had already come up with a patch, and one that is probably better and
certainly simpler than whatever I would have done.

It might be worth noting that the problem seems to come up when an array is
passed to an intrinsic function that returns a scalar when its argument is a
scalar and that returns an array when it's passed an array.  In the sample
program in the description, the intrinsic function is integer to real
conversion.  The following sample program reproduces that problem with a simple
array instead of an implied do loop, and also with the square root function. 
Compiling this with -fbounds-check makes the program fail on the assignment
statement:

program assign_allocatable
implicit none

  call s_int_real_cvt
  call s_sqrt

contains

  subroutine s_int_real_cvt
  implicit none
  integer, parameter :: r(3) = [101, 102, 103]
  real, allocatable :: k(:)

  k = r

  if (any(k /= r)) call abort

  return
  end subroutine

  subroutine s_sqrt
  implicit none
  real, parameter :: r(5) = [1, 4, 9, 16, 25]
  real, allocatable :: a(:)

  a = sqrt(r)

  if (any(a /= [1, 2, 3, 4, 5])) call abort

  return
  end subroutine

end program

Array-value intrinsics like TRANSFER and PACK don't seem to trigger this
problem.

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr ---
(In reply to comment #4)
 This seems to fix it here (not heavily tested): ...

Confirmed, regtested without regression and no obvious problem with my other
tests.

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[mikael at gcc dot gnu.org]

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

Mikael Morin mikael at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #4 from Mikael Morin mikael at gcc dot gnu.org ---
This seems to fix it here (not heavily tested):


Index: trans-expr.c
===
--- trans-expr.c(révision 209169)
+++ trans-expr.c(copie de travail)
@@ -7932,9 +7932,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr

   /* Walk the lhs.  */
   lss = gfc_walk_expr (expr1);
-  if (gfc_is_reallocatable_lhs (expr1)
- !(expr2-expr_type == EXPR_FUNCTION
-  expr2-value.function.isym != NULL))
+  if (gfc_is_reallocatable_lhs (expr1))
 lss-is_alloc_lhs = 1;
   rss = NULL;
   if (lss != gfc_ss_terminator)

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Whatever the issue was, it appears to be fixed in HEAD.

troutmask:sgk[205] gfc4x -o z h.f90
troutmask:sgk[206] ./z
   1.
troutmask:sgk[207] gfc49 -o z h.f90
troutmask:sgk[208] ./z

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
 Whatever the issue was, it appears to be fixed in HEAD.
 
 troutmask:sgk[205] gfc4x -o z h.f90
 troutmask:sgk[206] ./z
1.
 troutmask:sgk[207] gfc49 -o z h.f90
 troutmask:sgk[208] ./z
 
 Program received signal SIGSEGV: Segmentation fault - invalid memory
 reference.

I take it back.  It is broken with optimizations.

troutmask:sgk[213] gfc4x -o z -O -fcheck=all h.f90  ./z
At line 6 of file h.f90
Fortran runtime error: Index '1' of dimension 1 of array 'x' above upper
bound of 1
Segmentation fault (core dumped)

[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference

[dominiq at lps dot ens.fr]

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

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

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-07-10
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr ---
 Whatever the issue was, it appears to be fixed in HEAD.

I don't think so. Could you run the test with -fsanitize=address. On
x86_64-apple-darwin13 r212433, I get at run time:

=
==4401==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020e014
at pc 0x1064f08c1 bp 0x7fff597100e0 sp 0x7fff597100d8
WRITE of size 4 at 0x6020e014 thread T0
#0 0x1064f08c0
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x118c0)
#1 0x1064f0d19
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11d19)
#2 0x7fff922ef5fc (/usr/lib/system/libdyld.dylib+0x35fc)

0x6020e014 is located 0 bytes to the right of 4-byte region
[0x6020e010,0x6020e014)
allocated by thread T0 here:
#0 0x10652a4c9 (/opt/gcc/gcc4.10p-212433/lib/libasan.1.dylib+0x314c9)
#1 0x1064f0846
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11846)
#2 0x1064f0d19
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11d19)
#3 0x7fff922ef5fc (/usr/lib/system/libdyld.dylib+0x35fc)

SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
  0x1c041bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c041bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c041bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c041be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c041bf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=0x1c041c00: fa fa[04]fa fa fa 06 fa fa fa 06 fa fa fa 05 fa
  0x1c041c10: fa fa 00 fa fa fa 00 00 fa fa 03 fa fa fa 00 02
  0x1c041c20: fa fa 00 07 fa fa 00 fa fa fa 00 00 fa fa 00 00
  0x1c041c30: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
  0x1c041c40: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
  0x1c041c50: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  ASan internal:   fe
==4401==ABORTING