Maybe something like this?

diff -r 829a32a4171c libinterp/corefcn/stack-frame.cc
--- a/libinterp/corefcn/stack-frame.cc        Tue Jul 11 19:43:03 2023 +0200
+++ b/libinterp/corefcn/stack-frame.cc        Tue Jul 11 20:20:19 2023 +0200
@@ -1197,11 +1197,13 @@

     // Member dtor order is last to first.  So, m_auto_vars before m_values.

-    for (auto& auto_var : m_auto_vars)
-      auto_var = octave_value ();
-
-    for (auto& value : m_values)
-      value = octave_value ();
+    for (auto auto_vars_iter = m_auto_vars.begin ();
+         auto_vars_iter != m_auto_vars.end ();)
+      auto_vars_iter = m_auto_vars.erase (auto_vars_iter);
+
+    for (auto values_iter = m_values.begin ();
+         values_iter != m_values.end ();)
+      values_iter = m_values.erase (values_iter);
   }

   std::size_t size () const

It seems reasonable to me to ensure that the classdef destructors called in the same order for all versions of Octave regardless of what a particular standard library implementation does to destroy vector elements.  In that case, we should not assume that libstdc++ will always behave the way it does now and we should enforce the behavior we want unconditionally.

If there is no C++ standard guarantee of the order that elements of an array will be deleted, then I don't think this change should be conditional on HAVE_LLVM_LIBCXX.

Is there any compatibility reason we need to guarantee the order of execution for classdef destructors?  If not, then I don't see the point in Octave forcing a particular order either and in that case, I'd opt to fix the tests instead.

From the point of view of the VM it does not matter. It does the libstdc++ order (first to last element of the variables) and does not use the code effected by the patch.

I guess the destructor execution order matter if a user put side effects in a classdef dtor? I guess the specific order is not that important, but it might be confusing of different builds of Octave of the same version are not deterministic in their execution?

I think I'll do a patch an alternative patch for the test that accepts any dtor order anyways.

"
Same destructor order for octave_value:s in frame in std::vector for libstdc++ and libc++

• libinterp/corefcn/stack-frame.cc:

Explicitly overwrite octave_value:s in libstdc++ order for libc++ users
"

The current behaviour might be correct.

clang with libc++ Octave builds fails in the bytecode_cdef_use.m test due to base_value_stack_frame using std::vector to store octave_value:s in the frame. The test is dependent on that the tree_evaluator has the same classdef dtor order as the VM.

The patch writes nil values to the std::vector:s for libc++ to get the same dtor order as libstdc++.

I remember reading some documentation that classdef dtor order is not defined for Octave so maybe the test should be updated to accept both orders instead?