RE: [avr-gcc-list] More results from the testsuite with avrtest

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Paulo Marques
> Sent: Saturday, January 19, 2008 11:27 AM
> To: address@hidden
> Subject: [avr-gcc-list] More results from the testsuite with avrtest
> 
> 
> Hi, all
> 
> I've been running the testsuite from SVN with avrtest to 
> track down the 
> latest bugs. I've finally track down every failure in 
> execute.exp, and 
> I'm preparing to move on to the full testsuite (I hope).
> 
> So, here's a list of all the problems so far:
> 
<snip>
> 
> 
> FAIL: gcc.c-torture/execute/built-in-setjmp.c execution,  -O2
> FAIL: gcc.c-torture/execute/built-in-setjmp.c execution,  -O3 
> -fomit-frame-pointer
> FAIL: gcc.c-torture/execute/built-in-setjmp.c execution,  -O3 
> -fomit-frame-pointer -funroll-loops
> FAIL: gcc.c-torture/execute/built-in-setjmp.c execution,  -O3 
> -fomit-frame-pointer -funroll-all-loops -finline-functions
> FAIL: gcc.c-torture/execute/built-in-setjmp.c execution,  -O3 -g
> FAIL: gcc.c-torture/execute/built-in-setjmp.c execution,  -Os
> 
> This is an actual bug, that only appears with O2, O3 or Os. The 
> __builtin_setjmp stores Y+1 in the setjmp buffer. With -O0 the first 
> instruction after the jmp does a "sbiw r28, 1" that restores the 
> original value, but for some reason, with higher optimization levels, 
> this instruction is optimized away, leaving R28 pointing to the wrong 
> address by one.
> 
> The __builtin_setjmp code:
> 
>   if (__builtin_setjmp (buf))
> 16a:  ce 01           movw    r24, r28
> 16c:  01 96           adiw    r24, 0x01       ; 1
>   Notice the increment here, before storing R28
> 
> 16e:  90 93 07 01     sts     0x0107, r25
> 172:  80 93 06 01     sts     0x0106, r24
> 176:  8f ee           ldi     r24, 0xEF       ; 239
> 178:  90 e0           ldi     r25, 0x00       ; 0
> 17a:  90 93 09 01     sts     0x0109, r25
> 17e:  80 93 08 01     sts     0x0108, r24
> 182:  ed b7           in      r30, 0x3d       ; 61
> 184:  fe b7           in      r31, 0x3e       ; 62
> 186:  f0 93 0b 01     sts     0x010B, r31
> 18a:  e0 93 0a 01     sts     0x010A, r30
> 
> The __builtin_longjmp code:
> 
>   __builtin_longjmp (buf, 1);
> 10c:  e0 91 08 01     lds     r30, 0x0108
> 110:  f0 91 09 01     lds     r31, 0x0109
> 114:  c0 91 06 01     lds     r28, 0x0106
> 118:  d0 91 07 01     lds     r29, 0x0107
> 11c:  80 91 0a 01     lds     r24, 0x010A
> 120:  90 91 0b 01     lds     r25, 0x010B
> 
> no decrement, R28 is used "as is".
> 
> 
> FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation,  -O0
> FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation,  -O1
> FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation,  -O2
> FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation,  -O3 
> -fomit-frame-pointer
> FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation,  -O3 
> -fomit-frame-pointer -funroll-loops
> FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation,  -O3 
> -fomit-frame-pointer -funroll-all-loops -finline-functions
> FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation,  -O3 -g
> FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation,  -Os
> 
> This test fails compilation with these errors:
> 
> builtin-bitops-1.c:(.text+0x672): undefined reference to `__ffshi2'
> builtin-bitops-1.c:(.text+0x6b4): undefined reference to 
> `__popcounthi2'
> builtin-bitops-1.c:(.text+0x6ee): undefined reference to `__parityhi2'
> builtin-bitops-1.c:(.text+0x183e): undefined reference to `__clzhi2'
> builtin-bitops-1.c:(.text+0x1872): undefined reference to `__ctzhi2'
> 
> Maybe these should be defined in avr-libc? Is there something wrong 
> with my setup?


No. AFAIK, these are not defined for the AVR.

All of the above look like real bugs. I don't know of any bug reports
for these (yet).

 
> 
> FAIL: gcc.c-torture/execute/ffs-1.c compilation,  -O0
> FAIL: gcc.c-torture/execute/ffs-1.c compilation,  -O1
> FAIL: gcc.c-torture/execute/ffs-1.c compilation,  -O2
> FAIL: gcc.c-torture/execute/ffs-1.c compilation,  -O3 
> -fomit-frame-pointer
> FAIL: gcc.c-torture/execute/ffs-1.c compilation,  -O3 -g
> FAIL: gcc.c-torture/execute/ffs-1.c compilation,  -Os
> 
> This one just needs:
> 
> ffs-1.c:(.text+0x8): undefined reference to `__ffshi2'
> 
> 
> FAIL: gcc.c-torture/execute/ffs-2.c compilation,  -O0
> FAIL: gcc.c-torture/execute/ffs-2.c compilation,  -O1
> FAIL: gcc.c-torture/execute/ffs-2.c compilation,  -O2
> FAIL: gcc.c-torture/execute/ffs-2.c compilation,  -O3 
> -fomit-frame-pointer
> FAIL: gcc.c-torture/execute/ffs-2.c compilation,  -O3 
> -fomit-frame-pointer -funroll-loops
> FAIL: gcc.c-torture/execute/ffs-2.c compilation,  -O3 
> -fomit-frame-pointer -funroll-all-loops -finline-functions
> FAIL: gcc.c-torture/execute/ffs-2.c compilation,  -O3 -g
> FAIL: gcc.c-torture/execute/ffs-2.c compilation,  -Os
> 
> And again:
> 
> ffs-2.c:(.text+0x8): undefined reference to `__ffshi2'
> ffs-2.c:(.text+0x20): undefined reference to `__ffshi2'
> ffs-2.c:(.text+0x38): undefined reference to `__ffshi2'
> ffs-2.c:(.text+0x50): undefined reference to `__ffshi2'
> 

Again, it looks like the above needs bug reports.


 
> FAIL: gcc.c-torture/execute/float-floor.c execution,  -O0
> FAIL: gcc.c-torture/execute/float-floor.c execution,  -O1
> FAIL: gcc.c-torture/execute/float-floor.c execution,  -O2
> FAIL: gcc.c-torture/execute/float-floor.c execution,  -O3 
> -fomit-frame-pointer
> FAIL: gcc.c-torture/execute/float-floor.c execution,  -O3 -g
> FAIL: gcc.c-torture/execute/float-floor.c execution,  -Os
> 
> This test seems to only work if we have a 8 byte "double" type. So, 
> this should probably be unsupported for avr.
> 

Agreed. Although at some point it would be nice to have 8 byte double
types for the AVR.

 
> FAIL: gcc.c-torture/execute/multi-ix.c compilation,  -O0
> FAIL: gcc.c-torture/execute/multi-ix.c compilation,  -O1
> FAIL: gcc.c-torture/execute/multi-ix.c compilation,  -O2
> FAIL: gcc.c-torture/execute/multi-ix.c compilation,  -O3 
> -fomit-frame-pointer
> FAIL: gcc.c-torture/execute/multi-ix.c compilation,  -O3 
> -fomit-frame-pointer -funroll-loops
> FAIL: gcc.c-torture/execute/multi-ix.c compilation,  -O3 
> -fomit-frame-pointer -funroll-all-loops -finline-functions
> FAIL: gcc.c-torture/execute/multi-ix.c compilation,  -O3 -g
> FAIL: gcc.c-torture/execute/multi-ix.c compilation,  -Os
> 
> This fails compilation with:
> 
> testsuite/multi-ix.c:38: error: total size of local objects too large
> 
> This code allocates large objects on the stack. To avoid 
> having a stack 
> overflow, it calculates the maximum size it gives to the type 
> used for 
> the vars on the stack using this macro:
> 
> #define CHUNK ((STACK_SIZE-40*sizeof(int)-256*sizeof(void 
> *))/40/sizeof(int))
> 
> since our tests run with STACK_SIZE=400, this gives
> 
> ((400-40*2-256*2) / 40 / 2) = -2
> 
> If I change the STACK_SIZE to 1000, the test runs successfully. Since 
> the atmega128 has 4Kb of RAM, maybe we should increase our 
> requirements 
> a little.

Agreed. 

>From what I remember, there are some other test in the test suite that
fail on the AVR because the AVR does not have enough RAM to support
those tests. In those cases, those tests should be disabled for the AVR.


 
> FAIL: gcc.c-torture/execute/pr17377.c execution,  -O0
> FAIL: gcc.c-torture/execute/pr17377.c execution,  -O1
> FAIL: gcc.c-torture/execute/pr17377.c execution,  -O2
> FAIL: gcc.c-torture/execute/pr17377.c execution,  -O3 
> -fomit-frame-pointer
> FAIL: gcc.c-torture/execute/pr17377.c execution,  -O3 -g
> FAIL: gcc.c-torture/execute/pr17377.c execution,  -Os
> 
> This also uses __builtin_return_address. Still tracking down this one.
> 

See AVR GCC bug #21080
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21080>
It references __builtin_return_address. A comment in that bug also
references bug #21078:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21078>
Which I mentioned earlier.

So it's possible that these could all be related.

 
> FAIL: gcc.c-torture/execute/pr22493-1.c execution,  -O1
> FAIL: gcc.c-torture/execute/pr22493-1.c execution,  -O2
> FAIL: gcc.c-torture/execute/pr22493-1.c execution,  -Os
> 
> This is an actual bug. This function:
> 
> void f(int i)
> {
>   if (i>0)
>     abort();
>   i = -i;
>   if (i<0)
>     return;
>   abort ();
> }
> 
> is compiled to:
> 
> void f(int i)
> {
>   abort ();
> }
> 
> because "if (i <= 0)", then "(-i >= 0)" must be true, right?
> 
> Unfortunately this is wrong for the corner case where "i = INT_MIN", 
> because "-i" is also INT_MIN.


Then it probably needs a bug report.
 

 
> FAIL: gcc.c-torture/execute/pr27364.c execution,  -O1
> FAIL: gcc.c-torture/execute/pr27364.c execution,  -O2
> FAIL: gcc.c-torture/execute/pr27364.c execution,  -Os
> 
> This test assumes 32 bit integers.

Then the test itself needs to be fixed. There have been a number of
cases like this recently where the test would fail on another 16-bit
integer target, and the test was fixed so as to not make that
assumption.

 
> And that's all, at least for now ;)

Fantastic!! :-)
 
<snip>
> 
> 
> Now I'm trying to report all this through gcc's bugzilla, but I'm 
> having some problems with the "component" selection. Possible choices:
> 
> - "target" if this is specific to avr, but how do I know that? Do I 
> need to run the tests in other archs?

Go ahead and report it as "target" first, since it is mostly likely a
target issue. If the problem turns out to be non-target specific, it
will get changed later.
 
> - "c", "middle-end", for the C frontend and middle-end, but 
> where does 
> the error come from? That would involve tracking down the 
> error, which 
> should be done after reporting it, no?

Yes, it will be done after reporting.

 
> - "regression" has "regression tester failures" in the help 
> text. Well, 
> these are all regression tester failures. Maybe I should use this one 
> for everything?

The problem is that we don't know if this is a regression in the AVR
port. It could be that it never worked in the first place so this is
truly not a regression.
 
> - "testsuite" for problems in the testsuite framework itself

Also set it to "testsuite" if the test itself needs fixing, like the
test that assumes 32-bit integers.
 
> Suggestions?

Set the "Target" field to "avr-*-*", and please let me know the bug
numbers so I can get on the CC list and track these bugs on the AVR GCC
bug list:
<http://www.nongnu.org/avr-libc/bugs.html>

In the end, it is better to get the bugs reported first, even if the
fields aren't completely correct. That stuff can always be fixed up
later.


A VERY BIG THANK YOU! for doing all of this! This work will go a long
way towards improving the quality of the AVR toolchain!

Eric Weddington