[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

2012-10-21 Thread mikael at gcc dot gnu.org 


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



Mikael Morin  changed:



   What|Removed |Added



 CC||mikael at gcc dot gnu.org



--- Comment #10 from Mikael Morin  2012-10-21 
13:52:35 UTC ---

(In reply to comment #8)

> Actually, the situation is a bit bizarre. There are no conforming programs for

> which bounds-checking can trigger... all these bounds-checking statements can

> be just optimized away :-). That's not quite what the users want...



Well, if the middle-end is able to prove that the bounds checking code is

useless, it may as well remove it.  In the case of a bogus array access, that

code is useful, so the middle-end shouldn't be able to prove that it isn't, and

the it won't be removed.

For the other case (code removed where it should stay) there is a bug in the

compiler, but that's not what -fbounds-check is supposed to check ;-).





Regarding the initial question:

> Hi,

> can someone fortran aware please double-check that the tests

> 

> * gfortran.dg/bounds_check_9.f90: New test.

> * gfortran.dg/bounds_check_fail_2.f90: New test.

> 

> do not contain out of bounds access?



There should be none, as the -fbounds-check instrumentation is supposed to

catch out of bounds early enough, so that the code is valid from a middle-end

point of view.

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

2012-10-20 Thread dominiq at lps dot ens.fr 


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



--- Comment #9 from Dominique d'Humieres  2012-10-20 
15:43:13 UTC ---

> can someone fortran aware please double-check that the tests

>

>* gfortran.dg/bounds_check_9.f90: New test.

>* gfortran.dg/bounds_check_fail_2.f90: New test.

>

> do not contain out of bounds access? ...



AFAICT the only difference (ignoring spaces) between the two tests is the line



   call sub((/4/))



in the second test.

So there is no out of bounds access for the first test, but in the second one

the call to sub((/4/)) in which an array of length 1 is copied in an array of

length 2, gives an out of bounds access triggering the error:



Fortran runtime error: Array bound mismatch for dimension 1 of array 'ivec'

(1/2)



when compiled with -fbounds-check.



IMO these tests are a misuse of the elemental subroutine set_optional in the

subroutine sub. The test being valid only if sub is called without argument or

with an array of length 2.



>From the 2008 standard



12.8.3 Elemental subroutine actual arguments



An elemental subroutine has only scalar dummy arguments, but may have array

actual arguments. 



In a reference to an elemental subroutine, either all actual arguments shall be

scalar, or all actual arguments corresponding to INTENT (OUT) and INTENT

(INOUT) dummy arguments shall be arrays of the same shape and the remaining

actual arguments shall be conformable with them. 



In the case that the actual arguments corresponding to INTENT (OUT) and INTENT

(INOUT) dummy arguments are arrays, the values of the elements, if any, of the

results are the same as would be obtained if the subroutine had been applied

separately, in array element order, to corresponding elements of each array

actual argument.

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

2012-10-20 Thread Joost.VandeVondele at mat dot ethz.ch 


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



--- Comment #8 from Joost VandeVondele  
2012-10-20 14:59:08 UTC ---

(In reply to comment #7)

> Hi,

> can someone fortran aware please double-check that the tests

> 

> * gfortran.dg/bounds_check_9.f90: New test.

> * gfortran.dg/bounds_check_fail_2.f90: New test.

> 

> do not contain out of bounds access?  I am working on path to bound number of

> loop iterations better based on array accesses and what I see is array A.9

> containing values {1,2} that is accessed in the loop header.

> We bound number of iterations of that loop to 1 (that is one loopback edge

> iteration to walk both parts of the array) and then the testcases start

> failing.

> 

> I do not understand the testcase.

> Perhaps the bounds-check instrumentation happens too late or we need to 
> disable

> this logic with -fbounds-check?

> 

> Honza



According to me, the first testcase (bounds_check_9.f90) should contain no

out-of-bounds access (at least from the fortran point of view, and also

according to valgrind), while the second testcase (bounds_check_fail_2.f90)

does contain out-of-bounds access (by design). Of course, -fbounds-check is

designed to catch out-of-bounds at runtime (which the second testcase tests).

Of course, fortran programs with out-of-bounds access are not standard

conforming. 



Actually, the situation is a bit bizarre. There are no conforming programs for

which bounds-checking can trigger... all these bounds-checking statements can

be just optimized away :-). That's not quite what the users want... I run

-fbounds-check -O2 quite often. I don't think one should switch off

optimization in the presence of -fbounds-check. Maybe the docs should be

enhanced and mention that bounds checking is most effective at -O0 ?

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

2012-10-20 Thread hubicka at gcc dot gnu.org 


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



Jan Hubicka  changed:



   What|Removed |Added



 CC||hubicka at gcc dot gnu.org



--- Comment #7 from Jan Hubicka  2012-10-20 
14:38:05 UTC ---

Hi,

can someone fortran aware please double-check that the tests



* gfortran.dg/bounds_check_9.f90: New test.

* gfortran.dg/bounds_check_fail_2.f90: New test.



do not contain out of bounds access?  I am working on path to bound number of

loop iterations better based on array accesses and what I see is array A.9

containing values {1,2} that is accessed in the loop header.

We bound number of iterations of that loop to 1 (that is one loopback edge

iteration to walk both parts of the array) and then the testcases start

failing.



I do not understand the testcase.

Perhaps the bounds-check instrumentation happens too late or we need to disable

this logic with -fbounds-check?



Honza

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

2007-09-18 Thread fxcoudert at gcc dot gnu dot org 


--- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-09-18 21:34 
---
Fixed.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

2007-09-18 Thread fxcoudert at gcc dot gnu dot org 


--- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-09-18 21:25 
---
Subject: Bug 31119

Author: fxcoudert
Date: Tue Sep 18 21:25:40 2007
New Revision: 128587

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128587
Log:
PR fortran/31119

* trans-array.c (gfc_conv_ss_startstride): Only perform bounds
checking for optional args when they are present.

* gfortran.dg/bounds_check_9.f90: New test.
* gfortran.dg/bounds_check_fail_2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/bounds_check_9.f90
trunk/gcc/testsuite/gfortran.dg/bounds_check_fail_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

2007-07-03 Thread jv244 at cam dot ac dot uk 


--- Comment #4 from jv244 at cam dot ac dot uk  2007-07-04 06:35 ---
patch ping ?


-- 


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

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

2007-05-09 Thread fxcoudert at gcc dot gnu dot org 


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-03-10 12:43:31 |2007-05-09 08:09:33
   date||


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

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

2007-03-19 Thread fxcoudert at gcc dot gnu dot org 


--- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-03-19 09:05 
---
Created an attachment (id=13229)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13229&action=view)
Patch that fixes the issue reported

The attached patch fixes the issue for the reported testcase. I checked that we
still issue errors when the optional parameter is present and has the wrong
size; the code below will error out as expected if one of the commented lines
is uncommented:

module sub_mod
contains
elemental subroutine set_optional(i,idef,iopt)
! set i to (iopt,idef) if iopt (is,is not) PRESENT
integer, intent(out)  :: i
integer, intent(in)   :: idef
integer, intent(in), optional :: iopt
if (present(iopt)) then
   i = iopt
else
   i = idef
end if
end subroutine set_optional

  subroutine sub(ivec)
integer  , intent(in), optional :: ivec(:)
integer :: ivec_(2)
call set_optional(ivec_,(/1,2/))
print*,"ivec_=",ivec_
call set_optional(ivec_,(/1,2/),ivec)
print*,"ivec_=",ivec_
  end subroutine sub
end module sub_mod

program main
  use sub_mod, only: sub
  call sub()
  call sub((/4,5/))
!  call sub((/4/))
!  call sub((/4,5,6/))
end program main


Anyway, the other calls to checking routines need to be audited for similar
problems with optional args. That probably includes making a testcase for each
situation, and see if optional arg can be used in each context.


-- 


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

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

2007-03-18 Thread fxcoudert at gcc dot gnu dot org 


--- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-03-18 17:49 
---
*** Bug 31148 has been marked as a duplicate of this bug. ***


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||vivekrao4 at yahoo dot com


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

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

2007-03-10 Thread fxcoudert at gcc dot gnu dot org 


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-03-10 12:43:31
   date||


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

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

2007-03-10 Thread burnus at gcc dot gnu dot org 


--- Comment #1 from burnus at gcc dot gnu dot org  2007-03-10 08:47 ---
The problem is that the bounds of an optional argument are checked,
regardlessly whether it is present.

  int8 ubound.0;
  if (ivec != 0B)
{
ubound.0 = (ivec->dim[0].ubound - ivec->dim[0].lbound) + 1;
}
  {
int8 D.1373;
if ((logical4) __builtin_expect ((int8) (D.1373 > 0 && ubound.0 <= 0), 0))
  {
_gfortran_runtime_error ("Array reference out of bounds, upper bound of
dimension 1 of array \'ivec\' exceeded (in file \'x.f90


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|Bogus "array abound |-fbounds-check: Check for
   |mismatch" for -fbounds-check|presence of optional
   ||arguments before bound
   ||checking


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