On Sep 4, 2014, at 12:22 , Richard Biener <richard.guent...@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
