Wrong code with throwing const function

[hvdijk]

Bugzilla Link	51021
Version	trunk
OS	Linux
CC	@dwblaikie,@DougGregor,@efriedma-quic,@zygoloid

Extended Description

The GCC developers have clarified that the function attributes const and pure do not imply that the functions do not throw. clang does assume that and as such miscompiles the following program:

  __attribute__((const)) void f() {
    throw 0;
  }

  int main() {
    try {
      f();
    } catch(int i) {
      return 0;
    }

    return 1;
  }

This program should return 0, not 1.

Godbolt link: https://godbolt.org/z/jj1PG7o78

(Please ignore the warning emitted by GCC, 'const' attribute on function returning 'void'; I have reported that as part of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101376.)

[hvdijk]

This worked with clang 3.2, started failing with clang 3.3, but looks like clang did have the same assumption in 3.2 already: bf005ec was part even of 3.0.

[davidstone]

Consider the following function that doesn't even visibly throw

int f() {
    try {
        throw 1;
    } catch (int) {
        return 0;
    }
}

I claim this function is neither gnu::pure nor gnu::const. It can be called in a destructor that might be invoked during stack unwinding when another exception is being handled. In that case, the program's behavior is to call std::terminate. Otherwise, the program's behavior is that this function returns 0.

[AaronBallman]

This behavior Changed in Clang 18, but not because we changed backend behavior but because the frontend started ignoring the attribute due to the void return type: https://godbolt.org/z/qEs4rnesj.

When you give a non-void return type, GCC and Clang's behavior matches: https://godbolt.org/z/Mreo61xeY

I think @davidstone is correct; throwing an exception means the function is neither const nor pure. From GCC's docs:

The pure attribute prohibits a function from modifying the state of the program that is observable by means other than inspecting the function’s return value.

Throwing an exception needs to allocate memory for the exception pointer (handled via __cxa_allocate_exception) and that is observable because that can fail (which calls std::terminate()). Then there's the fact that the function could be called from a destructor while an exception is already in-flight, which is also observable.

The const attribute prohibits a function from reading objects that affect its return value between successive invocations. However, functions declared with the attribute can safely read objects that do not change their return value, such as non-volatile constants.

Successive calls to the function may have different results. The first call may succeed and throw the exception while the second call fails to allocate memory for the exception pointer and calls std::terminate().

So closing this issue as behaving by design. However, feel free to reopen the issue with more details if there's something I'm missing.

[hvdijk]

I think @davidstone is correct; throwing an exception means the function is neither const nor pure.

I assumed the same and only reported this in response to an explicit statement by GCC developers that contradicts this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409#c8

(In reply to Harald van Dijk from comment #4)

The documentation for the pure attribute refers to "functions that have no
observable effects on the state of the program other than to return a value"
which implies not throwing exceptions, the Wsuggest-attribute=pure text says
that pure functions have to return normally, and the presence of throw
statements suppresses the compiler's suggestion to mark functions as pure.
This function throws, so should the fact that it is marked pure not simply
make the whole thing undefined?

It has been consensus that throwing exceptions and const/pure are different
concepts that co-exist. See for example the recent discussion at
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569435.html

[hvdijk]

That said, also agreed that the current example no longer demonstrates the problem and we need a new example. I will look for one.

[hvdijk]

New example:

foo.cc:

__attribute__((const)) int foo() { throw 0; }

bar.cc:

__attribute__((const)) int foo();
int bar() { return foo(); }

main.cc:

int bar();
int main() {
  try { bar(); }
  catch(int) { }
  return 0;
}

With clang++ -O3 *.cc -flto, this segfaults. With GCC, it does not segfault, and based on the above comment from the GCC bug tracker, I think GCC is correct that this should be regarded as valid. We are permitted to optimise away the call to foo() based on __attribute__((const)) and the fact that the result is not used, but we are not permitted to assume that if we do call foo(), it does not throw.

[AaronBallman]

I think @davidstone is correct; throwing an exception means the function is neither const nor pure.

I assumed the same and only reported this in response to an explicit statement by GCC developers that contradicts this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409#c8

(In reply to Harald van Dijk from comment #4)

The documentation for the pure attribute refers to "functions that have no
observable effects on the state of the program other than to return a value"
which implies not throwing exceptions, the Wsuggest-attribute=pure text says
that pure functions have to return normally, and the presence of throw
statements suppresses the compiler's suggestion to mark functions as pure.
This function throws, so should the fact that it is marked pure not simply
make the whole thing undefined?

It has been consensus that throwing exceptions and const/pure are different
concepts that co-exist. See for example the recent discussion at
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569435.html

I'm still not convinced. Specifically:

So, I think const and pure functions may validly throw (but then must always do so given the same inputs).

I don't think this holds in the case of memory allocation failures for the exception object resulting in a call to std::terminate(). Same inputs there may still lead to different observable behavior.

[hvdijk]

I'm still not convinced.

That's fair but then that is a conversation to be had on the GCC bug tracker with the GCC developers, in my opinion. As it stands, their comments say that the new test program is valid, and Clang treats it as invalid.

[AaronBallman]

CC @zygoloid @rjmccall for some other opinions on this; perhaps Clang and GCC simply diverge in this behavior and we should document the difference rather than change behaviors.