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?
