RE: c++/6212: g++ testsuite EH regressions for irix6 -mabi=64

["Billinghurst, David \(CRTS\)" <David.Billinghurst@riotinto.com>]

The following reply was made to PR c++/6212; it has been noted by GNATS.

From: "Billinghurst, David (CRTS)" <David.Billinghurst@riotinto.com>
To: "Richard Kenner" <kenner@vlsi1.ultra.nyu.edu>
Cc: <gcc-bug@gcc.gnu.org>,
	<gcc-gnats@gcc.gnu.org>,
	<rth@redhat.com>
Subject: RE: c++/6212: g++ testsuite EH regressions for irix6 -mabi=64
Date: Tue, 23 Apr 2002 11:56:16 +1000

 I am not sure I can adequately describe the problem.  Here goes anyway.
 
 Firstly, I have a simpler test case -  g++.old-deja/g++.mike/eh12.C
 
 // Special g++ Options: -fexceptions
 // excess errors test - XFAIL a29k-*-* sparc64-*-elf arm-*-pe
 
 class MyError { };
 
 int main (int argc, char **argv) {
   try {
     throw MyError();
   }
   catch (MyError x) {
   }
 
   return 0;
 }
 
 
 When compiled and executed by the testsuite (below) I see
 Abort (core dumped)
 
 If I compile it with -g -O0 I get the same results.
 
 When I try it under gdb-5.1.1 I see
 
 GNU gdb 5.1.1
 Copyright 2002 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you =
 are
 welcome to change it and/or distribute copies of it under certain =
 conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for =
 details.
 This GDB was configured as "mips-sgi-irix6.5"...Dwarf Error: wrong =
 version in compilation unit header.
 
 (gdb) run
 Starting program: =
 /exd6/billingd/obj/gcc-3.1/gcc/testsuite/./g++-mike-eh12-C.exe=20
 warning: shared library handler failed to enable breakpoint
 
 Program received signal SIGABRT, Aborted.
 warning: Warning: GDB can't find the start of the function at 0xd9e0904.
 
     GDB is unable to find the start of the function at 0xd9e0904
 and thus can't determine the size of that function's stack frame.
 This means that GDB may be unable to access that stack frame, or
 the frames below it.
     This problem is most likely caused by an invalid program counter or
 stack pointer.
     However, if you think GDB should simply search farther back
 from 0xd9e0904 for code which looks like the beginning of a
 function, you can increase the range of the search using the `set
 heuristic-fence-post' command.
 0x0d9e0904 in ?? ()
 (gdb)=20
 
 
 
 The exact compiler flags used are:
 
 /exd6/billingd/obj/gcc-3.1/gcc/testsuite/../g++ =
 -B/exd6/billingd/obj/gcc-3.1/gcc/testsuite/../ =
 /exd2/billingd/src/gcc-3.1/gcc/testsuite/g++.old-deja/g++.mike/eh12.C =
 -nostdinc++  -fmessage-length=3D0 -fexceptions -lstdc++ =
 -L/exd6/billingd/obj/gcc-3.1/mips-sgi-irix6.5/libstdc++-v3/src/.libs =
 -L/exd6/billingd/obj/gcc-3.1/mips-sgi-irix6.5/libiberty -lm -o =
 /exd6/billingd/obj/gcc-3.1/gcc/testsuite/j32.exe -O0 -g