[PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Sat, 1 Mar 2008, Richard Guenther wrote:

> > But arbitrary arithmetic expressions aren't marked as potentially trapping 
> > / having side-effects with -ftrapv, so cases such as
> > 
> > int f(int a, int b) { return 0 * (a + b); }
> > 
> > get the potentially trapping arithmetic folded away.  If -ftrapv is to 
> > have properly defined semantics, those must include trapping if (a + b) 
> > overflows in the above code.
> 
> Sure, the only clean way to do this is to introduce new tree codes for
> trapping arithmetic.  Then the usual mechanisms of omit_one_operand
> and friends like tree_could_trap_p can work.  VRP can for example then
> optimize trapping codes to non-trapping codes.

Yes, new tree codes (or flags on existing ones) to distinguish trapping / 
wrapping / undefined arithmetic are a clean approach.  Then -ftrapv and 
-fwrapv would be used only when front ends build trees, and not 
subsequently to affect the semantics of given GIMPLE trees.  It might be 
useful for optimizers to understand two expressions being equivalent in 
one direction only (if you have an overflow-undefined version of an 
expression, and an overflow-wrapping or overflow-trapping version, you can 
just evaluate the latter version and use the result for the 
overflow-undefined version, but not vice versa).

Depending on the target (whether it has instruction patterns for these 
operations), and on other flags such as -Os, and on the particular types 
involved, the trapping codes might then get converted to wrapping codes 
plus inline checks at some point through tree-ssa (especially if one 
argument is a constant), or might make it all the way to expand.  If given 
bit-field types, Ada types with special ranges, etc. (types not having the 
full range of their mode, or checked arithmetic on char or short where we 
don't provide libgcc functions because such arithmetic won't arise in C 
because of promotions), inline checks would definitely be needed since 
there wouldn't be suitable libgcc functions.  (The inline checks for 
special cases could simply be: do the checked arithmetic in the full width 
of the mode where there is a libgcc function, then add inline range checks 
on the result for the exact range desired.)

So far, the LTO work has concentrated on proving the concept by allowing 
real programs such as GCC and SPEC (but in a single language and built 
with a single set of options) to be built and linked using the LTO 
infrastructure.  (In the earlier days there was also all the work on 
reducing memory usage; unfortunately most of the miscellaneous tree 
trimming changes from that are still languishing on the oldlto branch 
without having been merged to trunk, despite many having been preapproved 
to go on trunk after 4.3 branched.)  To complete LTO it will be necessary 
to change all implicit GIMPLE semantics (in global variables or langhooks) 
into explicit semantics directly encoded in the GIMPLE - including 
flag_trapv and flag_wrapv among many others, but I don't know when that 
part of the LTO work might happen.

-- 
Joseph S. Myers
joseph@codesourcery.com