This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/81388] [7/8 Regression] Incorrect code generation with -O1


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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |wrong-code
   Last reconfirmed|                            |2017-07-17
                 CC|                            |amker at gcc dot gnu.org
     Ever confirmed|0                           |1
            Summary|Incorrect code generation   |[7/8 Regression] Incorrect
                   |with -O1                    |code generation with -O1
                   |-fno-strict-overflow        |
   Target Milestone|---                         |7.2

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Smells like a niter analysis issue to me.  With -fno-tree-ivcanon I get

  unsigned long ivtmp.3;

  <bb 3> [100.00%]:
  # ivtmp.3_7 = PHI <0(2), ivtmp.3_8(3)>
  bar ();
  ivtmp.3_8 = ivtmp.3_7 + 1;
  if (ivtmp.3_8 != 9223372036854775808)
    goto <bb 3>; [99.00%]
  else
    goto <bb 4>; [1.00%]

GCC 6 computes:

Loop 1 iterates at most -1 times.

while GCC 7 does:

Analyzing # of iterations of loop 1
  exit condition [dst_3(D) + 2, + , 2](no_overflow) < dst_3(D)
  bounds on difference of bases: -2 ... -2
Applying pattern match.pd:1308, generic-match.c:13648
  result:
    # of iterations 9223372036854775807, bounded by 9223372036854775807

so likely (T)P - (T)(P + A) -> -(T) A makes things go downhill here,
producing pointer (unsigned) typed negated 2 and us interpreting that
as unsigned.  The same pattern is in GCC 6 so sth in niter analysis
broke.  -fno-strict-overflow doesn't seem to be necessary btw, -fwrapv
does do the trick as well.

Bin?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]