Bug 39286 - Missing out-of-bounds diagnostic
Summary: Missing out-of-bounds diagnostic
Status: RESOLVED DUPLICATE of bug 36683
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks: Fortran_bounds_checking
  Show dependency treegraph
 
Reported: 2009-02-24 09:56 UTC by Tobias Burnus
Modified: 2013-08-09 07:55 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-03-08 16:07:58


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2009-02-24 09:56:06 UTC
Found in the thread at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/792d5c732cc84ddf

Post: http://groups.google.com/group/comp.lang.fortran/msg/025a878dd2d9f8e0

I have not checked whether this is indeed an issue.
---------------
[...]
> At line 25 of file jahed_1.f90
> Fortran runtime error: Array bound mismatch for dimension 1 of array
> 'v3'

I wonder if GFortran is misrepresenting the error. The error message
suggests that GFortran is inferring the size of the assignee from the
LHS of the assignment statement on Line-9, rather than from the RHS
expression on the same line. The former has dimension 1:5, the latter
has 1:6. MRC, Sec. 3.11 says "..if the expression includes a reference
to the array variable or to a part of it, the expression is
interpreted as being fully evaluated before the assignment commences".
The extent of the expression is 6; the extent of the lvalue is 5.

Following Oliver Hardy's advice, "let's really make it dirty", I added
to the RHS the term

       + (/(i+2,i=0,n)/)

and added i to the declaration of integers on Line-3. After this
change, GFortran gave this spurious message at compile time

    err.f90:9: warning: 'i' may be used uninitialized in this function

and, despite the bounds-check being on, gave no error during execution.
Comment 1 Paul Thomas 2009-03-08 16:07:58 UTC
Confirmed.

For some reason, we have never added a bounds check to assignments.  The first testcase uses a check internal to the function.  Once an extra expression is added to the rhs, there is nothing to check against.

Cheers

Paul
Comment 2 Dominique d'Humieres 2009-04-29 14:12:33 UTC
I wonder if this not a duplicate of pr36683.

Comment 3 Dominique d'Humieres 2009-04-29 14:19:51 UTC
I have modified the code referenced in pr36683 as:

PROGRAM calls 
   IMPLICIT NONE 
   INTEGER :: a(2), b(3), c(6), n , i
   c = myfunc(a,b) 
   WRITE(*,*) "c:",c    !! gives "c: 1 2 3 4 5 6" 
   n = 5 
   c = 0 
   c(1:n) = (/(i+2,i=0,n)/)/myfunc(a,b)
   WRITE(*,*) "c:",c    !! gives "c: 1 2 3 4 5 0" 
CONTAINS 
FUNCTION myfunc(v1,v2) RESULT(v3) 
   IMPLICIT NONE 
   INTEGER, INTENT(IN) :: v1(:), v2(:) 
   INTEGER :: v3(SIZE(v1,1)*SIZE(v2,1)) 
   INTEGER :: i, j, k 
   DO i=1,SIZE(v1,1) 
      DO j=1,SIZE(v2,1) 
         k = (i-1)*SIZE(v2,1) + j 
         v3(k) = k 
      ENDDO 
   ENDDO 
   WRITE(*,*) "myfunc: v3:",v3    !! always gives "v3: 1 2 3 4 5 6" 
END FUNCTION myfunc 
END PROGRAM calls 

and I don't get any run time error even with '-fbounds-check'.
This confirms that this pr is a duplicate of pr36683.

Comment 4 Thomas Koenig 2013-08-09 07:55:23 UTC
Closing as dup.

*** This bug has been marked as a duplicate of bug 36683 ***