[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Test results for avr-gcc-3.4.3 with test suite adapte

From: E. Weddington
Subject: Re: [avr-libc-dev] Test results for avr-gcc-3.4.3 with test suite adapted for avr
Date: Thu, 06 Jan 2005 12:24:45 -0700
User-agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)

Rolf Ebert wrote:

On Wed, 5 Jan 2005 16:16:59 +0100, Björn Haase <address@hidden> wrote:

Find enclosed the repeated and "cleaned-up" test report for the avr

thank you very much, Björn, for your efforts!

Yes, thank you!

When adapting the test suite, I had to decide for a couple of cases whether a test is relevant for avr or not. A couple of failures stems from the fact
that required header files are not present. They reflect, thus, rather a
missing support of the std library than a problem with the compiler itself. For header files, that I personally assumed to be not relevant for avr, I decided to mark the test to be XFAIL. I would appreciate comments from the
other avr users for the following points :

I think we can to distinguish between features that will never be supported (XFAIL) and features, that are currently missing (preliminary XFAIL?). The preliminary XFAIL cases are reminders to complete the libc in the future.

5.) nested functions
Due to the Harvard-Architecture of avr, gcc seems to have always problems when using nested functions: Gcc seems to try to use trampolines all the time. a feature rather than a bug. IMHO the only real use of nested functions is to employ them for passing pointers to them to other functions. IIRC, however,
this allways requires the use of trampolines.

Nested functions are very common in Ada and Pascal. I don't know about gpc, but gnat heavily relies on the GNU extension of nested functions in C. It'd be helpful for AVR-Ada if they were tested at the C testsuite already.

6.) Presently alias attributes are not supported for avr. I have marked
tests as XFAIL if they use this feature. (This should be discussed!).

Aliasing gives lots of hints for the optimizer; a feature that would be useful to AVR-gcc. I think they should be marked as preliminary XFAIL.


P.S. There is nothing like "preliminary XFAIL". We probably have to document that elsewhere, something like a TODO list.

As I understand it, XFAIL means an expected failure, which makes sense for tests that don't apply to the AVR. The FAIL code means an *unexpected* failure, and this makes sense on tests that are applicable to the AVR, but are not working due to a bug. So instead of a "preliminary XFAIL", just mark them as FAIL and let's get them in the bug database.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]