On 07/31/2017 10:49 AM, Joel Sherrill wrote: > > > On 7/31/2017 11:12 AM, Oleg Endo wrote: >> On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote: >>> Around 2010, someone who used a code snipped that I published in >>> a wiki, reported that the code didn't work and hang in an >>> endless loop. Soon I found out that it was due to some GCC >>> problem, and I got interested in fixing the compiler so that >>> it worked with my code. >>> >>> 1 1/2 years later, in 2011, [...] >> >> I could probably write a similar rant. This is the life of a "minority >> target programmer". Most development efforts are being done with >> primary targets in mind. And as a result, most changes are being >> tested only on such targets. >> >> To improve the situation, we'd need a lot more target specific tests >> which test for those regressions that you have mentioned. Then of >> course somebody has to run all those tests on all those various >> targets. I think that's the biggest problem. But still, with a test >> case at hand, it's much easier to talk to people who have silently >> introduced a regression on some "other" targets. Most of the time they >> just don't know. > > Long ago, there was a code size regression tester for at least > ARM. Is that still around? > > RTEMS also has a number of "minority targets" and we have seen > breakages take a long time to get fixed. Most of our targets > use gcc 7.1.0 but two have to use 4.9.x, one uses 4.8.3, and > one is at 6.3.0. One of the things that I think would improve this situation would be a public build-bot for RTEMS targets.
I've actually got some bits along this path (but not for RTEMS). Essentially config-list.mk is useful for verifying that our various targets compile/link. But it doesn't verify that the resulting compiler has any functionality at all. But we can use newlib, glibc, rtems, etc to do that next level of testing. So my buildbot will first build binutils, then gcc, then newlib/glibc. I briefly looked at building rtems as part of that process, but I didn't find the instructions particularly clear/useful. Ultimately I determined I was getting good enough coverage at this step with newlib/glibc. Anyway, that gives us a basic level of testing the code generator. It doesn't run the testsuite or anything like that, but it has been useful in catching problems earlier. The second problem is once you build the buildbot, then someone has to actually monitor the results, and either fix the problems or farm them out to the appropriate engineer :-) jeff
