On Sun, 22 May 2022 16:45:11 GMT, Kim Barrett <kbarr...@openjdk.org> 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 <typename T>
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.
  set(bits, traceid_tag_byte(ptr));


PR: https://git.openjdk.java.net/jdk/pull/8646

Reply via email to