This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Split out some tests from builtins-20.c
- From: Mike Stump <mikestump at comcast dot net>
- To: Richard Sandiford <richard dot sandiford at arm dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 15 Oct 2015 14:03:29 -0700
- Subject: Re: Split out some tests from builtins-20.c
- Authentication-results: sourceware.org; auth=none
- References: <87h9lsi81p dot fsf at e105548-lin dot cambridge dot arm dot com> <C8596A11-B6D9-40B0-AAE5-2A7DB927555A at comcast dot net> <87eggv29tg dot fsf at e105548-lin dot cambridge dot arm dot com> <95C2720B-4BFA-4E08-AA6B-5D2AD0134FAC at comcast dot net> <87a8rj27gb dot fsf at e105548-lin dot cambridge dot arm dot com>
On Oct 15, 2015, at 1:38 PM, Richard Sandiford <richard.sandiford@arm.com> wrote:
> Mike Stump <mikestump@comcast.net> writes:
>> On Oct 15, 2015, at 12:47 PM, Richard Sandiford
>> <richard.sandiford@arm.com> wrote:
>>> I can see that argument if people are only taking work items from
>>> the PR database. But it's possible (likely even) that people will
>>> independently find a problem like this and just fix it, if the missed
>>> optimisation happens to be important to them. I don't think they
>>> should then have to trawl the PR database to see which PRs their patch
>>> fixes.
>>
>> There is no requirement that they do.
>
> But if they don't the original test stays #if 0d out.
Only until someone retests the PR.
> I don't see why that's better than having an XFAIL become an XPASS, so that it's
> obvious that the XFAIL can be removed and we get the test back quicker.
I have a slight preference to not split the test cases in this case. As I said, it isn’t a big deal, and if you feel it is better to split the test case, then your patch is ok. I think it is trivial as I don’t know of a reason why someone should reject it.