This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch for the shift count problem
- From: Marek Michalkiewicz <marekm at amelek dot gda dot pl>
- To: Bernardo Innocenti <bernie at develer dot com>
- 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 22:46:03 +0100
- Subject: Re: Patch for the shift count problem
- References: <200501192239.46970.bjoern.m.haase@web.de> <20050119223418.GA16982@amelek.gda.pl> <41EF484F.80800@develer.com>
On Thu, Jan 20, 2005 at 06:57:35AM +0100, Bernardo Innocenti wrote:
> 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:
Please also note the condition in avr.c (notice_update_cc), checking
for ashrqi3 by a constant != 6. Of course, CC is not set correctly
if the shift count is zero or negative (no shift at all), and this
condition needs to be updated.
> 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.
C standard is one thing, but GCC has other language front ends, which
might have different rules here (or not). I'm not sure really...
If the shift count is not a constant (it's a value in a register),
avr.c (out_shift_with_cnt) outputs a loop like this:
rjmp 2f
1: /* template */
2: dec %3
brpl 1b
I think it might be a good idea to make the undefined behaviour
consistent between const and non-const shift count. This means,
no shift for count <= 0, and copy zero/sign to all bits for too big
count - that's what the above loop does.
(There is one ugly special case left: variable shift count -128
works like +128, but I wouldn't bother with this...)
Marek