[Bug c/39593] New: faulty value assignment

[Bug c/39593] New: faulty value assignment

[szir at sch dot bme dot hu]

This is a serious bug, since the compiler produces faulty code, without any
warning! It pissed me off really bad, I had to wait a month or two to calm down
and prepare a half decent bug report.
It can appear anywhere and anytime. It happened with me, when I removed an
unrelated line from a different portion of the code. 
(I know everything in the universe is related :) )

I was able to reproduce the bug in WinAVR 20080610, 20081205, 20090313 (gcc
4.3.0,4.3.2). In short the bug looks like this:

  TF.key32[1]=TFdw1; /// 0x04050607
 484:    ldi    r16, 0x07       ; 7
 486:    mov    r14, r16
 488:    ldi    r16, 0x06       ; 6
 48a:    mov    r15, r16
 48c:    ldi    r16, 0x05       ; 5
 48e:    mov    r16, r16         ;;;;;;<---- mov        r16, r16  !!!!
 490:    ldi    r16, 0x04       ; 4  ;;;;;;<---- ldi    r16, 0x04 !!!!
 492:    mov    r17, r16
 494:    sts    0x0064, r14
 498:    sts    0x0065, r15
 49c:    sts    0x0066, r16
 4a0:    sts    0x0067, r17
 [...]
The rest of the code is in the attached files, I tried to minimize the code, I
think I left only what is needed.

The working WinAVR versions (20070525 (4.1.2), 20060421 (3.4.6) ) are just
that, working, (they use different temp register r17,r19,r23,r24,r25... instead
of r16, it depends on the rest of the program code) but they still miss
optimization. (They might still have the bug, I just was not able to find the
right test case)
The problem seems that register assignment and type are handled as a unit in
(u)int32 instructions, rather than separate.
What I mean: r0-15 no immediate instructions, need temp registers, so anytime
any register of the register quad used by an int32 instruction is r0-r15 it
forces all registers to be handled like no-immediate registers.
what we would like is something on the line of this:

        ldi     r16, 0x07       ; 7
        mov     r14, r16
        ldi     r16, 0x06       ; 6
        mov     r15, r16

        ldi     r16, 0x05       ; 5  ;
        ldi     r17, 0x04       ; 4  ; instead of  ldi  r16, 0x04       +mov   
r17, r16

        sts     0x0064, r14
        sts     0x0065, r15
        sts     0x0066, r16
        sts     0x0067, r17

how any "mov    r16, r16" remains in the optimized code anyway is a mystery to
me :)

Thank the developers hard work!

compile command line:
avr-gcc -v -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=8000000UL -DBOOTSIZE=1024 
-Os -save-temps  -funsigned-char -funsigned-bitfields -fpack-struct
-fshort-enums -fno-inline-small-functions  -Wall -Winline -Wstrict-prototypes
-Wa,-adhlns=vat.lst   -std=gnu99 -MD -MP -MF .dep/vat.o.d vat.c -o vat.o

Using built-in specs.
Target: avr
Configured with: ../gcc-4.3.2/configure --enable-win32-registry=WinAVR-20090313
--with-gmp=/usr/local --with-mpfr=/usr/local --prefix=/c/WinAVR --target=avr
--enable-languages=c,c++,objc --with-dwarf2 --enable-doc --disable-shared
--disable
-libada --disable-libssp --disable-nls --with-pkgversion='WinAVR 20090313'
--with-bugurl='URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=browse'
Thread model: single
gcc version 4.3.2 (WinAVR 20090313)
COLLECT_GCC_OPTIONS='-v' '-c' '-mmcu=atmega16' '-I.' '-gdwarf-2'
'-DF_CPU=8000000UL' '-DBOOTSIZE=1024' '-Os' '-save-temps' '-funsigned-char'
'-funsigned-bitfields' '-fpack-struct' '-fshort-enums'
'-fno-inline-small-functions' '-Wall' '-Winl
ine' '-Wstrict-prototypes' '-std=gnu99' '-MD' '-MP' '-MF' '.dep/vat.o.d' '-o'
'vat.o'
 e:/winavr/20090313/bin/../libexec/gcc/avr/4.3.2/cc1.exe -E -quiet -v -I.
-imultilib avr5 -iprefix e:\winavr\20090313\bin\../lib/gcc/avr/4.3.2/ -MD vat.d
-MF .dep/vat.o.d -MP -MQ vat.o -DF_CPU=8000000UL -DBOOTSIZE=1024 vat.c
-mmcu=atmega16
-std=gnu99 -Wall -Winline -Wstrict-prototypes -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -fno-inline-small-functions
-fworking-directory -Os -fpch-preprocess -o vat.i
ignoring nonexistent directory
"e:/winavr/20090313/lib/gcc/../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 .
 e:\winavr\20090313\bin\../lib/gcc/avr/4.3.2/include
 e:\winavr\20090313\bin\../lib/gcc/avr/4.3.2/include-fixed
 e:/winavr/20090313/lib/gcc/../../lib/gcc/avr/4.3.2/include
 e:/winavr/20090313/lib/gcc/../../lib/gcc/avr/4.3.2/include-fixed
 e:/winavr/20090313/lib/gcc/../../avr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-c' '-mmcu=atmega16' '-I.' '-gdwarf-2'
'-DF_CPU=8000000UL' '-DBOOTSIZE=1024' '-Os' '-save-temps' '-funsigned-char'
'-funsigned-bitfields' '-fpack-struct' '-fshort-enums'
'-fno-inline-small-functions' '-Wall' '-Winl
ine' '-Wstrict-prototypes' '-std=gnu99' '-MD' '-MP' '-MF' '.dep/vat.o.d' '-o'
'vat.o'
 e:/winavr/20090313/bin/../libexec/gcc/avr/4.3.2/cc1.exe -fpreprocessed vat.i
-quiet -dumpbase vat.c -mmcu=atmega16 -auxbase-strip vat.o -gdwarf-2 -Os -Wall
-Winline -Wstrict-prototypes -std=gnu99 -version -funsigned-char
-funsigned-bitfiel
ds -fpack-struct -fshort-enums -fno-inline-small-functions -o vat.s
GNU C (WinAVR 20090313) version 4.3.2 (avr)
        compiled by GNU C version 3.4.5 (mingw-vista special r3), GMP version
4.2.3, MPFR version 2.4.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: abe89850c430a90419070abaa31bf632
COLLECT_GCC_OPTIONS='-v' '-c' '-mmcu=atmega16' '-I.' '-gdwarf-2'
'-DF_CPU=8000000UL' '-DBOOTSIZE=1024' '-Os' '-save-temps' '-funsigned-char'
'-funsigned-bitfields' '-fpack-struct' '-fshort-enums'
'-fno-inline-small-functions' '-Wall' '-Winl
ine' '-Wstrict-prototypes' '-std=gnu99' '-MD' '-MP' '-MF' '.dep/vat.o.d' '-o'
'vat.o'
 e:/winavr/20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/as.exe
-mmcu=atmega16 -adhlns=vat.lst -o vat.o vat.s
COMPILER_PATH=e:/winavr/20090313/bin/../libexec/gcc/avr/4.3.2/;e:/winavr/20090313/bin/../libexec/gcc/;e:/winavr/20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/
LIBRARY_PATH=e:/winavr/20090313/bin/../lib/gcc/avr/4.3.2/avr5/;e:/winavr/20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr5/;e:/winavr/20090313/bin/../lib/gcc/avr/4.3.2/;e:/winavr/20090313/bin/../lib/gcc/;e:/winavr/20090313/bin/../l
ib/gcc/avr/4.3.2/../../../../avr/lib/
COLLECT_GCC_OPTIONS='-v' '-c' '-mmcu=atmega16' '-I.' '-gdwarf-2'
'-DF_CPU=8000000UL' '-DBOOTSIZE=1024' '-Os' '-save-temps' '-funsigned-char'
'-funsigned-bitfields' '-fpack-struct' '-fshort-enums'
'-fno-inline-small-functions' '-Wall' '-Winl
ine' '-Wstrict-prototypes' '-std=gnu99' '-MD' '-MP' '-MF' '.dep/vat.o.d' '-o'
'vat.o'


-- 
           Summary: faulty value assignment
           Product: gcc
           Version: 4.3.2
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: szir at sch dot bme dot hu


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

[Bug c/39593] faulty value assignment

[szir at sch dot bme dot hu]

------- Comment #1 from szir at sch dot bme dot hu  2009-03-30 23:53 -------
Created an attachment (id=17561)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17561&action=view)
preprocessed test case


-- 


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

[Bug target/39593] faulty value assignment

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal
          Component|c                           |target
 GCC target triplet|                            |avr
            Summary|faulty value assignment     |faulty value assignment


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

[Bug target/39593] faulty value assignment

[szir at sch dot bme dot hu]

------- Comment #2 from szir at sch dot bme dot hu  2009-03-30 23:56 -------
Created an attachment (id=17562)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17562&action=view)
compile environment


-- 


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

[Bug target/39593] faulty value assignment

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2009-03-30 23:57 -------

 BYTE b[4];

 *((DWORD *)b) = x;


this is violating aliasing rules.  Does adding -fno-strict-aliasing allow this
to work?


-- 


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

[Bug target/39593] faulty value assignment

[szir at sch dot bme dot hu]

------- Comment #4 from szir at sch dot bme dot hu  2009-03-30 23:58 -------
Created an attachment (id=17563)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17563&action=view)
test case source


-- 


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

[Bug target/39593] faulty value assignment

[szir at sch dot bme dot hu]

------- Comment #5 from szir at sch dot bme dot hu  2009-03-31 00:09 -------
Created an attachment (id=17564)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17564&action=view)
compiled assembly lists

vat_20060421.lss gcc 3.4.6
vat_20070525.lss gcc 4.1.2
vat_20080610.lss gcc 4.3.0
vat_20081205.lss gcc 4.3.2
vat_20090313.lss gcc 4.3.2


-- 


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

[Bug target/39593] faulty value assignment

[szir at sch dot bme dot hu]

------- Comment #6 from szir at sch dot bme dot hu  2009-03-31 00:20 -------
(In reply to comment #3)
>  BYTE b[4];
>  *((DWORD *)b) = x;
> this is violating aliasing rules.  Does adding -fno-strict-aliasing allow this
> to work?

If you look at the code you can see it is never called, the only code that is
actually called at all is the InitTF() assignments, the rest is just junk, that
confuses the compiler.

And -fno-strict-aliasing does not help, by the way the junk code works just
fine, that is not the problem. Thanks anyway, I added -fno-strict-aliasing to
makefile.


-- 


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

[Bug target/39593] faulty value assignment

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2009-03-31 09:44 -------
For convenience, here is the testcase reduced (I didn't verify it still
"fails",
but it obviously should).

unsigned long key32[8];
void __attribute__((noinline)) InitTF(void)
{
  key32[0]=0x00010203;
  key32[1]=0x04050607;
  key32[2]=0x08091011;
  key32[3]=0x12131415;
  key32[4]=0x00010203;
  key32[5]=0x04050607;
  key32[6]=0x08091011;
  key32[7]=0x12131415;
}
void abort (void);
int main()
{
  InitTF();
  if (key32[1] != 0x04050607 || key32[5] != 0x04050607)
    abort ();
  return 0;
}

Can you check if that causes a runtime failure?  It indeed looks like a
target issue related to loading constants.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code


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

[Bug target/39593] faulty value assignment

[szir at sch dot bme dot hu]

------- Comment #8 from szir at sch dot bme dot hu  2009-03-31 12:05 -------
(In reply to comment #7)
> For convenience, here is the testcase reduced (I didn't verify it still
> "fails", but it obviously should).
No it should not, the junk code is necessary to produce the error. As I said
before if I remove any more lines from the code, it won't produce the bug.
I suspect it's because it's massive register usage.

> Can you check if that causes a runtime failure?  It indeed looks like a
> target issue related to loading constants.
I tried your testcase, it uses r24 as a temp reg. (won't corrupt the value)
I inserted the junk code into your testcase, and the bug rearreared, but only
if it is inserted before InitTF.

#include "junk.i.c"  ///BUG
unsigned long key32[8];
//#include "junk.i.c" ///BUG 
void __attribute__((noinline)) InitTF(void)
{
  key32[0]=0x00010203;
  key32[1]=0x04050607;
  key32[2]=0x08091011;
  key32[3]=0x12131415;
  key32[4]=0x00010203;
  key32[5]=0x04050607;
  key32[6]=0x08091011;
  key32[7]=0x12131415;
}
//#include "junk.i.c"  ///r24
void abort (void);
int main()
{
  InitTF();
  if (key32[1] != 0x04050607 || key32[5] != 0x04050607)
    abort ();
  return 0;
}
//#include "junk.i.c"   ///r24


-- 


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

[Bug target/39593] faulty value assignment

[szir at sch dot bme dot hu]

------- Comment #9 from szir at sch dot bme dot hu  2009-03-31 12:10 -------
Created an attachment (id=17570)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17570&action=view)
junk code to reproduce the bug

this is a reduced portion of the original program and the simplest that still
generates the bug


-- 


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

[Bug target/39593] [avr] faulty value assignment

[eric dot weddington at atmel dot com]

------- Comment #10 from eric dot weddington at atmel dot com  2009-04-06 22:38 -------
This looks like a duplicate of bug #37466.

*** This bug has been marked as a duplicate of 37466 ***


-- 

eric dot weddington at atmel dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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