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

[Björn Haase]

Am Donnerstag, 6. Januar 2005 20:24 schrieb E. Weddington:
> >> 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
In my opion this should be the guide line for the test case classification.
> > (preliminary  XFAIL?).  The preliminary XFAIL cases are reminders to
> > complete the libc  in the future.
IIUC "XFAIL" is meant to be used for what you are calling "preliminary XFAIL". 
There is another possibility, to mark a test case as UNSUPPORTED. 

> >
> >> 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.
Presently avr-gcc seems not able to use any nested function at all. The only 
way that I am seeing now to implement nested functions would mean much much 
work and would be doomed to be very inefficient: All the used local variables 
would be forced to reside im memory instead of registers and the nested 
function itself would probably need to learn to work with two frame pointers 
simultaneously (one for the host function variables and one for the own local 
ones). And even given that, one would have big difficulties with making the 
code reentrant.
Maybe a good approach would be to mark all nested functions that *really* 
would need to use trampolines are marked as UNSUPPORTED. I.e. I am talking 
about nested functions for which a pointer to the function is passed to 
another function. Unfortunately this is probably the most useful application 
of nested functions.
The other test cases then would be marked as XFAIL. I.e. nested functions that 
merely are used for making the structure of the code more transparent and 
that could as well be replaced by explicit "inlining" of the programer.

> >
> >> 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.
Maybe I did not understand this issue too well. I had the impression that the 
attributes I am talking about were used for overriding the naming convention 
the compiler is using when giving symbols names. E.g. in order to force the 
compiler to generate a different symbol name in the assembler sources than 
the name in C. E.g. genreate a label "hugo" for a variable that is refered to 
in C code as "int frieda;".  Look e.g. at weak-3. This test case does also 
test for functional alias attributes.

> 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.
Yes. That is how also I understood it.

I so far have committed a bug report for the a << -13 problem. In my opinion 
we should, however, at least issue a warning that such type of code is very 
probably a programing mistake. I have already posted a patch that should 
remove the problem. This already reduces the amount of compile failures 
significantly.

An important source of failure -- if you are looking at the failure number -- 
are the 54 failures due to debugging issues. I so far have no idea what the 
origin is. I would appreciate if someone else with more experience with the 
debugging formats could have a look at it.

Yours,

Björn.