Warnings Cleanup

[matthewhall2]

Suppresses warnings when building on OpenXL

Warnings:

• uninitialized variables
• C++ 11 ISO does not allow conversion from string literal to char *
• unused statements
• assignments inside if clause
• unhandled enums in switch

R29 build: https://hyc-runtimes-jenkins.swg-devops.com/job/jvm.29.personal/34216/

[r30shah]

jenkins test sanity all jdk11,jdk21

[r30shah]

@matthewhall2 seems like there are some failures in the build, can you check ?

[r30shah]

jenkins test sanity all jdk11,jdk21

[r30shah]

Looking into JDK21/JDK11 failures on s390, failures in JDK21 is not related to changes in this PR. Issue for the failures seen : #20150

[r30shah]

Seems like x86 failures are related to #18557.

[r30shah]

jenkins test sanity xlinux jdk11

[matthewhall2]

Looking into JDK21/JDK11 failures on s390, failures in JDK21 is not related to changes in this PR. Issue for the failures seen : #20150

JDK11 failures look to be the same

[keithc-ca]

Given the name of the function, I suspect 0x3 ought to be 0x07 (that the offset is a multiple of 8).

[r30shah]

I think this part of code needs some investigation - Looking at the places where we would use this query will be while inlining method from AtomicLong and the value (confirmed with sig is long), Sincename intOrBoolOffset sounds contradictory to the name of the function, and change this as a separate PR if Keith you are OK with it, I would like @matthewhall2 to verify and fix this as a separate PR ?

[r30shah]

@keithc-ca ping to see what you think about above ? As I said what you pointed out is correct, but given that the this code is there since long I think a verification from @matthewhall2 is warranted on places where this query is used, so I think this can be done as a separate change (As original purpose of this PR from @matthewhall2 was to clean-up some of the warnings we saw with OpenXL compiles).

@matthewhall2 can open up the issue and get started on it to keep track of this.

[keithc-ca]

Yes, I think it makes sense to investigate and make any necessary changes for that mask separately.

[keithc-ca]

Approving on the assumption that the offset mask discussed in #20039 (comment) will be addressed separately.

[r30shah]

jenkins test sanity all jdk11,jdk21

[r30shah]

Will merge this once sanity test finishes

[r30shah]

@matthewhall2 Can you checkout the failed tests and confirm if they are known issues or something new ?

[matthewhall2]

@r30shah jdk21 s390x_linux failure looks to be #18521

jdk11 and 21 arch64: #20233

mac got these failures (should we re-run?)

15:44:57  update to openj9 sha: origin/pr/20039/merge
15:44:57  git fetch -q --unshallow
15:45:07  error: pathspec 'origin/pr/20039/merge' did not match any file(s) known to git
15:45:07  SHA not yet found. Continue fetching PR refs and tags...
15:45:07  git fetch -q --tags https://github.com/eclipse-openj9/openj9.git +refs/pull/*:refs/remotes/origin/pr/*
15:45:32  error: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8)
15:45:32  error: 7344 bytes of body are still expected
15:45:32  fetch-pack: unexpected disconnect while reading sideband packet
15:45:32  fatal: early EOF
15:45:32  fatal: fetch-pack: invalid index-pack output

windows is not showing any failures and all 3 of build, sanity functional, and sanity openjdk have no errors, not sure why its showings as failed

[r30shah]

jenkins test sanity xmac jdk21

[r30shah]

jenkins test sanity zlinux jdk21

[r30shah]

Thanks @matthewhall2 , I have launched another for zLinux - Will merge this once it finishes.

[r30shah]

Failure seen on s390 was same as #19618, I am merging this one as satisfied with the passed tests so far and I do not expect the changes in this PR to cause issue with the targets we could not get passing due to existing issues.