https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71762
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 9 Nov 2016, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71762 > > Jeffrey A. Law <law at redhat dot com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |law at redhat dot com > > --- Comment #7 from Jeffrey A. Law <law at redhat dot com> --- > ISTM the transformation is valid on gimple, but that at RTL expansion time we > don't guarantee the range of the uninitialized object is [01]. And yes, if we > have to insert truncations this transformation becomes a lose. > > One approach would be something similar to the unswitching on an uninitialized > value fix that I need to get back to -- ensure the values are initialized and > if they aren't, don't allow the transformation. > > I wouldn't be surprised if there are other places where using type/vrp > information on a sub-word sized object that is uninitialized is going to cause > problems. I think RTL expansion is conservative in inserting truncations whenever necessary, see the reduce_bit_field handling in expand_expr. So the issue will appear only if defs (or no defs!) appear outside the scope of expand_expr. Which for this particular case means we have to expand unsigned default-defs to have zero bits outsize of their precision. > I don't think losing the transformations would be that big of a deal either. > My recollection is they definitely triggered in GCC itself, but I don't have a > sense of how often. I'll see if I can work out sth reasonable along the above lines.
