RE: warning: right shift count >= width of type

[Andrew Haley <aph at redhat dot com>]

Dave Korn writes:
 > > -----Original Message-----
 > > From: gcc-owner On Behalf Of Andrew Haley
 > > Sent: 29 November 2004 17:11
 > 
 > > Dave Korn writes:
 > 
 > >  >   So my question is really "Given that it's undefined, 
 > > which means that
 > >  > whatever the compiler does is correct, and given that 
 > > there's already code
 > >  > in there to detect the situation and issue a warning, 
 > > which probably means
 > >  > that it would be very easy at such a point to replace the 
 > > offending RTL with
 > >  > (const_int 0), is there any specific reason why not to?"
 > > 
 > > I think the idea is that 
 > > 
 > >   a << n  /* n == 32 */
 > > 
 > > and 
 > > 
 > >   a << 32
 > > 
 > > should do the same thing.  This seems IMO more helpful than
 > > optimizing away the shift.
 > 
 >   Ah, well I can see that as a desirable goal (although who ever said
 > undefined behaviour had to produce the same results consistently across
 > different methods of invoking said undefined behaviour?) I suppose.  

Well, I said "helpful".  We don't try deliberately to be inconsistent
when people invoke undefined behaviour, it just happens as a
side-effect.  :-)

 > > No, not at all.  The x86 processors interpret this as 
 > > 
 > >   a << (n % 32)
 > > 
 > >  > but it's surely only an issue of bugward-compatibility:
 > >  > mathematically, there's really no problem with right-shifting more
 > >  > than the width of the integer, all that happens is that _all_ the
 > >  > bits drop out the right-hand side and you're left with nothing.
 > > 
 > > That's not what all hardware actually does with shift instructions.
 > > 
 > >  > ISTM reasonable that the result of a right-shift by 32 bits could
 > >  > be assumed to be the same thing you get if you right-shift by 1 bit
 > >  > 32 times....
 > > 
 > > The chip designers don't agree.
 > 
 >   I would argue that the x86 simply does not _provide_ a shift-by-32 bits
 > instruction, owing to that implicit modulo, any more than a RISC cpu with a
 > 5-bit-wide field in the opcode to encode a shift amount does so.
 > 
 >   I myself would want "(n >> 32)" to produce the same result as "((n >> 16)
 > >> 16)" and indeed "for (int i = 32; i > 0; i--, n >>= 1) ;", and it seems
 > to be generally agreed that the compiler would be at liberty to so do if it
 > wants to.

But you could never depend on it.  If it only works when the shift
count is a constant, a failure to do constant folding would break it.

Andrew.