This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

PATCH[cvs-20000819]: Fix for frame pointer omission and exception handling (was: Re: C++ exception handling broken if parts of libgcc are compiled using `-fomit-frame-pointer´)


FWIW, running "make check" with the attached patch applied resulted
in the usual three failures:

FAIL: g++.ext/instantiate1.C not instantiated (test for errors, line 18)
FAIL: g++.ext/instantiate1.C not instantiated (test for errors, line 20)
FAIL: g++.ns/koenig7.C (test for excess errors)

BOOT_CFLAGS was set to "-O9 -funroll-loops -fomit-frame-pointer"

OK to install?

Cheers

l8er
manfred


On Saturday, 19 August 2000, 12:42:31 +0200, manfredh@redhat.com wrote:

> Hi there,
> 
> Yesterday I  ran   "make bootstrap check"   on  i686-redhat6-linux-gnu
> several   times on   the   same sources,   each  time  using different
> BOOT_CFLAGS. It turned  out, that if  `-fomit-frame-pointer´ (FOFP) is
> used, 8 additional failures in the g++ testsuite show up:
> 
>   FAIL: g++.eh/spec2.C  Execution test
>   FAIL: g++.eh/spec3.C  Execution test
>   FAIL: g++.eh/spec4.C  Execution test
>   FAIL: g++.mike/dyncast1.C  Execution test
>   FAIL: g++.mike/dyncast2.C  Execution test
>   FAIL: g++.mike/eh33.C  Execution test
>   FAIL: g++.mike/eh50.C  Execution test
>   FAIL: g++.mike/eh51.C  Execution test
> 
> IIRC, somebody mentioned that the current exception handling mechanism
> doesn't work if  the FOFP flag  is used. So I  rebuilt those  parts of
> libgcc.a, which   depend  on proper  frame  handling, this  time using
> `-fno-omit-frame-pointer´, and replaced those modules in libgcc.a.
> 
> Running the tests, which formerly crashed, terminated successfully now.
> 
> So, my question is:
> 
>   `Is "-fomit-frame-pointer" plus exception handling deprecated in
>    general, or just on those platforms which are using the DWARF2
>    unwinder?´
> 
> If the latter is true, I'd suggest we reset flag_omit_frame_pointer in
> toplev.c emitting a suitable warning like this:
> 
> #if DWARF2_UNWIND_INFO
>   if (flag_omit_frame_pointer && flag_exceptions)
>     {
>       warning ("-fomit-frame-pointer is incompatible with the exception handling mechanism on this target; disabling it");
>       flag_omit_frame_pointer = 0;
>     }
> #endif
> 
> If this   isn't the way to  go,  we need to find  a  way to make sure,
> libgcc.a  will   be generated  properly  regardless  of   BOOT_CFLAGS,
> however.
> 
> Thoughts?
> 
> Cheers, manfred.


2000-08-19  Manfred Hollstein  <manfredh@redhat.com>

	* toplev.c (main): Reset flag_omit_frame_pointer if DWARF2 stack
	unwinding is used and exceptions are not disabled.

diff -rup -x CVS -x RCS -x *.o -x *.info* -x *.html* -x *.elc -x *.dvi -x *.orig -x *~ -x version.el egcs-20000819.orig/gcc/toplev.c egcs-20000819/gcc/toplev.c
--- egcs-20000819.orig/gcc/toplev.c	Sat Aug 19 09:51:46 2000
+++ egcs-20000819/gcc/toplev.c	Sat Aug 19 12:51:24 2000
@@ -4655,6 +4655,15 @@ main (argc, argv)
   if (flag_check_memory_usage)
     flag_omit_frame_pointer = 0;
 
+#if DWARF2_UNWIND_INFO
+  /* The DWARF2 frame unwinder uses the frame pointer.  */
+  if (flag_omit_frame_pointer && flag_exceptions)
+    {
+      warning ("-fomit-frame-pointer is incompatible with the exception handling mechanism on this target; disabling it");
+      flag_omit_frame_pointer = 0;
+    }
+#endif
+
   if (optimize == 0)
     {
       /* Inlining does not work if not optimizing,

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]