On Thu, 29 Apr 2021 20:54:47 GMT, Phil Race <[email protected]> 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
