Bug 42976 - Illegal translation for IF operator
Illegal translation for IF operator
Status: RESOLVED INVALID
Product: gcc
Classification: Unclassified
Component: target
4.3.3
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
: wrong-code
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-05 16:16 UTC by Dmitry A. Kharitonov
Modified: 2011-03-10 20:21 UTC (History)
4 users (show)

See Also:
Host: i386
Target: avr
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry A. Kharitonov 2010-02-05 16:16:32 UTC
//Nouse skiped
                // test for holdkey
                if(keybuf.keys!=keys.keys) {
 20c:    20 91 fa 00     lds    r18, 0x00FA
 210:    30 91 fb 00     lds    r19, 0x00FB
 214:    40 91 fc 00     lds    r20, 0x00FC
 218:    50 91 fd 00     lds    r21, 0x00FD
 21c:    80 91 04 01     lds    r24, 0x0104
 220:    90 91 05 01     lds    r25, 0x0105
 224:    a0 91 06 01     lds    r26, 0x0106
 228:    b0 91 07 01     lds    r27, 0x0107
 22c:    28 17           cp    r18, r24
 22e:    39 07           cpc    r19, r25
 230:    4a 07           cpc    r20, r26
 232:    5b 07           cpc    r21, r27
 234:    e1 f0           breq    .+56         ; 0x26e <__stack+0xf>

is illegal

                // test for presskey
                if(keybuf.keys) {
 26e:    80 91 fa 00     lds    r24, 0x00FA
 272:    90 91 fb 00     lds    r25, 0x00FB
 276:    a0 91 fc 00     lds    r26, 0x00FC
 27a:    b0 91 fd 00     lds    r27, 0x00FD
 27e:    00 97           sbiw    r24, 0x00    ; 0
 280:    a1 05           cpc    r26, r1
 282:    b1 05           cpc    r27, r1
 284:    79 f1           breq    .+94         ; 0x2e4 <__stack+0x85>

is illegal

[user@localhost Documents]$ cat bugif.c
#include <avr/io.h>

int main(void) {
    volatile uint16_t a=8,b=7;
a++;
b++;
if(a==b) a++;
if(b) b++;
return 0;
}
[user@localhost Documents]$ avr-gcc -Wall -Werror -g -Os -o bugif.elf -mint8
-I/usr/include/avr -mmcu=atmega8535 bugif.c; avr-objdump -S -h bugif.elf
>bugif.S

  8c:    8b 83           std    Y+3, r24    ; 0x03
if(a==b) a++;
  8e:    29 81           ldd    r18, Y+1    ; 0x01
  90:    3a 81           ldd    r19, Y+2    ; 0x02
  92:    8b 81           ldd    r24, Y+3    ; 0x03
  94:    9c 81           ldd    r25, Y+4    ; 0x04
  96:    28 17           cp    r18, r24
  98:    39 07           cpc    r19, r25
  9a:    29 f4           brne    .+10         ; 0xa6 <main+0x44>

is illegal

  9c:    89 81           ldd    r24, Y+1    ; 0x01
  9e:    9a 81           ldd    r25, Y+2    ; 0x02
  a0:    01 96           adiw    r24, 0x01    ; 1
  a2:    9a 83           std    Y+2, r25    ; 0x02
  a4:    89 83           std    Y+1, r24    ; 0x01
if(b) b++;
  a6:    8b 81           ldd    r24, Y+3    ; 0x03
  a8:    9c 81           ldd    r25, Y+4    ; 0x04
  aa:    89 2b           or    r24, r25
  ac:    29 f0           breq    .+10         ; 0xb8 <main+0x56>

is right

  ae:    8b 81           ldd    r24, Y+3    ; 0x03
  b0:    9c 81           ldd    r25, Y+4    ; 0x04
  b2:    01 96           adiw    r24, 0x01    ; 1
  b4:    9c 83           std    Y+4, r25    ; 0x04
  b6:    8b 83           std    Y+3, r24    ; 0x03
return 0;


c:\WinAVR-20100110\bin>avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../gcc-4.3.3/configure --enable-win32-registry=WinAVR-20100110
--with-gmp=/usr/local --with-mpfr=/usr/local --prefix=/c/WinAVR --target=avr --e
nable-languages=c,c++,objc --with-dwarf2 --enable-doc --disable-shared --disable
-libada --disable-libssp --disable-nls --with-pkgversion='WinAVR 20100110' --wit
h-bugurl='URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=br
owse'
Thread model: single
gcc version 4.3.3 (WinAVR 20100110)
Comment 1 Georg-Johann Lay 2011-03-10 20:14:46 UTC
There is nothing wrong with the code.

bugif.c is compiled and disassembled as expected.

For the snippets with keybuf.keys, keys.keys there is no source, so presumably these variables are defined to be 32-bit scalar.

Again, there is nothing wrong with that code. This bug can be marked as "invalid".

Johann
Comment 2 Eric Weddington 2011-03-10 20:21:23 UTC
Resolving as invalid.