Hi! As mentioned in the PR, during expand_arith_overflow expansion expand_neg_overflow falls through into expand_addsub_overflow, so expands roughly the same code twice and keeps perhaps the less efficient version around.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2016-09-16 Jakub Jelinek <ja...@redhat.com> Eric Botcazou <ebotca...@adacore.com> PR middle-end/77594 * internal-fn.c (expand_arith_overflow) <case MINUS_EXPR>: Don't fall through into expand_addsub_overflow after expand_neg_overflow. * gcc.target/i386/pr77594.c: New test. --- gcc/internal-fn.c.jj 2016-08-29 12:17:14.000000000 +0200 +++ gcc/internal-fn.c 2016-09-15 09:42:09.693980531 +0200 @@ -1833,7 +1833,10 @@ expand_arith_overflow (enum tree_code co { case MINUS_EXPR: if (integer_zerop (arg0) && !unsr_p) - expand_neg_overflow (loc, lhs, arg1, false); + { + expand_neg_overflow (loc, lhs, arg1, false); + return; + } /* FALLTHRU */ case PLUS_EXPR: expand_addsub_overflow (loc, code, lhs, arg0, arg1, --- gcc/testsuite/gcc.target/i386/pr77594.c.jj 2016-09-15 09:44:51.879910346 +0200 +++ gcc/testsuite/gcc.target/i386/pr77594.c 2016-09-15 09:44:43.000000000 +0200 @@ -0,0 +1,11 @@ +/* PR middle-end/77594 */ +/* { dg-do compile } */ +/* { dg-options "-O0" } */ + +int +foo (int a, int *b) +{ + return __builtin_sub_overflow (0, a, b); +} + +/* { dg-final { scan-assembler-times "\tjn?o\t" 1 } } */ Jakub