[Bug regression/55168] [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0

2012-11-06 Thread hubicka at gcc dot gnu.org


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



Jan Hubicka hubicka at gcc dot gnu.org changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||hubicka at gcc dot gnu.org

 Resolution||FIXED



--- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-06 
14:57:22 UTC ---

Should be fixed now.


[Bug regression/55168] [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0

2012-11-04 Thread hp at gcc dot gnu.org


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



Hans-Peter Nilsson hp at gcc dot gnu.org changed:



   What|Removed |Added



 CC||hubicka at ucw dot cz



--- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-04 
20:26:26 UTC ---

(In reply to comment #2)

 This actually looks like a previously latent issue in predict.c For all but

 estimate_num_iterations_int.  It uses the funny definition of number of

 iterations ...



Honza, the regression went away in (193100:193109].  I see you made a series of

predict.c improvements there.  Is fixing this bug reasonably an expected effect

of those patches, so this PR can be closed?  As opposed to I thought of that

but that bug is expected to still be there, I mean.


[Bug regression/55168] [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0

2012-11-01 Thread hp at gcc dot gnu.org


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



Hans-Peter Nilsson hp at gcc dot gnu.org changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-01 
20:26:05 UTC ---

Found the patch, added co-author to CC.


[Bug regression/55168] [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0

2012-11-01 Thread hubicka at ucw dot cz


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



--- Comment #2 from Jan Hubicka hubicka at ucw dot cz 2012-11-01 20:49:18 UTC 
---

This actually looks like a previously latent issue in predict.c For all but

estimate_num_iterations_int.  It uses the funny definition of number of

iterations (i.e. 0 means that loop will exit at first invocation of the exit

condition and that is what it will be predicted with when nitercst == 1.



Index: predict.c

===

--- predict.c   (revision 193062)

+++ predict.c   (working copy)

@@ -1433,8 +1437,8 @@ predict_loops (void)

 the loop, use it to predict this exit.  */

  else if (n_exits == 1)

{

- nitercst = estimated_stmt_executions_int (loop);

- if (nitercst  0)

+ nitercst = estimated_stmt_executions_int (loop) + 1;

+ if (nitercst = 0)

continue;

  if (nitercst  max)

nitercst = max;