[Bug middle-end/52316] New: Loops not optimized away, though result is not used

[Bug middle-end/52316] New: Loops not optimized away, though result is not used

[burnus at gcc dot gnu.org]

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

             Bug #: 52316
           Summary: Loops not optimized away, though result is not used
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


The following program takes 7.5s without optimization and 1.5s with -O1 to
-Ofast. However, for -Ofast, I had expected that the loops are optimized away.
However, that does not seem to happen.

With "ifort -fast", the program takes "0.0s".


Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5ee459a4ddaeab9e#

program hello
implicit none
real :: x, y, n, i, j, t1, t2
call CPU_TIME(t1)
n = 30000.0
j = 1.0
do while (j < n)
i = 1.0
do while (i < n)
x = sin(45.0) * asin(0.5) * sqrt(5.000000) * atan(2.5555)
 i = i + 1.0
  end do
j = j + 1
end do
call CPU_TIME(t2)
print *, t2-t1
!call sleep(10)
end program hello

[Bug middle-end/52316] Loops not optimized away, though result is not used

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-20 15:07:27 UTC ---
Is it sufficiently common to do something that insane though?
We optimize away the dead code in there of course, but the problem is that it
uses a floating point iterator.  I guess our number of iterations analysis just
gives up when the IV is floating, here for known compile time constant init
value and condition operand if both values are sufficiently small we could
compute the number of iterations anyway, but as soon as adding 1 to a floating
point value doesn't change it, for IEEE single when the value is 16777216.0f,
you end up with an endless loop, and that should be honored even for -Ofast.

[Bug middle-end/52316] Loops not optimized away, though result is not used

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-20 15:08:05 UTC ---
can not prove finiteness of loop 1
can not prove finiteness of loop 2

number of iteration analysis does not work on non-integral IVs.

[Bug middle-end/52316] Loops not optimized away, though result is not used

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-02-20
         Depends on|                            |14886
     Ever Confirmed|0                           |1

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-02-20 21:47:44 UTC ---
Related to PR 14886.

[Bug middle-end/52316] Loops with floating-point iteration variables not optimized away, though result is not used

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org
            Summary|Loops not optimized away,   |Loops with floating-point
                   |though result is not used   |iteration variables not
                   |                            |optimized away, though
                   |                            |result is not used

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-21 08:50:57 UTC ---
(In reply to comment #1)
> Is it sufficiently common to do something that insane though?

Well, seemingly, other vendors answer this question with yes. The loop is
optimized away with pathf95, openf90, ifort and crayftn.

Whether it is common? I don't know. Some problems can naturally be expressed
with loops which use floating-point (FP) iteration variables (IV). Though, I
assume that a simple FP count ("r = r + 1.0") should be a bit rarer. The
feature was seemingly popular enough that Fortran 77 introduced real/complex IV
in DO loops.

On the other hand, loops with FP IV are ill defined - and that's the presumably
the reason why Fortran 90 has deleted the feature (FP IV in DO loops). But
using WHILE/DO WHILE one can still use floating-point IV - as one can do in
C/C++.

[Bug middle-end/52316] Loops with floating-point iteration variables not optimized away, though result is not used

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement