References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
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