The following fixes the second bug you'll hit very fast when writing
testcases for -ftrapv (maybe not so often in "real" scenarios). There
are several places in the optimization pipeline where after constant
folding we fail to generate trapping instructions.
The simplest solution as implemented below is to avoid constant-folding
trapping instructions.
Another solution would be to make sure to fold to
(__builtin_trap (), value), but I didn't try that (and it's not
what the existing mitigation in folding of negates does).
For bit-ccp I decided to say it's not its business to re-invent
constant folding (so only handle partially constant values).
For CSE and simplify-rtx.c we need to make sure to _not_ record
non-trapping REG_EQUAL variants, that is, when expanding
a + b with overflow trapping we may not attach a simple
(plus:SI reg1 reg2) REG_EQUAL note to the libcall. (similar
to signed vs. unsigned ops there doesn't seem to be a way
to make this plus "trapping")
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Note that bootstrap with -ftrapv currently fails (not because
of trapping but because ICEing in expr.c:9218 - probably a fallout
of my earlier patch ... bah).
Ok for trunk?
Thanks,
Richard.
2014-07-29 Richard Biener <rguenther@suse.de>
PR middle-end/61893
* fold-const.c (const_binop): For trapping overflow types return
NULL_TREE if the operation overflowed.
* tree-ssa-ccp.c (bit_value_unop): Do not do constant folding.
(bit_value_binop): Likewise.
* optabs.c (emit_libcall_block_1): Allow a NULL_RTX equiv.
(expand_binop): For -ftrapv optabs do not record an REG_EQUAL
note.
(expand_unop): Likewise.