On Mon, 18 Sept 2023 at 08:23, Jonathan Wakely <jwakely....@gmail.com> wrote: > > > > On Mon, 18 Sept 2023, 08:03 Paul Floyd via Gcc, <gcc@gcc.gnu.org> wrote: >> >> >> >> 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. > > > There are no padding bits in int64_t and all object representations are valid > values, so it has no trap representations. > > >> >> > *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. > > > If it isn't safe to load that integer then it isn't safe to call f.operator > bool() either. GCC knows they are part of the same object. > >> >> 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. > > > Yes, GCC assumes that the reference is bound to a valid object,
Sorry, replying to email too early in the morning. The parameter isn't optional<int64_t>& it's just optional<int64_t> so there's no reference, it's on the stack (as you said) and the compiler can assume that if the function was called then the stack address is valid. > because C++ requires that to be true. Of course memcheck can't assume that, > because one of its main reasons to exist is to find undefined behaviour where > that isn't true! > > I think what GCC is doing is a valid transformation, in the context of a > valid C++ program. But I'm not sure that helps valgrind, which doesn't have > the liberty of assuming a valid program. > > >
