Bug in powerpc-eabivle-gcc-4.9.2

[yveslhuillier]

When compiling (-O2) the following code (file attached: bug.c):

#include <inttypes.h>

typedef struct Bar { uint8_t value; } Bar;
void make_bar( Bar* bar, uint32_t code ) { bar->value = (code >> 12) & 0x7f; }

uint32_t
foo( uint32_t code )
{
  if ((code & 0xfe000001) == 0x70000001)
  {
    Bar bar;
    make_bar(&bar, code);
    return bar.value;
  }
  return 0;
}

The generated assembly for foo is:

00000008 <foo>:
   8:   74 67 07 cd     e_rlwinm r7,r3,0,31,6
   c:   74 69 a6 6f     e_rlwinm r9,r3,20,25,23
  10:   71 40 00 00     e_li    r10,0
  14:   70 6e e0 00     e_lis   r3,28672
  18:   65 f3           se_bseti r3,31
  1a:   0c 37           se_cmp  r7,r3
  1c:   7c 69 50 9e     iseleq  r3,r9,r10
  20:   00 04           se_blr

The "e_rlwinm r9,r3,20,25,23" is obviously faulty; should be "e_rlwinm r9,r3,20,25,31".

Thus when given 0x70004001, foo returns 0x00170004 whereas it should return 4.

Original Attachment has been moved to: bug.c.zip

[stanish · Accepted solution]

Hello Yves,

Thanks for your report and sorry about the delay. Currently we have some support staff out-of-office.

Anyway, I can confirm this is indeed a known issue which should be fixed in the next release (v1.2)

I've tried to build and disassemble your snippet using the compiler version from v1.2 and the rotation instruction is ok now:

foo:
000040c8: e_rlwinm r6,r3,0,31,6
000040cc: e_rlwinm r7,r3,20,25,31
000040d0: e_lis r3,28672
000040d4: se_bseti r3,31
000040d6: se_cmp r6,r3
000040d8: se_li r6,0
000040da: iseleq r3,r7,r6
000040de: se_blr‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

S32DS Power v1.2 should be released at the end of this week 16-June-2017.

It will be announced on the S32 Design Studio community.

Regards,

Stan

[peterb2]

Hello Yves,

    I had found the same problem as you (Value Comparison Giving the Wrong Result)  and the response I got was that it is fixed in the next version of the compiler which is due for release on the 16 June 2017.  As a workaround I am compiling the file with the problematic code with the optimisations turned off.

[jfrey]

Not a solution to the problem, but for the NXP guys, why not put the compiler GitHub where people can properly report issues and help fix them? It's clear that this side of the business is new to 'open development', but releasing a blob of your source is literally the least you can (and need to) do.

You already have the space for it and it's not being used for much of anything: NXP · GitHub