RFR(S): 8252407: Build failure with gcc-8+ and asan

[Kim Barrett]

> On Sep 29, 2020, at 6:51 AM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
>> On Sep 28, 2020, at 11:13 AM, Eric Liu <eric.c.liu at 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