https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68785
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 8 Dec 2015, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68785 > > Jakub Jelinek <jakub at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |jakub at gcc dot gnu.org > Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot > gnu.org > > --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #3) > > So it folds > > > > # VUSE <.MEM_30> > > # rhs access alignment 32+0 > > _92 = MEM[(u32 *)path_7]; > > > > but path_7 is know to point to "". location of the stmt above is > > drivers/acpi/acpica/nsaccess.c:562:36 I guess that's > > > > *(u32 *)(void *)(&simple_name) = *(u32 *)(void *)(path); > > > > eventually jump-threaded from the > > > > if (!pathname) { > > > > > > > > num_segments = 0; > > this_node = acpi_gbl_root_node; > > path = ""; > > > > case . Yeah, quite obvious. > > > > We avoid doing the work to zero the "undefined" area given the program does > > not invoke undefined behavior only if the uninitialized bits of the result > > are not used (like masked out or so). > > > > One could silence valgrind with some annotation I guess. > > > > Patch to make it trigger as ICE: > > > > Index: gcc/gimple-fold.c > > =================================================================== > > --- gcc/gimple-fold.c (revision 231355) > > +++ gcc/gimple-fold.c (working copy) > > @@ -5495,9 +5492,13 @@ fold_ctor_reference (tree type, tree cto > > && size <= MAX_BITSIZE_MODE_ANY_MODE) > > { > > unsigned char buf[MAX_BITSIZE_MODE_ANY_MODE / BITS_PER_UNIT]; > > - if (native_encode_expr (ctor, buf, size / BITS_PER_UNIT, > > - offset / BITS_PER_UNIT) > 0) > > - return native_interpret_expr (type, buf, size / BITS_PER_UNIT); > > + int elen; > > + if ((elen = native_encode_expr (ctor, buf, size / BITS_PER_UNIT, > > + offset / BITS_PER_UNIT)) > 0) > > + { > > + gcc_assert (elen >= size / BITS_PER_UNIT); > > + return native_interpret_expr (type, buf, size / BITS_PER_UNIT); > > + } > > } > > if (TREE_CODE (ctor) == CONSTRUCTOR) > > { > > Looks like the bug is right here (and in tree-ssa-sccvn.c) too. > The interfaces are really meant to be used the way fold_view_convert_expr uses > them, i.e. that native_interpret_expr is called with the length returned by > native_encode_expr. Will try to reduce the testcase and write a patch. 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. I think it's perfectly fine like above. The other option would be to zero buf from elen to size. But then these "undefined" parts of the read just become reliably zero. And that just for a valgrind complaint? Richard.
