Mark Mitchell wrote:
Joel Sherrill wrote:
Ralf encountered problems on the avr and bfin during the tool
build and has filed or updated PRs for those.
Understood, and thnanks for testing!
I should make clear that I don't see release candidates as opportunities
for general testing; they're final release candidates, not alpha
releases. The open nature of GCC development means that testing by
stakeholders can (and should) be done well before this point. The
testing of release candidates should be generally to confirm expected
behavior: do the results that you saw the last time you ran tests,
against an SVN checkout, match what you see today, with a release tarball?
To be honest we did a lot more testing against pre 4.1 SVN code than against
pre 4.2. All the talk about 4.2 being in bad shape on primary targets
made us leary. Plus we had our own project's fish to fry. :)
I don't see any problems at this point though except on the avr and bfin.
This is in no way a criticism, or a comment on RETMS testing (about
which I know almost nothing), etc.; just a general comment, which your
message gave me the excuse to make. :-)
No criticism taken. If someone wants to volunteer to help us improve our
testing of gcc, we have ideas which would be mutually beneficial to both
RTEMS and gcc. If there is bandwidth and a volunteer to help, it would
be a good candidate for the Compile Farm.
It just takes a lot of build time for us to get a test toolset in place
and test it.
We build gcc C/C++ RPMs for about 10-12 targets including newlib.
That ends up generating 70 libc.a instances once installed. Then we build
RTEMS, common add-on packages, and examples for over 100
multilib and board specific configurations. wc reports that source base
as about 915K lines of code.
It's just a matter of human time and machine time. Both are in short
supply. :)
--joel
Thanks,
