[patch] prevent tree sinking of trapping stmts

[Olivier Hainque]

On Sep 4, 2014, at 12:22 , Richard Biener <richard.guenther@gmail.com> wrote:

> So I tend to think that removing / delaying traps is ok unless you
> can catch them within the active EH scheme.

> Certainly that Oliver excludes loads/stores (but not integer
> division!) points at the fact that preserving the order of
> traps with respect to other sequence points is no good
> for optimization.

 Right, Eric convinced me of that and pushed me in the direction
 of leaving stores and loads alone on the grounds that traps from
 there meant undefined behavior anyway.
 
 It seemed to me that other trapping operations were less
 clearly representative of undefined programs, but I was admittedly
 biased by the Ada model where traps map to exceptions.

 So from the Ada perspective, conditioning on could_throw_p seems
 fine to me. We set flag_exceptions + flag_non_call_exceptions to 1
 when using a GCC eh scheme, which is in most cases. It's just for our
 front-end sjlj special case that we have a problem. We are considering
 options here, switching to the middle-end sjlj scheme for our sjlj
 runtimes is a possibility we're seriously considering.

 Olivier