https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69320
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-01-17
Ever confirmed|0 |1
--- Comment #1 from Jeffrey A. Law <law at redhat dot com> ---
THanks for the .i and .s files. The one thing that is missing that would help
a lot is the compiler flags used. Without that information we have to guess
and with the number of flags, it's easy to guess wrong.
Thankfully something seems to have recorded the flags and embedded them into
your assembly output files. So was able to use those. Please if you file
future reports make sure to include the compiler flags too.
Anyway, it's a mis-compilation of svq1`_encode_plane. It's quite strange
though.
So we have:
_373 = _370 <= _372;
best_374 = (int) _373;
That establishes best_374 as having a boolean range, even though it's an
integer variable.
That's important because later we see a conditional on best_374 and infer its
value on both arms of the conditional.
So if we look further we have:
;; basic block 444, loop depth 2, count 0, freq 1, maybe hot
;; prev block 443, next block 445, flags: (NEW, REACHABLE)
;; pred: 441 [71.0%] (FALSE_VALUE,EXECUTABLE)
;; 440 [50.0%] (FALSE_VALUE,EXECUTABLE)
if (best_374 == 1)
goto <bb 445>;
else
goto <bb 452>;
If we follow the TRUE arm where we know best_374 will have the value 1 we have
this path (there's others, this is just one):
445->445->446->461->451->462->453
Where BB453 looks like:
# best_3287 = PHI <0(443), best_374(462), 0(429)>
After my patch that statement looks like:
# best_3287 = PHI <0(443), 0(461), 0(429)>
Yow! That's clearly not right.
Still digging, but that looks like a real problem, and hopefully it's the
mis-compilation we're looking for. Certainly if I block the propagation of
best_374 via a dbg-counter the resulting code passes its internal tests.
