[Bug middle-end/68785] [6 Regression] valgrind reports issues with folding on x86_64

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68785

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 9 Dec 2015, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68785
> 
> --- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #5)
> > Err, no - the only option would be to _not_ fold if elen < size.  As
> > said, SCCVN aggressively folds reads from initializers (even if
> > in differing types).  I invented the "offset" parameter for this.
> 
> But that is what will happen, if there aren't enough bytes in the buffer for
> a value you want native_interpret_*, then it returns NULL_TREE.
> Look at all the native_interpret_* functions, they start with checking if there
> are enough bytes in the buffer for what they want.

Sure, but SCCVN explicitely tells it the buffer is large enough
(because it ensured this for the cases it handles).  If the read
is out-of-bounds SCCVN doesn't care (and I don't see why we should
preserve the original undefined behavior here, just for the sake
of valgrind).

Yes, SCCVN _could_ pass the return value from native_encode_expr
to native_interpret_expr.