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


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