On Mar 6, 2009, at 04:11, Richard Guenther wrote:
I didn't spend too much time thinking about the trapping variants
(well, I believe it isn't that important ;)). But in general we would
have to expand the non-NV variants via the trapping expanders
if flag_trapv was true (so yeah, combining TUs with different
flag_trapv
settings would be difficult again and it would ask for explicitly
encoding this variant in the IL ...).
The non-NV variants have wrap-around semantics on the no-undefined-
overflow
branch, right? I'm not about to change that based on some global
flag! :)
I'm proposing something like:
{PLUS,MINUS,MULT,NEGATE}_EXPR:
- signed integer operation with wrap-around
{PLUS,MINUS,MULT,NEGATE)NV_EXPR
- signed integer operations known to not overflow
{PLUS,MINUS,MULT,NEGATE)V_EXPR
- signed integer operation with overflow check that traps,
aborts or raises an exception on overflow
There is of course the problem that we have to be careful not to
introduce new traps via folding, a problem that doesn't exist with
the no-overflow variants (I can simply drop to the wrapping variants).
With for example (a -/v 10) +/v 10 would you want to preserve
the possibly trapping a -/v 10? For (a -/v 10) +/v (b -/v 10) do
we want to be careful to not introduce extra traps when simplifying
to (a +/v b) -/v 20?
Indeed, there has to be a very clear boundary as we'd be changing
semantics. The original -ftrapv implementation muddled that issue,
something I absolutely want to avoid
So while trapping variants can certainly be introduced it looks like
this task may be more difficult. So lowering them early during
gimplification looks like a more reasonable plan IMHO.
Right, that was my intention. Still, I'll need to add code to
handle the new tree codes in fold(), right?
-Geert
