RFC: Monitoring old PRs, new dg directives

Nathan Sidwell nathan@acm.org
Fri Aug 7 13:21:27 GMT 2020


On 8/6/20 6:55 PM, Marek Polacek wrote:
> On Thu, Aug 06, 2020 at 10:01:37AM -0400, Nathan Sidwell wrote:
>> On 8/5/20 7:29 PM, Marek Polacek wrote:
>>> On Wed, Aug 05, 2020 at 11:03:08AM -0400, Nathan Sidwell wrote:
>>>> On 8/4/20 8:54 PM, Marek Polacek via Gcc-patches wrote:
>>>>> On Tue, Aug 04, 2020 at 03:33:23PM -0700, Mike Stump wrote:
>>>>>> I think the read of the room is that people think it would be generally useful, so let approve the general plan.
>>>>>
>>>>> Cool.
>>>>>
>>>>>> So, now we are down to the fine details.  Please do see just how far you can stretch the existing mechanisms to cover what you need to do.  I think the existing mechanisms should be able to cover it all; but the devil is in the details and those matter.
>>>>>
>>>>> At this point I'm only proposing one new directive, dg-ice.  I think we can't
>>>>> really do without it.  The other one was a matter of convenience.
>>>>
>>>> I've realized I have a concern.  Grepping (or searching in an editor buffer)
>>>> the log file for 'internal compiler error' to find actual regressions is a
>>>> thing I want to still be able to do (perhaps with alternative spelling, I
>>>> don't care).  I don't want to see the ICEs of tests that are expected to
>>>> ICE.
>>>>
>>>> I think that means there has to be a positive marker on the unexpected ICEs,
>>>> rather than lack of an expected marker on them.
>>>
>>> Hmm, by the log file you mean g++.log?  Currently, if you run a dg-ice test,
>>> and the test still ICEs, the g++.log file (but not the stdout of make
>>> check-c++!) will have:
>>>
>>> Executing on host: ... xg++ with options ...
>>> spawn -ignore SIGHUP ... xg++ with options ...
>>> .../foo.C:14:15: internal compiler error: in poplevel_class, at cp/name-lookup.c:4225
>>> <backtrace>
>>> compiler exited with status 1
>>> XFAIL: g++.dg/foo.C  -std=c++17 (internal compiler error)
>>> PASS: g++.dg/foo.C  -std=c++17 (test for excess errors)
>>>
>>> Which one of these would you not like to see?
>>
>> Neither of these is solving the issue.  How do I find the ICES that are
>> unexpected, without tripping over the ICEs that are expected?
>>
>>> Can you give me more details?  Hopefully we'll work something out that doesn't
>>> break your workflow.
>>
>> sure.
>> * develop patch
>> * run testsuite
>> * observe unexpected ICEs
>> * load g++.log into editor
>> * ^sinternal comp
>> * gets to first unexpected ICE
>> * debug it.
>>
>> What does '^sinternal comp' become?  As there could be many expected ICEs
>> it'll be painful to determine whether any particular utterance of 'internal
>> compiler' is expected or not.
> 
> That is a problem I don't know how to deal with.  I know how to pass
> additional options to the compiler from dejagnu.  I thought maybe I could use
> -pass-exit-codes, redirect stderr to /dev/null, and check if the exit code is
> ICE_EXIT_CODE, but there seems to be no way to do that redirection.  So I'm
> stuck.
> 
> Though, you could just grep for '^FAIL.*internal comp', which will find the
> first unexpected ICE.  Contrary to the expected ICEs, the unexpected ICEs will
> be shown in 'Excess errors:'.  Won't that work?

Read what I wrote:
 >> * load g++.log into editor
 >> * ^sinternal comp

are you telling me not to use an editor for this task?  the search is so 
one can get the command line.  Grepping the log file will not do that.

while solveable, this seems to be the equivalent of putting stones in 
ones shoe.  an annoyance one could do without.  I'm sadly not convinced 
the goal is worth it.

nathan
-- 
Nathan Sidwell


More information about the Gcc-patches mailing list