https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045
--- Comment #19 from Mark Wielaard <mark at gcc dot gnu.org> --- (In reply to David Binderman from comment #18) > (In reply to Mark Wielaard from comment #17) > > I am surprised valgrind memcheck doesn't produce more output, normally it > > would tell you why & where it found the address invalid. > > The valgrind output I gave originally looks to be in the usual valgrind > format to me. > Perhaps you are assuming some other debugging tool like asan or ubsan ? Normally valgrind adds something like: Address 0xaaaaaa is x bytes inside a block of size y free'd please a stacktrace where that block was allocated/freed In this case I would expect to say something like that the address that is being access is after a block. Assuming it is indeed not accessible. The read of 4 bytes is interesting, it seems to mean that valgrind decided to chop up this read into smaller blocks. > > I assume somehow > > valgrind memcheck believes it is reading past the end of a data buffer, > > while the code assumes this is fine because it will mask off the bits it > > won't use. > > valgrind doesn't normally produce an error for copying around un-initialised > bytes. > > However, it will produce an error if those bytes are used in a decision > like an if statement. Or it will produce an error if it is an unaddressible location. Which seems to be the case here. I would try to figure out which address exactly it is, what the exact arm/neon (?) instruction it is that is being executed. How many bytes it is supposed to read and if that many bytes are actually available. If this is an overread then you might try --partial-loads-ok=yes (although that should be the default these days). If that doesn't work then valgrind might have chopped up the read into smaller blocks, so memcheck cannot see that it is a larger load and the backend (VEX/priv/guest_arm_toIR.c) might have to be adjusted.
