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
>
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.
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 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
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 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 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, 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 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
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
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
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)`:
>
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
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
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 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
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 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 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 :=
>
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:
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 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
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
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
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
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
26 matches
Mail list logo
