On Tue, 23 Jul 2024 13:55:06 GMT, fitzsim wrote:
> To check this, I
> [added](https://github.com/fitzsim/jdk/commits/regenerate-sleef-headers-2/)
> the `riscv64` `CMake` steps to `SleefCommon.gmk`.
>
> I had intended to factor out `SetupSleefHeader` anyway for `aarch64`, to
> eliminate
On Thu, 18 Jul 2024 20:50:14 GMT, fitzsim wrote:
> It is possible to regenerate `sleefinline_advsimd.h` and `sleefinline_sve.h`
> with some new OpenJDK build logic and only the following fifteen SLEEF source
> files:
>
> ```
> 32K
On Tue, 16 Jul 2024 10:42:24 GMT, Andrew Haley wrote:
> We're only a couple of weeks away from the summit. What would be a long time?
OK, then let's wait for it.
-
PR Comment: https://git.openjdk.org/jdk/pull/18605#issuecomment-2230591233
On Mon, 15 Jul 2024 17:35:59 GMT, Ludovic Henry wrote:
>>> > I can't tell what problem we're trying to solve by not simply checking in
>>> > the source code, in its preferred form, to the OpenJDK tree. Thhis has
>>> > practical advantages to do with traceability and security, and
>>> >
On Tue, 16 Jul 2024 09:48:55 GMT, Andrew Haley wrote:
>>> Currently,
>>>
>>> * in [8329816: Add SLEEF version 3.6.1
>>> #19185](https://github.com/openjdk/jdk/pull/19185) it generates the sleef
>>> inline headers from sleef 3.6.1, which is tagged in sleef repo.
>>>
>>> * And with the
On Tue, 16 Jul 2024 08:35:25 GMT, Andrew Haley wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> skip TANH
>
>> Currently,
>>
>> * in [8329816: Add SLEEF version 3.6
On Mon, 15 Jul 2024 17:35:59 GMT, Ludovic Henry wrote:
> I think so, along with scripting that generates the preprocessed file we use.
> It might be the case that there are some sleef files not used at all they
> could be omitted, but I'm not sure it would be useful, and from a
> traceability
On Wed, 10 Jul 2024 10:48:19 GMT, Andrew Haley wrote:
> I can't tell what problem we're trying to solve by not simply checking in the
> source code, in its preferred form, to the OpenJDK tree. Thhis has practical
> advantages to do with traceability and security, and in-principle reasons to
>
On Mon, 8 Jul 2024 16:20:40 GMT, Andrew Haley wrote:
> I finally did some measurements.
Thanks for testing it!
> It would be nice if the JMH test were part of this patch.
OK, I can do that later.
>
> It mostly looks good, but I can see an odd regression of DoubleMaxVector.TANH
> (by 39%)
; Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559
> | 2.865 | 296.741 | 103.18 | 2.876
> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 |
> 3.967 | 195.891 | 49.771 | 3.936
> Float128Vector.ATAN2 | 1024 | thrpt | 10 | 0.021
; Float128Vector.ASIN | 1024 | thrpt | 10 | 0.013 | ops/ms | 296.702 | 103.559
> | 2.865 | 296.741 | 103.18 | 2.876
> Float128Vector.ATAN | 1024 | thrpt | 10 | 0.004 | ops/ms | 196.862 | 49.627 |
> 3.967 | 195.891 | 49.771 | 3.936
> Float128Vector.ATAN2 | 1024 | thrpt | 10 | 0.021 |
On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt wrote:
>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
>> optimize vector math operations by leveraging the SLEEF library. For legal
>> reasons the actual contribution of the SLEEF files needs to be handled
>>
On Mon, 8 Jul 2024 08:43:34 GMT, Andrew Haley wrote:
> That doesn't work.
>
> ```
> Running tests using MICRO control variable
> 'FORK=1;ITER=10;WARMUP_ITER=10;JAVA_OPTIONS=-XX:+UnlockExperimentalVMOptions
> -XX:+EnableVectorSupport -XX:+UseVectorStubs'
> Unknown test selection:
>
On Fri, 5 Jul 2024 17:44:14 GMT, Andrew Haley wrote:
> I also had problems with javac running out of heap space, which was very odd.
> I fixed it with this:
>
> ```
> diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4
> index 8d272c28ad5..617ccfd8fff 100644
> ---
On Thu, 27 Jun 2024 22:03:37 GMT, Mikael Vidstedt wrote:
>> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
>> optimize vector math operations by leveraging the SLEEF library. For legal
>> reasons the actual contribution of the SLEEF files needs to be handled
>>
On Thu, 27 Jun 2024 21:59:30 GMT, Mikael Vidstedt wrote:
>> In case you need it and avoid to generate yourself, I've generated sleef
>> inline header of 3.6.1 for riscv, it's at
>> https://github.com/openjdk/jdk/pull/18605/commits/c279a3c290554892939267d9ebe88198988d31a4
>
le128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054
> |24420.692|0.734|
> |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003
> |21343.863|0.749 |
> |3479:Double128Vector.EXP |1024 |4553.108 |
On Thu, 27 Jun 2024 21:59:30 GMT, Mikael Vidstedt wrote:
>> In case you need it and avoid to generate yourself, I've generated sleef
>> inline header of 3.6.1 for riscv, it's at
>> https://github.com/openjdk/jdk/pull/18605/commits/c279a3c290554892939267d9ebe88198988d31a4
>
On Thu, 23 May 2024 16:06:42 GMT, Magnus Ihse Bursie wrote:
>> I think both `sleefinline_advsimd.h` and `sleefinline_sve.h` are specific
>> for arm.
>> In the future, on riscv the corresponding file name will be
>> `sleefinline_rvvm1.h`.
>>
>> Only `misc.h` is a generic file shared among
On Thu, 23 May 2024 10:40:26 GMT, Magnus Ihse Bursie wrote:
>>> So you'd need a different copy of sleef for each platform?
>>
>> I think it's one or more.
>>
>>> The files you have put in linux/native/libvectormath, what platform are
>>> they for? Should we not put them in a platform-specific
On Wed, 22 May 2024 09:31:27 GMT, Magnus Ihse Bursie wrote:
> So you'd need a different copy of sleef for each platform?
I think it's one or more.
> The files you have put in linux/native/libvectormath, what platform are they
> for? Should we not put them in a platform-specific subdirectory?
On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote:
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
> optimize vector math operations by leveraging the SLEEF library. For legal
> reasons the actual contribution of the SLEEF files needs to be handled
>
On Fri, 17 May 2024 16:45:19 GMT, Mikael Vidstedt wrote:
> Thank you Hamlin. I'll try to keep my eyes open for the announcement of the
> upcoming SLEEF release but do feel free to notify me if you see it first!
Thank you @vidmik , sure, I will do it.
> I, too, envision that we'll be importing
On Thu, 27 Jun 2024 11:53:38 GMT, Fei Gao wrote:
>> in progress...
>
> Hi @Hamlin-Li , thanks for your work.
>
> I tried to run benchmarks,
> [FloatMaxVector](https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incub
le128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054
> |24420.692|0.734|
> |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003
> |21343.863|0.749 |
> |3479:Double128Vector.EXP |1024 |4553.108 |
le128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054
> |24420.692|0.734|
> |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003
> |21343.863|0.749 |
> |3479:Double128Vector.EXP |1024 |4553.1
On Wed, 8 May 2024 17:41:23 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jdk/pull/18294).
On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote:
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
> optimize vector math operations by leveraging the SLEEF library. For legal
> reasons the actual contribution of the SLEEF files needs to be handled
>
On Mon, 13 May 2024 17:33:20 GMT, Mikael Vidstedt wrote:
> Looks like that change is not yet in a released version of SLEEF, and in
> particular not in 3.6.
>
> We do need updated approvals when we pick up new versions. Since we've gone
> through the process once it's typically easier/faster
On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote:
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
> optimize vector math operations by leveraging the SLEEF library. For legal
> reasons the actual contribution of the SLEEF files needs to be handled
>
On Fri, 10 May 2024 22:32:29 GMT, Mikael Vidstedt wrote:
> [JDK-8312425](https://bugs.openjdk.org/browse/JDK-8312425) is looking to
> optimize vector math operations by leveraging the SLEEF library. For legal
> reasons the actual contribution of the SLEEF files needs to be handled
>
le128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054
> |24420.692|0.734|
> |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003
> |21343.863|0.749 |
> |3479:Double128Vector.EXP |1024 |4553.1
On Tue, 9 Apr 2024 20:10:36 GMT, Mikael Vidstedt wrote:
>> Hamlin Li has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - disable unused-function warnings; add log msg
>> - minor
>
> Than
le128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054
> |24420.692|0.734|
> |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003
> |21343.863|0.749 |
> |3479:Double128Vector.EXP |1024 |4553.1
On Thu, 11 Apr 2024 10:36:03 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jd
le128Vector.COS |1024 |14081.857|ns/op|14846.117 |0.054
> |24420.692|0.734|
> |3478:Double128Vector.COSH |1024 |12202.306|ns/op|12237.772 |0.003
> |21343.863|0.749 |
> |3479:Double128Vector.EXP |1024 |4553.1
On Thu, 11 Apr 2024 10:36:03 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jd
On Thu, 11 Apr 2024 10:36:03 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jd
On Tue, 9 Apr 2024 20:10:36 GMT, Mikael Vidstedt wrote:
>> Hamlin Li has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - disable unused-function warnings; add log msg
>> - minor
>
> Than
ly, e.g.
> remove some uncessary files or changes especially in make dir of jdk.
>
> Besides of the code changes, one important task is to handle the legal
> process.
>
> Thanks!
Hamlin Li has updated the pull request incrementally with one additional commit
On Wed, 10 Apr 2024 09:24:09 GMT, Hamlin Li wrote:
> > Thank you for the update and for working on this in general.
> > I've started working on JDK-8329816, preparing the change for the SLEEF
> > specific part of the change. Specifically, I'm currently planning on
> > i
On Tue, 9 Apr 2024 20:10:36 GMT, Mikael Vidstedt wrote:
> Thank you for the update and for working on this in general.
>
> I've started working on JDK-8329816, preparing the change for the SLEEF
> specific part of the change. Specifically, I'm currently planning on
> including the three SLEEF
On Fri, 5 Apr 2024 12:17:17 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review the patch?
>> This pr is based on previous work and discussion in [pr
>> 16234](https://github.com/openjdk/jdk/pull/16234), [pr
>> 18294](https://github.com/openjdk/jdk/pull/18294).
On Fri, 5 Apr 2024 10:45:24 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols.
>> Tested with gcc and clang, and llvm and binutils backend.
>>
>> I didn't find any use of the "DLL_ENTRY", so I removed it.
>>
>>
On Thu, 4 Apr 2024 21:55:54 GMT, Mikael Vidstedt wrote:
>> Hamlin Li has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - disable unused-function warnings; add log msg
>> - minor
>
> make/modules/
On Thu, 4 Apr 2024 16:47:44 GMT, Magnus Ihse Bursie wrote:
> Build libsleef using their cmake system and look at the compile command line.
> (You do this by `VERBOSE=1 cmake` IIRC). Then you can see what flags they are
> using. This is what I was referring to as "normal libsleef build". I
ly, e.g.
> remove some uncessary files or changes especially in make dir of jdk.
>
> Besides of the code changes, one important task is to handle the legal
> process.
>
> Thanks!
Hamlin Li has updated the pull request incrementally with two additional
commits since the last revi
On Wed, 3 Apr 2024 19:23:01 GMT, Magnus Ihse Bursie wrote:
> Just a quick question after giving this a glance: My understanding was that
> the normal libsleef build set a lot of compiler options, e.g. disabling
> built-in maths etc. You don't seem to set any of these. Have you determined
>
On Thu, 14 Mar 2024 08:48:11 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review this patch?
> Thanks
>
> This is a continuation of work based on [1] by @XiaohongGong, most work was
> done in that pr. In this new pr, just rebased the code in [1], then added
> some mi
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1
On Thu, 28 Mar 2024 18:41:03 GMT, Paul Sandoz wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix jni includes
>
> Hamlin, thank you for working on this. I think integrating a sub-set of
Hi,
Can you help to review the patch?
This pr is based on previous work and discussion in [pr
16234](https://github.com/openjdk/jdk/pull/16234), [pr
18294](https://github.com/openjdk/jdk/pull/18294).
Compared with previous prs, the major change in this pr is to integrate the
source of sleef
On Thu, 28 Mar 2024 18:41:03 GMT, Paul Sandoz wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix jni includes
>
> Hamlin, thank you for working on this. I think integrating a sub-set of
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1
On Wed, 27 Mar 2024 14:47:00 GMT, Magnus Ihse Bursie wrote:
> At this point, I think I am not really qualified to continue the discussion.
>
> I will ask around inside Oracle to see if I can find someone who better
> understands the implications of the suggested libsleef integration (with or
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1
On Mon, 25 Mar 2024 09:15:21 GMT, Magnus Ihse Bursie wrote:
> > A question about the licensing: how long does it take to finish the legal
> > process of the sleef licence?
>
> I am not sure this is a relevant question anymore. As I said, the libsleef
> build system seems virtually impossible
On Mon, 25 Mar 2024 09:24:16 GMT, Magnus Ihse Bursie wrote:
> > > But that raises an interesting question. What happens if you try to load
> > > a library compiled with `-march=armv8-a+sve` on a non-SVE system? Is the
> > > ELF flagged to require SVE so it will fail to load? I'm hoping this is
On Fri, 22 Mar 2024 10:29:36 GMT, Robbin Ehn wrote:
>>> What is the relevance of SVE support at build time? Should it matter what
>>> the build machine is?
>>
>> My understanding is that we need a compiler that supports
>> `-march=armv8-a+sve`; otherwise we can't build the redirect library
On Fri, 22 Mar 2024 12:42:04 GMT, Magnus Ihse Bursie wrote:
> > Ah, it'll only be the redirect library that's compiled with
> > -march=armv8-a+sve Forget that.
>
> But that raises an interesting question. What happens if you try to load a
> library compiled with `-march=armv8-a+sve` on a
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1
On Fri, 22 Mar 2024 10:29:36 GMT, Robbin Ehn wrote:
> > > What is the relevance of SVE support at build time? Should it matter what
> > > the build machine is?
> >
> >
> > My understanding is that we need a compiler that supports
> > `-march=armv8-a+sve`; otherwise we can't build the
On Thu, 21 Mar 2024 15:43:28 GMT, Magnus Ihse Bursie wrote:
>>> > The problem I see is that J. Random Java User has no way to know if SLEEF
>>> > is making their program faster without running benchmarks. They'll put
>>> > SLEEF somewhere and hope that Java uses it.
>>>
>>> Please kindly
On Fri, 15 Mar 2024 11:25:37 GMT, Hamlin Li wrote:
> > * There is no way to stop the VM from trying to load vmath ?
>
> No official way, but deleting libvmath.so will have a same effect. I'm not
> sure if avoiding loading vmath is necessary for typical users, if it turns
>
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote:
>> Hi,
>> Can you help to review this patch?
>> Thanks
>>
>> This is a continuation of work based on [1] by @XiaohongGong, most work was
>> done in that pr. In this new pr, just rebased the code in [1
On Fri, 15 Mar 2024 11:55:14 GMT, Magnus Ihse Bursie wrote:
>> Hamlin Li has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - rename
>> - resolve magicus's comments
>
> src/jdk.incubat
> [1] https://github.com/openjdk/jdk/pull/16234
>
> ## Regression Test
> * test/jdk/jdk/incubator/vector/
> * test/hotspot/jtreg/compiler/vectorapi/
>
> ## Performance Test
> Previously, @XiaohongGong has shared the data:
> https://github.com/openjdk/jdk/pull/16234#is
On Thu, 14 Mar 2024 15:29:51 GMT, Andrew Haley wrote:
> > Hi, thanks for continuing with this.
> > As this is similar to SVML, comments applies to x86 also:
> > ```
> > * There is no way to stop the VM from trying to load vmath ?
> > There is both a UseNeon and a UseSVE, if I set both to false
On Thu, 14 Mar 2024 15:25:54 GMT, Andrew Haley wrote:
> > ```
> > * at build time
> >
> > * with/without sleef
> > * with/without sve support
> > ```
>
> What is the relevance of SVE support at build time? Should it matter what the
> build machine is?
>
> Its important to realize that
On Thu, 14 Mar 2024 12:23:17 GMT, Magnus Ihse Bursie wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix variable name in github workflow
>
> src/jdk.incubator.vector/linux/native/libvma
On Thu, 14 Mar 2024 15:29:51 GMT, Andrew Haley wrote:
> Hi, thanks for continuing with this.
Thanks for the comments
> As this is similar to SVML, comments applies to x86 also:
>
> * There is no way to stop the VM from trying to load vmath ?
No official way, but deleting libvmath.so will
> [1] https://github.com/openjdk/jdk/pull/16234
>
> ## Regression Test
> * test/jdk/jdk/incubator/vector/
> * test/hotspot/jtreg/compiler/vectorapi/
>
> ## Performance Test
> Previously, @XiaohongGong has shared the data:
> https://github.com/openjdk/jdk/pull/16234#is
On Thu, 14 Mar 2024 08:59:09 GMT, Ludovic Henry wrote:
>> Hamlin Li has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix variable name in github workflow
>
> .github/workflows/build-cross-compile.yml line 13
> [1] https://github.com/openjdk/jdk/pull/16234
>
> ## Regression Test
> * test/jdk/jdk/incubator/vector/
> * test/hotspot/jtreg/compiler/vectorapi/
>
> ## Performance Test
> Previously, @XiaohongGong has shared the data:
> https://github.com/openjdk/jdk/pull/16234#is
On Fri, 1 Mar 2024 15:10:30 GMT, Magnus Ihse Bursie wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix potential attribute issue
>
> Iirc, your assessment is right; the code should be ready for integration; I
>
Hi,
Can you help to review this patch?
Thanks
This is a continuation of work based on [1] by @XiaohongGong, most work was
done in that pr. In this new pr, just rebased the code in [1], then added some
minor changes (renaming of calling method, add libsleef as extra lib in CI
cross-build on
On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Wed, 1 Nov 2023 11:52:20 GMT, Robbin Ehn wrote:
>> Hi, please consider.
>>
>> insn_options[0] is set to empty string if there is no options (NULL or empty
>> strings).
>> Checking it for empty string should cover both cases, caller option is NULL
>> or caller option is empty string.
>>
>>
On Tue, 31 Oct 2023 13:05:44 GMT, Robbin Ehn wrote:
> Hi, please consider.
>
> insn_options[0] is set to empty string if there is no options (NULL or empty
> strings).
> Checking it for empty string should cover both cases, caller option is NULL
> or caller option is empty string.
>
> Tested
On Sat, 21 Oct 2023 10:56:01 GMT, Doug Simon wrote:
>> The Graal code base has
>> [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33)
>> its module to `jdk.compiler.graal` as part of preparations for Project
>> Galahad. Due to the way Java modules work,
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, 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
84 matches
Mail list logo
