> On Sep 29, 2020, at 6:51 AM, Kim Barrett <kim.barr...@oracle.com> wrote: > >> On Sep 28, 2020, at 11:13 AM, Eric Liu <eric.c....@arm.com> wrote: >> >> Hi, >> >> Thanks for looking at this. >> >> For gcc-10, it's hard to make 'strncpy' all right with asan enabled >> (approaches we talked previous don't work). >> I'm trying to find a better way to avoid using compile pragma. I suppose it >> would be better to use 'memcpy' >> to replace 'strncpy'. >> >> >> Thanks, >> Eric > > […] > At this point all I can conclude is that --enable-asan (i.e. > -fsanitize=address) is simply incompatible with -Wstringop-truncation, at > least through gcc10. That seems like a bug that someone should report. > (Might be same as or related to > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650) > > […] > > Since it seems to be incompatible with various other options that we *do* > normally use, I think the way to allow --enable-asan to be (possibly) usable > is in the build system at configure time. That is, the --enable-asan > configure option should, in addition to adding -fsanitize=address, also (1) > disable -Wstringop-truncation and (2) disable the defining of > _FORTIFY_SOURCE in fastdebug builds. It looks like making those changes > involves conditionalizing their addition/removal using ${ASAN_ENABLED}. > > Scattering pragmas for disabling -Wstringop-truncation doesn't cut it.
Another option might be to solve https://bugs.openjdk.java.net/browse/JDK-8232187
