compiler bug with -O2

[GoogleCodeExporter]

>> What steps will reproduce the problem?

simple c code for extracting RGB from 565 value:

{
  short color = 0x192d;

  b = (color & 31) << 3;
  g = ((color >> 5) & 63) << 2;
  r = ((color >> 11) & 31) << 3;

  // r, g, b values?
}

workaround:

{
  short color = 0x192d;

  b = (color & 0x001f) << 3;
  g = (color & 0x07e0) >> 3;
  r = (color & 0xf800) >> 8;
}

while there is a workaround, this is a compiler bug that should get fixed,
as you never know where else you could run into this problem.

>> What is the expected output? What do you see instead?

-O2
r =  24, g =   0, b = 104

without -O
r =  24, g =  36, b = 104  (correct result)

>> What version of the product are you using? On what operating system?

kroo's development environment, 05.dmg
MacOSX 10.4.10

>> Please provide any additional information below.

simple bug.

// Aaron Ardiri

Original issue reported on code.google.com by ard...@gmail.com on 16 Sep 2007 at 3:07

[GoogleCodeExporter]

I don't see this with the latest toolchain on this site: For the first, with 
-O2, I get:

    add r4, pc, r3
    mov r5, #104
    mov r6, #36
    mov r8, #24
    mov r0, r4
    mov r1, r8
    mov r2, r6
    mov r3, r5
    bl L_printf$stub

which will produce the correct result.

Original comment by nightwat...@gmail.com on 19 Sep 2007 at 10:19

• Changed state: WorksForMe

[GoogleCodeExporter]

it also produced weird results with -O7 as well.

if this is fixed with 0.30 toolchain (trunk); then that is great. this was an 
issue
with the 0.20 toolchain (kroo 05 dmg). doesn't crash the program, but gives 
invalid
results with color extraction.

i look forward to using the new 0.30 toolchain once it is stable

// Aaron Ardiri 

Original comment by ard...@gmail.com on 20 Sep 2007 at 8:27