Re: avoiding removal of -ftrapv libcalls in RTL optimization

[Ken Raeburn <raeburn at raeburn dot org>]

On Sep 17, 2007, at 04:56, Richard Guenther wrote:
> Which of my observations in PR19020 comment #5 does this fix?  I guess
> the first one?

Actually, with my patch, your first comment is still accurate.  It's  
just no longer marked as a side-effect-free function, and we  
therefore don't let it get discarded (at least, via dead_libcall_p).

> In general I think it is not worth in trying to fix -ftrapv, I  
> believe we should
> instead deprecate and kill it.  It is somewhat ill-defined as you  
> noticed and
> lacks trap on conversions and also on division and shifts.

Shifts!  That's the one I was missing from my other email to the gcc  
list.  I knew there was something else... :)

It could become well-defined, which I guess was part of the idea  
behind my other email.  But it would probably mean chasing down a  
number of issues in the tree optimizers.  I'd kind of like to have  
the functionality.  (Actually, it's not *quite* what I'd want.   
Better would be super-studly analysis of all the library code in my  
project, and warnings for code where signed overflow or conversion or  
shift problems *might* happen based on values supplied by the  
application or off the net.  And, in some poorly-defined set of  
cases, wherever wrapping or truncation might occur in unsigned math  
and introduce security problems.  A man can dream, can't he?  But,  
run-time checks of undefined behavior with signed math are better  
than no checks.)

> What we certainly would need is some more testcases for the feature.
> (I'd put your testcase in gcc.target/i386).

It's not x86 specific, aside from checking that a multiply  
instruction isn't used when we're on i386.  The function calls  
checked for should be needed on almost all platforms.  (Any that  
don't define RTL patterns for trapping math operations.)

> Btw., can you use -p for the patches please?

Sorry, I didn't think "svn diff" supported that.  Or do you mean not  
to use the built-in diff?

Ken