On Thu, 29 Apr 2021 20:54:47 GMT, Phil Race <p...@openjdk.org> wrote:
>> We can see following compiler warnings in imageioJPEG.c on GCC 11. > > src/java.desktop/share/native/libjavajpeg/imageioJPEG.c line 673: > >> 671: if (info->is_decompressor) { >> 672: j_decompress_ptr dinfo = (j_decompress_ptr) info; >> 673: #ifdef __GNUC__ > > I know how these structs are defined but I am not sure how gcc can decide > anything like this. > I'd almost worry if it were true that we had the other type despite what the > flag said except I can't > imagine gcc is doing even any static analysis of the code calling sequence > and you may even need a dynamic analysis for this. > > Have you submitted a gcc bug ? > Why is it only complaining in this branch ? > Have you considered disabling the warning in the make files - with broader > scope of course - but a simpler change ? > > Is 520 bytes the actual size of the compress struct ? And even then I am not > sure I know what the compiler message means. so long as we have the right > starting address free will only free what was allocated ... surely ... I also think GCC does not do any static analysis of the code calling. And also the code uses `struct` like a C++ class, so I guess GCC reports incorrect warnings at this point. Many -Warray-bounds related issues are reported in [GCC Bugzilla](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456). Especially it does not seem to work when the value is accessed by a pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99474 - it looks alike to me. WebKit seems to encounter [similar issue](https://bugs.webkit.org/show_bug.cgi?id=224782), they has avoided it with pragma. I concidered to disable it with a compiler option in makefile of course as you said, but I didn't do so because I heard in other review (I forget the JBS ticket) that we should disable warnings locally because they might be useful in future. ------------- PR: https://git.openjdk.java.net/jdk/pull/3788