Patch for the shift count problem

[Bernardo Innocenti]

Marek Michalkiewicz wrote:
> On Wed, Jan 19, 2005 at 10:39:46PM +0100, Björn Haase wrote:
> 
>>Bernardo Innocenti asked me to forward you the following patch concerning the 
>>shift count problem. It's a slightly more comprehensive patch that addresses 
>>the same problem Bernardo Innocenti has solved.

Sorry Bjorn, it didn't occur to me that testing for
values outside the datatype range isn't useful at
all in the patterns that my patch fixed:

  ashlqi3_out
  ashrqi3_out
  lshrqi3_out


Your patch instead takes care of additional patterns:

  ashrqi3_out
  ashrsi3_out
  ashrsi3_out
  lshrqi3_out
  lshrhi3_out
  lshrsi3_out

(you're missing ashlqi3_out, btw).


So I think our patches should be combined, using my
solution for the first three patterns, and yours for
the rest.

After all, PR19293 and PR19329 weren't quite the
same bug, so I regret closing the latter as a
duplicate!


> Thanks, but I see a potential problem: while shift count == 0
> is clearly a no-op (as done in the original patch), "strange"
> shift counts (by more bits than operand width) shouldn't be
> treated as such IMHO.  The way it works now (clear all bits,
> or copy sign bit to all bits for ashr*) looks correct to me.

This is undefined behavior according to the C standard.
Some hardware barrel shifters just wrap the shift count
to the word size.  Others output 0 as we do.

> Not sure what to do with negative shift counts: does this
> ever happen?  Should this be handled like count == 0, or
> perhaps by shifting in the opposite direction?  If it should
> never happen, better report an internal compiler error...

I think the C standard says this is undefined behavior too,
and GCC emits a warning if you do it explicitly in source
code.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/