https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90437
Bug ID: 90437 Summary: Overflow detection too late for VRP Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- bool f(unsigned a, unsigned b, unsigned*c){ if(a>10)__builtin_unreachable(); if(b>10)__builtin_unreachable(); *c = a + b; return *c < a; } In the .optimized dump, we still have _9 = .ADD_OVERFLOW (a_2(D), b_3(D)); _1 = REALPART_EXPR <_9>; _8 = IMAGPART_EXPR <_9>; *c_5(D) = _1; _7 = _8 != 0; return _7; We have code in VRP to simplify IFN_ADD_OVERFLOW when the arguments have interesting ranges, but this call only appears in the widening_mul pass. In this particular case, expand optimizes the code properly, but in general _8 would be used in a GIMPLE_COND and we would have a number of further optimizations to make. We could either have an earlier pass than widening_mul detect a+b<a and introduce IFN_ADD_OVERFLOW, or VRP could detect a+b<a and optimize it as if it was IFN_ADD_OVERFLOW (without introducing it).