On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga <ysuen...@openjdk.org> wrote:
>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1
>> on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should
>> separate them by area.
>>
>> * -Wstringop-overflow
>> * src/hotspot/share/oops/array.hpp
>> *
>> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>>
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned
>> char]',
>> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at
>> /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>> inlined from 'void ConstantPool::method_at_put(int, int, int)' at
>> /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>> inlined from 'ConstantPool*
>> BytecodeConstantPool::create_constant_pool(JavaThread*) const' at
>> /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Revert change for java.c , parse_manifest.c , LinuxPackage.c
Some suggestions for code changes instead of warning suppression. And some
warnings that I don't yet understand and don't think should be suppressed
without more details or investigation.
src/hotspot/share/classfile/bytecodeAssembler.cpp line 95:
> 93: ShouldNotReachHere();
> 94: }
> 95: PRAGMA_DIAG_POP
One of these is another of the symbol_at_put cases that I don't understand.
Are there other cases in the switch that warn? And if so, which ones and how?
There are no details of this one in the PR cover description.
src/hotspot/share/classfile/classFileParser.cpp line 5970:
> 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED
> 5969: _cp->symbol_at_put(hidden_index, _class_name);
> 5970: PRAGMA_DIAG_POP
I don't understand these warning suppressions for symbol_at_put (here and
elsewhere). I don't see any stringops here. What is the compiler complaining
about? (There's no mention of classfile stuff in the review cover message.)
src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
line 103:
> 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED
> 102: *dest = op(bits, *dest);
> 103: PRAGMA_DIAG_POP
I see no stringop here. I'm still trying to understand what the compiler is
complaining about.
src/hotspot/share/opto/memnode.cpp line 1413:
> 1411: bt == T_BYTE || bt == T_SHORT ||
> 1412: bt == T_INT || bt == T_LONG, "wrong type = %s",
> type2name(bt));
> 1413: PRAGMA_DIAG_POP
The problem here is the definition of type2name, which returns NULL for an
unknown BasicType. It would probably be better if it returned a recognizable
string for that situation, eliminating this warning at it's source.
src/hotspot/share/opto/type.cpp line 4300:
> 4298: PRAGMA_FORMAT_OVERFLOW_IGNORED
> 4299: fatal("not an element type: %s", type2name(etype));
> 4300: PRAGMA_DIAG_POP
Another occurrence of type2name returning NULL for unknown BasicType.
-------------
Changes requested by kbarrett (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/8646
