Re: c++/2613: incorrect code if -fsjlj-exceptions and exception specification on member function

Re: c++/2613: incorrect code if -fsjlj-exceptions and exception specification on member function

[nathan]

Synopsis: incorrect code if -fsjlj-exceptions and exception specification on member function

State-Changed-From-To: open->closed
State-Changed-By: nathan
State-Changed-When: Fri Apr 26 02:23:26 2002
State-Changed-Why:
    this is fixed on 3.0 seriesm, but
    -fsjlj-exceptions is no longer supported as a runtime
    switch, and -fasynchronous-exceptions has been renamed
    -fnon-call-exceptions. Your program works at all optimization
    levels with that latter option

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

c++/2613: incorrect code if -fsjlj-exceptions and exception specification on member function

[gcc-bug]

>Number:         2613
>Category:       c++
>Synopsis:       incorrect code if -fsjlj-exceptions and exception specification on member function
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Sun Apr 22 12:36:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Stefan Vogtner
>Release:        gcc version 2.95.3 20010315 (release)
>Organization:
>Environment:
Linux client0 2.2.13 #11 Son Jan 21 17:58:52 CET 2001 i686 unknown 
and
SunOS 5.6 sun4u sparc SUNW,Ultra-5_10
>Description:
If the compiler/libstd++ is built with -fsjlj-exceptions
exceptions from class members are not correctly handled.
if the member function has an exception specification.
(find details in file "summary").
Depending on the optimization level the member function
is called twice and/or exceptions are uncaught and/or
process terminates due tue UNIX signals.
>How-To-Repeat:
configure:
 
../$GCCDIR/configure \
--prefix=$LOCAL \
--enable-shared \
--enable-threads \
--enable-version-specific-runtime-libs \
--enable-languages=c,c++
 
and make with
 
export CFLAGS='-fasynchronous-exceptions -fsjlj-exceptions'
export CXXFLAGS='-fasynchronous-exceptions -fsjlj-exceptions'
export LIBCFLAGS='-fasynchronous-exceptions -fsjlj-exceptions'
export LIBCXXFLAGS='-fasynchronous-exceptions -fsjlj-exceptions'
make CFLAGS='-fasynchronous-exceptions -fsjlj-exceptions' CXXFLAGS='-fasynchronous-exceptions -fsjlj-exceptions' LIBCFLAGS='-fasynchronous-exceptions -fsjlj-exceptions' LIBCXXFLAGS='-fasynchronous-exceptions -fsjlj-exceptions' bootstrap

After the installation (and setting the PATH and LD_LIBRARY_PATH)
I added
 
*cc1plus:
-fasynchronous-exceptions -fsjlj-exceptions
 
to the specs file. The enclosed gcc-bug-2001-04-16.cc
does now show strange behavior depending on compiler
version, exception-specification and optimization level.
Static linking yields same result. If the exception
specification is left out, everything works fine.
 
The result are summarized in the following table:
 
        +-------------+------------+
        | GCC         | GCC        |
        | 2.95.2      | 2.95.3     |
+-------+-------------+------------+
| -O0   | UA          | -          |
+-------+-------------+------------+
| -O1   | CUS         | CUS        |
+-------+-------------+------------+
| -O2   | C           | C          |
+-------+-------------+------------+
| -O3   | C           | C          |
+-------+-------------+------------+
 
C: ctor is called twice
U: integer exception is uncaught
A: SIGABRT
S: SIGSEGV
-: works as excepted
 
Results of the current gcc 3.0 snapshot could not be optained
since I could not get the compiler/libs built with -fsjlj-exception.  
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="gcc-bug-2001-04-16.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="gcc-bug-2001-04-16.cc"

Ly8KLy8JCWdjYy1idWctMjAwMS0wNC0xNiBzdHZvCi8vCi8vCQlnY2MgMi45NS4zIGFuZCBsaWJz
dGRjKysgYnVpbHQgd2l0aCAtZnNqbGotZXhjZXB0aW9ucwovLwkJcHJvZHVjZSBpbmNvcnJlY3Qg
Y29kZSAoPykgaWYgZXhjZXB0aW9uIHNwZWNpZmljYXRpb24gCi8vCQlpcyBwcmVzZW50IHRocm93
ICh0eXBlbmFtZSkgCi8vCi8vCQktIG9wdGltaXphdGlvbiBpcyBhdCBsZWFzdCAtTzEKLy8KLy8J
CWNvbXBpbGUgd2l0aDoKLy8KLy8JCWcrKyAtT1swMTIzXSAtZnNqbGotZXhjZXB0aW9ucyBbLURU
SFJPV1NQRUNdIAovLwojaW5jbHVkZSA8aW9zdHJlYW0+CnVzaW5nIG5hbWVzcGFjZSBzdGQ7Cgp2
b2xhdGlsZSBpbnQgY250ICgwKTsKCmNsYXNzIFggewpwdWJsaWM6CglYICgpIAojaWZkZWYgVEhS
T1dTUEVDCgkJdGhyb3cgKGludCkgLy8gaWYgcHJlc2VudCBzdHJhbmdlIHRoaW5ncyBoYXBwZW4g
aWYgb3B0ID49IC1PMQojZW5kaWYKCXsKCQljb3V0IDw8ICsrY250IDw8IF9fUFJFVFRZX0ZVTkNU
SU9OX18gPDwgZW5kbDsKCQl0aHJvdyBpbnQgKDgpOwoJfQp9OwoKaW50IG1haW4gKCkKewoJdHJ5
IHsKCQlYIHg7CgkJKHZvaWQpIHg7Cgl9CgljYXRjaCAoaW50IGkpIHsKCQljZXJyIDw8ICJjYXVn
aHQgYW4gaW50ID0gIiA8PCBpIDw8IGVuZGw7Cgl9CgljYXRjaCAoLi4uKSB7CgkJY2VyciA8PCAi
Y2F1Z2h0IHNvbWV0aGluZyBlbHNlIiA8PCBlbmRsOwoJfQoJcmV0dXJuIDA7Cn0K