Re: [tree-ssa] Fun with exceptions -- opinions needed

[Michael Matz <matz at suse dot de>]

Hi,

On 16 Jun 2003, Frank Ch. Eigler wrote:

> > [...]  OK.  So think about what happens if "get" throws an exception
> > in the statement "i = get (strm.5)".  Right, the side effect of
> > assigning a new value to "i" does not happen.
>
> Can someone explain why such a side-effect would be expected?

In "l = rhs", where rhs is (or contains) a function call, there is a
sequence point right after the copying of the return value (1.9.17).  This
means, that in C++ function calls can clobber the return value, even
when they throw, if there are no other reasons for a sequence point being
there (for instance by overloading 'operator =', which would then require
that it _not_ be called).  Now that I think about this, some of our C++
testcases could be wrong, for instance

  int i_throw_something ( throw 1; return 42; }
  void bla() {
    int i = 0;
    try { i = i_throw_something(); }
    catch (...) {/*ignore*/}
    if (i != 0)
      abort();
  }

would invoke unspecified behaviour.  Hmm.  There is another sequence point
after evaluating the args, but before any statements of the function are
executed.  But that wouldn't help us here.  Then it's required that the
called function completes before execution resumes in the caller, but that
too doesn't help us here.

If 'rhs' does _not_ contain any function call, but could anyway throw an
exception (like overflow, or null-pointer access, or div by zero) the
behaviour is unspecified, because there is no sequence point involved
(except when there is one due to other reasons like use of '&&' or
similar).

But anyway, that's C++, but the IR needs to represent more than just that,
including languages where it's required to not affect 'l' in case 'rhs'
throws, for instance Java.  Hence it's best to explicitely differentiate
between the different types of side-effects.


Ciao,
Michael.