[RFC] Implement Undefined Behavior Sanitizer (take 2)

[Jakub Jelinek]

On Tue, Jun 11, 2013 at 10:20:24PM +0200, Marek Polacek wrote:
> On Tue, Jun 11, 2013 at 10:09:00PM +0200, Jakub Jelinek wrote:
> > On Tue, Jun 11, 2013 at 09:44:40PM +0200, Marek Polacek wrote:
> > > > >+  tree type0 = TREE_TYPE (op0);
> > > > >+  tree type1 = TREE_TYPE (op1);
> > > > 
> > > > Can the 2 types be different? I thought divisions had homogeneous
> > > > arguments, and the instrumentation was done late enough to avoid any
> > > > potential issue, but maybe not...
> > > 
> > > Yeah, they can; they only have to be of arithmetic type.
> > 
> > Nope, if this is after conversion to result_type (resp. orig_type),
> > then they both have result_type resp. orig_type type.
> > 
> > Shift is different, there the two arguments can have different type.
> 
> But currently I'm cp_convert-ing the arguments to orig_type only if
> we were performing the shortening which changed the result_type.
> If, with current patch, I put debug_tree (type0); debug_tree (type1);
> into ubsan_instrument_division, I see different types (int vs.
> unsigned int etc.).

That means you probably should move the function call down in
cp_build_binary_op (resp. C counterpart), after the arguments are converted
to result_type?

	Jakub