On Tue, 3 Sep 2024 07:26:53 GMT, Matthias Baesken wrote:
>> We get a couple of warnings as errors on AIX because of unused variables or
>> functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c
On Mon, 2 Sep 2024 13:25:51 GMT, Matthias Baesken wrote:
>> We get a couple of warnings as errors on AIX because of unused variables or
>> functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c
On Tue, 30 Apr 2024 16:36:52 GMT, Kim Barrett wrote:
>> I will do after labor day and create a PR with this suggested solution in
>> your JDK-8330539.
>
> I think I still prefer just unconditionally including in
> globalDefinitions_gcc.hpp. For gcc/clang we are using `-std=c++14` +
> `-D_GNU
On Thu, 2 May 2024 09:54:14 GMT, Joachim Kern wrote:
> We need to find a better way to handle alloca on AIX.
>
> See the discussion in the PR for https://bugs.openjdk.org/browse/JDK-8329257,
> e.g. https://github.com/openjdk/jdk/pull/18536#discussion_r1568650313 in
> which three alternatives a
On Thu, 18 Apr 2024 04:26:21 GMT, Kim Barrett wrote:
>> I opened https://bugs.openjdk.org/browse/JDK-8330539 so we don't lose track
>> of this, but we can keep the discussion/voting here.
>
> For the impatient, I suggest adopting mechanism 2, i.e. unconditionally
> include in globalDefinitions_
On Mon, 29 Apr 2024 12:15:55 GMT, Matthias Baesken wrote:
> Currently we run into some alignment related issues when building with
> '--enable-ubsan' . Those errors already occur in the build. Fixing them might
> take some time and maybe also some discussion if it is worth the effort ,
> So for
On Wed, 17 Apr 2024 12:22:10 GMT, Magnus Ihse Bursie wrote:
>> I don't mind all 3, though I certainly prefer 1 and 3 over 2 (The way I see
>> it, the AIX macro check is more of a message to the programmer than it is
>> important to the compiler, so I prefer the options that have it. However, I
On Mon, 15 Apr 2024 11:46:25 GMT, Magnus Ihse Bursie wrote:
>> Should also remove the `#pragma alloca` in os_aix.cpp.
>
> It was too bad that I did not see and review this change in the makefiles. :-(
>
> While you guys could have gone either way, I strongly dislike the choice to
> include a re
On Fri, 12 Apr 2024 12:26:06 GMT, Magnus Ihse Bursie wrote:
> Unfortunately, after
> [JDK-8329704](https://bugs.openjdk.org/browse/JDK-8329704) AIX fails to
> build. The reason is that libjli is specially treated on AIX, and built like
> a static library. I tried to compensate for this (and ha
On Wed, 10 Apr 2024 12:15:34 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus t
On Wed, 10 Apr 2024 13:35:39 GMT, Julian Waters wrote:
>> Yes I believe. I will remove the `#pragma alloca` everywhere, I will remove
>> the `#include ` everywhere and I will add
>> `-Dalloca=__builtin_alloca` to the compile commands. If it works I will
>> update the PR.
>
> In my humble opin
On Tue, 9 Apr 2024 17:25:04 GMT, Stewart X Addison wrote:
>> Pinging @sxa - what build environment does temurin use for AIX?
>
> Currently XLC16 but looking to upgrade to XLC17 on the minimum supported
> level for it (So it wouldn't be SP7 at present). Thanks for the ping - we
> have no current
On Wed, 10 Apr 2024 10:00:02 GMT, Martin Doerr wrote:
>> If I omit this #include
>> I get compiler errors of the following kind
>>
>> .../src/hotspot/share/runtime/javaThread.cpp::24: error: use of
>> undeclared identifier 'alloca&
On Wed, 10 Apr 2024 09:40:16 GMT, Joachim Kern wrote:
>> Do we even need to include ?
>>
>> From the Linux man page for alloca:
>>
>> By necessity, alloca() is a compiler built-in, also known as
>> __builtin_alloca(). By default, modern compilers automatically
>> translate all uses of alloca(
On Tue, 2 Apr 2024 11:22:54 GMT, Joachim Kern wrote:
>> I'd prefer having less AIX specific parts in this file. Can this be moved
>> somewhere else? Or maybe combine it with the AIX code above?
>
> My question is, do we need this block, because now already configure warns
> about an outdated co
On Thu, 28 Mar 2024 16:53:39 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus t
On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++. SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
>
> I need someone from the aix-ppc porte
On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of gcc
> to be used for building OpenJDK from 6.0 to 10.0.
>
> This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
> that. A minimum of gcc 10 also
On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++. SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
>
> I need someone from the aix-ppc porte
On Mon, 5 Feb 2024 08:26:55 GMT, Martin Doerr wrote:
> A trivial ADLC build fix. The ADLC_LANGSTD_CXXFLAGS should get passed.
Thanks for the reviews!
-
PR Comment: https://git.openjdk.org/jdk/pull/17705#issuecomment-1928892061
On Mon, 5 Feb 2024 08:26:55 GMT, Martin Doerr wrote:
> A trivial ADLC build fix. The ADLC_LANGSTD_CXXFLAGS should get passed.
This pull request has now been integrated.
Changeset: 9ee9f288
Author: Martin Doerr
URL:
https://git.openjdk.org/jdk/com
A trivial ADLC build fix. The ADLC_LANGSTD_CXXFLAGS should get passed.
-
Commit messages:
- 8325213: Flags introduced by configure script are not passed to ADLC build
Changes: https://git.openjdk.org/jdk/pull/17705/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17705&range=
On Thu, 11 Jan 2024 13:04:35 GMT, Julian Waters wrote:
> There is a typo in adlc:
>
> ```
> diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk
> b/make/hotspot/gensrc/GensrcAdlc.gmk
> index 0898d91e1c2..bb356476847 100644
> --- a/make/hotspot/gensrc/GensrcAdlc.gmk
> +++ b/make/hotspot/gensrc/Gensr
On Tue, 30 Jan 2024 14:02:41 GMT, Matthias Baesken wrote:
>>> Yes there is a nice define in the AIX header
>>
>> *sigh* On linux, they go to some lengths to avoid this, using a __REDEFINE
>> mechanism. Oh well.
>>
>> Anyway, I think this particular can be resolved by not including the
>> sta
On Sat, 13 Jan 2024 17:29:58 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8323008](https://bugs.openjdk.org/browse/JDK-8323008), commit
> [68c42860](https://github.com/openjdk/jdk/commit/68c4286026bc2c0ec0f594e0b96fe03fe5624d6d)
> from the [openjd
On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Require clang 13 in toolchain.m4
Thanks!
On Thu, 11 Jan 2024 12:36:31 GMT, Martin Doerr wrote:
>> Regarding
>> https://github.com/TheShermanTanker/jdk/actions/runs/7070564987/job/19247370401,
>> could it be that the adlc build didn't get the correct C++ version flags?
>> It doesn't loo
On Thu, 11 Jan 2024 11:33:07 GMT, Martin Doerr wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary -std=c++17 option in Lib.gmk
>
> Regarding
> https://github.com/
On Wed, 10 Jan 2024 13:11:38 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove unnecessary -std=c++17 option in Li
On Wed, 10 Jan 2024 13:11:38 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove unnecessary -std=c++17 option in Li
On Fri, 15 Dec 2023 08:08:10 GMT, Julian Waters wrote:
>> Implementation of [JEP draft: Compile the JDK as
>> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
>
> Julian Waters has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes t
On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 17:49:43 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 17:54:08 GMT, suchismith1993 wrote:
>> src/java.base/aix/native/libsyslookup/syslookup.c line 30:
>>
>>> 28: #include
>>> 29: #include
>>> 30: #include
>>
>> Are string.h and stdlib.h needed? I can't see them in the comments below.
>
> string.h is needed for strlen. Let m
On Tue, 21 Nov 2023 13:01:50 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 13:01:50 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 11:52:23 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 11:21:40 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Fri, 17 Nov 2023 12:45:32 GMT, suchismith1993 wrote:
> And I still don't understand if this is the list of symbols that are required
> by our tests, or the complete list of symbols that FFI `defaultLookup`
> returns to user applications. If it is the latter, then this is sort-of okay
> as a
On Mon, 13 Nov 2023 11:47:52 GMT, suchismith1993 wrote:
>>> There is not generic way of generating this. It needs a manual intervention
>>> and symbols are to be added on a need basis in future. Looks like a list to
>>> be maintained. I had tried adding comments to explain the list, but that
>
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
Changes requested by mdoerr (Reviewer).
LGTM. You may want to replace the Copyright header of th
On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote:
> Implementation of [JEP draft: Compile the JDK as
> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
We're not changing it for existing releases. I don't think non-LTS releases
play a significant role regarding such compatibility. Next
On Wed, 6 Sep 2023 10:04:35 GMT, Jorn Vernee wrote:
>> This patch contains the implementation of the foreign linker & memory API
>> JEP for Java 22. The initial patch is composed of commits brought over
>> directly from the [panama-foreign
>> repo](https://github.com/openjdk/panama-foreign). T
On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote:
> Currently there is a number of functionality that would be interesting to
> have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
> Th
On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote:
> Implementation of [JEP draft: Compile the JDK as
> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
Successfully tested on AIX with xlc 17.1.1. Works for us (SAP). Please check
with others who might still use an older compiler (IBM).
On Wed, 14 Jun 2023 10:07:01 GMT, Christian Stein wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [8aad881e](https://github.com/openjdk/jdk/commit/8aad881e803fddc26f45270f779ff0c0e5a095d8)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit
On Wed, 14 Jun 2023 10:07:01 GMT, Christian Stein wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [8aad881e](https://github.com/openjdk/jdk/commit/8aad881e803fddc26f45270f779ff0c0e5a095d8)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit
On Wed, 7 Jun 2023 11:23:26 GMT, JoKern65 wrote:
>> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared
>> code https://github.com/openjdk/jdk/pull/14146
>> It handles the part in java.base.
>>
>> Compiling on AIX with xlc17 which contains the new clang 15 frontend
>> sh
On Wed, 7 Jun 2023 09:03:27 GMT, JoKern65 wrote:
>> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared
>> code https://github.com/openjdk/jdk/pull/14146
>> It handles the part in java.base.
>>
>> Compiling on AIX with xlc17 which contains the new clang 15 frontend
>> sh
On Fri, 2 Jun 2023 10:19:53 GMT, JoKern65 wrote:
> This pr is a split off from JDK-8308288: Fix xlc17 clang warnings in shared
> code https://github.com/openjdk/jdk/pull/14146
> It handles the part in security and servicability.
>
> Compiling on AIX with xlc17 which contains the new clang 15 fr
On Fri, 2 Jun 2023 18:24:16 GMT, Y. Srinivas Ramakrishna
wrote:
>> Kelvin Nilsen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Force PLAB sizes to align on card-table size
>
> src/hotspot/cpu/riscv/gc/shenandoah/c1/shenandoahBarrierSe
On Fri, 2 Jun 2023 02:49:25 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>> `-XX:+UnlockExp
On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen wrote:
> OpenJDK Colleagues:
>
> Please review this proposed integration of Generational mode for Shenandoah
> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>
> Generational mode of Shenandoah is enabled by adding
> `-XX:+UnlockExperimen
On Fri, 26 May 2023 16:58:41 GMT, Thomas Stuefe wrote:
>> The crazy thing is that `malloc` is defined! That means all places where we
>> use the term malloc are getting replaced without such a workaround. (E.g.
>> for log tags.)
>
> So, we do this only for malloc? Not for calloc, posix_memalign
On Fri, 26 May 2023 08:31:46 GMT, JoKern65 wrote:
>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk
>> on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small
>> adjustments.
>> A lot of those chang
On Thu, 25 May 2023 15:04:32 GMT, Kim Barrett wrote:
>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk
>> on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small
>> adjustments.
>> A lot of those ch
On Fri, 12 May 2023 21:51:59 GMT, Kim Barrett wrote:
>> src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp line 426:
>>
>>> 424: // Missing test if instr is commutative and if we should swap.
>>> 425: if (right.value()->type()->as_LongConstant() &&
>>> 426: (x->op() == Bytecodes::_lsub &&
>>
On Fri, 12 May 2023 16:16:01 GMT, JoKern65 wrote:
>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk
>> on AIX , we run into various "warnings as errors".
>> Many of those are in the aix or ppc specific codebase and could be addressed
>> by small adjustments.
>> A l
On Mon, 8 May 2023 10:29:56 GMT, Matthias Baesken wrote:
> After the harfbuzz 7.2 update we run into
>
> /linuxmuslx86_64/jdk-dev/src/java.desktop/share/native/libharfbuzz/OT/glyf/Glyph.hh:281:8:
> error: offset '4' outside bounds of constant string [-Werror=array-bounds]
> 281 | bool get_poi
On Thu, 4 May 2023 09:50:23 GMT, Axel Boldt-Christmas
wrote:
>>> I'm getting build warnings on all linux platforms with gcc-11.3.0:
>>>
>>> ```
>>> src/hotspot/share/gc/z/zDriver.cpp:84:13: error: In the GNU C Library,
>>> "minor" is defined
>>> by . For historical compatibility, it is
>>> c
On Wed, 3 May 2023 19:36:55 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 Wed, 3 May 2023 10:55:49 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 Wed, 3 May 2023 10:55:49 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, 21 Apr 2023 20:26:12 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X
On Fri, 21 Apr 2023 08:40:49 GMT, Christoph Langer wrote:
> This is the plain fix for the currently observed error in GHA.
>
> Will handle the optional install of the MSVC toolchain in a separate item.
LGTM.
-
Marked as reviewed by mdoerr (Reviewer).
PR Review: https://git.openjd
On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X
On Wed, 12 Apr 2023 17:31:49 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X
On Tue, 11 Apr 2023 21:09:43 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X
On Tue, 11 Apr 2023 18:35:56 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X
On Tue, 11 Apr 2023 17:58:54 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X
On Tue, 11 Apr 2023 17:58:54 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X
On Tue, 11 Apr 2023 10:26:02 GMT, ExE Boss wrote:
>> test/jdk/jdk/internal/util/ArchTest.java line 128:
>>
>>> 126: case RISCV64 -> true;
>>> 127: case S390 -> false;
>>> 128: case PPC64 -> true;
>>
>> This is not always true. The PPC64 architecture supports
On Sat, 8 Apr 2023 18:00:53 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Fri, 17 Mar 2023 22:36:24 GMT, Tyler Steele wrote:
> Minor changes to the build system to recognize and warn that an incompatible
> toolchain is detected.
Yes, I think it's better to define the minimum version to a compiler which will
work at the point of time at which we integrate this PR.
On Fri, 17 Mar 2023 22:36:24 GMT, Tyler Steele wrote:
> Minor changes to the build system to recognize and warn that an incompatible
> toolchain is detected.
I think we should get it compiling before we define the minimum level.
Otherwise we may have to change it several times.
-
On Fri, 17 Mar 2023 22:36:24 GMT, Tyler Steele wrote:
> Minor changes to the build system to recognize and warn that an incompatible
> toolchain is detected.
I think 16.1.0.0002 is pretty old. Shouldn't we better require some version we
have tested? We have tested 16.1.0.13.
-
PR
On Fri, 17 Mar 2023 22:36:24 GMT, Tyler Steele wrote:
> Minor changes to the build system to recognize and warn that an incompatible
> toolchain is detected.
LGTM. I think the reason for this PR is another issue? If so, please link the
JBS issues as "relates to".
@MBaesken: Please take a look.
On Fri, 10 Mar 2023 12:28:05 GMT, Matthias Baesken wrote:
> When switching from gcc8 to gcc10 on Linux ppc64le, we get dozens of warnings
> in hotspot and other sources like this
>
> adaptiveSizePolicy.cpp:262:6: note: the layout of aggregates containing
> vectors with 8-byte alignment has cha
ve additional commits since
> the last revision:
>
> - Merge branch 'master' into membar
> - Test fixes
> - PPC64 port courtesy Martin Doerr
> - Change header and constants handling
> - 8292591 - initial
Thanks for the update! LGTM. I hope that no
ses t1-7 with option forced on, also passes t1-4 as is in this PR.
>
> Robbin Ehn has updated the pull request incrementally with one additional
> commit since the last revision:
>
> PPC64 port courtesy Martin Doerr
Thanks for integrating my PPC64 implementation. I prefer ser
On Thu, 8 Sep 2022 09:44:44 GMT, Robbin Ehn wrote:
>> Please consider, only implemented on x64/aarch64 linux/windows.
>>
>> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>>
>> Passes t1-7 with option forced on, also passes t1-4 as is in this PR.
>
> Robbin Ehn has
On Thu, 1 Sep 2022 16:47:58 GMT, Robbin Ehn wrote:
> Please consider, only implemented on x64/aarch64 linux/windows.
>
> On my box calling clock_gettime via JNI goes from 35ns to 28ns when enabled.
>
> Passes t1-7 with option forced on, also passes t1-4 as is in this PR.
Nice to see usage of t
82 matches
Mail list logo
