Re: PATCH RFC: -fstrict-overflow

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > > > >>>>> "Ian" == Ian Lance Taylor <iant@google.com> writes:
> > > > 
> > > > Ian> It's not clear to me how -ftrapv interacts with signed overflow
> > > > Ian> assumptions.  Does -ftrapv mean that signed overflow is undefined?  Or
> > > > Ian> does it mean that we may not touch any operation that may overflow?
> > > > Ian> I don't know what the original purpose of -ftrapv was.  It was added
> > > > Ian> here:
> > > > Ian>     http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00607.html
> > > > Ian> but that message sheds no light on the goal of the option.
> > > > 
> > > > It seems strange to have a feature like this where: nobody seems to
> > > > know why it was added, no one knows its precise semantics, and we
> > > > aren't even sure it covers all the cases we think it ought to.
> > > > 
> > > > How about we remove it?
> > > 
> > > The value of this feature, even if buggy, is obvious; it is being used to 
> > > find and fix overflow bugs in real software 
> > > <http://gcc.gnu.org/ml/gcc/2007-01/msg00294.html>.
> > 
> > what about to fix it? IMHO, it could be made much more reliable if
> > instead of testing -ftrapv everywhere, we just instrumented the program
> > early (perhaps during gimplification, or in a separate pass immediatelly after
> > it), and then just behaved the same way as with -fno-wrapv?
> 
> That approach goes right back to the question I had originally: does
> -trapv mean that we may not touch any operation that may overflow?
> Joseph Myers answered in the affirmative.  So we would have to treat
> -ftrapv as (in my proposal) -fno-strict-overflow.
> 
> In general I think that's a good idea.  But something to consider is
> that the i386, for example, can detect overflow efficiently (although
> we don't currently use that capability as far as I can see).  Do we
> have any chance of going from the instrumentation back to efficient
> overflow detection instructions?

you could generate the appropriate builtin calls during the
instrumentation, if the md provides them; it would kill optimizations,
though (you would no longer see what the results of the operations are).

Other possibility is to generate just the checking code in the form
of builtins that would expand to efficient rtl if possible, and rely
on cse/combine/fwprop to replace the redundant non-checked operations
by the expressions computed in the checking code.

Another (less robust, but leading to more efficient code) approach is
what Joseph proposed (remember for which expressions we need to check
for trapping); I tried that once, the patch is somewhere in the lists, but I
think it would be quite hard to make this reliable.

Zdenek