Re: c++/10457: exception specs vs. -fno-enforce-eh-specs

Re: c++/10457: exception specs vs. -fno-enforce-eh-specs

[Benjamin Kosnik]

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

From: Benjamin Kosnik <bkoz@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, mark@codesourcery.com,
   nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/10457: exception specs vs. -fno-enforce-eh-specs
Date: Wed, 23 Apr 2003 00:34:40 -0500

 >You were right when you said that your testcase is ill-formed.  The errors
 >g++ is giving are correct, per 15.4p3.
 
 I don't think so.
 
 It's not an assignment or initialization. See my updated comment, where
 d.foo must be called in the try block. 
 
 In any case, 15.4p10, and p8 suggest that this is a runtime error, not a
 compile time error. I think a warning is wise, but an error I think is
 not conformant behavior. This blocks the explicitly granted ability of
 library implementors to tighten exception specs.
 
 >I suppose that, as an extension, if a derived function has a looser
 >exception specification we could clobber it with the one from the base
 >class and give a pedwarn.  But that seems ugly to me.
 
 What happens is that unexpected is called, I don't see this as up for
 debate if we are just interpreting the standard. In this case, what
 unexpected does is implementation defined, and may indeed do what you
 are suggesting, throw bad_exception, etc.
 
 I think the current behavior is wrong. Icc seems to agree.
 
 -benjamin

Re: c++/10457: exception specs vs. -fno-enforce-eh-specs

[Jason Merrill]

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

From: Jason Merrill <jason@redhat.com>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, mark@codesourcery.com,
   nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/10457: exception specs vs. -fno-enforce-eh-specs
Date: Wed, 23 Apr 2003 19:42:12 +0100

 Also note that icc gives the same error when compiling with -ansi.
 
 Jason

Re: c++/10457: exception specs vs. -fno-enforce-eh-specs

[Jason Merrill]

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

From: Jason Merrill <jason@redhat.com>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, mark@codesourcery.com,
   nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/10457: exception specs vs. -fno-enforce-eh-specs
Date: Wed, 23 Apr 2003 15:14:32 +0100

 On Wed, 23 Apr 2003 00:34:40 -0500, Benjamin Kosnik <bkoz@redhat.com> wrote:
 
 >>You were right when you said that your testcase is ill-formed.  The errors
 >>g++ is giving are correct, per 15.4p3.
 >
 > I don't think so.
 >
 > It's not an assignment or initialization. See my updated comment, where
 > d.foo must be called in the try block. 
 
 That's irrelevant; the error is the declaration of c::foo.  15.4p3 says, 
 
   If a virtual function has an exception-specification, all declarations,
   including the definition, of any function that overrides that virtual
   function in any derived class shall only allow exceptions that are
   allowed by the exception-specification of the base class virtual
   function.
 
 Thus, c::foo must also be declared throw().
 
 > In any case, 15.4p10, and p8 suggest that this is a runtime error, not a
 > compile time error.
 
 15.4p8 deals with runtime behavior, and talks about a function with an
 exception specification.  c::foo has no exception specification, which is
 the problem.
 
 15.4p10 deals with expressions.  The problem is with the declaration.
 
 > This blocks the explicitly granted ability of library implementors to
 > tighten exception specs.
 
 True.  But this also seems problematic: if a library implementor tightens
 an exception spec, and a user wants to write a derived class which throws
 an exception which would be allowed by the standard, they lose.
 
 It's probably worth raising this conflict in the standards committee,
 perhaps as both core and library issues.
 
 >>I suppose that, as an extension, if a derived function has a looser
 >>exception specification we could clobber it with the one from the base
 >>class and give a pedwarn.  But that seems ugly to me.
 
 A more reasonable extension might be to only do this for declarations with
 no exception specification at all.
 
 > What happens is that unexpected is called, I don't see this as up for
 > debate if we are just interpreting the standard.
 
 Exception specs are enforced in the callee, not the caller.  They are a
 promise made by a function that a call to that function will not throw an
 exception other than those explicitly listed.  Since c::foo doesn't have an
 exception specification, it never calls unexpected.
 
 The reason for 15.4p3 is so that if I have a b*, I can assume that a call
 to bp->foo() will not throw.  But if that call finds c::foo instead, and it
 throws, we're throwing an exception that we promised not to.
 
 With the current compiler, since b::foo() is declared throw(), unwinding
 would fail and we would call terminate().  If b::foo() had some other throw
 spec, the exception would escape, violating the exception specification.
 
 > In this case, what unexpected does is implementation defined, and may
 > indeed do what you are suggesting, throw bad_exception, etc.
 
 What unexpected does is not implementation defined.  For a throw()
 specifier, it calls the unexpected handler, which unless changed is
 terminate().
 
 > I think the current behavior is wrong. Icc seems to agree.
 
 It looks like icc isn't calling unexpected, either.
 
 Jason

Re: c++/10457: exception specs vs. -fno-enforce-eh-specs

[Jason Merrill]

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

From: Jason Merrill <jason@redhat.com>
To: Cc: bkoz@redhat.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   mark@codesourcery.com, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/10457: exception specs vs. -fno-enforce-eh-specs
Date: Wed, 23 Apr 2003 05:13:14 +0100

 You were right when you said that your testcase is ill-formed.  The errors
 g++ is giving are correct, per 15.4p3.
 
 I suppose that, as an extension, if a derived function has a looser
 exception specification we could clobber it with the one from the base
 class and give a pedwarn.  But that seems ugly to me.
 
 Jason

Re: c++/10457: exception specs vs. -fno-enforce-eh-specs

[bkoz]

Synopsis: exception specs vs. -fno-enforce-eh-specs

State-Changed-From-To: open->analyzed
State-Changed-By: bkoz
State-Changed-When: Wed Apr 23 03:59:48 2003
State-Changed-Why:
    
    Actually icc does the right thing. I need to add d.foo() in the try block, and then:
    
    %a.out
    caught
    St13runtime_error

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

c++/10457: exception specs vs. -fno-enforce-eh-specs

[bkoz]

>Number:         10457
>Category:       c++
>Synopsis:       exception specs vs. -fno-enforce-eh-specs
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Apr 23 03:06:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     bkoz@redhat.com
>Release:        gcc-3.2.x, gcc-3.3.x, gcc-head
>Organization:
>Environment:
x86/linux RH9
>Description:

This page:
http://gcc.gnu.org/onlinedocs/gcc/C---Dialect-Options.html#C++%20Dialect%20Options

Says that:

-fno-enforce-eh-specs
    Don't check for violation of exception specifications at runtime. This option violates the C++ standard, but may be useful for reducing code size in production builds, much like defining NDEBUG. The compiler will still optimize based on the exception specifications. 

Seems simple enough. However, this code, which I'd like to use this flag with, won't compile.

#include <stdexcept>
#include <iostream>

struct b
{
  virtual void
  foo() throw() { }
};

struct c : virtual public b
{
  void
  foo() { throw std::runtime_error("call unexpected"); }
};

int main()
{
  try
    {
      c obj;
    }
  catch(std::exception& obj)
    {
      std::cout << "caught" << std::endl;
      std::cout << typeid(obj).name() << std::endl;
    }
  return 0;
}

This part of the C++ Standard,

15.4 - Exception specifications

gives me the impression that 
1) the code above is ill-formed
2) the code above should compile (p10)
3) the code above should throw unexpected when c::foo is called and throws anything (p8)

I'd expect that the above would print out caught, with either the runtime_error or bad_exception type on the thrown object.

That part ok? I'm not quite sure of CWG issues in this area, so bear with me if I don't understand something here.

Anyway.

This behavior, as specified in the standard, is important, and going to get more important in the future (more on that below). If I could specify what g++ did, I'd suggest that
g++ compile this ill-formed code, with an optional warning, and throw unexpected when the exception specs are violated. 

For the record, icc-7.0 doesn't get this right either. It doesn't warn (perhaps there is an optional flag) and it doesn't throw.

g++ 3.2.2 does this:
%g++ -fno-enforce-eh-specs xspex.cc
xspex.cc:13: looser throw specifier for `virtual void c::foo()'
xspex.cc:7:   overriding `virtual void b::foo() throw ()'
xspex.cc:13: looser throw specifier for `virtual void c::foo()'
xspex.cc:7:   overriding `virtual void b::foo() throw ()'
xspex.cc:13: looser throw specifier for `virtual void c::foo()'
xspex.cc:7:   overriding `virtual void b::foo() throw ()'

g++ version 3.4 20030420 -fno-enforce-eh-specs
xspex.cc:13: error: looser throw specifier for `virtual void c::foo()'
xspex.cc:7: error:   overriding `virtual void b::foo() throw ()'


So. This is important for two reasons:

1) Mark just checked in a patch that supposedly improves compile times when throw() exception specs are used. Jason has also indicated that there are code-size savings.

2) I'd like to add throw() specs to some of the locale facet member functions, to fix things like 10132, and make policy clear.

-benjamin
>How-To-Repeat:

>Fix:

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