This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 10/12] always define EH_RETURN_HANDLER_RTX
- From: Mike Stump <mikestump at comcast dot net>
- To: Jeff Law <law at redhat dot com>
- Cc: Bernd Schmidt <bschmidt at redhat dot com>, Trevor Saunders <tbsaunde at tbsaunde dot org>, tbsaunde+gcc at tbsaunde dot org, gcc-patches at gcc dot gnu dot org
- Date: Mon, 9 Nov 2015 13:05:56 -0800
- Subject: Re: [PATCH 10/12] always define EH_RETURN_HANDLER_RTX
- Authentication-results: sourceware.org; auth=none
- References: <1447087669-14039-1-git-send-email-tbsaunde+gcc at tbsaunde dot org> <1447087669-14039-11-git-send-email-tbsaunde+gcc at tbsaunde dot org> <5640E580 dot 90607 at redhat dot com> <5640E90B dot 8060808 at redhat dot com> <20151109185201 dot GC22527 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <5640F645 dot 1000002 at redhat dot com> <5640F819 dot 7070102 at redhat dot com>
On Nov 9, 2015, at 11:46 AM, Jeff Law <law@redhat.com> wrote:
On 11/09/2015 12:38 PM, Bernd Schmidt wrote:
>> We might want to think about making a policy decision to try waiving
>> some of the testing requirements for target macro -> hook conversions.
>> Maybe try only a "build to cc1" requirement and see whether that causes
>> too much breakage.
> A config-list.mk build is a build to cc1*, f951, gnat1, so we're not requiring deep tests on the affected targets. Not sure how much we're getting by forcing a bootstrap & regression test of that kind of change.
>
> I'm certainly open to this kind of relaxed testing to help this stuff move forward an complete before we're all retired :-)
Testing is a cornerstone of gcc quality. I like it. It is useful. That said, I don’t think we should always be fanatical about it. How and when we accept less that a standard bootstrap and regression test run I’ve sure would be a big topic, but rather than make a ton of rules, I’d rather let small handful of reviewers decide when and how to accept less, and let them do what they want. We can give them negative feedback if it impacts too many people, too often and they can adjust.
The other way, would be to have an integration branch that is tested and merged post testing on a regular basis and let people contribute less than well tested things on it, the idea being that it still won’t hit trunk until after a bootstrap and tests suite run, but that we can bundle 2-100 patches into one test suite run. This strikes me as more scalable, easier for developers and removes the requirement of test suite + bootstrap before checkin while retaining the useful quality of everything merged to trunk is tested. Hardest part about this would be ChangeLogs, merge resolution and svn blame. git handles this gracefully. svn as I recall, a little less so. [ quick check ] Ah, seems svn blame -g TARGET ca n handle this graceful (in theory).