https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466
--- Comment #13 from cqwrteur <unlvsur at live dot com> --- (In reply to Richard Biener from comment #12) > (In reply to Richard Biener from comment #11) > > With some hand-waving we could generate > > > > void square(unsigned t, int *tt) > > { > > if (t<=4) __builtin_abort(); > > tt[0] = 0; > > tt[1] = 0; > > tt[2] = 0; > > tt[3] = 0; > > tt[4] = 0; > > } > > > > but I don't see how it fits any existing transform? The "hand-waving" > > would be that __builtin_abort () since it's a known function cannot > > observe the dropped side-effects like tt[0] = 0 when t > 0. > > That is, we'd sink the stores across the abort ()s because they are > not uses of them, then we arrive at > > if (t<=0) __builtin_abort(); > if (t<=1) __builtin_abort(); > if (t<=2) __builtin_abort(); > if (t<=3) __builtin_abort(); > if (t<=4) __builtin_abort(); > tt[0] = 0; > tt[1] = 0; > tt[2] = 0; > tt[3] = 0; > tt[4] = 0; > > where we'd somehow "thread" to a single condition (PRE tail merging > merges the abort () blocks and reassoc way after it manages to merge > the controlling conditions). https://godbolt.org/z/af8nn8K4h I found this to be interesting. with -fno-exceptions, all those calls are folded together. It looks -fno-exceptions hurts optimizations here. Is that a bug or C++ EH truly affects the semantics here?