Re: Integrated: 8286562: GCC 12 reports some compiler warnings
The new assertion in src/hotspot/share/utilities/globalDefinitions.hpp
inline const char* type2name(BasicType t) {
assert((uint)t < T_CONFLICT + 1, "invalid type");
return type2name_tab[t];
}
is failing with test
compiler/jvmci/errors/TestInvalidDebugInfo.java
I have filed:
https://bugs.openjdk.java.net/browse/JDK-8287491
The test will probably need ProblemListing as it is causing major noise
in our CI.
David
On 28/05/2022 12:12 pm, Yasumasa Suenaga wrote:
On Wed, 11 May 2022 05:58:31 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:
This pull request has now been integrated.
Changeset: 410a25d5
Author:Yasumasa Suenaga
URL:
https://git.openjdk.java.net/jdk/commit/410a25d59a11b6a627bbb0a2c405c2c2be19f464
Stats: 41 lines in 5 files changed: 26 ins; 1 del; 14 mod
8286562: GCC 12 reports some compiler warnings
Reviewed-by: ihse, kbarrett, prr
-
PR: https://git.openjdk.java.net/jdk/pull/8646
Integrated: 8286562: GCC 12 reports some compiler warnings
On Wed, 11 May 2022 05:58:31 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: This pull request has now been integrated. Changeset: 410a25d5 Author:Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/410a25d59a11b6a627bbb0a2c405c2c2be19f464 Stats: 41 lines in 5 files changed: 26 ins; 1 del; 14 mod 8286562: GCC 12 reports some compiler warnings Reviewed-by: ihse, kbarrett, prr - PR: https://git.openjdk.java.net/jdk/pull/8646
Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Respond to review feedback. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8236
Re: gcc, arm, and thumbs mode
Hi Thomas,
On 5/27/22 16:12, Thomas Stüfe wrote:
P.S. I found one possible solution for my particular problem was to add
`.type function` to the static assembler routine. That caused gcc to use
the correct jump instruction (blx instead of bl). But I am not sure this is
the best solution, maybe best would be to just use the same mode for all
hotspot compilation units.
AFAIR, that .type %function directive is a correct way to write asm
code. At least this is what gcc generates for the C code [1]. I'm not
sure how the annotation in the assembly code affects the caller code,
may be link time optimization? But if adding the directive resolves the
issue, I vote for it.
(I expect arm-none crosscompiler to produce similar results compared to
arm-linux target)
Thanks,
Anton
$ echo "int main() { return 0; }" | arm-none-eabi-gcc -mthumb -S -x c - -o -
.cpu arm7tdmi
.arch armv4t
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 6
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.file ""
.text
.align 1
.global main
.syntax unified
.code 16
.thumb_func
.type main, %function
main:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
push{r7, lr}
add r7, sp, #0
movsr3, #0
movsr0, r3
mov sp, r7
@ sp needed
pop {r7}
pop {r1}
bx r1
.size main, .-main
.ident "GCC: (Arch Repository) 12.1.0"
Re: gcc, arm, and thumbs mode
(cited the wrong JBS issue, the correct one is https://bugs.openjdk.java.net/browse/JDK-8284997) On Fri, May 27, 2022 at 3:12 PM Thomas Stüfe wrote: > Hi, > > I am investigating the arm-specific problem > https://bugs.openjdk.java.net/browse/JDK-8283326. It looks like the > error is caused by arm- and thumb-code interleaving: GCC-compiled code, in > thumb mode, calls into a static assembler subroutine that has been compiled > into arm mode, but the caller uses the wrong call instruction and we call > into SafeFetch without switching into arm mode (gcc-generated code uses bl > instead of blx). > > This problem only happens if the OpenJDK was built with a GCC that itself > was built with --with-mode=thumb. Without that option, GCC defaults to arm > code generation, and that hides the error I describe above. > > My question is: Is this by design? It seems strange to leave this decision > up to whoever built the toolchain. Should we not fix the arm/thumb decision > at build time with either one of -mthumb or -marm? > > Thanks, Thomas > > P.S. I found one possible solution for my particular problem was to add > `.type function` to the static assembler routine. That caused gcc to use > the correct jump instruction (blx instead of bl). But I am not sure this is > the best solution, maybe best would be to just use the same mode for all > hotspot compilation units. >
gcc, arm, and thumbs mode
Hi, I am investigating the arm-specific problem https://bugs.openjdk.java.net/browse/JDK-8283326. It looks like the error is caused by arm- and thumb-code interleaving: GCC-compiled code, in thumb mode, calls into a static assembler subroutine that has been compiled into arm mode, but the caller uses the wrong call instruction and we call into SafeFetch without switching into arm mode (gcc-generated code uses bl instead of blx). This problem only happens if the OpenJDK was built with a GCC that itself was built with --with-mode=thumb. Without that option, GCC defaults to arm code generation, and that hides the error I describe above. My question is: Is this by design? It seems strange to leave this decision up to whoever built the toolchain. Should we not fix the arm/thumb decision at build time with either one of -mthumb or -marm? Thanks, Thomas P.S. I found one possible solution for my particular problem was to add `.type function` to the static assembler routine. That caused gcc to use the correct jump instruction (blx instead of bl). But I am not sure this is the best solution, maybe best would be to just use the same mode for all hotspot compilation units.
Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Respond to review feedback. Marked as reviewed by erikj (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Respond to review feedback. Marked as reviewed by dholmes (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: 8287378: GHA: Update cygwin to fix issues in langtools tests on Windows
On Thu, 26 May 2022 16:07:56 GMT, Christoph Langer wrote: > This fixes the Windows GHA test failures that popped up short time ago, e.g. > [these](https://github.com/RealCLanger/jdk/runs/6598399845) > > Failing tests: > tools/javac/Paths/MineField.sh > tools/javac/Paths/wcMineField.sh > > I've debugged it and it comes down to calls to javac/java in the test through > env are failing with RC 127. E.g. here: > https://github.com/openjdk/jdk/blob/e44465d4d6eaddebfc5a1b149223aa8332affa8b/test/langtools/tools/javac/Paths/MineField.sh#L218 > > Don't know why but I figured that the test failure goes away with current > cygwin. > > It should be ok to update cygwin now because the bug that made JDK-8276854 > necessary seems to be fixed. PS: The Windows langtools failure seen here is jdk/jshell/HighlightUITest.java, which seems to be unstable as of [JDK-8284144](https://bugs.openjdk.java.net/browse/JDK-8284144) and has already been excluded on several other platforms but not Windows yet. - PR: https://git.openjdk.java.net/jdk/pull/8903
