[Bug tree-optimization/50439] New: gfortran infinite loop with -floop-interchange

[Bug tree-optimization/50439] New: gfortran infinite loop with -floop-interchange

[pthaugen at gcc dot gnu.org]

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

             Bug #: 50439
           Summary: gfortran infinite loop with -floop-interchange
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: pthaugen@gcc.gnu.org
                CC: bergner@gcc.gnu.org
              Host: powerpc64-linux
            Target: powerpc64-linux
             Build: powerpc64-linux


The following testcase (reduced from cpu2000 benchmark 200.sixtrack, comnul.f)
results in gfortran looping when compiled with -floop-interchange.


C       gfortran -c -O3 -floop-interchange
C-----------------------------------------------------------------------
      subroutine comnul
C-----------------------------------------------------------------------
      implicit real*8 (a-h,o-z)
      parameter(zero=0.0d0,half=0.5d0,one=1.0d0)
      common/secom/rtc(9,18,10,5),rts(9,18,10,5)
      save
C-----------------------------------------------------------------------
      do 110 i1=1,9
        do 110 i2=1,18
          do 110 i3=1,10
            do 110 i4=1,5
              rtc(i1,i2,i3,i4)=zero
              rts(i1,i2,i3,i4)=zero
  110 continue
      return
      end


I stopped it a few times under the debugger and following appeared to be common
chain in backtrace:

#6  0x0000000010d2b694 in Parma_Polyhedra_Library::PIP_Problem::solve
(this=0x11689bd0)
    at /home/pthaugen/src/ppl-0.11.2/src/PIP_Problem.cc:215
#7  0x0000000010d2b984 in Parma_Polyhedra_Library::PIP_Problem::is_satisfiable
(
    this=<optimized out>) at
/home/pthaugen/src/ppl-0.11.2/src/PIP_Problem.cc:649
#8  0x0000000010c1d864 in ppl_PIP_Problem_is_satisfiable (pip=<optimized out>)
    at
/home/pthaugen/src/ppl-0.11.2/interfaces/C/ppl_c_implementation_common.cc:2298
#9  0x0000000010ae2dd4 in ppl_powerset_is_empty (ps=0x115bcb40)
    at /home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-ppl.c:553
#10 0x0000000010adb2ac in build_lexicographical_constraint
(direction=<optimized out>, 
    offset=<optimized out>, tdim=<optimized out>, dim=<optimized out>,
bag=<optimized out>)
    at /home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-dependences.c:396
#11 dependence_polyhedron (original_scattering_p=<optimized out>,
direction=<optimized out>, 
    pdr2=<optimized out>, pdr1=<optimized out>)
    at /home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-dependences.c:479
#12 new_poly_ddr (pdr1=<optimized out>, pdr2=0x114b80c0, direction=-1, 
    original_scattering_p=<optimized out>)
    at /home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-dependences.c:534
#13 0x0000000010adc188 in graphite_legal_transform_dr (pdr2=<optimized out>, 
    pdr1=<optimized out>) at
/home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-dependences.c:631
#14 graphite_legal_transform_bb (pbb2=<optimized out>, pbb1=<optimized out>)
    at /home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-dependences.c:710
#15 graphite_legal_transform (scop=0x114c0200)
    at /home/pthaugen/src/gcc/trunk/gcc/gcc/graphite-dependences.c:729
...


GCC configure:

> ~/install/gcc/trunk/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/pthaugen/install/gcc/trunk/bin/gcc
COLLECT_LTO_WRAPPER=/home/pthaugen/install/gcc/trunk/libexec/gcc/powerpc64-linux/4.7.0/lto-wrapper
Target: powerpc64-linux
Configured with: /home/pthaugen/src/gcc/trunk/gcc/configure
--prefix=/home/pthaugen/install/gcc/trunk --target=powerpc64-linux
--host=powerpc64-linux --build=powerpc64-linux --enable-secureplt
--enable-threads=posix --enable-shared --enable-__cxa_atexit
--with-long-double-128 --enable-decimal-float --disable-alsa --enable-checking
--with-lto --with-as=/home/wschmidt/binutils/install/bin/as
--with-ld=/home/wschmidt/binutils/install/bin/ld
--with-gmp=/home/pthaugen/install/gcc-host-libs
--with-mpfr=/home/pthaugen/install/gcc-host-libs
--with-mpc=/home/pthaugen/install/gcc-host-libs
--with-ppl=/home/pthaugen/install/gcc-host-libs
--with-cloog=/home/pthaugen/install/gcc-host-libs
--with-host-libstdcxx=-Wl,-Bstatic,-L/home/pthaugen/install/gcc-host-libs/lib,-lstdc++,-Bdynamic,-lm
--enable-languages=c,fortran,c++ --disable-bootstrap
Thread model: posix
gcc version 4.7.0 20110913 (experimental) [trunk revision 178814] (GCC) 



Using the following prereq libs:

cloog-ppl-0.15.10
gmp-4.3.2
mpc-0.9
mpfr-3.0.0
ppl-0.11.2


gfortran also loops with -floop-interchange when building cpu2006 benchmark
416.gamess file mpcint.fppized.f.

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-04-05 16:47:32 UTC ---
I verified that the looping occurs inside the PPL library, on a call to
ppl_PIP_Problem_is_satisfiable.  I used ppl_PIP_Problem_ascii_dump to examine
the "pip" variable passed into that routine:

external_space_dim: 32

internal_space_dim: 0

input_cs( 38 )
size 33 0 0 162 0 1 0 9 0 1620 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1
f -RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 162 0 1 0 9 0 1620 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0
f -RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 162 0 1 0 9 0 1620 0 0 0 0 0 0 -162 0 -1 0 -9 0 0 0 0 0 0 -1620 0 0
0 0 0 0 f -RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 -1 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 162 0 1 0 9 0 1620 0 0 0 0 0 0 -162 0 -1 0 -9 0 -1620 0 0 0 0 0 0 0
0 0 0 0 f -RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 1 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 1 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 1 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 1 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V -RPI  -NNC_V -NNC
size 33 -1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V +RPI  -NNC_V -NNC
size 33 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V +RPI  -NNC_V -NNC
size 33 6480 0 -162 0 -1 0 -9 0 -1620 0 0 0 0 0 0 162 0 1 0 9 0 0 0 0 0 0 0 0 0
0 0 0 0 f -RPI_V +RPI  -NNC_V -NNC
size 33 9 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V +RPI  -NNC_V -NNC
size 33 8 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V +RPI  -NNC_V -NNC
size 33 17 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V +RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V +RPI  -NNC_V -NNC
size 33 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V +RPI  -NNC_V -NNC
size 33 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V +RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V +RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V +RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V +RPI  -NNC_V -NNC
size 33 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 f
-RPI_V +RPI  -NNC_V -NNC

first_pending_constraint: 0

status: PARTIALLY_SATISFIABLE

parameters
variables( 0 )

initial_context
0 x 0

control_parameters
CUTTING_STRATEGY_FIRST
PIVOT_ROW_STRATEGY_FIRST

big_parameter_dimension: 18446744073709551615

current_solution: BOTTOM


It appears we'll need to report this to the PPL folks.  I'll get an account
over there and point them to this PR.

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-04-05 17:06:47 UTC ---
Opened a bug report as https://www.cs.unipr.it/mantis/view.php?id=353 against
PPL.

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-04-06 12:09:47 UTC ---
PPL administrator "bagnara" was very helpful in investigating this.

The PPL code is not actually looping, but simply is taking a very long time to
analyze a large input set.  The "PIP problem" has no integer solutions, and
this algorithm has a difficult time determining that.

bagnara also indicated that GCC is not using ppl_PIP_Problem_is_satisfiable
correctly.  Following are his comments:

================================================================================
I have checked the GCC sources. The problem is that
ppl_PIP_Problem_is_satisfiable() and several other functions that involve
algorithms of exponential complexity are used unguarded. The right thing to do
is to use the deterministic timeout facility of the PPL. See
ppl-0.11.2/interfaces/C/tests/weightwatch1.c for an example using the C
interface.

Moreover, there appears to be a design problem in functions such as

/* Checks for integer feasibility: returns true when the powerset
   polyhedron PS has no integer solutions. */
bool
ppl_powerset_is_empty (ppl_Pointset_Powerset_C_Polyhedron_t ps);

The output of such a function should be a tristate: (1) there are integer
solutions; (2) there are no integer solutions; (3) don't know (it was not
possible to decide the question due to time/space limitations).

Alternatively, one could change the name and the specification:

/* Checks for integer feasibility: returns true when the powerset
   polyhedron PS has no integer solutions; returns false if PS
   has integer solutions or the analysis was inconclusive. */
bool
ppl_powerset_is_definitely_empty (ppl_Pointset_Powerset_C_Polyhedron_t ps);

Concerning the implementation, besides using the deterministic timeout facility
of the PPL, you should also use MIP_Problem in addition to PIP_Problem: try the
second one with timeout; upon timeout try the first one. For the specific
testcase, MIP_Problem immediately answers that there are no integer solutions
(it is easy to come up with testcases where MIP_Problem takes a lot of time and
PIP_Problem does much better). 
=============================================================================

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt <wschmidt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dberlin at gcc dot gnu.org,
                   |                            |grosser at gcc dot gnu.org

--- Comment #4 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-04-06 12:13:50 UTC ---
CCing the Graphite maintainers.

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[bagnara at cs dot unipr.it]

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

bagnara at cs dot unipr.it changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bagnara at cs dot unipr.it

--- Comment #5 from bagnara at cs dot unipr.it 2012-04-06 13:49:57 UTC ---
Here is a sketch (100% untested) of what can be done without intervening on the
specification of the function, that is, without giving up.  The original
implementation was inefficient, by the way: if one element of the powerset was
found not to be empty, all the other elements were tested anyway instead of
immediately returning false.  Whether it is best to try the MIP solver or the
PIP solver first is something to be determined experimentally.

bool
ppl_powerset_is_empty (ppl_Pointset_Powerset_C_Polyhedron_t ps)
{
  ppl_dimension_type d;
  ppl_Constraint_System_const_iterator_t first, last;
  ppl_Pointset_Powerset_C_Polyhedron_iterator_t it, end;
  bool has_integer_solutions = false;
  /* FIXME: the following values should be determined experimentally. */
  unsigned weight = 20000;
  unsigned weight_increment = 5000;
  unsigned timeouts;

  if (ppl_Pointset_Powerset_C_Polyhedron_is_empty (ps))
    return true;

  while (true)
    {
      ppl_Pointset_Powerset_C_Polyhedron_space_dimension (ps, &d);
      ppl_new_Constraint_System_const_iterator (&first);
      ppl_new_Constraint_System_const_iterator (&last);
      ppl_new_Pointset_Powerset_C_Polyhedron_iterator (&it);
      ppl_new_Pointset_Powerset_C_Polyhedron_iterator (&end);

      timeouts = 0;
      for (ppl_Pointset_Powerset_C_Polyhedron_iterator_begin (ps, it),
             ppl_Pointset_Powerset_C_Polyhedron_iterator_end (ps, end);
           !ppl_Pointset_Powerset_C_Polyhedron_iterator_equal_test (it, end);
           ppl_Pointset_Powerset_C_Polyhedron_iterator_increment (it))
        {
          ppl_const_Polyhedron_t ph;
          ppl_const_Constraint_System_t pcs;
          ppl_Linear_Expression_t le;
          ppl_MIP_Problem_t mip;
          int ppl_result;

          ppl_Pointset_Powerset_C_Polyhedron_iterator_dereference (it, &ph);

          ppl_Polyhedron_get_constraints (ph, &pcs);

          /* Try with the MIP solver first. */
          ppl_new_Linear_Expression (&le);
          ppl_new_MIP_Problem (&mip, d, pcs, le,
                               PPL_OPTIMIZATION_MODE_MAXIMIZATION);

          ppl_set_deterministic_timeout (weight);
          ppl_result = ppl_MIP_Problem_is_satisfiable (mip);
          ppl_reset_deterministic_timeout ();
          ppl_delete_MIP_Problem (mip);

          if (ppl_result == PPL_TIMEOUT_EXCEPTION)
            {
              /* Deterministic timeout expired: try with the PIP solver. */
              ppl_PIP_Problem_t pip;

              ppl_Constraint_System_begin (pcs, first);
              ppl_Constraint_System_end (pcs, last);

              ppl_new_PIP_Problem_from_constraints (&pip, d, first, last, 0,
                                                    NULL);
              ppl_set_deterministic_timeout (weight);
              ppl_result = ppl_PIP_Problem_is_satisfiable (pip);
              ppl_reset_deterministic_timeout ();
              ppl_delete_PIP_Problem (pip);
              if (ppl_result == PPL_TIMEOUT_EXCEPTION)
                ++timeouts;
              else if (ppl_result > 0)
                {
                  has_integer_solutions = true;
                  break;
                }
            }
          else if (ppl_result > 0)
            {
              has_integer_solutions = true;
              break;
            }
        }

      ppl_delete_Constraint_System_const_iterator (first);
      ppl_delete_Constraint_System_const_iterator (last);
      ppl_delete_Pointset_Powerset_C_Polyhedron_iterator (it);
      ppl_delete_Pointset_Powerset_C_Polyhedron_iterator (end);

      /* If there were no timeouts, then we have the answer. */
      if (timeouts == 0)
        return !has_integer_solutions;

      if (weight <= UINT_MAX - weight_increment)
        weight += weight_increment;
    }
}

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[bagnara at cs dot unipr.it]

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

--- Comment #6 from bagnara at cs dot unipr.it 2012-04-06 14:04:09 UTC ---
Created attachment 27104
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27104
Example alternative implementation for ppl_powerset_is_empty ()

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[bagnara at cs dot unipr.it]

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

--- Comment #7 from bagnara at cs dot unipr.it 2012-04-06 14:06:38 UTC ---
(In reply to comment #5)
> Here is a sketch (100% untested) of what can be done without intervening [...]

So untested that I forgot to declare to the MIP problem that all variables are
integer.  I have attached a file (example1.c) where this is corrected.

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-04-06 19:08:09 UTC ---
Roberto, I tried your patch, but got the following error:

PPL error code -8
PPL C interface error:
ppl_set_deterministic_timeout: the PPL Watchdog library is not enabled.

I assume this is a configuration feature for PPL that GCC doesn't enable.  I
wonder if there are portability concerns here.  Graphite maintainers, can you
please comment?  I'm afraid I know practically nothing about Graphite.

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[bagnara at cs dot unipr.it]

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

--- Comment #9 from bagnara at cs dot unipr.it 2012-04-06 19:17:25 UTC ---
Pity it is not enabled: it definitely should.

Note that the addition of the deterministic timeout facility of the PPL was
solicited by the Graphite people.  Previously the PPL only supported timeouts
based on wall-clock time, which resulted in non-determinism that is
unacceptable in GCC.

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-04-09 16:03:27 UTC ---
FWIW, my original compile did eventually complete (after 31.5 hours)...

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |tkoenig at gcc dot gnu.org
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2020-06-01

--- Comment #11 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
I just stumbled across this, and it seems fixed.

Commit the test case and close?

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[pthaugen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439

pthaugen at gcc dot gnu.org changed:

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

--- Comment #12 from pthaugen at gcc dot gnu.org ---
I can no longer produce the condition either, with the reduced testcase or
416.gamess. So if you think the correct thing to do is close this bug I'm fine
with that.

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Kथà¤nig <tkoenig@gcc.gnu.org>:

https://gcc.gnu.org/g:905ba62ec96f8469c1085861d9ceec58fbee5709

commit r11-1018-g905ba62ec96f8469c1085861d9ceec58fbee5709
Author: Thomas Koenig <tkoenig@gcc.gnu.org>
Date:   Sun Jun 7 10:43:54 2020 +0200

    Added test case for a PR which has been fixed in the meantime.

    gcc/testsuite/ChangeLog:

            PR tree-optimization/50439
            * gfortran.dg/loop_interchange_2.f: New test.

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Closing, then.  If this should ever regress, we'll see it.