On 17-09-23 22:51, Jonathan Wakely wrote:
Why would it be trapping? It's loading an int64_t, which might be
uninitialised but it can't trap.
In this context I think that Valgrind is considering that any memory
load could trap.
*f on a std::optional is not like dereferencing a pointer, the int64_t
memory location is always present as part of the object.
For this
movq 40(%rbx), %rax
unless you know that what RBX+40 is pointing to is safe to dereference
it's not different to dereferencing a pointer.
So I think that the problem is that Valgrind is being cautious and not
allowing any loads but GCC is accepting what it considers safe loads
from the stack.
A+
Paul
