On Thu, Aug 28, 2025 at 1:12 PM Rainer Orth via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi Sam,
>
> > When a test fails with 'excess errors', there's often only one actual
> > error (an excess "(error|warning|note):") and it'd be nice to not have
> > to dig in the .log files to fish that out.
>
> I think such a move would be a bad mistake. Consider ICEs where you
> have something like
>
> FAIL: gcc.c-torture/compile/pr35318.c -O0 (test for excess errors)
> Excess errors:
> /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.c-torture/compile/pr35318.c:9:1:
> error: unrecognizable insn:
> (insn 13 25 26 2 (parallel [
> (set (reg:DF 10 %o2 [orig:112 x ] [112])
> (asm_operands/v:DF ("") ("=r,r") 0 [
> (reg:SI 11 %o3 [orig:112 x+4 ] [112])
> (mem/c:DF (plus:SI (reg/f:SI 30 %fp)
> (const_int -24 [0xffffffffffffffe8])) [3
> %sfp+-24 S8 A64])
> [and many more lines...]
>
> This would clutter the output beyond recognition, especially if this is
> a torture test which is run at several optimization options.
>
> Excess errors, like all others, always require further investigation.
> In my experience, digging the full error messages from the .log files is
> usually the smallest part of that. You often even have to rerun the
> compilation manually to also get the parts that are filtered out by the
> prune procs.
I find the classification this would provide useful, like I like the
(internal compiler error) classification we already have. I would
of course not duplicate all of th eabove message but only
'(unrecognizable insn)' in the above case.
Richard.
>
> Rainer
>
> --
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
