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.
