https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109446
--- Comment #13 from Xi Ruoyao <xry111 at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #12) > On Wed, 12 Apr 2023, marxin at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109446 > > > > --- Comment #9 from Martin Li?ka <marxin at gcc dot gnu.org> --- > > (In reply to Richard Biener from comment #8) > > > (In reply to Jakub Jelinek from comment #7) > > > > (In reply to Richard Biener from comment #6) > > > > > not sure if we should prevent all of those transforms. But the > > > > > question is > > > > > why ASAN doesn't instrument the generated aggregate copy? Maybe > > > > > because > > > > > in C/C++ you cannot write an aggregate array copy? > > > > > > > > We do instrument those. But only instrument them by checking the first > > > > and > > > > last byte > > > > of the copy, not all bytes in between (because that would be for inline > > > > checking too large - we'd need to emit inline a loop over those bytes). > > > > > > OK, that's lack of an appropriate API then? But still the first and last > > > byte should be sufficient to detect the problem (but maybe I'm missing > > > something here). > > > > No, because the last byte is out of redzone: > > > > =>0x7ffff5300000: f1 f1 f1 f1 00 00 00[f3]f3 f3 f3 f3 00 00 00 00 > > > > the 'f3' redzone is covering 5*8 bytes after the data type only. > > OK, so it's lack of an API then. The alternative would be to > do sth similar to stack-checking - instrument every 5*8 byte, > possibly up to some limit. Or, as you probably suggest, avoid > folding memcpy with size larger than 5*8 byte inline. I guess doing so will need to change the cpymemM expand of all targets.
