RE: [avr-gcc-list] testsuite saga continues

[Wouter van Gulik]

> Hi all,
> 
> I'm still trying to get the testsuite to pass all tests cleanly.
> 
> Yesterday I've done a patch to mark as unsupported tests that used the
> "double" type. This helps float-floor.c pass the test (as unsupported)
> but 538 tests (just in execute.exp) are also marked as unsupported
> because of this.
> 
> It seems like a bad trade-off, so I'll try to come up with a way to
> change just float-floor.c to "#ifdef" on the size of the double type, so
> that it doesn't fail, and we can keep all the other tests.
> 
> In the meantime, I tried to not mark "long long" as unsupported, with
> similar results.
> 
> Without "no_long_long" there are more 32 tests that fail, but less 556
> tests are marked as unsupported. Which means that 64 bit "long long"'s
> are mostly supported in fact.
> 
> The question is: are "long long"'s officially supported? Should we be
> running the tests that use them?
> 

Well, the GCC library provides most (if not all) functions for 64-bit
operations. Alas this is written in C and the compiler can't make this
nearly as good as an handwritten assembler routine. Mostly due to the lack
of carry support in gcc.

Do you have a clue on why the tests fail? There is an ugly bug concerning
stack allocation and 64 bit variables, maybe that is the evil one. See:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27386 for details.

> BTW: 64 bit long long is really hard for a 8 bit microcontroller. At
> least one of the tests (with -O0 optimization) was initially failing
> from timeout, which means that it was taking more than 500 million
> cycles to execute. Increasing the timeout to 2 billion cycles solved the
> problem, though.
> 

This is probably due to earlier mentioned not so optimal libgcc long long
implementation.

Wouter