This is the mail archive of the
mailing list for the GCC project.
Re: Overwhelmed by GCC frustration
- From: Jeff Law <law at redhat dot com>
- To: Joel Sherrill <joel dot sherrill at oarcorp dot com>, Oleg Endo <oleg dot endo at t-online dot de>, Georg-Johann Lay <avr at gjlay dot de>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 31 Jul 2017 11:50:05 -0600
- Subject: Re: Overwhelmed by GCC frustration
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5C2F3C0587D7
- References: <597F2FB4.email@example.com> <firstname.lastname@example.org> <email@example.com>
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
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
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
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 :-)