This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)


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

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2012-10-17 19:21:22 UTC ---
On Wed, Oct 17, 2012 at 06:51:08PM +0000, burnus at gcc dot gnu.org wrote:
> 
> > The Standard does not define 'incremented' and
> > 'incrementation', and in particular, these words
> > are not defined in terms of the numeric intrinsic
> > operations and so you cannot appeal to Section 7.
> 
> I disagree. One can surely read something differently, but I think it is very
> difficult to have a reading which makes both sense in terms of the English
> language ("increment" = "the action or process of increasing especially in
> quantity or value : enlargement"; source: Marriam-Webster) and the common
> understanding how programs behave.
> 
> For instance, for
> 
>   do i = 2, 5, 1
>     print *, i
>   end do
> 
> The standard has: "The DO variable, if any, is incremented by the value of the
> incrementation parameter m3."
> 
> In my reading of the standard, the program will print 2, 3, 4, 5 and after the
> loop i has the value 6. That matches in my understanding "i = i + 1" where m3
> == 1; thus, I fail to see why Section 7.1.5.2.4 shouldn't apply in this case.
> 
> Can you come up with a (somewhat sensible) different interpretation which still
> allows the program of comment 0?
> 

As I point out in c.l.f, the incrementataion process is
not defined by the standard.  While certainly, one would
assume that this process is i = i + m3 and so Section 7
rules apply.  The incrementation process could be done
in some other manner such as

   integer(8)
   j = int(i,8) + m3
   if (j < int(huge(i),8) + 1) then
      i = j
   else
      i = - huge(i) - 1 + m3 ! Assume wrap around semantics
   end if                    ! Preventing a possible hardware trap

or the incrementation process could be implemented via
bit-wise shift, and, and [x]or.  With bit manipulations
none of the numeric intrinsic operations are used, so
section 7 does not apply.

> (I concur that the invalidity of the program when m2 ==
> huge(integer-do-variable) is a bit surprising at a glance,
> but that doesn't make the program valid. I also concur that
> one could have written the standard differently such that
> the program becomes valid.)

The standard simply should have stated that the incrementation
process follows the rules of 7.1.5.2.4. 

As I said I don't care enough about the PR to 
re-open it.  In any event, gfortran should 
probably issue a warning if m2=huge(i) and
m3 > 0.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]