Re: Obsoleting c4x last minute for 4.0

[Björn Haase <bjoern dot m dot haase at web dot de>]

References: <20050405.113624.90807942.kazu@cs.umass.edu> 
<425306C6.10605@codesourcery.com> <20050405230451.GA26848@synopsys.com> 
<42531F93.90508@codesourcery.com> 
<1112780244.1601.3.camel@pc960.cambridge.arm.com> 
<Pine.LNX.4.61.0504061041580.12059@digraph.polyomino.org.uk>

Joseph Myers wrote: 
>One possible way of assessing activity would be to say that after 4.1 
maintained CPU ports should have test results for mainline regularly sent to 
gcc-testresults and monitored for regressions, though this rather depends on 
the willingness of maintainers of embedded ports to do this testing; ports 
without such testing and regression monitoring could be considered at risk.
 
> Only the following ports seem to have had results for 4.1.0-mainline (i.e. 
mainline since 4.0 branched) sent to gcc-testresults: alpha, arm, hppa, 
i?86/x86_64, ia64, mips, powerpc, s390, sh, sparc, although cris and mmix are 
evidently monitored for regressions even though they don't get test results 
to gcc-testresults.
 
 Eric Weddington wrote
>Add the AVR to the list of ports that (so far) haven't had test results sent 
to gcc-testresults. It's only been recently that the GCC test suite has been 
able to run for the AVR using an outside simulator. Hopefully in the future 
this will change; there's a lot of work being done on the AVR port.
 
There have been at least two testsuite reports for the AVR family on 
gcc-testresults by me and head 4.1 is regularly tested by me with the 
testsuite (about once a week). Excecuting tests are realized with the 
simulavr simulator. The procedure of running the test with simulavr is not of 
the turn-key type but not too complicated either. 

The reason why I have stopped posting the test results is that we are 
currently having 481 failures for the AVR target and the existing real bugs 
are completely hidden behind the huge number of failures due to issues like 
"test needs trampolines but does not communicate it" or "test case assumes 
int to be 32 bit". 
IMHO regularly posting the same huge bug list is was not useful at all unless 
one could distinguish between *real* and *pseudo* failures.

I had started to adapt the testsuite by adding functionality for communicating 
that a test case asssumes int to be 32 bit and by means to switch of all 
tests that require trampolines. 

Unfortunately, I did not get any response to the patch I had posted to 
gcc-patches a couple of months ago implementing additional effective target 
keywords :-(. A useful reworking of dozens of the affected test cases 
requires that new effective targets are present and that their names are 
agreed upon. Since I did not get any response on it, I did refrain to 
continue to work on testsuite adaptions so far.

Yours,

Björn