On Thu, 21 Jul 2022 10:18:05 GMT, Sacha Coppey wrote:
> This patch adds a JVMCI implementation for RISC-V. It creates the
> jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 packages, as well as
> implements a part of jvmciCodeInstaller_riscv64.cpp. To check for
> correctness, it enables JVMCI c
On Thu, 21 Mar 2024 15:33:21 GMT, Aleksey Shipilev wrote:
> Debian "unstable" is currently undergoing t64 (hello, Y2038) transition,
> which breaks "sid" repo that we use for debootstrapping RISC-V very often.
> This is seen across multiple repositories, and requires everyone to look
> through
On Fri, 23 Aug 2024 18:42:28 GMT, Hamlin Li wrote:
>> Roman Kennke has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix bit counts in GCForwarding
>
> src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp line 170:
>
>> 168: mv(tmp1, (int3
Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use
for debootstrapping RISC-V breaks very often. Currently, the GHA
linux-cross-build for RISC-V would not continue and is simply skipped when this
debootstrap for "sid" repos fails. (See
[JDK-8326960](https://bugs.openjd
On Wed, 4 Sep 2024 14:40:38 GMT, Fei Yang wrote:
> Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use
> for debootstrapping RISC-V breaks very often. Currently, the GHA
> linux-cross-build for RISC-V would not continue and is simply ski
On Wed, 4 Sep 2024 14:40:38 GMT, Fei Yang wrote:
> Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use
> for debootstrapping RISC-V breaks very often. Currently, the GHA
> linux-cross-build for RISC-V would not continue and is simply ski
On Thu, 5 Sep 2024 13:23:14 GMT, Erik Joelsson wrote:
>> Marked as reviewed by erikj (Reviewer).
>
>> @erikj79 : Please take a look. Thanks.
>
>> Maybe @erikj79 ? Thanks.
>
> I generally skip most GHA related PRs as there are plenty of other reviewers
> on this mailing list with deeper GHA kno
On Wed, 4 Sep 2024 14:40:38 GMT, Fei Yang wrote:
> Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use
> for debootstrapping RISC-V breaks very often. Currently, the GHA
> linux-cross-build for RISC-V would not continue and is simply ski
On Wed, 4 Sep 2024 14:40:38 GMT, Fei Yang wrote:
> Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use
> for debootstrapping RISC-V breaks very often. Currently, the GHA
> linux-cross-build for RISC-V would not continue and is simply ski
On Wed, 27 Jul 2022 11:25:22 GMT, Sacha Coppey wrote:
>> This patch adds a partial JVMCI implementation for RISC-V, to allow using
>> the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for
>> code emission.
>> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 pa
On Mon, 22 Aug 2022 16:57:41 GMT, Sacha Coppey wrote:
>> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.riscv64/src/jdk/vm/ci/riscv64/RISCV64Kind.java
>> line 54:
>>
>>> 52: V256_QWORD(32, QWORD),
>>> 53: V256_SINGLE(32, SINGLE),
>>> 54: V256_DOUBLE(32, DOUBLE);
>>
>> I see some ve
On Mon, 22 Aug 2022 11:32:54 GMT, Sacha Coppey wrote:
> Sorry for the delay, but all the JVMCI tests now pass.
So I give it a second try with fastdebug build on my unmatched board [1], I see
the error has changed into [2].
Is there anything I missed? Thanks.
[1]
$ make run-test-only
TEST="./t
On Tue, 23 Aug 2022 11:29:45 GMT, Sacha Coppey wrote:
>> This patch adds a partial JVMCI implementation for RISC-V, to allow using
>> the GraalVM Native Image RISC-V LLVM backend, which does not use JVMCI for
>> code emission.
>> It creates the jdk.vm.ci.riscv64 and jdk.vm.ci.hotspot.riscv64 pa
On Wed, 24 Aug 2022 07:43:06 GMT, Sacha Coppey wrote:
> > I see you added more changes in hotspot file sharedRuntime_riscv.cpp
> > guarded by macro INCLUDE_JVMCI. Searching for INCLUDE_JVMCI or
> > COMPILER2_OR_JVMCI in src/hotspot/cpu/aarch64, I see several more places
> > checking for these
On Wed, 5 Oct 2022 11:33:14 GMT, Sacha Coppey wrote:
> Hello, this PR has been stuck for some time now. What should I do to proceed?
The current version does not build. I will take another look after this is
rebased on the latest jdk master.
-
PR: https://git.openjdk.org/jdk/pull/
On Wed, 30 Nov 2022 14:03:30 GMT, Magnus Ihse Bursie wrote:
> We should add devkit support for linux/riscv64.
make/devkit/Tools.gmk line 71:
> 69: BASE_OS_VERSION := $(DEFAULT_OS_VERSION)
> 70: endif
> 71: BASE_URL :=
> http://fedora.riscv.rocks/repos-dist/$(BASE_OS_VERSION)/$(AR
On Wed, 30 Nov 2022 14:03:30 GMT, Magnus Ihse Bursie wrote:
> We should add devkit support for linux/riscv64.
Marked as reviewed by fyang (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/11432
On Mon, 19 Dec 2022 01:35:42 GMT, Fei Yang wrote:
>> We should add devkit support for linux/riscv64.
>
> make/devkit/Tools.gmk line 71:
>
>> 69: BASE_OS_VERSION := $(DEFAULT_OS_VERSION)
>> 70: endif
>> 71: BASE_URL :=
>> http://fedora.r
On Tue, 21 Mar 2023 13:35:25 GMT, Per Minborg wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add example for Option::captureStateLayout
>
> A review of all the copyright years shall be made in this PR.
> Hi @minbo
On Tue, 21 Mar 2023 13:35:25 GMT, Per Minborg wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add example for Option::captureStateLayout
>
> A review of all the copyright years shall be made in this PR.
@minborg :
On Thu, 4 May 2023 11:44:14 GMT, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review the implementation of Generational ZGC, which can be turned on
>> by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational
>> ZGC is a major rewrite of the non-generational ZGC version tha
On Fri, 5 May 2023 06:50:55 GMT, Stefan Karlsson wrote:
>> We emailed to erik to discuss this issue two months ago, and maybe he missed
>> it.
>> ZForwardingTest does not guarantee a successful invoke of os::commit_memory
>> for ZAddressHeapBase, and we saw some conflicts between ZAddressHeapBa
On Mon, 8 May 2023 12:47:51 GMT, Stefan Karlsson wrote:
> That's unfortunate. Could you try this patch, which probes the address range
> to see if it can reserve the memory somewhere else within `[ZAddressHeapBase,
> ZAddressHeapBase+ZAddressOffsetMax)`:
> https://github.com/stefank/jdk/tree/z
On Thu, 3 Aug 2023 16:14:06 GMT, Aleksey Shipilev wrote:
> We don't need the fully bootable Debian installation to build against.
> Therefore, we can bootstrap with `--variant=minbase`. The sysroots are about
> 5..10% smaller then.
>
> This would also make our builds more immune to issues like
On Wed, 2 Aug 2023 06:55:40 GMT, Ludovic Henry wrote:
> Currently, RISC-V differs from other platforms in that it requires the
> linkage to libatomic.so to support sub-word atomic operations. However,
> because it is linked dynamically, it will depend on the installation of
> libatomic.so on t
On Fri, 4 Aug 2023 09:18:11 GMT, Aleksey Shipilev wrote:
> RISC-V is now the [official Debian
> architecture](https://lists.debian.org/debian-riscv/2023/07/msg00053.html).
> This means that the official repository is slowly building up the package
> set, while the old debian-ports repo is [slo
On Fri, 4 Aug 2023 14:58:08 GMT, Ludovic Henry wrote:
> > Hello, did you check the license for libatomic.a? Is it compatible with
> > libjvm.so?
>
> When compiling with gcc or clang (which are AFAIK the only compiler supported
> for Linux-RISC-V), it uses the compiler's implementation. In the
On Wed, 23 Aug 2023 08:40:25 GMT, Aleksey Shipilev wrote:
>> There is no need for keyring installation after
>> [JDK-8313701](https://bugs.openjdk.org/browse/JDK-8313701). We can simplify
>> that part to reduce the difference between different JDK releases.
>>
>> Additional testing:
>> - [ ]
On Fri, 25 Aug 2023 10:17:38 GMT, Ao Qi wrote:
> The `LOONGARCH` is not a macro that must be defined. It is not a C/C++
> pre-defined macro and is also not pre-defined in libraries such as libffi.
> We'd better use a macro defined in jdk.
Two minor nits.
make/autoconf/platform.m4 line 585:
>
On Sun, 27 Aug 2023 09:03:57 GMT, Ao Qi wrote:
>> The `LOONGARCH` is not a macro that must be defined. It is not a C/C++
>> pre-defined macro and is also not pre-defined in libraries such as libffi.
>> We'd better use a macro defined in jdk.
>
> Ao Qi has updated the pull request incrementally
On Wed, 6 Sep 2023 14:29:56 GMT, Antonios Printezis wrote:
> The build failure happens when building on RISC-V with GCC 12.3. Is there a
> better way to address this than disabling the stringop-overflow warnings for
> the two files in question?
Hi, I once created a similar JBS issue and provid
On Wed, 6 Sep 2023 14:29:56 GMT, Antonios Printezis wrote:
> The build failure happens when building on RISC-V with GCC 12.3. Is there a
> better way to address this than disabling the stringop-overflow warnings for
> the two files in question?
Marked as reviewed by fyang (Reviewer).
On Tue, 26 Sep 2023 12:04:49 GMT, Robbin Ehn wrote:
> Hi all, please consider.
>
> latomic is used for non native atomic operation which causes problems with
> extra dependency.
> This have been fixed in recent gcc, so latomic is no longer needed.
>
> Added new gtest, passes t1 on vf2/qemu.
T
On Fri, 11 Oct 2024 04:02:53 GMT, SendaoYan wrote:
>> Hi all,
>> The file
>> `src/jdk.incubator.vector/linux/native/libsleef/lib/vector_math_rvv.c`
>> introduced by [JDK-8341880](https://bugs.openjdk.org/browse/JDK-8341880)
>> native build fails by fedora OS shipped gcc13.
>> Gcc13 doesn't hav
On Thu, 10 Oct 2024 07:37:43 GMT, SendaoYan wrote:
> Hi all,
> The file
> `src/jdk.incubator.vector/linux/native/libsleef/lib/vector_math_rvv.c`
> introduced by [JDK-8341880](https://bugs.openjdk.org/browse/JDK-8341880)
> native build fails by fedora OS shipped gcc13.
> Gcc13 doesn't have `__r
On Thu, 10 Oct 2024 07:37:43 GMT, SendaoYan wrote:
> Hi all,
> The file
> `src/jdk.incubator.vector/linux/native/libsleef/lib/vector_math_rvv.c`
> introduced by [JDK-8341880](https://bugs.openjdk.org/browse/JDK-8341880)
> native build fails by fedora OS shipped gcc13.
> Gcc13 doesn't have `__r
On Thu, 26 Sep 2024 13:14:04 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks!
>>
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added
>> the sleef source (in particular the generated sleef inline headers). We use
>> sleef api to vectorize
.21.1), we need to add one extra
> option `--no-merged-usr` for bootstrap command to work (More discussion here:
> https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/2054925). This
> option seems not necessary for newer dpkg versions like 1.22.6.
>
> Testing:
> - [x] GHA tes
On Fri, 18 Oct 2024 14:12:06 GMT, Aleksey Shipilev wrote:
> I have a question about this. https://wiki.debian.org/UsrMerge says: "This
> page tracks Debian support for the merged /usr directories scheme, i.e. the
> /{bin,sbin,lib}/ directories becoming symbolic links to /usr/{bin,sbin,lib}/."
>
On Fri, 18 Oct 2024 01:33:18 GMT, Fei Yang wrote:
> In JDK-8339548, we switched to use Debian snapshot
> (https://snapshot.debian.org/archive/debian/20240228T034848Z/) for bootstrap.
> The reason is that we don't have a stable Debian release for RISC-V yet and
> De
On Sat, 19 Oct 2024 11:57:17 GMT, Fei Yang wrote:
>> In JDK-8339548, we switched to use Debian snapshot
>> (https://snapshot.debian.org/archive/debian/20240228T034848Z/) for
>> bootstrap. The reason is that we don't have a stable Debian release for
>> RISC-
In JDK-8339548, we switched to use Debian snapshot
(https://snapshot.debian.org/archive/debian/20240228T034848Z/) for bootstrap.
The reason is that we don't have a stable Debian release for RISC-V yet. And
Debian "sid" (https://httpredir.debian.org/debian) that we use for
debootstrapping RISC-V
On Thu, 10 Oct 2024 13:56:23 GMT, Hamlin Li wrote:
> > FYI: I witnessed some different kinds of compile errors about libsleef
> > while building with GCC version 13.2.0 (Ubuntu 13.2.0-23ubuntu4) shipped
> > with Ubuntu 24.04.1 LTS riscv64. Seems that GCC-13 doesn't have a good
> > support for
On Wed, 25 Sep 2024 20:10:41 GMT, Hamlin Li wrote:
>> Good question!
>> Let me do some further investigation and get back later.
>
> I see sleef code only set frm to RNE, but I'm not quite sure.
> Even if we can make sure current sleef only set frm to RNE, seems to me we
> can not depends on cur
On Tue, 24 Sep 2024 19:09:29 GMT, Hamlin Li wrote:
>> Then why would we put a constraint on the number of supported argument
>> vector registers here (v8-v15 instead of v8-v23)? Could we just support all
>> of them, i.e., v8-v23 to comply with the RISC-V psABI?
>
> There is no strong reason, ju
On Tue, 24 Sep 2024 19:12:53 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks!
>>
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added
>> the sleef source (in particular the generated sleef inline headers). We use
>> sleef api to vectorize
On Mon, 23 Sep 2024 19:32:10 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks!
>>
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added
>> the sleef source (in particular the generated sleef inline headers). We use
>> sleef api to vectorize
On Tue, 24 Sep 2024 05:25:38 GMT, Robbin Ehn wrote:
>> src/hotspot/cpu/riscv/assembler_riscv.hpp line 51:
>>
>>> 49: n_int_register_parameters_c = 8, // x10, x11, ... x17 (c_rarg0,
>>> c_rarg1, ...)
>>> 50: n_float_register_parameters_c = 8, // f10, f11, ... f17 (c_farg0,
>>> c_f
On Tue, 24 Sep 2024 14:57:48 GMT, Robbin Ehn wrote:
>> Thanks Robbin for helping explaining!
>>
>> minor correction: v1-v7/v24-v31 = callee saved
>
> Yes, sorry what I meant, updated.
Then why would we put a constraint on the number of supported argument vector
registers here (v8-v15 instead o
On Thu, 26 Sep 2024 13:14:04 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks!
>>
>> This patch is based on https://github.com/openjdk/jdk/pull/20781 which added
>> the sleef source (in particular the generated sleef inline headers). We use
>> sleef api to vectorize
On Fri, 27 Sep 2024 07:06:44 GMT, Hamlin Li wrote:
>> src/jdk.incubator.vector/linux/native/libsleef/lib/vector_math_rvv.c line 51:
>>
>>> 49: // the dynamic rounding mode is always RNE.
>>> 50:
>>> 51: #ifdef DEBUG
>>
>> Question: Should we check for `NDEBUG` macro (A macro specified by C/C++
On Fri, 20 Dec 2024 17:32:53 GMT, Robbin Ehn wrote:
>> Hi please consider.
>>
>> This adds below to hs_err:
>>
>> Floating point state:
>> fcsr=1
>> Floating point registers:
>> f0=0x44a72000 | 1.84467e+19
>> f1=0x44a72000 | 1.84467e+19
>>
>> f31=0x44a72000 | 1.8446
On Tue, 7 Jan 2025 13:07:03 GMT, Robbin Ehn wrote:
>> Hi please consider.
>>
>> This adds below to hs_err:
>>
>> Floating point state:
>> fcsr=1
>> Floating point registers:
>> f0=0x44a72000 | 1.84467e+19
>> f1=0x44a72000 | 1.84467e+19
>>
>> f31=0x44a72000 | 1.84467
53 matches
Mail list logo
