> 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 _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
