https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109446
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- 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.
