[Bug fortran/31269] New: short-circuit in -fbounds-check

[Bug fortran/31269] New: short-circuit in -fbounds-check

[mimo2 at free dot fr]

program toto
 implicit none
 real    :: a(10)
 integer :: i
 a(:) = 1.
 do i=1,100
   if( i <= 10 .and. a(i) > 0. ) write(*,*) i,a(i)
 enddo
 end
Compiling this program with -fbounds-check will give an out-of-bound error
because the bound checking happens before the evaluation of the expression.
As short-circuit (i.e. not evaluating the second part of the expression when
its result is determined by the first part) is used by gfortran, it would be
nice to use it also for bound checking (at least as an option).


-- 
           Summary: short-circuit in -fbounds-check
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mimo2 at free dot fr


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

[Bug fortran/31269] short-circuit in -fbounds-check

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-03-19 17:24 -------
As mentioned before, this is not really a bug as the fortran says .and. is not
short circuiting.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug fortran/31269] short-circuit in -fbounds-check

[tobi at gcc dot gnu dot org]

------- Comment #2 from tobi at gcc dot gnu dot org  2007-03-19 17:37 -------
I'm not going to dig through the standard again to dig out the precise wording,
but as long as one doesn't actually access the out-of-bound array element the
program is valid.  Furthermore, the standard allows short-circuiting logic. 
Finally, bounds checking is not defined by the standard.

I agree with the submitter that this behavior is at least surprising, and could
be enhanced upon.


-- 

tobi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug fortran/31269] short-circuit in -fbounds-check

[tobi at gcc dot gnu dot org]

-- 

tobi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-03-19 17:40:07
               date|                            |


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

[Bug fortran/31269] short-circuit in -fbounds-check

[kargl at gcc dot gnu dot org]

------- Comment #3 from kargl at gcc dot gnu dot org  2007-03-20 03:09 -------
Tobi, this is a bogus request and the PR should be
closed.  The standard does not require left to right
evaluation.  It is the responsibility of the programmer
to know what she is doing.  I think this should be 
closed.


-- 


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

[Bug fortran/31269] short-circuit in -fbounds-check

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-03-20 05:54 -------
Closing again, this time as won't fix.  Fortran is not C/C++/Java.  This case
if you get -fbounds-check failing, then the bug is in the code and not in
Gfortran.  Yes the standard might allow for short circuiting but it does not
disallow for not short circuiting.  Also the code is depning on the current
behavior of Gfortran which might change in the future.  -fbounds-check just
shows this case is undefined.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


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

[Bug fortran/31269] short-circuit in -fbounds-check

[mimo2 at free dot fr]

------- Comment #5 from mimo2 at free dot fr  2007-03-20 08:56 -------
OK   but in the present situation, the execution could be different wether you
have -fbounds-check or not. Let's change the code by
program toto
 implicit none
 real    :: a(100)
 integer :: i, k
 a(:) = 1.
 do i=1,100
   if( i <= 10 .and. a(k(i)) > 0. ) write(*,*) i,a(i)
 enddo
end
which is perfectly legitimate, and with k(i) a function. I've understood that
when i>10, k will not be called when no bound-checking (there is presently
short-circuit) while it will be called if bound checking. As k(i) may have some
side effects, this could lead to different execution path.
  I still think that having a consistent behaviour between the two options is
the right thing to do. As short-circuit seems to be an extension of the
standard, the most sensible way would be to have an additionnal flag
-short-circuit which would allow the user to choose if he wants it or not, and
that this flag apply to all situations (i.e. bound-checking or not). 


-- 


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

[Bug fortran/31269] short-circuit in -fbounds-check

[tobi at gcc dot gnu dot org]

------- Comment #6 from tobi at gcc dot gnu dot org  2007-03-20 17:50 -------
I don't see why nobody besides me thinks that consistency, whether it's
mandated by the standard or not is a user-friendly feature.  Yes I understand
the arguments for our current behavior, but I'm not going to discuss this any
further, I don't think it's important enough as I said on the mailing list. 
I'd just like to note that I'd prefer if Andrew had chosen not to outvote an
--admittedly inactive-- Fortran maintainer (myself) twice, and had instead left
it to the other Fortran maintainers to decide.


-- 


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

[Bug fortran/31269] short-circuit in -fbounds-check

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2007-03-20 18:03 -------
> I don't see why nobody besides me thinks that consistency

Because the code is undefined either way you look at it :).
Yes GCC might allow it to work without -fbounds-check but that does not mean it
will work somewhere else.  Also Steve agreed with me ...


-- 


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

[Bug fortran/31269] short-circuit in -fbounds-check

[mimo2 at free dot fr]

------- Comment #8 from mimo2 at free dot fr  2007-03-20 18:52 -------
Why do you say the code is undefined. The last version (comment #5) is totally
valid, but possible side effects in the function k could lead to different
results depending on the fact that the -fbounds-check is set or no.
 And this is not a sane behaviour.


-- 


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

[Bug fortran/31269] short-circuit in -fbounds-check

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2007-03-20 18:57 -------
(In reply to comment #8)
> Why do you say the code is undefined. The last version (comment #5) is totally
> valid, but possible side effects in the function k could lead to different
> results depending on the fact that the -fbounds-check is set or no.

No, the last one just shows how the code is really undefined.

>  And this is not a sane behaviour.
Fortran is not C here sorry.


-- 


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

[Bug fortran/31269] short-circuit in -fbounds-check

[tobi at gcc dot gnu dot org]

------- Comment #10 from tobi at gcc dot gnu dot org  2007-03-20 19:11 -------
Mimo,

you rely on behavior that is not specified by the standard.  It says explicitly
that only, in order to determine the value of an expression, only as much of it
needs to be evaluated, as is needed to determine the vlaue of the entire
expression.  E.g. in "sqrt(x) + f(y)" f(y) needs not be executed if x is < 0. 
The result will be NaN after all.  But this doesn't mean that negative x
implies that f(y) won't be executed.

If you want sane behavior, the general rule is to follow the standard.  Now I
personally think that, since we're using shortcut logic, it's perfectly sane
to, so to say, shortcut bounds checking as well.  Other people have disagreed,
and they have strong arguments in their favor.

As for side-effects, one can easily come up with weird cases, which is why the
standard refrains from defining them.  Think e.g. about
  b .and. f(b) .and. b
where f may change its argument.

</rant>


-- 


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

[Bug fortran/31269] short-circuit in -fbounds-check

[mimo2 at free dot fr]

------- Comment #11 from mimo2 at free dot fr  2007-03-20 20:12 -------
hi tobi, may-be they have strong arguments as you say, but I've not catched
them. And I still believe that if there is an ambiguity in the standard, the
solution is to have a -fshort-circuit to let the user decide what he wants, and
more importantly that this option applies equally to bound-checking or not.
  The other thing I wanted to add is that I've worked on alpha with f90, and I
could bound-check my program, so I guess they were short-circuiting it. Then I
switched to linux with pgf90, and there also bound-check was working with my
program. Now I'm trying free compilers, i.e. gfortran and g95. With g95,
short-circuit is also applied on bound-checks. There is only gfortran which has
this singular behaviour. I agree this doesn't prove anything, and may-be
gfortran is the only "standard compliant" program. But I'll stop this
discussion here, and will stay with g95 when I want to bound-check my program.
   Thanks anyway to all for the time spent to answer my questions.


-- 


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

[Bug fortran/31269] short-circuit in -fbounds-check

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

------- Comment #12 from Tobias dot Schlueter at physik dot uni-muenchen dot de  2007-03-20 20:17 -------
Subject: Re:  short-circuit in -fbounds-check

I'm on your side, mimo, no need to convince me :-)


-- 


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

[Bug fortran/31269] short-circuit in -fbounds-check

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2007-03-20 20:58 -------
> But I'll stop this discussion here, and will stay with g95 when I want to
> bound-check my program.

Why short circuiting is legal and so is not short circuiting.  Yes Gfortran's
behavior is semi inconstaint but that does not make gfortran's behavior
incorrect.  In fact I want to say Gfortran's behavior with -fbounds-check with
not short circuiting is actually a good thing because you catch more
invalid/undefined fortran code that way.


-- 


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

[Bug fortran/31269] short-circuit in -fbounds-check

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

------- Comment #14 from Tobias dot Schlueter at physik dot uni-muenchen dot de  2007-03-20 21:04 -------
Subject: Re:  short-circuit in -fbounds-check

pinskia at gcc dot gnu dot org wrote:
>> But I'll stop this discussion here, and will stay with g95 when I want to
>> bound-check my program.
> 
> Why short circuiting is legal and so is not short circuiting.  Yes Gfortran's
> behavior is semi inconstaint but that does not make gfortran's behavior
> incorrect.  In fact I want to say Gfortran's behavior with -fbounds-check with
> not short circuiting is actually a good thing because you catch more
> invalid/undefined fortran code that way.

How about we stop this discussion?  I don't think anyone was 
volunteering to implement a solution anyway.  To sum up the 
alternatives:  you repeated the argument for one side above.  Other 
people want their program to do the same thing whether bounds checking 
is enabled or not -- except in the case where the non bounds-checking 
program would have made an out-of-bounds access.  Neither party is 
"right", I consider this latter behavior preferable.

Thank you, and goodbye.


-- 


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