Possible issue with ARC gcc 4.8

[Richard Biener]

On Fri, Jul 3, 2015 at 3:10 PM, Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:
> Hi,
>
> I have the following test case (reduced from Linux kernel sources) and it seems
> gcc is optimizing away the first loop iteration.
>
> arc-linux-gcc -c -O2 star-9000857057.c -fno-branch-count-reg --save-temps -mA7
>
> ----------->8-------------
> static inline int __test_bit(unsigned int nr, const volatile unsigned long *addr)
> {
>  unsigned long mask;
>
>  addr += nr >> 5;
> #if 0
>     nr &= 0x1f;
> #endif
>  mask = 1UL << nr;
>  return ((mask & *addr) != 0);
> }
>
> int foo (int a, unsigned long *p)
> {
>   int i;
>   for (i = 63; i>=0; i--)
>   {
>       if (!(__test_bit(i, p)))
>            continue;
>       a += i;
>   }
>   return a;
> }
> ----------->8-------------
>
> gcc generates following
>
> ----------->8-------------
>         .global foo
>         .type   foo, @function
> foo:
>         ld_s r2,[r1,4]  <---- dead code
>         mov_s r2,63
>         .align 4
> .L2:
>         sub r2,r2,1    <-----SUB first
>         cmp r2,-1
>         jeq.d [blink]
>         lsr r3,r2,5   <----- BUG: first @mask is (1 << 62) NOT (1 << 63)
>         .align 2
> .L4:
>         ld.as r3,[r1,r3]
>         bbit0.nd r3,r2,@.L2
>         add_s r0,r0,r2
>         sub r2,r2,1
>         cmp r2,-1
>         bne.d @.L4
>         lsr r3,r2,5
>         j_s [blink]
>         .size   foo, .-foo
>         .ident  "GCC: (ARCv2 ISA Linux uClibc toolchain arc-2015.06-rc1-21-g21b2c4b83dfa)
> 4.8.4"
> ----------->8-------------
>
> For initial 32 loop operations, this test is effectively doing 64 bit operation,
> e.g. (1 << 63) in 32 bit regime. Is this supposed to be undefined, truncated to
> zero or port specific.
>
> If it is truncate to zero then generated code below is not correct as it needs to
> elide not just the first iteration (corresponding to i = 63) but 63..32
>
> Further ARCompact ISA provides that instructions involving bitpos operands BSET,
> BCLR, LSL can any number whatsoever, but core will only use the lower 5 bits (so
> clamping the bitpos to 0..31 w/o need for doing that in code.
>
> So is this a gcc bug, or some spec misinterpretation,.....

It is the C language standard that says that shifts like this invoke
undefined behavior.

Richard.

> TIA,
> -Vineet