This is the mail archive of the
mailing list for the GCC project.
Re: Patch for the shift count problem
- From: Bernardo Innocenti <bernie at develer dot com>
- To: Marek Michalkiewicz <marekm at amelek dot gda dot pl>
- Cc: Björn Haase <bjoern dot m dot haase at web dot de>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 20 Jan 2005 06:57:35 +0100
- Subject: Re: Patch for the shift count problem
- References: <email@example.com> <20050119223418.GA16982@amelek.gda.pl>
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
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
// Bernardo Innocenti - Develer S.r.l., R&D dept.