e to apply the same fix to x86, so we never hear of this bug
again. What do you think?
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd.
<https://urldefense.com/v3/__https://www.redhat.com__;!!ACWV5N9M2RV99hQ!OtbRk3IjtkZWG0t0Bpsa66EfBsaQMGoFlzSIyRDF9W1_eN7GogdN6wA4buYUnsub7-H2
warning diabled, and let me know how you get on.
Thanks,
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd.
<https://urldefense.com/v3/__https://www.redhat.com__;!!ACWV5N9M2RV99hQ!MulKzlihq43T1sPs-W08TRZXylpYLvnm5d6PBrmBZ7f5D-tWv1IelKqS8BV1aHFAMWKDSgNM8j-HaQT0O-fSqqB0ZUtw$
&
ns. A better fix is on the way, I promise.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd.
<https://urldefense.com/v3/__https://www.redhat.com__;!!ACWV5N9M2RV99hQ!Oz1Ll2hpKPTlsavALMxhVl5deB43BVS2oGsKZCQ_HgV9dSr4TPYP38bH44OSZN-JeX8MuUsa5bej6ltBMURcAZCwjinB$
>
https://url
On 6/21/22 14:12, Aleksey Shipilev wrote:
On 6/21/22 11:07, Andrew Haley wrote:
On 6/20/22 09:55, Aleksey Shipilev wrote:
Yes, please. I think I am seeing this now in mainline JDK with GCC 11:
* For target hotspot_variant-server_libjvm_objs_sharedRuntime_x86_32.o:
/home/buildbot/worker/build
On Fri, 1 Jul 2022 10:36:36 GMT, Hao Sun wrote:
> **MOTIVATION**
>
> This is a big refactoring patch of merging rules in aarch64_sve.ad and
> aarch64_neon.ad. The motivation can also be found at [1].
>
> Currently AArch64 has aarch64_sve.ad and aarch64_neon.ad to support SVE
> and NEON codegen
On Fri, 1 Jul 2022 11:25:36 GMT, Andrew Haley wrote:
>> **MOTIVATION**
>>
>> This is a big refactoring patch of merging rules in aarch64_sve.ad and
>> aarch64_neon.ad. The motivation can also be found at [1].
>>
>> Currently AArch64 has aarch64_sve.ad and a
On Wed, 20 Jul 2022 14:15:54 GMT, Jorn Vernee wrote:
>> This patch enables lossy conversion warnings (C4244 [1]) for hotspot on
>> Windows/MSVC. Instead of fixing all warnings that were produced from this,
>> I've instead locally disabled the warning in the files that produced
>> warnings. Thi
On Wed, 20 Jul 2022 14:42:44 GMT, Jorn Vernee wrote:
> This change was mostly applied mechanically by parsing the build log, and
> then using a script to insert these lines, with a manual review + 1 or 2
> fixups. Making sure the inserted `checked_cast`s are correct seems much
> harder.
It is
On Wed, 12 Oct 2022 15:59:48 GMT, Aleksey Shipilev wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8295159: DSO created with -ffast-math breaks Java floating-point arithmetic
>
&g
JDK. I guess the best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 28 commits:
- Merge branch 'JDK-8295159' of https
On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley wrote:
>> A bug in GCC causes shared libraries linked with -ffast-math to disable
>> denormal arithmetic. This breaks Java's floating-point semantics.
>>
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55
On Wed, 11 Oct 2023 13:31:22 GMT, Andrew Haley wrote:
> I'm seeing one automated test failure on Linux x86, which I don't understand
> because I've excluded that test for generic-i586. If anyone understands this,
> please shout up.
For avoidance of doubt, the test does
On Wed, 27 Sep 2023 07:49:48 GMT, Magnus Ihse Bursie wrote:
>> Andrew Haley has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 28 commits:
>>
>> - Merge branch 'JDK-8295159' of https://github.com/t
On Wed, 11 Oct 2023 14:03:24 GMT, Thomas Stuefe wrote:
>> Andrew Haley has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 28 commits:
>>
>> - Merge branch 'JDK-8295159' of https://github.com/t
On Wed, 11 Oct 2023 13:54:05 GMT, Thomas Stuefe wrote:
> > > I'm seeing one automated test failure on Linux x86, which I don't
> > > understand because I've excluded that test for generic-i586. If anyone
> > > understands this, please shout up.
> >
> >
> > For avoidance of doubt, the test doe
JDK. I guess the best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Add TestDenormalDouble.java
-
Changes:
-
On Wed, 11 Oct 2023 18:41:08 GMT, Thomas Stuefe wrote:
>> What difference does it make if it does?
>
> I was trying to understand the BSD+gcc combination. We use clang on MacOS, so
> the only platform I thought would be affected would be one of the BSDs.
>
> But I thought those also moved to c
On Thu, 12 Oct 2023 09:23:08 GMT, Florian Weimer wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add TestDenormalDouble.java
>
> test/hotspot/jtreg/compiler/floatingpoint/libfast-ma
On Wed, 11 Oct 2023 17:57:27 GMT, Vladimir Ivanov wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add TestDenormalDouble.java
>
> src/hotspot/os/bsd/os_bsd.cpp line 977:
>
On Wed, 11 Oct 2023 19:51:34 GMT, Vladimir Ivanov wrote:
> And I was confused at first why there's a volatile on `tresh`. A short
> comment describing the intentions would definitely help here.
OK.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/10661#discussion_r1356952291
On Wed, 11 Oct 2023 18:08:55 GMT, Vladimir Ivanov wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add TestDenormalDouble.java
>
> test/hotspot/jtreg/compiler/floatingpoint/li
JDK. I guess the best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with two additional
commits since the last revision:
- Comments only.
- Review feedback
-
Changes:
-
On Tue, 17 Oct 2023 02:15:45 GMT, David Holmes wrote:
>> Andrew Haley has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Comments only.
>> - Review feedback
>
> src/hotspot/cpu/x86/macroAss
JDK. I guess the best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with three additional
commits since the last revision:
- Review feedback
- Merge branch 'JDK-8295159'
On Wed, 18 Oct 2023 00:01:20 GMT, David Holmes wrote:
> Meta-question and apologies if this was covered before, but why is this logic
> being added to stubRoutines.cpp?
Because tha'ts where @iwanowww asked me to put it. I don't much care.
-
PR Comment: https://git.openjdk.org/jdk/
On Wed, 18 Oct 2023 09:31:22 GMT, Daniel Jeliński wrote:
> hsdis-binutils.c doesn't use any functions from libiberty.h. This header is
> absent on Ubuntu (installed separately, and under a different path), so
> removing the include fixes the hsdis compilation on Ubuntu.
>
> Additionally, the s
On Wed, 18 Oct 2023 08:50:13 GMT, Andrew Haley wrote:
>> Meta-question and apologies if this was covered before, but why is this
>> logic being added to stubRoutines.cpp?
>
>> Meta-question and apologies if this was covered before, but why is this
>> logic bein
On Thu, 19 Oct 2023 01:26:43 GMT, Joe Darcy wrote:
>> Andrew Haley has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Review feedback
>> - Merge branch 'JDK-8295159' of https://github
On s390x only, HotSpot is built by GCC with -ffunction-sections.
This means that debug helpers such as ps() and pfl() are not available. These
helpers are extremely useful in debugging, so it makes no sense to omit them
from debug builds.
-
Commit messages:
- 8318834: Debug builds
JDK. I guess the best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
s/Denormal/Subnormal/g
-
Changes:
- all: https://git.openj
On Thu, 19 Oct 2023 09:31:36 GMT, Andrew Haley wrote:
>> src/hotspot/os/linux/os_linux.cpp line 1853:
>>
>>> 1851:
>>> 1852: #ifndef IA32
>>> 1853: // Quickly test to make sure denormals are correctly handled.
>>
>> Nit: I recommend u
JDK. I guess the best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 36 commits:
- Merge from head
- s/Denormal/Subno
On Wed, 18 Oct 2023 19:13:40 GMT, Vladimir Ivanov wrote:
> > Meta-question and apologies if this was covered before, but why is this
> > logic being added to stubRoutines.cpp?
>
> Because tha'ts where @iwanowww asked me to put it. I don't much care.
Hi @iwanowww , do you have any suggestion ab
JDK. I guess the best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Remove dead code
-
Changes:
- all: https://git.openjdk.or
JDK. I guess the best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Duh
-
Changes:
- all: https://git.openjdk.org/jdk/pull/1
On Wed, 25 Oct 2023 18:30:36 GMT, Aleksey Shipilev wrote:
> The block in question also works when link-time gc is enabled, which is only
> so on s390x by default:
>
> https://github.com/openjdk/jdk/blob/d96f38b80c1606b54b9f3dbfe9717ab9653a0605/make/autoconf/jdk-options.m4#L105-L110
It does, bu
On Wed, 25 Oct 2023 17:26:13 GMT, Andrew Haley wrote:
> On s390x only, HotSpot is built by GCC with -ffunction-sections.
> This means that debug helpers such as ps() and pfl() are not available. These
> helpers are extremely useful in debugging, so it makes no sense to omit them
>
On Wed, 25 Oct 2023 18:26:23 GMT, Aleksey Shipilev wrote:
> The comment in the block says:
>
> ```
> # do this on s390x also for libjvm (where serviceability agent is not
> supported)
> ```
>
> ...which I read as "if we enable this, SA would break". Does
> `serviceability/sa` pass in both
JDK. I guess the best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Remove accidental include
-
Changes:
- all: https://git.o
JDK. I guess the best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Move IEE subnormal check to globalDefinitions
-
Change
On Thu, 26 Oct 2023 15:59:08 GMT, Thomas Stuefe wrote:
> One more thought, it would be good to add the FTZ_mode_enabled check to
> `os::run_periodic_checks()`.
>
> We already do signal handler checks there, and it is the right place to check
> for "global things third party native code may mes
On Thu, 26 Oct 2023 17:42:39 GMT, Vladimir Ivanov wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove accidental include
>
> make/test/JtregNativeH
JDK. I guess the best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Fix header
-
Changes:
- all: https://git.openjdk.org/jdk/
On Thu, 26 Oct 2023 15:41:35 GMT, Thomas Stuefe wrote:
> This looks good to me.
>
> One suggestion: to reduce code duplication and to make the code a bit safer
> against accidental returns prior to fesetenv, I would have used a mark object
> like this:
Thanks. I take your point, but I think t
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 Tue, 31 Oct 2023 14:42:22 GMT, Robbin Ehn wrote:
>> The parse_caller_options handles the NULL case, so I forgot about the early
>> bailout.
>>
>> for (p = caller_options; p != NULL; ) {
>> }
>> *iop = '\0';
>>
>>
>> Sorry.
>
> Sorry again, long day:
>
> struct hsdis_app_data app_d
On Fri, 27 Oct 2023 11:59:59 GMT, Andrew Haley wrote:
>> A bug in GCC causes shared libraries linked with -ffast-math to disable
>> denormal arithmetic. This breaks Java's floating-point semantics.
>>
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55
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.
>>
>>
JDK. I guess the best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 42 commits:
- Merge
- Fix header
- Move IEE subnorma
JDK. I guess the best thing to do is find and wrap them all. I'd like to
> hear people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Delete src/hotspot/os/linux/.#os_linux.cpp
-
Changes:
-
On Tue, 11 Oct 2022 16:02:41 GMT, Andrew Haley wrote:
> A bug in GCC causes shared libraries linked with -ffast-math to disable
> denormal arithmetic. This breaks Java's floating-point semantics.
>
> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>
> One
On Wed, 22 Nov 2023 01:52:51 GMT, Xiaohong Gong wrote:
> > Have you considered the possibility of copying the sleef source to the
> > OpenJDK repository and thereby it becomes part of the build process? I
> > don't know how straightforward that is technically and IANAL but I think
> > it's wor
On Thu, 23 Nov 2023 09:09:37 GMT, Galder Zamarreño wrote:
>> FYI @theRealAph
>>
>> It includes a couple of commits to integrate with Capstone v6 while still
>> working with Capstone v5 and before:
>> * `CAPSTONE_ARCH` for aarch64 is now `CS_ARCH_AARCH64` instead of
>> `CS_ARCH_ARM64`. See [thi
On Thu, 23 Nov 2023 08:57:23 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 X
On Thu, 23 Nov 2023 08:57:23 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 X
On Thu, 23 Nov 2023 16:31:22 GMT, Galder Zamarreño wrote:
>> FYI @theRealAph
>>
>> It includes a couple of commits to integrate with Capstone v6 while still
>> working with Capstone v5 and before:
>> * `CAPSTONE_ARCH` for aarch64 is now `CS_ARCH_AARCH64` instead of
>> `CS_ARCH_ARM64`. See [thi
On Thu, 23 Nov 2023 16:31:22 GMT, Galder Zamarreño wrote:
>> FYI @theRealAph
>>
>> It includes a couple of commits to integrate with Capstone v6 while still
>> working with Capstone v5 and before:
>> * `CAPSTONE_ARCH` for aarch64 is now `CS_ARCH_AARCH64` instead of
>> `CS_ARCH_ARM64`. See [thi
On Mon, 27 Nov 2023 01:06:21 GMT, Xiaohong Gong wrote:
>> make/autoconf/lib-vmath.m4 line 94:
>>
>>> 92: # Check the ARM SVE feature
>>> 93: SVE_CFLAGS="-march=armv8-a+sve"
>>> 94:
>>
>> What's this about? We're building a standard binary, and all SVE detection
>> is to be
On Mon, 27 Nov 2023 07:38:28 GMT, Galder Zamarreño wrote:
>> FYI @theRealAph
>>
>> It includes a couple of commits to integrate with Capstone v6 while still
>> working with Capstone v5 and before:
>> * `CAPSTONE_ARCH` for aarch64 is now `CS_ARCH_AARCH64` instead of
>> `CS_ARCH_ARM64`. See [thi
On Mon, 27 Nov 2023 14:59:23 GMT, Magnus Ihse Bursie wrote:
> You still need to separate out the SVE detection from the libsleef code, and
> provide a way to enable/disable it from the configure command line.
Why? I don't think this should be a build-time option at all, because it puts
the peo
On Mon, 27 Nov 2023 15:22:32 GMT, Magnus Ihse Bursie wrote:
> In fact, I am not even sure why it seems to the PR author to be a good idea
> to let the default be dependent on the build machine at all. My personal
> opinion is that it would be better to select either "SVE enabled" or "SVE
> dis
On Tue, 28 Nov 2023 01:37:01 GMT, Xiaohong Gong wrote:
>>> In fact, I am not even sure why it seems to the PR author to be a good idea
>>> to let the default be dependent on the build machine at all. My personal
>>> opinion is that it would be better to select either "SVE enabled" or "SVE
>>>
On Wed, 29 Nov 2023 02:25:20 GMT, Mikael Vidstedt wrote:
> When building linux-aarch64 at Oracle using jib,
> --openjdk-target=aarch64-linux-gnu is always specified regardless of if
> building natively or cross compiling (on linux-x64). Among other things this
> has the (harmless) effect of tr
On Wed, 29 Nov 2023 08:33:33 GMT, Andrew Haley wrote:
>> When building linux-aarch64 at Oracle using jib,
>> --openjdk-target=aarch64-linux-gnu is always specified regardless of if
>> building natively or cross compiling (on linux-x64). Among other things this
>> has
On Thu, 30 Nov 2023 09:35:04 GMT, Magnus Ihse Bursie wrote:
> This version looks much better, thank you! I guess cflags/SVE_CFLAGS is an
> okay-ish solution.
>
> I'm still not 100% happy though, but it might be due to my limited
> understanding. Let me write down a few numbered statements and t
On Thu, 30 Nov 2023 06:39:43 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 X
On Thu, 30 Nov 2023 06:39:43 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 X
On Thu, 30 Nov 2023 11:46:58 GMT, Andrew Haley wrote:
> [vect_math.S.txt](https://github.com/openjdk/jdk/files/13512306/vect_math.S.txt)
I guess this will live only in os_linux and os_bsd because the Windows compiler
won't like it AFAIK.
-
PR Comment: https://git.openjdk
On Thu, 30 Nov 2023 14:50:24 GMT, Andrew Haley wrote:
>> Do this, but with the name vect_math.S. Don't use SLEEF headers in the
>> build. I think you can do this with no build-time dependency on SLEEF at all
>> if you load the library lazily at runtime.
>>
On Fri, 1 Dec 2023 01:13:37 GMT, Xiaohong Gong wrote:
>> make/autoconf/lib-sleef.m4 line 56:
>>
>>> 54: AC_MSG_CHECKING([for the specified LIBSLEEF])
>>> 55: if test -e ${with_libsleef}/lib/libsleef.so &&
>>> 56:test -e ${with_libsleef}/include/sleef.h; then
>>
>> Th
On Fri, 1 Dec 2023 09:59:58 GMT, Andrew Haley wrote:
> Not having a build time dependency on libsleef means you cannot really verify
> that the functions you want to call are correct, but maybe you feel secure
> that they will never change?
We can still have SLEEF tests, but they wil
On Fri, 1 Dec 2023 01:19:12 GMT, Xiaohong Gong wrote:
> > Not having a build time dependency on libsleef means you cannot really
> > verify that the functions you want to call are correct, but maybe you feel
> > secure that they will never change?
>
> I'm not sure. The main reason that we add
On Fri, 1 Dec 2023 08:48:52 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 X8
On Fri, 1 Dec 2023 08:48:52 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 X8
On Fri, 1 Dec 2023 10:19:01 GMT, Andrew Haley wrote:
>> Xiaohong Gong has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains ten addi
raries. By definition,
because if you're building against a compatible set of libraries you
don't have a different sysroot.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On 12/6/23 14:35, erik.joels...@oracle.com wrote:
On 12/6/23 04:18, Andrew Haley wrote:
On 11/29/23 14:31, erik.joels...@oracle.com wrote:
Perhaps what we need to do is separate the notion of needing a separate
BUILD_JDK from the notion of cross compiling.
Isn't that what --with-sy
I think I may
be missing something important here: what is the downside of treating a
build as a cross compilation? Is it simply that more work has to be done,
or something else?
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
On Fri, 15 Dec 2023 13:05:32 GMT, Julian Waters wrote:
>> The keyword also happens to go in the same location as well. How
>> coincidental...
>
> I also realized that this uses a gcc statement expression currently, I wonder
> if this could use a lambda expression instead in another change?
Tha
On Wed, 17 Jan 2024 11:19:03 GMT, Magnus Ihse Bursie wrote:
> We have been stuck on a very old gcc for a long time, due to various reasons.
> Partly because old gcc versions were not as terrible as old versions of
> cl.exe, and partly to support odd linux platforms where newer gcc versions
> w
er to mimic how Oracle compiles
both OpenJDK and Oracle JDK as closely as possible.
I sh ./configure --helpbelieve Oracle probably does it by specifying different
parts of the version string on configure, something like
bash configure
"sh ./configure --help" and look for the --wit
On Thu, 15 Feb 2024 17:11:34 GMT, Thomas Stuefe wrote:
> > Sure, you can always install a newer GCC than the system one, but it's
> > another thing that makes it harder for people to build OpenJDK. Having said
> > that, C++17 is nice to have.
>
> @theRealAph I am still just hearing hand-waving
On Fri, 16 Feb 2024 08:35:29 GMT, Andrew Haley wrote:
>
> To be clear: I do not object to this PR. I would like to use C++17.
Maybe the advantages of C++17 have been discussed elsewhere, in which case all
we need is a link to that discussion on the Bug page. Maybe it's just that
On 2/16/24 08:49, Thomas Stüfe wrote:
It is probably safe to hide C++ mangled symbols since those decorations are
compiler-specific anyway, no? So they cannot have worked in a reliable fashion
They're not entirely compiler specific, but part of the ABI. See
https://itanium-cxx-abi.github.io/cxx
On Fri, 16 Feb 2024 12:43:29 GMT, Magnus Ihse Bursie wrote:
> I think Kim's approach here -- to separate compiler upgrades from C++17 usage
> -- is the right way. Then we can discuss each part separately -- what version
> is suitable for each compiler, and then -- if or when we end up with all
On Sat, 24 Feb 2024 20:01:50 GMT, Martijn Verburg wrote:
>> Hi all - yes the Windows Arm port is maintained by Microsoft's JDK team. How
>> can we help in this particular case?
>
> I assume you want to know if we use DAS/DAS1 for debugging purposes on that
> platform?
I use `das` every day. In
On Thu, 14 Mar 2024 09:14:04 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 minor changes (renami
On Thu, 14 Mar 2024 11:20:26 GMT, Robbin Ehn 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 I wo
On Thu, 14 Mar 2024 09:14:04 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 minor changes (renami
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], then added
>> some minor changes (renami
On Fri, 15 Mar 2024 11:35:05 GMT, Hamlin Li wrote:
> > I'm running the tests, but I have no way to confirm that SLEEF or SVE is in
> > use. Exactly what did you do, and how did you confirm it?
>
> Thanks for running test. I just turn on some log, and check the output.
The problem I see is that
On Tue, 19 Mar 2024 17:00:48 GMT, Hamlin Li 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 correct me if I misunder
On Tue, 19 Mar 2024 17:15:29 GMT, Andrew Haley wrote:
>>> If there was some kind of plan, with evidence of the intention to do
>>> something to get this valuable tech into people's hands in a form they can
>>> use, sure. But as you can tell, I think thi
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 corre
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], then added
>> some minor changes (renami
On Fri, 22 Mar 2024 12:31:01 GMT, Andrew Haley 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=
On Fri, 22 Mar 2024 13:38:54 GMT, Robbin Ehn wrote:
> > > is this how you want us to export these symbols?
> >
> >
> > Close but no cigar. :-)
> > Use `JNIEXPORT` instead, that is properly defined for this purpose and
> > works on all compilers. You will need to also add:
> > ```
> > #include
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], then added
>> some minor changes (renami
On Mon, 25 Mar 2024 09:11:40 GMT, Magnus Ihse Bursie wrote:
> > And neither should we compile or link it with "-fvisibility=hidden". That
> > is the root of this problem.
>
> If you suggest that we should not compile hsdis with hidden visibility, I
> disagree.
Yes, that's what I would do.
>
On Thu, 4 Apr 2024 16:43:18 GMT, Magnus Ihse Bursie wrote:
> I apologize for the late reply. I've been just working spotty hours due to
> spring break.
I apologize for my bad temper. 😀
Thanks to everyone working on this. I still think that hsdis ought not to have
any dependencies on HotSpot,
1 - 100 of 210 matches
Mail list logo
