Marek Polacek via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >> > > 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. > > No, I'm saying that looking for '^FAIL.*internal comp' (in an editor) instead > of just 'internal comp' will get you to the ICEs you care about. In vim, > '/^FAIL.*in' gets me there.
Yeah, this works. I'm not sure whether Nathan's ^s is isearch or regexp-isearch :-) > If that is still too much, we could maybe add a new diagnostic kind, like > DK_EXPECTED_ICE that has different wording than DK_ICE, and have dg-ice > use it via some option/envvar. Seems unnecessary given the above. >> 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. > > If this is an annoyance to people, I'll just go back to my own repo. Please don't! I'm sure we can find something for Nathan's use case, if your regexp search isn't enough. How do things stand with the new directives? Seems like there are no objections to dg-ice, but I lost track of the others. Personally I'm not interested in any solution that replaces one of your new directives with two existing directives: one (sub)test should be one directive as far as possible. So IMO we should add every directive that doesn't already have a one-for-one analogue. Happy to review any updated patch :-) Thanks, Richard
