> Regressions that cause ICE's on invalid code often go unnoticed in the
> testsuite, since regular errors and ICE's both match { dg-error "" }.
> See for example g++.dg/parse/error16.C which ICE's since yesterday,
> but the testsuite still reports "PASS":
>
> Executing on host:
> /Work/reichelt/gccbuild/src-4.0/build/gcc/testsuite/../g++
> -B/Work/reichelt/gccbuild/src-4.0/build/gcc/testsuite/../
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C
> -nostdinc++
> -I/home/reichelt/Work/gccbuild/src-4.0/build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
>
> -I/home/reichelt/Work/gccbuild/src-4.0/build/i686-pc-linux-gnu/libstdc++-v3/include
> -I/home/reichelt/Work/gccbuild/src-4.0/gcc/libstdc++-v3/libsupc++
> -I/home/reichelt/Work/gccbuild/src-4.0/gcc/libstdc++-v3/include/backward
> -I/home/reichelt/Work/gccbuild/src-4.0/gcc/libstdc++-v3/testsuite
> -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -S -o error16.s
> (timeout =
> 300)
>
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:8:
> error: redefinition of 'struct A::B'
>
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:5:
> error: previous definition of 'struct A::B'
>
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:8:
> internal compiler error: tree check: expected class 'type', have
> 'exceptional' (error_mark) in cp_parser_class_specifier, at
> cp/parser.c:12407
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> compiler exited with status 1
> output is:
>
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:8:
> error: redefinition of 'struct A::B'
>
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:5:
> error: previous definition of 'struct A::B'
>
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:8:
> internal compiler error: tree check: expected class 'type', have
> 'exceptional' (error_mark) in cp_parser_class_specifier, at
> cp/parser.c:12407
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>
> PASS: g++.dg/parse/error16.C (test for errors, line 5)
> PASS: g++.dg/parse/error16.C (test for errors, line 8)
> PASS: g++.dg/parse/error16.C (test for excess errors)
>
> (Btw, Mark, I think the regression was caused by your patch for
> PR c++/20152, could you please have a look?)
>
> The method used right now is to not use "" in the last error message,
> but that's forgotten too often.
>
> This calls for a more robust method IMHO.
> One way would be to make the testsuite smarter and make it recognize
> typical ICE patterns itself. This can indeed be done (I for example
> use it to monitor the testcases in Bugzilla, Phil borrowed the patterns
> for his regression tester).
>
> An easier way IMHO would be to return a different error code when
> encountering an ICE. That's only a couple of places in diagnostic.c
> and errors.c where we now have "exit (FATAL_EXIT_CODE);".
> We could return an (appropriately defined) ICE_ERROR_CODE instead.
> The testsuite would then just have to check the return value.
>
> What do you think?
That would certantly be a Good Thing. As far as I know,
regular errors return exit code 1. I have two suggestions
on that:
a) use a testsuite that supports regexps and match a 1
exit code agianst
/^Please submit a full bug report/
b) make it return a diffrent exit code (say -127 or even
2 ;-).
c) make a seperate function for ICEs and make _that_
return exit code indicating ICE. There would be a
disadvantage: as with any code moving, there would still be
some code that didn't call that function
Samuel Lauber
--
_____________________________________________________________
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.
Powered by Outblaze
