From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32112 invoked by alias); 21 Nov 2009 17:33:51 -0000 Received: (qmail 32047 invoked by uid 48); 21 Nov 2009 17:33:38 -0000 Date: Sat, 21 Nov 2009 17:33:00 -0000 Message-ID: <20091121173338.32046.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/42131] Weird translation of DO loops In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "toon at moene dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg01800.txt.bz2 ------- Comment #2 from toon at moene dot org 2009-11-21 17:33 ------- Sorry, Steve - my mistake. The original message should have been: To illustrate this with a simple example: DO I = M1, M2, M3 B(I) = A(I) ENDDO would be most easily, and straightforwardly, implemented as follows: IF (M3 > 0 .AND. M1 > M2) GOTO 200 ! Loop executed zero times IF (M3 < 0 .AND. M1 < M2) GOTO 200 ! Ditto ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop counter I = M1 100 CONTINUE B(I) = A(I) ITEMP = ITEMP - 1 ! Adjust internal loop counter I = I + M3 ! Adjust DO loop variable IF (ITEMP >= 0) GOTO 100 200 CONTINUE I hope this makes clear what's weird about the way the Fortran Frontend does it now. The example code follows the Standard as close as possible (it only doesn't check that m3 isn't zero, which isn't allowed), except that I follow Note 8.7 instead of the reasoning in the "sequence of steps". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131