This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: MIPS regressions
- From: Geoff Keating <geoffk at geoffk dot org>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org, kevinb at redhat dot com
- Date: 23 May 2002 17:14:44 -0700
- Subject: Re: MIPS regressions
- References: <247860000.1022191279@gandalf.codesourcery.com>
Mark Mitchell <mark@codesourcery.com> writes:
> One of us seems to have broken the MIPS build on the mainline. The
> regression checker says:
>
> In file included from
> /maat/heart/tbox/cvs-gcc/gcc/libstdc++-v3/libsupc++/new:42,
> from
> /maat/heart/tbox/cvs-gcc/gcc/libstdc++-v3/libsupc++/del_op.cc:31:
> /maat/heart/tbox/cvs-gcc/gcc/libstdc++-v3/libsupc++/exception:72: Internal
> compiler error in decl_type_context, at tree.c:4229
> Please submit a full bug report,
> with preprocessed source if appropriate.
>
> We need to keep on top of these things so that we can keep the quality
> up for 3.2.
>
> This apparently started breaking somewhere around a couple of days ago;
> 2002-05-21 is the earliest entry in the ChangeLog since the tests passed.
I'm pretty sure it was this patch:
+2002-05-22 Kevin Buettner <kevinb@redhat.com>
+
+ * dbxout.c (dbxout_class_name_qualifiers): New function.
+ (dbxout_symbol): Output class/struct qualifiers for a .stabs entry.
+
To track down these things, I find the best thing is to go to the
gcc-regression mailing list archive, and look at the first message
reporting the problem; that narrowed it down to about changes in this
case. Unfortunately, I couldn't easily see which of the four was it
(the performance of the regression tester has been slowly fading as
GCC takes longer to build), but I managed to get a stack backtrace:
#0 decl_type_context (decl=0x40220708)
at /maat/heart/tbox/cvs-gcc/gcc/gcc/tree.c:4229
#1 0x0828c107 in dbxout_class_name_qualifiers (decl=0x40220708)
at /maat/heart/tbox/cvs-gcc/gcc/gcc/dbxout.c:1839
#2 0x0828c809 in dbxout_symbol (decl=0x40220708, local=0)
at /maat/heart/tbox/cvs-gcc/gcc/gcc/dbxout.c:2005
#3 0x082371b0 in rest_of_decl_compilation (decl=0x40220708, asmspec=0x0,
top_level=0, at_end=0) at /maat/heart/tbox/cvs-gcc/gcc/gcc/toplev.c:2255
#4 0x080674ed in cp_finish_decl (decl=0x40220708, init=0x0, asmspec_tree=0x0,
flags=0) at /maat/heart/tbox/cvs-gcc/gcc/gcc/cp/decl.c:8255
#5 0x080be774 in parse_end_decl (decl=0x40220708, init=0x0, asmspec=0x0)
at parse.y:203
#6 0x080c20e5 in yyparse () at parse.y:2160
#7 0x08118627 in c_common_parse_file (set_yydebug=0)
at /maat/heart/tbox/cvs-gcc/gcc/gcc/c-lex.c:160
#8 0x08236c71 in compile_file ()
at /maat/heart/tbox/cvs-gcc/gcc/gcc/toplev.c:2070
#9 0x0823b5ef in do_compile ()
at /maat/heart/tbox/cvs-gcc/gcc/gcc/toplev.c:5169
#10 0x0823b64d in toplev_main (argc=62, argv=0xbfffe254)
at /maat/heart/tbox/cvs-gcc/gcc/gcc/toplev.c:5201
#11 0x4004f647 in __libc_start_main (main=0x8119df4 <main>, argc=62,
ubp_av=0xbfffe254, init=0x8049038 <_init>, fini=0x82eb7b0 <_fini>,
rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbfffe24c)
at ../sysdeps/generic/libc-start.c:129
... and that seems to answer that.
--
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>