This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/36494] Char arrays gets corrupted in avr programs.



------- Comment #3 from martin at kfib dot org  2008-06-11 21:13 -------
Exact line for compiling is:

avr-gcc -mmcu=atmega48 -Wall    test.c   -o test

And now I'm very confused. I KNOW I've tried with and without optimization
before and that it made no difference (or possibly I'm a major clutz) but now I
can only reproduce the bug if I don't optimize. If I optimize (all kinds), I
get 3, but without optimization I get 2. This is what I get without
optimization:

  6c:   df 93           push    r29
  6e:   cf 93           push    r28
  70:   00 d0           rcall   .+0             ; 0x72 <main+0x6>
  72:   00 d0           rcall   .+0             ; 0x74 <main+0x8>
  74:   00 d0           rcall   .+0             ; 0x76 <main+0xa>
  76:   cd b7           in      r28, 0x3d       ; 61
  78:   de b7           in      r29, 0x3e       ; 62
  7a:   80 91 00 01     lds     r24, 0x0100
  7e:   90 91 01 01     lds     r25, 0x0101
  82:   9c 83           std     Y+4, r25        ; 0x04
  84:   8b 83           std     Y+3, r24        ; 0x03
  86:   8a e3           ldi     r24, 0x3A       ; 58
  88:   8d 83           std     Y+5, r24        ; 0x05
  8a:   1e 82           std     Y+6, r1 ; 0x06
  8c:   1a 82           std     Y+2, r1 ; 0x02
  8e:   19 82           std     Y+1, r1 ; 0x01
  90:   8b 81           ldd     r24, Y+3        ; 0x03
  92:   8a 33           cpi     r24, 0x3A       ; 58
  94:   29 f4           brne    .+10            ; 0xa0 <main+0x34>
  96:   89 81           ldd     r24, Y+1        ; 0x01
  98:   9a 81           ldd     r25, Y+2        ; 0x02
  9a:   81 60           ori     r24, 0x01       ; 1
  9c:   9a 83           std     Y+2, r25        ; 0x02
  9e:   89 83           std     Y+1, r24        ; 0x01
  a0:   8d 81           ldd     r24, Y+5        ; 0x05
  a2:   8a 33           cpi     r24, 0x3A       ; 58
  a4:   29 f4           brne    .+10            ; 0xb0 <main+0x44>
  a6:   89 81           ldd     r24, Y+1        ; 0x01
  a8:   9a 81           ldd     r25, Y+2        ; 0x02
  aa:   82 60           ori     r24, 0x02       ; 2
  ac:   9a 83           std     Y+2, r25        ; 0x02
  ae:   89 83           std     Y+1, r24        ; 0x01
  b0:   e7 e2           ldi     r30, 0x27       ; 39
  b2:   f0 e0           ldi     r31, 0x00       ; 0
  b4:   8f e0           ldi     r24, 0x0F       ; 15
  b6:   80 83           st      Z, r24
  b8:   e8 e2           ldi     r30, 0x28       ; 40
  ba:   f0 e0           ldi     r31, 0x00       ; 0
  bc:   89 81           ldd     r24, Y+1        ; 0x01
  be:   80 83           st      Z, r24
  c0:   80 e0           ldi     r24, 0x00       ; 0
  c2:   90 e0           ldi     r25, 0x00       ; 0
  c4:   26 96           adiw    r28, 0x06       ; 6
  c6:   0f b6           in      r0, 0x3f        ; 63
  c8:   f8 94           cli
  ca:   de bf           out     0x3e, r29       ; 62
  cc:   0f be           out     0x3f, r0        ; 63
  ce:   cd bf           out     0x3d, r28       ; 61
  d0:   cf 91           pop     r28
  d2:   df 91           pop     r29
  d4:   08 95           ret

The result is that my LEDs indicate a very shining 0x02 on the outport.
However, with -Os I get:

  6c:   8f e0           ldi     r24, 0x0F       ; 15
  6e:   87 b9           out     0x07, r24       ; 7
  70:   83 e0           ldi     r24, 0x03       ; 3
  72:   90 e0           ldi     r25, 0x00       ; 0
  74:   88 b9           out     0x08, r24       ; 8
  76:   80 e0           ldi     r24, 0x00       ; 0
  78:   90 e0           ldi     r25, 0x00       ; 0
  7a:   08 95           ret

This is with version 4.3.1. I've verified with 4.1.2 and it behaves the same;
without optimization it bugs, with it works. I guess I forgot to do a make
clean and thus deserve the title klutz. Sorry for the confusion.

Unfortunately the same doesn't go for my actual program (this one was just a
test case). It bugs badly no matter optimization (yes, I've verified that I've
made a make clean this time) and it boils down to that if I do:

  display.write_string ("Hello");

it bugs, but if I do:

  char h[6];
  h[0] = 'H';
  h[1] = 'e';
  h[2] = 'l';
  h[3] = 'l';
  h[4] = 'o';
  h[5] = 0;

  display.write_string (h);

it prints out a nice little Hello on my LCD.

Something is definitely very fishy in how the char-arrays are handled and I
can't figure it out.

I know you said in the faq that you don't want the source code, but if you want
to look at it it's at http://martin.kfib.org/atmelLCD.zip. Maybe it can shed
some light over this.

It behave the same if I optimize or not (and I hope that I haven't screwed
anything up now...); in test.cc if I use the code that I claim works I get a
nice little Hello on the LCD but if I use the one that I clam doesn't work I
just get garbage on the LCD.

Would you like me to generate .i-files too or what's the next step?


-- 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]