On Tue, Sep 18, 2012 at 1:49 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Mon, Sep 17, 2012 at 7:17 PM, Ian Lance Taylor <i...@google.com> wrote: >> This patch to the diagnostic code uses the new backtrace library to >> print a backtrace on an ICE. For example, here is the output of a test >> case I took from a C++ PR: >> >> /home/iant/foo2.cc:6:6: internal compiler error: in >> cp_lexer_new_from_tokens, at cp/parser.c:638 >> 0xec549f internal_error(char const*, ...) >> ../../trunk/gcc/diagnostic.c:1057 >> 0xec3f53 fancy_abort(char const*, int, char const*) >> ../../trunk/gcc/diagnostic.c:1111 >> 0x5ff78e cp_lexer_new_from_tokens >> ../../trunk/gcc/cp/parser.c:638 >> 0x5ff78e cp_parser_push_lexer_for_tokens >> ../../trunk/gcc/cp/parser.c:3290 >> 0x60ff40 cp_parser_late_parsing_for_member >> ../../trunk/gcc/cp/parser.c:21713 >> 0x60ff40 cp_parser_class_specifier_1 >> ../../trunk/gcc/cp/parser.c:18207 >> 0x60ff40 cp_parser_class_specifier >> ../../trunk/gcc/cp/parser.c:18231 >> 0x60ff40 cp_parser_type_specifier >> ../../trunk/gcc/cp/parser.c:13390 >> 0x61c83d cp_parser_decl_specifier_seq >> ../../trunk/gcc/cp/parser.c:10731 >> 0x628317 cp_parser_single_declaration >> ../../trunk/gcc/cp/parser.c:21313 >> 0x6289c0 cp_parser_template_declaration_after_export >> ../../trunk/gcc/cp/parser.c:21198 >> 0x62de39 cp_parser_declaration >> ../../trunk/gcc/cp/parser.c:10183 >> 0x62c487 cp_parser_declaration_seq_opt >> ../../trunk/gcc/cp/parser.c:10105 >> 0x62c762 cp_parser_translation_unit >> ../../trunk/gcc/cp/parser.c:3757 >> 0x62c762 c_parse_file() >> ../../trunk/gcc/cp/parser.c:27557 >> 0x72e4e4 c_common_parse_file() >> ../../trunk/gcc/c-family/c-opts.c:1138 >> Please submit a full bug report, >> with preprocessed source if appropriate. >> See <http://gcc.gnu.org/bugs.html> for instructions. >> >> >> Bootstrapped on x86_64-unknown-linux-gnu. I didn't bother to run the >> testsuite, since the code only changes when an ICE occurs anyhow. >> >> OK for mainline? > > Hm. Can you please be that verbose only for ENABLE_CHECKING compilers?
That would be easy enough but I don't think it's a good idea. The
time when this can help the most is when we get a bug report from
somebody who doesn't know how to or doesn't want to share the input
file. The backtrace can show us whether this is a known ICE. But
that will only work if we actually dump the backtrace for a release
compiler.
It's not like this is something that happens in an ordinary
compilation. I think verbosity is just fine here.
> I'd say that we should do sth fancy with the backtrace first, like in your
> example note that it came from an assert (and skip the first two frames),
> or more simple - skip frames until the function name we printed anyways
> is listed.
That function name is not convenient to access. I changed the
backtrace to simply skip any leading stack frames in diagnostic.c,
which achieves the same effect.
> Then for !ENABLE_CHECKING I'd derive bugzilla components
> (backtrace from the frontend? from which tree/RTL pass?).
That's a good idea but I'd rather leave it for later.
> I mean the above is so verbose that bugreporters likely will only paste the
> last non-interesting lines like
I added an explicit note directing them to include the complete backtrace.
> also consider ICEs from infinite recursion - you'd get a way too large
> backtrace
> (so please consider pruning recursions).
In my original patch the backtrace is already cut off after 20 functions.
> Or at least provide a way to disable the backtrace printing with a configure
> switch.
Again, I don't think this is necessary or appropriate. I could add a
command line option to disable the backtrace if you think that is
important, but I think it's important that the default be to print it.
I've attached the updated patch. Here is what it prints now.
/home/iant/foo2.cc:6:6: internal compiler error: in
cp_lexer_new_from_tokens, at cp/parser.c:638
0x5ff78e cp_lexer_new_from_tokens
../../trunk/gcc/cp/parser.c:638
0x5ff78e cp_parser_push_lexer_for_tokens
../../trunk/gcc/cp/parser.c:3290
0x60ff40 cp_parser_late_parsing_for_member
../../trunk/gcc/cp/parser.c:21713
0x60ff40 cp_parser_class_specifier_1
../../trunk/gcc/cp/parser.c:18207
0x60ff40 cp_parser_class_specifier
../../trunk/gcc/cp/parser.c:18231
0x60ff40 cp_parser_type_specifier
../../trunk/gcc/cp/parser.c:13390
0x61c83d cp_parser_decl_specifier_seq
../../trunk/gcc/cp/parser.c:10731
0x628317 cp_parser_single_declaration
../../trunk/gcc/cp/parser.c:21313
0x6289c0 cp_parser_template_declaration_after_export
../../trunk/gcc/cp/parser.c:21198
0x62de39 cp_parser_declaration
../../trunk/gcc/cp/parser.c:10183
0x62c487 cp_parser_declaration_seq_opt
../../trunk/gcc/cp/parser.c:10105
0x62c762 cp_parser_translation_unit
../../trunk/gcc/cp/parser.c:3757
0x62c762 c_parse_file()
../../trunk/gcc/cp/parser.c:27557
0x72e4e4 c_common_parse_file()
../../trunk/gcc/c-family/c-opts.c:1138
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Ian
foo.patch
Description: Binary data
