[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|wrong-code                  |diagnostic

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-10 14:45:27 UTC ---
We assume the loop iterates with induction variable a from zero to
((unsigned long)((unsigned)(((int)x->b) - 8) /[ex] 8)) & 536870911 + 1
which is one iteration less than required.

The assumptions made from niter analysis for that to be valid is
((unsigned int) D.2724_6 & 7) == 0 which isn't satisfied (it's 1).

So, technically we run into

  if (flag_unsafe_loop_optimizations)
    niter->assumptions = boolean_true_node;

and assume the above holds true.  We add this assumption here:

  if (!exit_must_be_taken)
    {
      /* If we cannot assume that the exit is taken eventually, record the
         assumptions for divisibility of c.  */
      assumption = fold_build2 (FLOOR_MOD_EXPR, niter_type, c, d);
      assumption = fold_build2 (EQ_EXPR, boolean_type_node,
                                assumption, build_int_cst (niter_type, 0));

thus a proper warning wording would say sth about that reason.

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu.org
         AssignedTo|unassigned at gcc dot       |aoliva at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #5 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-01-16 03:15:35 UTC ---
Looking into it, noncommittal for the time being.

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[aoliva at gcc dot gnu.org]

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

--- Comment #6 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-01-16 08:13:44 UTC ---
Created attachment 22978
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22978
Patch that fixes the problem by discarding too unsafe optimizations

When there's more than one exit from the loop, discarding the assumptions for
the trip count to apply might be regarded as a bit too unsafe, as in this
particular case.  This candidate patch disables the assumption entirely, and
disables the -Wunsafe-loop-optimizations warnings the loop exits would produce,
since -funsafe-loop-optimizations wouldn't affect them any longer.

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-01-16 08:28:36 UTC ---
Created attachment 22979
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22979
Patch that fixes (papers over?) the bug by compensating for the unsafe
assumption

Here's another alternative, that does not discard the unsafe optimization, but
instead attempts to make it safe.  Considering that the computed trip count
should only apply when the counter is exact, and that the other exit is taken
at the next trip, this patch compensates for the too-low trip count by
replacing the exact division by a rounded-up division, which gives us the
correct trip count for this particular loop.

Other cases in which we'd take another exit after more than one iteration would
presumably still fail, but I don't know enough about the loop infrastructure to
tell whether this possibility might arise.

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #22978|0                           |1
        is obsolete|                            |

--- Comment #8 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-01-16 08:32:33 UTC ---
Created attachment 22980
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22980
Patch that fixes the problem by discarding too unsafe optimizations

Oops, the first attachment was missing a refresh on the correct machine.  This
is the version I meant to post.  The one I posted before was was abandoned
approach that I had already started turning into what I meant to post, but that
would print a different warning for the case of multiple exits, rather than
being silent about the optimization it refused to perform.

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #9 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-01-16 08:35:50 UTC ---
Mine, but expecting comments on which approach is preferrable before completing
a patch with a testcase, a ChangeLog and a full regression testing cycle.

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

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

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-19 16:17:50 UTC ---
I think the 2nd patch is more "sound" (that is, it's easier to see what
effects it will have).  Zdenek, do you agree?

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[aoliva at gcc dot gnu.org]

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

--- Comment #11 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-01-28 07:06:50 UTC ---
Richi, which one is “second”?  The second I posted, or the second in the active
attachment list?  (the third posted superseded the first, becoming second in
the list)

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-28 10:57:31 UTC ---
(In reply to comment #11)
> Richi, which one is “second”?  The second I posted, or the second in the active
> attachment list?  (the third posted superseded the first, becoming second in
> the list)

The patch attached to comment #8, disabling the optimization for loops
with more than one exit.

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[rakdver at gcc dot gnu.org]

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

--- Comment #13 from Zdenek Dvorak <rakdver at gcc dot gnu.org> 2011-01-30 18:20:21 UTC ---
(In reply to comment #10)
> I think the 2nd patch is more "sound" (that is, it's easier to see what
> effects it will have).  Zdenek, do you agree?

yes

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-01-31 18:56:33 UTC ---
Created attachment 23185
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23185
gcc46-pr45122.patch

Here is a patch I've bootstrapped/regtested today on x86_64-linux and
i686-linux.  The only regressions on both of those targets are:
+FAIL: gcc.dg/tree-ssa/pr19210-1.c  (test for warnings, line 9)
+FAIL: gcc.dg/tree-ssa/pr19210-1.c  (test for warnings, line 12)
+FAIL: gcc.dg/tree-ssa/pr19210-1.c  (test for warnings, line 24)
+FAIL: gcc.dg/tree-ssa/pr19210-1.c  (test for warnings, line 27)
+FAIL: gcc.dg/tree-ssa/pr19210-2.c  (test for warnings, line 9)
+FAIL: gcc.dg/tree-ssa/pr19210-2.c  (test for warnings, line 12)
+FAIL: gcc.dg/tree-ssa/pr19210-2.c  (test for warnings, line 23)
+FAIL: gcc.dg/tree-ssa/pr19210-2.c  (test for warnings, line 26)
(none of the expected warnings have been emitted in those).

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-01 11:02:44 UTC ---
Ah, the reason why pr19210-* fail is that those loops have non-const/pure call
in it.  So, while single_exit (loop) == exit, loop_only_exit_p (loop, exit)
still returns false.
So, the question is if we really need to give up on -funsafe-loop-optimizations
whenever loop_only_exit_p (loop, exit), or if a single_exit (loop) == exit
test would be sufficient for that.

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[rakdver at gcc dot gnu.org]

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

--- Comment #16 from Zdenek Dvorak <rakdver at gcc dot gnu.org> 2011-02-01 11:27:13 UTC ---
(In reply to comment #15)
> Ah, the reason why pr19210-* fail is that those loops have non-const/pure call
> in it.  So, while single_exit (loop) == exit, loop_only_exit_p (loop, exit)
> still returns false.
> So, the question is if we really need to give up on -funsafe-loop-optimizations
> whenever loop_only_exit_p (loop, exit), or if a single_exit (loop) == exit
> test would be sufficient for that.

I believe single_exit (loop) test would sufficiently match the expectations of
-funsafe-loop-optimizations.  This would misscompile code like

while (b)
  {
    foo(b);
    b -= 8;
  }

in the case that b is not divisible by 8, on the assumption that there are no
nontrivial infinite loops; which seems reasonable.

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23185|0                           |1
        is obsolete|                            |

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-02 13:54:26 UTC ---
Created attachment 23214
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23214
gcc46-pr45122.patch

This patch passed bootstrap/regtest on x86_64-linux and i686-linux, no
regressions this time.

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[aoliva at gcc dot gnu.org]

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

--- Comment #18 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-02-03 06:01:43 UTC ---
Author: aoliva
Date: Thu Feb  3 06:01:40 2011
New Revision: 169781

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169781
Log:
gcc/ChangeLog:
PR tree-optimization/45122
* tree-ssa-loop-niter.c (number_of_iterations_exit): Don't make
unsafe assumptions when there's more than one loop exit.
gcc/testsuite/ChangeLog:
PR tree-optimization/45122
* gcc.dg/tree-ssa/pr45122.c: New.

Added:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/pr45122.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-loop-niter.c

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

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

--- Comment #19 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-02-03 06:06:50 UTC ---
Fixed

[Bug tree-optimization/45122] New: [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[zsojka at seznam dot cz]

With -funsafe-loop-optimizations in flags, pr27285.c FAILs:
FAIL: gcc.c-torture/execute/pr27285.c execution,  -O1 
FAIL: gcc.c-torture/execute/pr27285.c execution,  -O2 
FAIL: gcc.c-torture/execute/pr27285.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/pr27285.c execution,  -O3 -fomit-frame-pointer
-funroll-loops 
FAIL: gcc.c-torture/execute/pr27285.c execution,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/pr27285.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/pr27285.c execution,  -O2 -flto 
FAIL: gcc.c-torture/execute/pr27285.c execution,  -O2 -fwhopr 

Output:
$ gcc -O -funsafe-loop-optimizations pr27285.i -Wunsafe-loop-optimizations
/mnt/svn/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/pr27285.c: In function
'foo':
/mnt/svn/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/pr27285.c:19:10:
warning: assuming that the loop counter does not overflow
[-Wunsafe-loop-optimizations]
/mnt/svn/gcc-trunk/gcc/testsuite/gcc.c-torture/execute/pr27285.c:17:9: warning:
assuming that the loop counter does not overflow [-Wunsafe-loop-optimizations]
$ ./a.out 
Aborted

There is no overflow in the loop.

When compiled with -funsafe-loop-optimizations, the loop is exited when 'b' has
value 1 (that is, e[a] = d[a] & c; is not executed when b == 0). 'b' has values
of 25,17,19,1 (and then the loop ends) - without -funsafe-loop-optimizations,
it has values 25,17,19,1,0.

Even though -funsafe-loop-optimizations is expected to be unsafe, this
behaviour makes it unusable. The loop is finite and the counter doesn't
overflow, so this is a wrong code generated.

Tested revisions:
r162653 - fail
r162456 - OK


-- 
           Summary: [4.6 Regression] -funsafe-loop-optimizations causes
                    FAIL: gcc.c-torture/execute/pr27285.c execution
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[zsojka at seznam dot cz]

------- Comment #1 from zsojka at seznam dot cz  2010-07-29 01:24 -------
"25,17,19,1" should have been "25,17,9,1"


-- 


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

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2010-07-29 01:28 -------
IV-OPTS is choosing b-8 as the IV which seems wrong anyways as that produces
worse code as far as I can tell.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.0


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

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2010-07-29 09:40 -------
Confirmed.  In the original code b doesn't overflow.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-07-29 09:40:17
               date|                            |


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

[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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