https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96397
--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> --- if I read this right, the basic premise is: x = p1 - 4, so if x + 8 doesn't overflow, then p1 - 4 couldn't have underflowed, and therefore x must be > p1 which is a little more complicated than just back propagation. Firstly, we have to understand that builtin_add_overflow is actually x + 8 and that the IMAG_PART is in fact the overflow flag. we currently understand that the IMAG_PART is a boolean, but we dont "understand" the add yet. so we'll eventually start treating those built-ins like tree-codes and provide the appropriate understanding. secondly, the x = p1 - 4 + 8 calculation is handle-able by rangeops, we just need slightly better range tracking of overflows on unsigned values.. which is already on my todo list. and then the if (x > p1) would be handled by the upcoming relational code automatically once we get the calculation right. so its not quite as simple as back propagation, but it is on the radar, possibly during this stage 1.
