https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Pierre-Marie de Rodat from comment #6)
> Thanks for your answer, Richard!
>
> (In reply to Richard Biener from comment #5)
> > So what is the issue with replacing zero-extending an uninitialized %ebp
> > with a random other value? Both are essentially undefined when reached via
> > the somlabel bypass.
>
> Well, at least on x86, even when %ebp is uninitialized, “movzwl %bp, %ebp”
> makes its upper half zero (and yes, the lower half is uninitialized). Hence
> a following “shr $0x10, %ebp” is supposed to leave zero in %epb, for
> instance. If we have a random value instead as shr’s input, this does not
> work anymore, so I consider this transformation is an error.
>
> > Is the real issue happening in a downstream pass? I don't think REE does
> > anything wrong here.
>
> REE is the pass where I observed the change in behavior I described in my
> first message, and I did not notice anything weird beyond this. If the above
> is wrong (i.e. if we cannot assume (zext UNDEF from i16 to i32) >> 16 == 0),
> then I guess I’ll have to look for something wrong up in the pipe. ;-)
It would be certainly good to see why we have this UNDEF in the first place.
But yes, I have to agree that zext UNDEF >> 16 should be zero. Unlike
sext UNDEF which is always undefined as the sign-bit is undefined.
