The usual reason for explicitly calling the destructor is if you then follow it up with a call to placement new to construct a new object in the same memory, but presumably that part was not relevant to the crash and so was not included in the minimal test case.

Probably not, but the compiler crashing isn't a good way of notifying the user of that!

Ah, I didn't realize the segfault was in the compiler itself. The title ("segmentation fault on calling destructor in member function") made it sound like the generated code crashed. Now that there's a gist of a callstack it's clearer.

Yeah, maybe this is just a standard-conforming implementation of undefined behavior.

It's nothing to do with standard-conforming or not. A correct implementation shall never crash.

That's a pretty broad and idealistic claim to be making.

"Correctness" itself isn't an absolute. While something either does or does not conform to whatever has been defined as "correct", it's perfectly fine for the defined "correct" behavior in a given situation to be a crash.

In some cases a crash is the best that can be hoped for. Continuing on, even in an attempt to handle the failure more gracefully, can potentially be more harmful than just crashing.

I think you're confusing a crash in the generated program with a crash in the compiler itself. The latter is what's happening here.

There is lots of undefined behavior that causes crashing, although usually of the target program, not the compiler. Crashing compilers is nothing new though. I can't count how many ICEs I used to run into in certain versions of certain other compilers...