https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83653
Jeffrey A. Law <law at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |RESOLVED CC| |law at redhat dot com See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=72785 Resolution|--- |INVALID --- Comment #10 from Jeffrey A. Law <law at redhat dot com> --- So look for something similar to this: <bb 29> [local count: 96151367]: # i_280 = PHI <0(28), 0(30)> if (i_280 < nr_300) goto <bb 81>; [92.50%] else goto <bb 40>; [7.50%] The subscripts may change, but I think that's what you're looking for. i_280 will be replaced with zero resulting in if (0 < nr_300) true else false And because nr is unsigned that will turn into an equality comparison if (nr_300 != 0) true else false At that point the compiler knows that nr_300 has the value 0 on the false arm of the conditional. Anyway, this isn't a GCC bug. I'll note that it may be worth reviewing pr72785 which is essentially the same issue with misunderstanding how builtin_constant_p works.