public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/46779] New: wrong code generation for array access
@ 2010-12-03 11:31 mschulze at ivs dot cs.ovgu.de
  2010-12-03 13:37 ` [Bug c/46779] " rguenth at gcc dot gnu.org
                   ` (18 more replies)
  0 siblings, 19 replies; 20+ messages in thread
From: mschulze at ivs dot cs.ovgu.de @ 2010-12-03 11:31 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779

           Summary: wrong code generation for array access
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: mschulze@ivs.cs.ovgu.de
                CC: mschulze@ivs.cs.ovgu.de
            Target: avr-*-*


Created attachment 22611
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22611
example program for reproducing the wrong code generation

The gcc versions 4.4.0-4.4.5 generates wrong code for an array access if some
thing come together and it was very difficult to produce a nearly minimal test
case. It seems to be that the generation of the code goes wrong if using size
optimization, inline assembler and nested loops. Maybe the optimizer runs out
of usable registers, because some registers are globbered by the inline
assembler. The inline assembler is not from my self, because I used a macro
from the avr-libc (version 1.6.8) for filling up a boot page for later writing
this into the flash. The relevant code look as follows (in the code I expanded
the macro directly):

uint8_t array[256]={'A','B'};

int main(void) {
    uint8_t *buf=array;
    uint32_t page=0;
    uint16_t w;
    uint8_t y;
    uint16_t i;
    for (y=0;y<100;++y) {
        page=((uint16_t)y)<<8;
        for (i=0; i<10; i+=2) {
            w = (buf[i+1]);
            w<<=8;
            w|= buf[i];
            __asm__ __volatile__
            (
                "movw  r0, %4\n\t"
                "movw r30, %A3\n\t"
                "sts %1, %C3\n\t"
                "sts %0, %2\n\t"
                "spm\n\t"
                "clr  r1\n\t"
              :
              :
                  "i" (_SFR_MEM_ADDR(__SPM_REG)),
                  "i" (_SFR_MEM_ADDR(RAMPZ)),
                  "r" ((uint8_t)__BOOT_PAGE_FILL),
                  "r" ((uint32_t)(page+i)),
                  "r" ((uint16_t)w)
                : "r0", "r30", "r31"
                );
        }
    }
    return 0;
}

To reproduce the bug, compile the provided attachment with:

avr-gcc -Os main.cc -mmcu=atmega128

This generates, showing only the inner loop:

  ea:   60 e0           ldi     r22, 0x00       ; 0
  ec:   eb 01           movw    r28, r22
  ee:   6c 91           ld      r22, X
  f0:   70 e0           ldi     r23, 0x00       ; 0
  f2:   6c 2b           or      r22, r28
  f4:   7d 2b           or      r23, r29
  f6:   0b 01           movw    r0, r22
  f8:   f9 01           movw    r30, r18
  fa:   40 93 5b 00     sts     0x005B, r20
  fe:   10 93 68 00     sts     0x0068, r17
 102:   e8 95           spm
 104:   11 24           eor     r1, r1
 106:   12 96           adiw    r26, 0x02       ; 2
 108:   2e 5f           subi    r18, 0xFE       ; 254
 10a:   3f 4f           sbci    r19, 0xFF       ; 255
 10c:   4f 4f           sbci    r20, 0xFF       ; 255
 10e:   5f 4f           sbci    r21, 0xFF       ; 255
 110:   71 e0           ldi     r23, 0x01       ; 1
 112:   aa 30           cpi     r26, 0x0A       ; 10
 114:   b7 07           cpc     r27, r23
 116:   49 f7           brne    .-46            ; 0xea <main+0x1c>

and you see at 0xee the RAM is read, but only at this position, however, in the
C-source we have two reads.

This example compiled with gcc version 4.4.x generates wrong code, instead
using gcc version 4.5.x it works as it should. However, I am not sure if this
is fixed there or is this bug there also latently contained. Maybe, it is bug
in the optimizer, which only needs another example to show up there too.

Some information to the used compiler:
avr-gcc  -v 
Using built-in specs.        
Target: avr
Configured with: /tmp/cross-build/gcc-4.4.0/configure --target=avr
--prefix=/localapp/cross-gcc/builds/2.20.1-4.4.0-7.1/avr --program-prefix=avr-
--with-gnu-ld --with-gnu-as --enable-languages=c,c++
Thread model: single
gcc version 4.4.0 (GCC)

The other compiler version are compiled with same configure flags.


^ permalink raw reply	[flat|nested] 20+ messages in thread
end of thread, other threads:[~2012-05-02 17:08 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-03 11:31 [Bug c/46779] New: wrong code generation for array access mschulze at ivs dot cs.ovgu.de
2010-12-03 13:37 ` [Bug c/46779] " rguenth at gcc dot gnu.org
2010-12-03 13:58 ` mschulze at ivs dot cs.ovgu.de
2010-12-03 14:06 ` [Bug target/46779] " rguenth at gcc dot gnu.org
2010-12-03 14:16 ` mschulze at ivs dot cs.ovgu.de
2011-02-05 16:01 ` avr at gjlay dot de
2011-02-23 15:55 ` avr at gjlay dot de
2011-02-24 14:04 ` avr at gjlay dot de
2011-04-14 18:52 ` gjl at gcc dot gnu.org
2011-06-16 10:01 ` gjl at gcc dot gnu.org
2011-06-27 15:49 ` jakub at gcc dot gnu.org
2011-07-08 17:40 ` gjl at gcc dot gnu.org
2011-07-08 17:47 ` gjl at gcc dot gnu.org
2011-07-08 17:54 ` gjl at gcc dot gnu.org
2011-07-10 20:58 ` gjl at gcc dot gnu.org
2011-07-23 15:10 ` gjl at gcc dot gnu.org
2011-10-26 20:03 ` [Bug target/46779] [4.4/4.5/4.6 Regression][avr] wrong code generation for values held in R28/R29 gjl at gcc dot gnu.org
2012-02-11 10:55 ` gjl at gcc dot gnu.org
2012-05-02 17:05 ` gjl at gcc dot gnu.org
2012-05-02 17:08 ` gjl at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).