public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/6467: Wrong interactions between sjlj-exceptions and inline functions in GCC 2.95.3 on FreeBSD
@ 2002-12-19 19:00 bangerth
  0 siblings, 0 replies; 4+ messages in thread
From: bangerth @ 2002-12-19 19:00 UTC (permalink / raw)
  To: ak03, gcc-bugs, gcc-prs, nobody

Synopsis: Wrong interactions between sjlj-exceptions and inline functions in GCC 2.95.3 on FreeBSD

State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Thu Dec 19 19:00:14 2002
State-Changed-Why:
    I'm sorry that nobody cared to look into your report until
    now. In the meantime, we have gcc3.2.1 -- could you
    possibly check whether the problem still occurs with
    your platform? I tried to reproduce it on x86 linux,
    but failed, but then I may not have used the same
    flags for compilation (you did not specify them in the
    report, as far as I could see).
    
    Thanks
      Wolfgang

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6467


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: c++/6467: Wrong interactions between sjlj-exceptions and inline functions in GCC 2.95.3 on FreeBSD
@ 2002-12-20  8:04 bangerth
  0 siblings, 0 replies; 4+ messages in thread
From: bangerth @ 2002-12-20  8:04 UTC (permalink / raw)
  To: ak03, gcc-bugs, gcc-prs, nobody

Synopsis: Wrong interactions between sjlj-exceptions and inline functions in GCC 2.95.3 on FreeBSD

State-Changed-From-To: feedback->closed
State-Changed-By: bangerth
State-Changed-When: Fri Dec 20 08:04:42 2002
State-Changed-Why:
    Reportedly fixed. Thanks for the quick feedback, Alexander!

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6467


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: c++/6467: Wrong interactions between sjlj-exceptions and inline functions in GCC 2.95.3 on FreeBSD
@ 2002-12-19 20:06 Alexander Kabaev
  0 siblings, 0 replies; 4+ messages in thread
From: Alexander Kabaev @ 2002-12-19 20:06 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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

From: Alexander Kabaev <kabaev@bellatlantic.net>
To: ak03@gte.com
Cc: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/6467: Wrong interactions between sjlj-exceptions and inline functions in GCC 2.95.3 on FreeBSD
Date: Thu, 19 Dec 2002 23:04:20 -0500

 On Thu, 19 Dec 2002 22:53:14 -0500
 Alexander Kabaev <kabaev@bellatlantic.net> wrote:
 
 > These bugs have been dealt with a long time ago. This PR should be
 > closed.
 
 Sorry, I need to expand on that little. The problems are still there on
 gcc-2.95-branch, but the whole integrate has been rewritten for GCC 3.x,
 so they do not happen with recent compiler versions. I submitted this
 PRs initially to help people who might still use GCC 2.95.x in
 production environment. FreeBSD 4.x users, for example.
 
 Meanwhile FreeBSD has applied these fixes locally, so whether this patch
 will ever make it into official FSF repository is irrelevant.
 
 -- 
 Alexander Kabaev


^ permalink raw reply	[flat|nested] 4+ messages in thread

* c++/6467: Wrong interactions between sjlj-exceptions and inline functions in GCC 2.95.3 on FreeBSD
@ 2002-04-25 21:16 ak03
  0 siblings, 0 replies; 4+ messages in thread
From: ak03 @ 2002-04-25 21:16 UTC (permalink / raw)
  To: gcc-gnats


>Number:         6467
>Category:       c++
>Synopsis:       Wrong interactions between sjlj-exceptions and inline functions in GCC 2.95.3 on FreeBSD
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 25 21:16:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Alexander Kabaev <ak03@gte.com>
>Release:        2.95.3 + patches from 2.59 branch (FreeBSD system compiler)
>Organization:
>Environment:
gcc version 2.95.4 20020320 [FreeBSD]
>Description:
I had to make the following changes to our system gcc to stop it from miscompiling OpenOffice code:

1. Changes to integrate.c deal with the problem, demonstrated by the code in the How To Repeat section below. If inline function which uses exception handling is being integrated into a function, which does not itself contain any try/catch constructs, several global flags values are not set correctly. The current_function_has_nonlocal_label flags is not getting set in particular. This allows GCC to allocate registers across function	calls. When exception is thrown in called functions, the exception handler is reached with global registers (ebx, edi, esi) content clobbered without gcc ever noticing that. The STLPort test suite failure on FreeBSD was caused by exactly this bug.

2. Changes in expr.c fix the problem demonstrated by the second code snippet below. I did not make a complete test case with nice printfs out of it, but if you compile it with g++ -O -S and then look into assembly code, you will notice rogue 'add $16, %esp' assembly instruction in return case. GCC defers adjusting stack pointer after function calls until absolutely necessary, but sometimes fails to do in at the right time. In this case, the bogus stack pointer adjustment is a leftover from a __cp_push_exception call done as a part of the throw statement processing. In DWARF2 case stack was getting adjusted at the right time as a side effect of expand_eh_region_end. sjlj-exceptions do not use this function so I added a call to do_pending_stack_adjust in its place. Alternatively, stack adjustment could be done right before a call to __sjthrow is expanded, but I think the current patch keeps us closer to DWARF2-based exceptions code flow. One nice side effect of this approach is that 'add $16, %esp' is getting optimized away at the first flow optimization pass as non-reachable. This patch
fixes the problem with saxparser found by Martin Blapp, who is currently trying to create OpenOffice port for FreeBSD.
>How-To-Repeat:
 The following code demonstrates the problem #1:

================= Begin ====================
void do_nothing()
{
    __asm ("movl $0, %%esi" : : :"%esi");
    throw 5;
}

int __inline crash()
{
    register int test = 0;

    try {
        test = 35;
        do_nothing();
    }
    catch(...) {
        test--;
    }
    return test;
}

extern "C"
int printf(const char *, ...);

void main()
{
    int ret = crash();
    printf("%d\n", ret);
}
================= End   ====================

This example demonstrates the problem #2. Not
as complete as the first example, you will need
to compile it to assembly. Look for the following
asembly fragment:

        movl -120(%ebp),%edx
        movl 4(%edx),%eax
        movl 4(%eax),%edx
        movl (%edx),%edx
        movl %edx,4(%eax)
        addl $16,%esp        # <== This add is bogus
        addl $-12,%esp       # Pushing arguments to guard_operate
        movl -124(%ebp),%eax # will stomp over saved registers
        pushl %eax           # Here goes calling function's EBX :)
        call guard_operate__FP5Guard
        movl -120(%ebp),%edx
        movl 4(%edx),%eax
        movl (%eax),%eax
        movl %eax,4(%edx)

================= Begin ====================

class Guard;

void  guard_operate(Guard *pG);

class Guard
{
public:
    
    Guard()
    {
	guard_operate(this);
    }
 
    ~Guard()
    {
	guard_operate(this);
    }
};

class SimpleRegistryImpl
{
public:
    SimpleRegistryImpl();

    ~SimpleRegistryImpl();

    virtual void open() throw(int);
};

extern int flag;

void SimpleRegistryImpl::open( ) 
	throw(int)
{
        __asm("int3;");
       	Guard aGuard;

	if ( flag )
	{
		return;
	}
	throw 5;
}
================= End   ====================
>Fix:
Index: integrate.c
===================================================================
RCS file: /home/ncvs/src/contrib/gcc.295/integrate.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 integrate.c
--- integrate.c	16 Oct 1999 06:05:22 -0000	1.1.1.3
+++ integrate.c	31 Mar 2002 05:51:24 -0000
@@ -1608,6 +1608,20 @@
   if (FUNCTION_FLAGS (header) & FUNCTION_FLAGS_NEEDS_CONTEXT)
     static_chain_value = lookup_static_chain (fndecl);
 
+  /* If the inline function has these flags sets, that means that 
+     coresponding global flags should be set for this function. */
+  if (FUNCTION_FLAGS (header) & FUNCTION_FLAGS_CALLS_SETJMP)
+    current_function_calls_setjmp = 1;
+
+  if (FUNCTION_FLAGS (header) & FUNCTION_FLAGS_CALLS_LONGJMP)
+    current_function_calls_longjmp = 1;
+
+  if (FUNCTION_FLAGS (header) & FUNCTION_FLAGS_HAS_NONLOCAL_LABEL)
+    current_function_has_nonlocal_label = 1;
+
+  if (FUNCTION_FLAGS (header) & FUNCTION_FLAGS_USES_CONST_POOL)
+    current_function_uses_const_pool = 1;
+
   if (GET_CODE (parm_insns) == NOTE
       && NOTE_LINE_NUMBER (parm_insns) > 0)
     {
Index: stmt.c
===================================================================
RCS file: /home/ncvs/src/contrib/gcc.295/stmt.c,v
retrieving revision 1.1.1.6
diff -u -r1.1.1.6 stmt.c
--- stmt.c	17 Feb 2001 08:36:08 -0000	1.1.1.6
+++ stmt.c	21 Apr 2002 06:07:51 -0000
@@ -4027,6 +4027,10 @@
 		    cleanup = protect_with_terminate (cleanup);
 		    expand_eh_region_end (cleanup);
 		  }
+		else 
+		  {
+		    do_pending_stack_adjust();
+		  }
 	      }
 
 	    if (reachable)

>Release-Note:
>Audit-Trail:
>Unformatted:


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2002-12-20 16:04 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-19 19:00 c++/6467: Wrong interactions between sjlj-exceptions and inline functions in GCC 2.95.3 on FreeBSD bangerth
  -- strict thread matches above, loose matches on Subject: below --
2002-12-20  8:04 bangerth
2002-12-19 20:06 Alexander Kabaev
2002-04-25 21:16 ak03

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).