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

Reply via email to