Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Sun, 22 May 2022 16:45:11 GMT, Kim Barrett wrote:
>> It might be GCC bug...
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
>>
>> This issue is for integer literal, but [Comment
>> 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address
>> calculation (e.g. `NULL + offset`) - it is similar the problem in
>> jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr +
>> low_offset`).
>
> I don't see the similarity. That gcc bug is about literals used as addresses,
> which get treated (suggested inappropriately) as NULL+offset, with NULL+offset
> being a cause of warnings. I don't see that happening in our case. That is,
> in our `addr + low_offset`, `addr` doesn't seem to be either a literal or NULL
> that I can see.
>
> It's hard for me to investigate this any further just by perusing the code, so
> I'm in the process of getting set up to build with gcc12.x. That will let me
> do some experiments. It may take me a few days to get to that point though.
I spent some time looking into this one. I agree there is a false positive
here, and there doesn't seem to be a better solution than suppressing the
warning. I would prefer the change below, rather than what's proposed. Also
eliminate the changes to utilities/compilerWarnings files. This is a very
gcc-specific issue; there's no reason to generalize the solution. The reason
for relocating the suppression is to be able to describe the issue in more
detail in a context where that description makes sense.
template
inline void JfrTraceIdBits::store(jbyte bits, const T* ptr) {
assert(ptr != NULL, "invariant");
// gcc12 warns "writing 1 byte into a region of size 0" when T == Klass.
// The warning seems to be a false positive. And there is no warning for
// other types that use the same mechanisms. The warning also sometimes
// goes away with minor code perturbations, such as replacing function calls
// with equivalent code directly inlined.
PRAGMA_DIAG_PUSH
PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overflow")
set(bits, traceid_tag_byte(ptr));
PRAGMA_DIAG_POP
}
-
PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Sun, 22 May 2022 08:45:48 GMT, Yasumasa Suenaga wrote: >> I don't think this warning has anything to do with that NULL check. But I'm >> still not understanding what it is warning about. The "region of size 0" part >> of the warning message seems important, but I'm not (yet?) seeing how it >> could >> be coming up with that. The code involved here is pretty contorted... > > It might be GCC bug... > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 > > This issue is for integer literal, but [Comment > 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address > calculation (e.g. `NULL + offset`) - it is similar the problem in > jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + > low_offset`). I don't see the similarity. That gcc bug is about literals used as addresses, which get treated (suggested inappropriately) as NULL+offset, with NULL+offset being a cause of warnings. I don't see that happening in our case. That is, in our `addr + low_offset`, `addr` doesn't seem to be either a literal or NULL that I can see. It's hard for me to investigate this any further just by perusing the code, so I'm in the process of getting set up to build with gcc12.x. That will let me do some experiments. It may take me a few days to get to that point though. - PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Sun, 22 May 2022 08:35:54 GMT, Yasumasa Suenaga wrote:
>> `Array::_data` is a pseudo flexible array member. "Pseudo" because C++
>> doesn't have flexible array members. The compiler is completely justified in
>> complaining about the apparently out-of-bounds accesses.
>>
>> There is a "well-known" (though moderately ugly) approach to doing flexible
>> array members in C++. Something like this:
>>
>>
>> T* data() {
>> return reinterpret_cast(
>> reinterpret_cast(this) + data_offset());
>> }
>>
>>
>> where `data_offset()` is new and private:
>>
>>
>> static size_t data_offset() {
>> return offset_of(Array, _data);
>> }
>>
>>
>> Use `data()` everywhere instead of using `_data` directly.
>>
>> There are other places in HotSpot that use this kind of approach.
>
> Thanks @kimbarrett for your advice! Warnings from array.hpp have gone with
> your suggestion.
Good. I see you found and used the existing `base_offset_in_bytes` (which I'd
overlooked), rather than using my suggested `data_offset`.
-
PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Sun, 22 May 2022 05:00:21 GMT, Kim Barrett wrote: >> I guess GCC cannot understand `assert(dest != NULL` immediately preceding it. >> >> >> In file included from >> /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33, >> from >> /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30, >> from >> /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30: >> In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = >> traceid_or]', >> inlined from 'void set(jbyte, jbyte*)' at >> /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23, >> inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T >> = Klass]' at >> /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6, >> inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const >> Klass*)' at >> /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3, >> inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at >> /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35: > > I don't think this warning has anything to do with that NULL check. But I'm > still not understanding what it is warning about. The "region of size 0" part > of the warning message seems important, but I'm not (yet?) seeing how it could > be coming up with that. The code involved here is pretty contorted... It might be GCC bug... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 This issue is for integer literal, but [Comment 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address calculation (e.g. `NULL + offset`) - it is similar the problem in jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + low_offset`). - PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Sun, 22 May 2022 03:15:20 GMT, Kim Barrett wrote:
>> Like the others, it is caused by `Array::at_put()`.
>>
>>
>> In file included from
>> /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28,
>> from
>> /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29,
>> from
>> /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30,
>> from
>> /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35:
>> In member function 'void Array::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::symbol_at_put(int, Symbol*)' at
>> /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15,
>> inlined from 'void
>> ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at
>> /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21:
>
> `Array::_data` is a pseudo flexible array member. "Pseudo" because C++
> doesn't have flexible array members. The compiler is completely justified in
> complaining about the apparently out-of-bounds accesses.
>
> There is a "well-known" (though moderately ugly) approach to doing flexible
> array members in C++. Something like this:
>
>
> T* data() {
> return reinterpret_cast(
> reinterpret_cast(this) + data_offset());
> }
>
>
> where `data_offset()` is new and private:
>
>
> static size_t data_offset() {
> return offset_of(Array, _data);
> }
>
>
> Use `data()` everywhere instead of using `_data` directly.
>
> There are other places in HotSpot that use this kind of approach.
Thanks @kimbarrett for your advice! Warnings from array.hpp have gone with your
suggestion.
-
PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Tue, 17 May 2022 12:43:02 GMT, Yasumasa Suenaga wrote: >> 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. > > I guess GCC cannot understand `assert(dest != NULL` immediately preceding it. > > > In file included from > /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33, > from > /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30, > from > /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30: > In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = > traceid_or]', > inlined from 'void set(jbyte, jbyte*)' at > /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23, > inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T > = Klass]' at > /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6, > inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' > at > /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3, > inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at > /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35: I don't think this warning has anything to do with that NULL check. But I'm still not understanding what it is warning about. The "region of size 0" part of the warning message seems important, but I'm not (yet?) seeing how it could be coming up with that. The code involved here is pretty contorted... - PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Tue, 17 May 2022 12:38:55 GMT, Yasumasa Suenaga wrote:
>> 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.)
>
> Like the others, it is caused by `Array::at_put()`.
>
>
> In file included from
> /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28,
> from
> /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29,
> from
> /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30,
> from
> /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35:
> In member function 'void Array::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::symbol_at_put(int, Symbol*)' at
> /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15,
> inlined from 'void
> ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at
> /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21:
`Array::_data` is a pseudo flexible array member. "Pseudo" because C++
doesn't have flexible array members. The compiler is completely justified in
complaining about the apparently out-of-bounds accesses.
There is a "well-known" (though moderately ugly) approach to doing flexible
array members in C++. Something like this:
T* data() {
return reinterpret_cast(
reinterpret_cast(this) + data_offset());
}
where `data_offset()` is new and private:
static size_t data_offset() {
return offset_of(Array, _data);
}
Use `data()` everywhere instead of using `_data` directly.
There are other places in HotSpot that use this kind of approach.
-
PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Tue, 17 May 2022 04:52:44 GMT, Kim Barrett wrote: >> 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. > > While looking at type2name, I noticed the comment for the immediately > preceding type2name_tab is wrong. The warning has gone in new commit, and I fixed the comment for `type2name_tab` in it. - PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Tue, 17 May 2022 03:06:49 GMT, Kim Barrett wrote:
>> 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
>
> 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.
The warning has gone in new commit due to change of `type2name`.
-
PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Tue, 17 May 2022 03:14:05 GMT, Kim Barrett wrote: >> 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 > > 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. Most of switch cases are warned. Please see [logs](https://github.com/openjdk/jdk/files/8708578/hotspot_variant-server_libjvm_objs_bytecodeAssembler.o.log) - PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Tue, 17 May 2022 03:02:55 GMT, Kim Barrett wrote: >> 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 > > 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. I guess GCC cannot understand `assert(dest != NULL` immediately preceding it. In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30: In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = traceid_or]', inlined from 'void set(jbyte, jbyte*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23, inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T = Klass]' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6, inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3, inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35: - PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Tue, 17 May 2022 01:43:25 GMT, Kim Barrett wrote: >> 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 > > 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.) Like the others, it is caused by `Array::at_put()`. In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35: In member function 'void Array::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::symbol_at_put(int, Symbol*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15, inlined from 'void ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21: - PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Tue, 17 May 2022 03:05:09 GMT, Kim Barrett wrote: >> 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 > > 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. While looking at type2name, I noticed the comment for the immediately preceding type2name_tab is wrong. - PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga 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::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
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga 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::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 Marked as reviewed by prr (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga 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::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 I've sent another review request for bug fixes as #8694 and #8696 , and I reverted change for them from this PR. Could you review this PR to suppress warnings which we can ignore? - PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
> 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::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 - Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/b3afa3e0..d5ef2c63 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8646=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8646=03-04 Stats: 10 lines in 3 files changed: 1 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646
