* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
@ 2009-11-21 16:26 ` kargl at gcc dot gnu dot org
2009-11-21 17:33 ` toon at moene dot org
` (27 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-11-21 16:26 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from kargl at gcc dot gnu dot org 2009-11-21 16:26 -------
(In reply to comment #0)
> To illustrate this with a simple example:
>
> DO I = M1, M2, M3
> B(I) = A(I)
> ENDDO
>
> would be most easily, and atraightforwardly, implemented as follows:
>
> IF (M3 > 0 .AND. M1 < M2) GOTO 200 ! Loop executed zero times
> IF (M3 < 0 .AND. M1 > M2) GOTO 200 ! Ditto
First, I just woke up 10 minutes ago and still have 1/2 of cup of coffee,
but the logic above looks wrong.
do i = 1, 2, 1
print *, i
end do
should produce
1
2
Here, we have m1 = 1, m2 = 2, m3 = 1
> IF (M3 > 0 .AND. M1 < M2) GOTO 200 ! Loop executed zero times
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
2009-11-21 16:26 ` [Bug fortran/42131] " kargl at gcc dot gnu dot org
@ 2009-11-21 17:33 ` toon at moene dot org
2009-11-21 18:31 ` tkoenig at gcc dot gnu dot org
` (26 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: toon at moene dot org @ 2009-11-21 17:33 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
2009-11-21 16:26 ` [Bug fortran/42131] " kargl at gcc dot gnu dot org
2009-11-21 17:33 ` toon at moene dot org
@ 2009-11-21 18:31 ` tkoenig at gcc dot gnu dot org
2009-11-21 19:24 ` rguenth at gcc dot gnu dot org
` (25 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2009-11-21 18:31 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from tkoenig at gcc dot gnu dot org 2009-11-21 18:31 -------
(In reply to comment #2)
> 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
As written, this executes the assignment one time too many.
The last but one line should read:
IF (ITEMP > 0) GOTO 100
What we generate has the test at the bottom of the loop,
whereas 8.1.6.4.2 puts the test of the iteration count first.
What we could generate, IMHO, is
read (*,*) m1, m2, m3
ITEMP = (M2 - M1 + M3) / M3 ! Temporary loop counter
print *,'itemp=',itemp
I = M1
100 CONTINUE
IF (ITEMP <= 0) GOTO 200
print *,i
I = I + M3 ! Adjust DO loop variable
ITEMP = ITEMP - 1 ! Adjust internal loop counter
GOTO 100
200 CONTINUE
print *,"final : i = ", i
end
Does this have any drawbacks? Would the middle end recognize this for
vectorization and loop unrolling?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (2 preceding siblings ...)
2009-11-21 18:31 ` tkoenig at gcc dot gnu dot org
@ 2009-11-21 19:24 ` rguenth at gcc dot gnu dot org
2009-11-21 21:41 ` toon at moene dot org
` (24 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-11-21 19:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-21 19:24 -------
The middle-end prefers do { } while () loop style so it knows the loop is
always executed. It even tries to transform other loop forms into this by
copying the loop header. So if the FE already can cheaply produce this
it would be prefered.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (3 preceding siblings ...)
2009-11-21 19:24 ` rguenth at gcc dot gnu dot org
@ 2009-11-21 21:41 ` toon at moene dot org
2009-11-21 23:07 ` tkoenig at gcc dot gnu dot org
` (23 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: toon at moene dot org @ 2009-11-21 21:41 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from toon at moene dot org 2009-11-21 21:40 -------
> The middle-end prefers do { } while () loop style so it knows the loop is
> always executed.
And the Fortran Standard describes the loops being built (by compilers) just
so:
1. First you determine what is m1, m2, m3
2. Then you initialize the do loop counter with m1
3. Then you determine the loop count (m2 - m1 + m3) / m3
4. If the loop count is zero or negative, you skip the loop
5. Otherwise, you traverse the loop body at least once.
Or, to return to our example (and fix the mistake Thomas Koenig noted):
DO I = M1, M2, M3
B(I) = A(I)
ENDDO
turns into
ITEMP = (M2 - M1 + M3) / M3 ! The iteration count
IF (ITEMP <= 0) GOTO 200 ! Past this point, the loop is executed
I = M1 ! at least once.
100 CONTINUE
B(I) = A(I)
ITEMP = ITEMP - 1
I = I + M3
IF (ITEMP > 0) GOTO 100
200 CONTINUE
therewith following the (normative) text of the Standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (4 preceding siblings ...)
2009-11-21 21:41 ` toon at moene dot org
@ 2009-11-21 23:07 ` tkoenig at gcc dot gnu dot org
2009-11-21 23:24 ` rguenther at suse dot de
` (22 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2009-11-21 23:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from tkoenig at gcc dot gnu dot org 2009-11-21 23:07 -------
Created an attachment (id=19076)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19076&action=view)
proposed patch
This patch generates
D.1336 = m1;
D.1337 = m2;
D.1338 = m3;
i = D.1336;
if (D.1338 > 0)
{
if (D.1337 < D.1336) goto L.2;
}
else
{
if (D.1337 > D.1336) goto L.2;
}
countm1.1 = (character(kind=4)) (D.1337 - D.1336) / (character(kind=4))
D.1338;
while (1)
{
{
Is this better, or did I overlook anything?
--
tkoenig at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (5 preceding siblings ...)
2009-11-21 23:07 ` tkoenig at gcc dot gnu dot org
@ 2009-11-21 23:24 ` rguenther at suse dot de
2009-11-21 23:42 ` tkoenig at gcc dot gnu dot org
` (21 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenther at suse dot de @ 2009-11-21 23:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from rguenther at suse dot de 2009-11-21 23:23 -------
Subject: Re: Weird translation of DO loops
On Sat, 21 Nov 2009, tkoenig at gcc dot gnu dot org wrote:
> ------- Comment #6 from tkoenig at gcc dot gnu dot org 2009-11-21 23:07 -------
> Created an attachment (id=19076)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19076&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19076&action=view)
> proposed patch
>
> This patch generates
>
> D.1336 = m1;
> D.1337 = m2;
> D.1338 = m3;
> i = D.1336;
> if (D.1338 > 0)
> {
> if (D.1337 < D.1336) goto L.2;
> }
> else
> {
> if (D.1337 > D.1336) goto L.2;
> }
> countm1.1 = (character(kind=4)) (D.1337 - D.1336) / (character(kind=4))
> D.1338;
> while (1)
> {
> {
>
> Is this better, or did I overlook anything?
That's better.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (6 preceding siblings ...)
2009-11-21 23:24 ` rguenther at suse dot de
@ 2009-11-21 23:42 ` tkoenig at gcc dot gnu dot org
2009-11-22 10:21 ` toon at moene dot org
` (20 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2009-11-21 23:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from tkoenig at gcc dot gnu dot org 2009-11-21 23:42 -------
Subject: Re: Weird translation of DO loops
On Sat, 2009-11-21 at 23:23 +0000, rguenther at suse dot de wrote:
> That's better.
Not yet correct, though, this causes regressions for
program main
character*9 line
line = ' 10 1 -3'
read (unit=line,fmt='(3I3)') m1, m2, m3
print *,m1,m2,m3
do i=m1, m2, m3
print *,i
end do
end program main
I'll have to look some more.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (7 preceding siblings ...)
2009-11-21 23:42 ` tkoenig at gcc dot gnu dot org
@ 2009-11-22 10:21 ` toon at moene dot org
2009-11-22 19:04 ` burnus at gcc dot gnu dot org
` (19 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: toon at moene dot org @ 2009-11-22 10:21 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from toon at moene dot org 2009-11-22 10:20 -------
Richard wondered about this earlier:
> countm1.1 = (character(kind=4)) (D.1337 - D.1336) / (character(kind=4))
D.1338;
but perhaps it's better to asked explicitly:
Where does the "(character(kind=4))" comes from in this (obvious) integer
computation ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (8 preceding siblings ...)
2009-11-22 10:21 ` toon at moene dot org
@ 2009-11-22 19:04 ` burnus at gcc dot gnu dot org
2009-11-23 21:48 ` tkoenig at gcc dot gnu dot org
` (18 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: burnus at gcc dot gnu dot org @ 2009-11-22 19:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from burnus at gcc dot gnu dot org 2009-11-22 19:04 -------
"Do loop with HUGE stepsize":
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/63348a0461ccf3e0
> Current status is that g77 prints 0 and gfortran prints 1.
To add: NAG f95, g95, sunf95, and ifort print "1" while open64 and pathf95
print "0".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (9 preceding siblings ...)
2009-11-22 19:04 ` burnus at gcc dot gnu dot org
@ 2009-11-23 21:48 ` tkoenig at gcc dot gnu dot org
2009-11-24 18:04 ` toon at moene dot org
` (17 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2009-11-23 21:48 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from tkoenig at gcc dot gnu dot org 2009-11-23 21:48 -------
Created an attachment (id=19104)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19104&action=view)
another proposed patch
Here's another proposed patch, but there is a problem with it.
If we calculate (m2 - m1 + m3)/m3 with signed types, then this will overflow,
for example, for
do i=-huge(i),huge(i),2
The current implementation gets around that by doing the addition and division
unsigned, then dividing unsigned as well. For this, there have to be two
cases, one for m3>0 and one for m3<0, which is what we generate
at the moment.
Possible solutions:
- get rid of the loop counter altogether
- perform the intermediate calculation with increased precision, if
available
- Multiply everything by the sign of m3 before doing the unsigned
math (which is what we do now, except that we hide this behind an
if)
- Trust two's complement arithmetic and hope that overflows don't trap
(not, in general, a good idea)
Any tricks I have missed?
--
tkoenig at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #19076|0 |1
is obsolete| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (10 preceding siblings ...)
2009-11-23 21:48 ` tkoenig at gcc dot gnu dot org
@ 2009-11-24 18:04 ` toon at moene dot org
2009-11-26 21:56 ` tkoenig at gcc dot gnu dot org
` (16 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: toon at moene dot org @ 2009-11-24 18:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from toon at moene dot org 2009-11-24 18:03 -------
> Any tricks I have missed?
Yes - we could provide for loop versioning in the front end.
I.e., generate code like:
IF (M3 > 0) THEN
... compute loop count ...
... perform loop ...
ELSE IF (M3 < 0) THEN
... compute loop count ...
... perform loop ...
ELSE
ABORT "M3 MUST NOT BE ZERO"
ENDIF
And then hope that Value Range Propagation and InterProcedural Analysis will
throw away 2 of the 3 branches of this loop because it is able to determine the
sign of M3.
<evil grin>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (11 preceding siblings ...)
2009-11-24 18:04 ` toon at moene dot org
@ 2009-11-26 21:56 ` tkoenig at gcc dot gnu dot org
2009-11-26 22:07 ` kargl at gcc dot gnu dot org
` (15 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2009-11-26 21:56 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from tkoenig at gcc dot gnu dot org 2009-11-26 21:56 -------
Created an attachment (id=19159)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19159&action=view)
patch that implements the multiplication idea
This generates
if (D.1339 > 0)
{
if (D.1338 < D.1337)
{
goto L.2;
}
else
{
step_sign.2 = 1;
}
}
else
{
if (D.1338 > D.1337)
{
goto L.2;
}
else
{
step_sign.2 = -1;
}
}
countm1.1 = (((character(kind=4)) D.1338 - (character(kind=4)) D.1337) *
(character(kind=4)) step_sign.2) / (character(kind=4)) (step_sign.2 * D.1339);
implementing the multiplication idea outlined above, and passes at
least do_3.F90.
Better?
--
tkoenig at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #19104|0 |1
is obsolete| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (12 preceding siblings ...)
2009-11-26 21:56 ` tkoenig at gcc dot gnu dot org
@ 2009-11-26 22:07 ` kargl at gcc dot gnu dot org
2009-11-26 23:43 ` tkoenig at gcc dot gnu dot org
` (14 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-11-26 22:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from kargl at gcc dot gnu dot org 2009-11-26 22:07 -------
(In reply to comment #13)
> }
> countm1.1 = (((character(kind=4)) D.1338 - (character(kind=4)) D.1337) *
> (character(kind=4)) step_sign.2) / (character(kind=4)) (step_sign.2 * D.1339);
>
> implementing the multiplication idea outlined above, and passes at
> least do_3.F90.
>
> Better?
Looks much better than the current situation. Is there a valid
reason for the character(kind=4) casts? I would have thought
that this should be a integer(kind=4).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (13 preceding siblings ...)
2009-11-26 22:07 ` kargl at gcc dot gnu dot org
@ 2009-11-26 23:43 ` tkoenig at gcc dot gnu dot org
2009-11-27 8:29 ` burnus at gcc dot gnu dot org
` (13 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2009-11-26 23:43 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from tkoenig at gcc dot gnu dot org 2009-11-26 23:43 -------
(In reply to comment #14)
> Looks much better than the current situation. Is there a valid
> reason for the character(kind=4) casts? I would have thought
> that this should be a integer(kind=4).
The casts are generated for unsigned types, which we need because
the difference between two integers can be larger than huge(integer).
Beats me why this is character instead of unsigned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (14 preceding siblings ...)
2009-11-26 23:43 ` tkoenig at gcc dot gnu dot org
@ 2009-11-27 8:29 ` burnus at gcc dot gnu dot org
2009-11-27 9:47 ` rguenther at suse dot de
` (12 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: burnus at gcc dot gnu dot org @ 2009-11-27 8:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from burnus at gcc dot gnu dot org 2009-11-27 08:29 -------
(In reply to comment #12)
> > Any tricks I have missed?
> Yes - we could provide for loop versioning in the front end.
[...]
> ELSE
> ABORT "M3 MUST NOT BE ZERO"
> ENDIF
Just for completeness a zeroness check is done for -fcheck=do:
Fortran runtime error: DO step value is zero
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (15 preceding siblings ...)
2009-11-27 8:29 ` burnus at gcc dot gnu dot org
@ 2009-11-27 9:47 ` rguenther at suse dot de
2009-11-27 9:48 ` rguenther at suse dot de
` (11 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenther at suse dot de @ 2009-11-27 9:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from rguenther at suse dot de 2009-11-27 09:47 -------
Subject: Re: Weird translation of DO loops
On Thu, 26 Nov 2009, tkoenig at gcc dot gnu dot org wrote:
> ------- Comment #13 from tkoenig at gcc dot gnu dot org 2009-11-26 21:56 -------
> Created an attachment (id=19159)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19159&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19159&action=view)
> patch that implements the multiplication idea
>
> This generates
>
> if (D.1339 > 0)
> {
> if (D.1338 < D.1337)
> {
> goto L.2;
> }
> else
> {
> step_sign.2 = 1;
> }
> }
> else
> {
> if (D.1338 > D.1337)
> {
> goto L.2;
> }
> else
> {
> step_sign.2 = -1;
> }
> }
> countm1.1 = (((character(kind=4)) D.1338 - (character(kind=4)) D.1337) *
> (character(kind=4)) step_sign.2) / (character(kind=4)) (step_sign.2 * D.1339);
>
> implementing the multiplication idea outlined above, and passes at
> least do_3.F90.
>
> Better?
Unfortunately the conditional step_sign.2 is as bad as a conditional
countm1.1 for optimization. The above might even be worse than
the original.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (16 preceding siblings ...)
2009-11-27 9:47 ` rguenther at suse dot de
@ 2009-11-27 9:48 ` rguenther at suse dot de
2009-11-28 15:16 ` tkoenig at gcc dot gnu dot org
` (10 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenther at suse dot de @ 2009-11-27 9:48 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from rguenther at suse dot de 2009-11-27 09:48 -------
Subject: Re: Weird translation of DO loops
On Thu, 26 Nov 2009, tkoenig at gcc dot gnu dot org wrote:
> ------- Comment #15 from tkoenig at gcc dot gnu dot org 2009-11-26 23:43 -------
> (In reply to comment #14)
>
> > Looks much better than the current situation. Is there a valid
> > reason for the character(kind=4) casts? I would have thought
> > that this should be a integer(kind=4).
>
> The casts are generated for unsigned types, which we need because
> the difference between two integers can be larger than huge(integer).
> Beats me why this is character instead of unsigned.
Well, in that case you can as well rely on twos-complement
arithmetic and avoid all the overflow issues?
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (17 preceding siblings ...)
2009-11-27 9:48 ` rguenther at suse dot de
@ 2009-11-28 15:16 ` tkoenig at gcc dot gnu dot org
2009-11-30 7:31 ` tkoenig at gcc dot gnu dot org
` (9 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2009-11-28 15:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from tkoenig at gcc dot gnu dot org 2009-11-28 15:16 -------
(In reply to comment #18)
> Well, in that case you can as well rely on twos-complement
> arithmetic and avoid all the overflow issues?
This is difficult without if statements or MAX_EXPR and MIN_EXPR,
because I need to cover both a<b and b<a.
I think I will go for calculating the difference in a larger size,
if any is available, and a special case for do loops using the largest
integer size.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (18 preceding siblings ...)
2009-11-28 15:16 ` tkoenig at gcc dot gnu dot org
@ 2009-11-30 7:31 ` tkoenig at gcc dot gnu dot org
2009-11-30 10:10 ` rguenther at suse dot de
` (8 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2009-11-30 7:31 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from tkoenig at gcc dot gnu dot org 2009-11-30 07:31 -------
Created an attachment (id=19182)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19182&action=view)
Patch that works for unrolling
It also passes do_3.F90.
I'll submit just in time for meeting the phase 4 deadline tonight (hopefully).
--
tkoenig at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #19159|0 |1
is obsolete| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (19 preceding siblings ...)
2009-11-30 7:31 ` tkoenig at gcc dot gnu dot org
@ 2009-11-30 10:10 ` rguenther at suse dot de
2009-11-30 19:16 ` tkoenig at gcc dot gnu dot org
` (7 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenther at suse dot de @ 2009-11-30 10:10 UTC (permalink / raw)
To: gcc-bugs
------- Comment #21 from rguenther at suse dot de 2009-11-30 10:10 -------
Subject: Re: Weird translation of DO loops
On Mon, 30 Nov 2009, tkoenig at gcc dot gnu dot org wrote:
> ------- Comment #20 from tkoenig at gcc dot gnu dot org 2009-11-30 07:31 -------
> Created an attachment (id=19182)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19182&action=view)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19182&action=view)
> Patch that works for unrolling
>
> It also passes do_3.F90.
>
> I'll submit just in time for meeting the phase 4 deadline tonight (hopefully).
If it works for unrolling it must be indeed better. Though:
+ /* Calculate SIGN (1,step) */
+
+ tmp = fold_build2 (RSHIFT_EXPR, type, step,
+ build_int_cst (type,
+ TYPE_PRECISION (type) - 1));
+
+ tmp = fold_build2 (MULT_EXPR, type, tmp,
+ build_int_cst (type, 2));
+
+ step_sign = fold_build2 (PLUS_EXPR, type, tmp,
+ fold_convert (type, integer_one_node));
the "sign" for unsigned steps is always 1, you don't seem to account
for unsignedness? Note that I believe generating
step_sign = fold_build3 (fold_build2 (LT_EXPR, boolean_type_node,
step, build_int_cst (TREE_TYPE (step),
0)),
build_int_cst (type, -1), build_int_cst (type, 1));
is better as that allows more freedom for fold and efficient expansion
for the target. Just double-check that it also works for the
unrolling ;)
Thanks,
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (20 preceding siblings ...)
2009-11-30 10:10 ` rguenther at suse dot de
@ 2009-11-30 19:16 ` tkoenig at gcc dot gnu dot org
2009-11-30 20:19 ` jvdelisle at gcc dot gnu dot org
` (6 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2009-11-30 19:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from tkoenig at gcc dot gnu dot org 2009-11-30 19:15 -------
(In reply to comment #21)
> the "sign" for unsigned steps is always 1, you don't seem to account
> for unsignedness?
(Un)fortunately, there are no unsigned varaibles in Fortran.
> Note that I believe generating
>
> step_sign = fold_build3 (fold_build2 (LT_EXPR, boolean_type_node,
> step, build_int_cst (TREE_TYPE (step),
> 0)),
> build_int_cst (type, -1), build_int_cst (type, 1));
>
> is better as that allows more freedom for fold and efficient expansion
> for the target. Just double-check that it also works for the
> unrolling ;)
That doesn't work (something about fold_build3 needing five arguments
instead of three), so think I'll submit my patch "as is".
Thanks for your comments!
> Thanks,
> Richard.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (21 preceding siblings ...)
2009-11-30 19:16 ` tkoenig at gcc dot gnu dot org
@ 2009-11-30 20:19 ` jvdelisle at gcc dot gnu dot org
2009-11-30 20:36 ` tkoenig at gcc dot gnu dot org
` (5 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2009-11-30 20:19 UTC (permalink / raw)
To: gcc-bugs
------- Comment #23 from jvdelisle at gcc dot gnu dot org 2009-11-30 20:19 -------
Thomas, Ido not have email access at the moment.
I reviewed your patch and it is approved for trunk.
Thanks for the work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (22 preceding siblings ...)
2009-11-30 20:19 ` jvdelisle at gcc dot gnu dot org
@ 2009-11-30 20:36 ` tkoenig at gcc dot gnu dot org
2009-11-30 21:01 ` tkoenig at gcc dot gnu dot org
` (4 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2009-11-30 20:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #24 from tkoenig at gcc dot gnu dot org 2009-11-30 20:35 -------
Subject: Bug 42131
Author: tkoenig
Date: Mon Nov 30 20:35:41 2009
New Revision: 154839
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154839
Log:
2009-11-30 Thomas Koenig <tkoenig@gcc.gnu.org>
PR fortran/42131
* trans-stmt.c (gfc_trans_do): Calculate loop count
without if statements.
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (23 preceding siblings ...)
2009-11-30 20:36 ` tkoenig at gcc dot gnu dot org
@ 2009-11-30 21:01 ` tkoenig at gcc dot gnu dot org
2009-12-01 9:42 ` rguenther at suse dot de
` (3 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2009-11-30 21:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #25 from tkoenig at gcc dot gnu dot org 2009-11-30 21:01 -------
Fixed on trunk. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (24 preceding siblings ...)
2009-11-30 21:01 ` tkoenig at gcc dot gnu dot org
@ 2009-12-01 9:42 ` rguenther at suse dot de
2009-12-01 18:33 ` jb at gcc dot gnu dot org
` (2 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenther at suse dot de @ 2009-12-01 9:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #26 from rguenther at suse dot de 2009-12-01 09:42 -------
Subject: Re: Weird translation of DO loops
On Mon, 30 Nov 2009, tkoenig at gcc dot gnu dot org wrote:
>
>
> ------- Comment #22 from tkoenig at gcc dot gnu dot org 2009-11-30 19:15 -------
> (In reply to comment #21)
>
> > the "sign" for unsigned steps is always 1, you don't seem to account
> > for unsignedness?
>
> (Un)fortunately, there are no unsigned varaibles in Fortran.
>
> > Note that I believe generating
> >
> > step_sign = fold_build3 (fold_build2 (LT_EXPR, boolean_type_node,
> > step, build_int_cst (TREE_TYPE (step),
> > 0)),
> > build_int_cst (type, -1), build_int_cst (type, 1));
> >
> > is better as that allows more freedom for fold and efficient expansion
> > for the target. Just double-check that it also works for the
> > unrolling ;)
>
> That doesn't work (something about fold_build3 needing five arguments
> instead of three), so think I'll submit my patch "as is".
Ah, of course ... more like
step_sign = fold_build3 (COND_EXPR, type,
fold_build2 (LT_EXPR, boolean_type_node,
step, build_int_cst (TREE_TYPE (step), 0)),
build_int_cst (type, -1), build_int_cst (type, 1));
Which still would be prefered IMHO.
Richard.
> Thanks for your comments!
> > Thanks,
> > Richard.
> >
>
>
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (25 preceding siblings ...)
2009-12-01 9:42 ` rguenther at suse dot de
@ 2009-12-01 18:33 ` jb at gcc dot gnu dot org
2009-12-02 9:23 ` jb at gcc dot gnu dot org
2009-12-04 14:24 ` dominiq at lps dot ens dot fr
28 siblings, 0 replies; 30+ messages in thread
From: jb at gcc dot gnu dot org @ 2009-12-01 18:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #27 from jb at gcc dot gnu dot org 2009-12-01 18:32 -------
Subject: Bug 42131
Author: jb
Date: Tue Dec 1 18:32:37 2009
New Revision: 154876
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154876
Log:
PR fortran/42131 Sign test using ternary operator
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (26 preceding siblings ...)
2009-12-01 18:33 ` jb at gcc dot gnu dot org
@ 2009-12-02 9:23 ` jb at gcc dot gnu dot org
2009-12-04 14:24 ` dominiq at lps dot ens dot fr
28 siblings, 0 replies; 30+ messages in thread
From: jb at gcc dot gnu dot org @ 2009-12-02 9:23 UTC (permalink / raw)
To: gcc-bugs
------- Comment #28 from jb at gcc dot gnu dot org 2009-12-02 09:23 -------
Subject: Bug 42131
Author: jb
Date: Wed Dec 2 09:22:50 2009
New Revision: 154900
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154900
Log:
Typo in ChangeLog entry for PR fortran/42131
Modified:
trunk/gcc/fortran/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/42131] Weird translation of DO loops
2009-11-21 13:58 [Bug fortran/42131] New: Weird translation of DO loops rguenth at gcc dot gnu dot org
` (27 preceding siblings ...)
2009-12-02 9:23 ` jb at gcc dot gnu dot org
@ 2009-12-04 14:24 ` dominiq at lps dot ens dot fr
28 siblings, 0 replies; 30+ messages in thread
From: dominiq at lps dot ens dot fr @ 2009-12-04 14:24 UTC (permalink / raw)
To: gcc-bugs
------- Comment #29 from dominiq at lps dot ens dot fr 2009-12-04 14:24 -------
AFAICT the inner loop of PR42108 is still unrolled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
^ permalink raw reply [flat|nested] 30+ messages in thread