Code generation bug with -fomit-frame-pointer

Nick Burrett nick at dsvr.net
Mon Dec 22 07:40:20 PST 2003


James Bursa wrote:
> On Tuesday 16 December 2003 20:29, Nick Burrett wrote:
> 
>>-fomit-frame-pointer makes no sense on RISC OS hence I'm not surprised
>>that it doesn't work.  The compiler should supply a warning to such effect.
> 
> 
> -O enables -fomit-frame-pointer, so that should be disabled too.

It has no effect on optimised code as the frame pointer is automatically 
eliminated.

> I've disabled it in my copy and updated with your sibling call fix, and -O2 
> now works in everything I tried. Thanks for your work on this!
> 
> With -O3 I'm getting
> 
>   ***Fatal error: Stack corruption detected***
> 
> when I run one program (ssltest from openssl). There is also one file which 
> causes

Try this patch and you might get a backtrace which suggests where the 
corruption was detected.

Index: _syslib.s
===================================================================
RCS file: /usr/local/cvsroot/gccsdk/unixlib/source/sys/_syslib.s,v
retrieving revision 1.22
diff -u -r1.22 _syslib.s
--- _syslib.s   23 Nov 2003 20:26:45 -0000      1.22
+++ _syslib.s   22 Dec 2003 15:39:04 -0000
@@ -49,7 +49,7 @@
  CHUNK_OVERHEAD *       24      ; Size of chunk header

  STACK_CHECK_MAGIC      *       1       ; Should we check that the 
magic number is valid each time the stack is extended/shrunk
-EXTREMELY_PARANOID     *       0       ; Should we check that the 
entire stack chunk chain is valid each time the stack is extended/shrunk
+EXTREMELY_PARANOID     *       1       ; Should we check that the 
entire stack chunk chain is valid each time the stack is extended/shrunk

         AREA    |C$$code|, CODE, READONLY

@@ -737,6 +737,8 @@
         DCB     "***Fatal error: Stack corruption detected***", 13, 10, 0
         ALIGN
  stack_corrupt
+       IMPORT  __write_corefile
+       BL      __write_corefile
         ADR     a1, stack_corrupt_msg
         B       __unixlib_fatal



>   internal compiler error: in subreg_hard_regno, at emit-rtl.c:931
> 
> (s_time.c from openssl). I can try and find out which particular optimisation 
> is causing this / supply preprocessed source, or is -O3 unsupported?

Just send preprocessed source and I'll take a look.






More information about the gcc mailing list