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



--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-10-17 
18:51:08 UTC ---

(In reply to comment #6)

> but you'll see that at least one person disagrees with both

> former J3 members.



The only way to get a definite answer is to fill an interpretation request and

wait until it has passed both the J3 and WG5 vote. However, based on my reading

of the standard and the three Richards (Maine, Hendrickson, and Biener), it is

invalid. I haven't seen so far any standard-backed argument which reasons why

it should be valid. (Besides that it were nice and I concur that, if one

forgets about the value after the loop, it seems to be reasonable if m2 ==

huge(int-do-var) were valid.)



I quickly tried to find the IR request





> 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?



(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.)

Reply via email to