http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-10
16:29:10 UTC ---
The test is really large, I guess it would be useful if you could try to reduce
the testcase as long as it still fails that BIT_SIZE(integer(8)) test.
Or can you step through the interesting part of the testcase and see where
things go wrong? I've eyeballed the *.final assembly of the ma computation and
it looks ok to me.
ldi 0,%r19
ldi 0,%r20
ldi 126,%r31
ldi -1,%r28
ldi -1,%r29
L$0032:
copy %r19,%r21
copy %r20,%r22
addi 1,%r20,%r20
addc %r19,%r0,%r19
comiclr,>= 0,%r21,%r0
b,n L$0029
comib,<> 0,%r21,L$0050
or %r28,%r29,%r23
comclr,>>= %r31,%r22,%r0
b,n L$0029
L$0050:
comib,=,n 0,%r23,L$0029
shd %r28,%r29,1,%r21
extru %r28,30,31,%r22
copy %r21,%r29
b L$0032
copy %r22,%r28
L$0029:
stw %r21,-240(%r30)
ldo -240(%r30),%r25
ldi 20,%r23
stw %r22,-236(%r30)
is the assembly I get for the interesting part. So, if you have the same, can
you step through this and see why you get 0 in %r21/%r22?
