On Tue, Sep 18, 2012 at 10: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? > 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. Then for !ENABLE_CHECKING I'd derive bugzilla components > (backtrace from the frontend? from which tree/RTL pass?). > > I mean the above is so verbose that bugreporters likely will only paste the > last non-interesting lines like > > 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. > > also consider ICEs from infinite recursion - you'd get a way too large > backtrace > (so please consider pruning recursions).
Which also means to use an alternate stack for all this (we probably should use sigaltstack for the ICEs anyway). Richard.
