This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch for the shift count problem

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:


Your patch instead takes care of additional patterns:


(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

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]