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. This
allows gradually making progress with cleaning up these warnings
On Sun, 17 Jul 2022 12:54:32 GMT, Julian Waters 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. T
On Tue, 19 Jul 2022 20:13:35 GMT, Dean Long 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. This
, for which disabling warnings
> doesn't matter any ways.
>
> [1]:
> https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170
Jorn Vernee has updated the pull request incrementally with one additional
commit si
, for which disabling warnings
> doesn't matter any ways.
>
> [1]:
> https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170
Jorn Vernee has updated the pull request incrementally with two additional
commits since t
, for which disabling warnings
> doesn't matter any ways.
>
> [1]:
> https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-levels-3-and-4-c4244?view=msvc-170
Jorn Vernee has updated the pull request with a new target base due to a merge
or a re
On Wed, 20 Jul 2022 14:18:45 GMT, Andrew Haley wrote:
>> Jorn Vernee has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Polish
>> - Remove PUSH POP from test files
>
> This feels to me like rather
On Wed, 20 Jul 2022 15:13:05 GMT, Andrew Haley wrote:
> > I think having `PRAGMA_ALLOW_LOSSY_CONVERSIONS` in the file also sends a
> > much clearer message that: warnings in this file have not been looked
> > at/fixed yet, which I don't think `checked_cast` does.
>
> It kinda would, because su
This patch removes the use of std::thread from the `java.lang.foreign` tests,
and switches to the OS specific thread APIs, in order to change things such as
the stack size on some platforms where this is required in the future (see the
JBS issue).
This is done by adding a small header-only libr
On Wed, 20 Jul 2022 14:18:49 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 tha
by adding a small header-only library that exposes a function to
> run code in freshly spawned threads (`run_async`).
>
> Testing: Running the affected tests on platforms that implement the linker.
Jorn Vernee has updated the pull request incrementally with one additional
commit since
On Fri, 22 Jul 2022 14:56:16 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixes
>
> Looks good!
@mcimadamore Thanks for the comments. I've clean
On Fri, 22 Jul 2022 15:09:13 GMT, Christoph Langer wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms where this is required in
>> the futu
On Fri, 22 Jul 2022 18:32:56 GMT, Thomas Stuefe wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixes
>
> test/lib/native/testlib_threads.h line 50:
>
>> 48: static
On Fri, 22 Jul 2022 18:37:02 GMT, Thomas Stuefe wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixes
>
> test/lib/native/testlib_threads.h line 61:
>
>> 59: helper->
On Sat, 23 Jul 2022 05:58:42 GMT, David Holmes wrote:
> `run_async` is an odd name for this, especially as the fact you create then
> join mean it doesn't run asynchronously at all - it runs synchronously in
> another thread.
I took the name from the CompleteableFuture API [1], although in th
On Mon, 25 Jul 2022 01:15:31 GMT, David Holmes wrote:
> > I propose that when a patch touches a file with lossy conversion warnings
> > disabled, it should also enable the warnings and fix them for that file.
>
> This contradicts other common recomendations of not mixing unrelated issues
> in
On Tue, 26 Jul 2022 12:58:09 GMT, Jorn Vernee wrote:
>> test/lib/native/testlib_threads.h line 50:
>>
>>> 48: static void fatal(const char* message) {
>>> 49: perror(message);
>>> 50: exit(-1);
>>
>> Won't work as intended for Win
On Tue, 26 Jul 2022 13:39:50 GMT, Jorn Vernee wrote:
>> The intent was to exit the test with a non-zero exit code, in order to avoid
>> any accidental false positives.
>>
>> I could return the error code from `GetLastError` and from the respective
>> pthread ap
by adding a small header-only library that exposes a function to
> run code in freshly spawned threads (`run_async`).
>
> Testing: Running the affected tests on platforms that implement the linker.
Jorn Vernee has updated the pull request incrementally with one additional
commit since t
by adding a small header-only library that exposes a function to
> run code in freshly spawned threads (`run_async`).
>
> Testing: Running the affected tests on platforms that implement the linker.
Jorn Vernee has updated the pull request incrementally with one additional
commit since t
On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms where this is required
by adding a small header-only library that exposes a function to
> run code in freshly spawned threads (`run_async`).
>
> Testing: Running the affected tests on platforms that implement the linker.
Jorn Vernee has updated the pull request incrementally with one additional
com
On Wed, 27 Jul 2022 06:43:45 GMT, David Holmes wrote:
> > Does run_in_new_thread seem good enough?
>
> No, sorry, the fact it both runs and joins is a critical aspect. `run_async`
> in `CompleteableFuture` just does the "run in new thread" part, whereas the
> `get()` on the returned `FutureTas
On Fri, 22 Jul 2022 18:44:30 GMT, Thomas Stuefe wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixes
>
> Hi @JornVernee,
>
> good job and thanks for doing it so quickly. Lo
On Thu, 21 Jul 2022 18:48:14 GMT, Jorn Vernee wrote:
> This patch removes the use of std::thread from the `java.lang.foreign` tests,
> and switches to the OS specific thread APIs, in order to change things such
> as the stack size on some platforms where this is required in the fu
On Mon, 8 Aug 2022 12:47:52 GMT, Magnus Ihse Bursie wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 15 commits:
>>
>> - Merge branch 'master' into Warn_Narrow
>> - P
ama-foreign/pull/849 Several test fixes to
> make sure the `jdk_foreign` tests can pass on 32-bit machines, taking
> linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API
> required. The `Linker::nativeLinker` method is not longer allo
On Mon, 2 Oct 2023 16:07:09 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://githu
ama-foreign/pull/849 Several test fixes to
> make sure the `jdk_foreign` tests can pass on 32-bit machines, taking
> linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API
> required. The `Linker::nativeLinker` method is not longer al
ama-foreign/pull/849 Several test fixes to
> make sure the `jdk_foreign` tests can pass on 32-bit machines, taking
> linux-x86 as a test bed.
> 9. https://github.com/openjdk/panama-foreign/pull/850 Make the linker API
> required. The `Linker::nativeLinker` method is not longer al
On Tue, 1 Aug 2023 10:29:06 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-for
Port of miscellaneous leftover implementation-only changes from the
panama-foreign repo:
These four related to improving the performance of the internal `strlen`
implementation:
- https://github.com/openjdk/panama-foreign/pull/862
- https://github.com/openjdk/panama-foreign/pull/860
- htt
gt; - https://github.com/openjdk/panama-foreign/pull/890 (note that this is a
> javadoc block in the implementation only)
> - https://github.com/openjdk/panama-foreign/pull/908
> - https://github.com/openjdk/panama-foreign/pull/910
>
> Testing: `jdk_foreign`
Jorn Vernee h
On Tue, 10 Oct 2023 21:41:01 GMT, Jorn Vernee wrote:
> Port of miscellaneous leftover implementation-only changes from the
> panama-foreign repo:
>
> These four related to improving the performance of the internal `strlen`
> implementation:
>
> - https://github.com/o
On Fri, 13 Oct 2023 12:18:59 GMT, Jorn Vernee wrote:
>> Port of miscellaneous leftover implementation-only changes from the
>> panama-foreign repo:
>>
>> These four related to improving the performance of the internal `strlen`
>> implementation:
>>
>
On Tue, 10 Oct 2023 21:41:01 GMT, Jorn Vernee wrote:
> Port of miscellaneous leftover implementation-only changes from the
> panama-foreign repo:
>
> These four related to improving the performance of the internal `strlen`
> implementation:
>
> - https://github.com/o
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)
For some context: `java.lang.foreign.Linker.nativeLinker().defaultLookup()`
returns a `SymbolLoo
On Mon, 13 Nov 2023 02:32:48 GMT, David Holmes wrote:
> I cannot decide if this is an AIX issue for not using dynamic libraries; a
> FFI issue for assuming dynamic libraries; or a test issue. Won't this be a
> general problem for any function you try to access via FFI that is statically
> link
On Fri, 10 Nov 2023 07:56:46 GMT, suchismith1993 wrote:
> > That said, I think we should limit the exported symbols to only those found
> > in the standard C library header files:
> > https://en.cppreference.com/w/c/header
>
> Currently the symbols are restricted to some parts of libc and the
On Fri, 17 Nov 2023 13:02:22 GMT, Martin Doerr wrote:
> My understanding is that a lot of symbols can be found out of the box because
> they are in dynamically linked libraries. Only some libraries are special on
> AIX which don't support dynamic linking and we need this workaround for them.
T
On Mon, 30 Oct 2023 10:54:48 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 with a
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 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 Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad wrote:
> JMH microbenchmarks may have dependencies on artifacts in the test image
> outside of the benchmarks.jar. This includes native libraries (built into
> `$TEST_IMAGE/micro/native`) and may soon include other test libraries like
> wb.jar (
On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy wrote:
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
This looks good to me. It will be easier to find where we are doing restricted
operations like this.
---
On Fri, 1 Mar 2024 13:51:15 GMT, Magnus Ihse Bursie wrote:
> If you really insist on not including jni.h, I would need to duplicate all
> the platform-specific JNIEXPORT definitions from that file. I can do it (I
> understand your reluctance of risking to bring in unintentional stuff), but
> i
On Thu, 29 Feb 2024 12:23:37 GMT, Magnus Ihse Bursie wrote:
> After we removed mapfiles, we can setup -fvisibility=hidden (and
> -Wl,--exclude-libs,ALL) in the most basic flags, so this applies to all
> compilation.
>
> This will remove duplicate code and make the underlying assumptions of the
On Wed, 6 Mar 2024 13: 43: 00 GMT, Magnus Ihse Bursie wrote: >> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as
ZjQcmQRYFpfptBannerStart
This Message Is From an External
On Tue, 12 Mar 2024 13:51:28 GMT, Magnus Ihse Bursie wrote:
>> test/jdk/java/foreign/CallGeneratorHelper.java line 216:
>>
>>> 214: if (header) {
>>> 215: System.out.println(
>>> 216: "#include \"export.h\"\n"
>>
>> We don't generate these header files any mo
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The
This PR adds a new JDK tool, called `jnativescan`, that can be used to find
code that accesses native functionality. Currently this includes `native`
method declarations, and methods marked with `@Restricted`.
The tool accepts a list of class path and module path entries through
`--class-path`
On Wed, 19 Jun 2024 14:30:23 GMT, Roger Riggs wrote:
> One more tool. or... Could this be coalesced into a tool that does deprscan
> and restricted methods, and other "lint" type checks? I might go so far as to
> suggest it be extensible and accept patterns or regular expressions for
> matchin
On Wed, 19 Jun 2024 17:16:54 GMT, Maurizio Cimadamore
wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The too
On Wed, 19 Jun 2024 17:30:08 GMT, Maurizio Cimadamore
wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The too
On Wed, 19 Jun 2024 17:53:12 GMT, Maurizio Cimadamore
wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The too
On Wed, 19 Jun 2024 17:28:23 GMT, Maurizio Cimadamore
wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The too
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Update src/jdk.jdeps/share/classes/com/sun
On Wed, 19 Jun 2024 18:09:15 GMT, Jorn Vernee wrote:
> these types don't have a common super type that exposes the needed information
No wait, they actually do :) That's just `MemberRefEntry`.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646604479
On Wed, 19 Jun 2024 17:45:14 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java
>> line 120:
>>
>>> 118: Optional info =
>>> systemClassResolver.lookup(methodRef.owner());
>
On Wed, 19 Jun 2024 17:41:36 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java
>>
On Wed, 19 Jun 2024 19:00:22 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted
On Wed, 19 Jun 2024 18:02:08 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassResolver.java
>> line 126:
>>
>>> 124:
>>> 125: private static Map packageToSystemModule() {
>>> 126:
On Wed, 19 Jun 2024 21:13:33 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted
On Wed, 19 Jun 2024 18:57:43 GMT, Jorn Vernee wrote:
>> I can do that, but I think this will always be a bit awkward since these
>> types don't have a common super type that exposes the needed information.
>
>> these types don't have a common super type that exp
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with two additional
commits since the last revision:
- review comments
- add man page
-
Changes:
On Wed, 19 Jun 2024 21:30:49 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - review comments
>> - add man page
>
> src/jdk.jdeps/share/man/jnativesc
On Thu, 20 Jun 2024 11:42:04 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/man/jnativescan.1 line 127:
>>
>>> 125: This option should be set to the version of the runtime under which the
>>> 126: application is eventually intended to be run.
>>> 127: If
On Wed, 19 Jun 2024 21:35:07 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - review comments
>> - add man page
>
> src/jdk.jdeps/share/man/jnativesc
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
man page review comments
-
Changes:
- al
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
update man page header to be consisten with the others
---
On Thu, 20 Jun 2024 12:51:22 GMT, Evemose wrote:
> wouldn't it be better to create one uniform tool
See my reply here:
https://github.com/openjdk/jdk/pull/19774#issuecomment-2179078565
-
PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2180653743
On Thu, 20 Jun 2024 16:13:04 GMT, Alan Bateman wrote:
> Another thing is that using joptsimple gives up a bit of control, e.g. the
> help output shows the parameter for --class-path as `` where the java
> launcher and other tools will show "path" or "class path". Same thing with
> `--release`
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
review comments Alan
-
Changes:
- all: htt
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
add extra test for missing root modules
---
On Fri, 21 Jun 2024 18:31:00 GMT, Jan Lahoda wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add extra test for missing root modules
>
> src/jdk.jdeps/share/classes/com/sun/tool
On Fri, 21 Jun 2024 18:38:07 GMT, Jorn Vernee wrote:
>> test/langtools/tools/jnativescan/TestJNativeScan.java line 174:
>>
>>> 172: "-add-modules",
>>> "org.singlejar,org.myapp",
>>> 173:
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with three additional
commits since the last revision:
- Add support for module directories + class path dir
On Thu, 20 Jun 2024 17:25:33 GMT, Alan Bateman wrote:
>> Something like that yes
>
> An altermative is to use ResolvedModule::reference to get a ModuleReference,
> then use its open method to open the contents of the module to get a
> ModuleReader. That will give you a stream over the names of
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
de-dupe on path, not module name
-
Changes:
On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
use instance resolveAndBind + use junit in tests
---
On Fri, 28 Jun 2024 16:47:27 GMT, Alan Bateman wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> de-dupe on path, not module name
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativesca
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
ofInvokeInstruction
-
Changes:
- all: htt
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee 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 t
On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>&
On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>&
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The
On Sat, 29 Jun 2024 06:26:57 GMT, Alan Bateman wrote:
> I assume you'll create follow-up issues in JBS for the Class-Path attribute,
> improvement the usage/help output to replace the "Path"/"String" types.
I've filed: https://bugs.openjdk.org/browse/JDK-8335877 and
https://bugs.openjdk.org/br
On Wed, 20 Jul 2022 14:18:49 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 tha
On Fri, 15 Jul 2022 13:25:57 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
&g
This patch fixes incremental builds on Windows.
There are 2 parts to this:
1. the build system needs to run the paths in the modified file list through
fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an extra
target for generating the file with fixed paths. On non-windows
On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee wrote:
> This patch fixes incremental builds on Windows.
>
> There are 2 parts to this:
> 1. the build system needs to run the paths in the modified file list through
> fixpath. I've added a `convert` mode to `fixpath.sh`
On Tue, 4 Oct 2022 16:56:52 GMT, Erik Joelsson wrote:
>> This patch fixes incremental builds on Windows.
>>
>> There are 2 parts to this:
>> 1. the build system needs to run the paths in the modified file list through
>> fixpath. I've added a `convert` mode to `fixpath.sh` for that. There's an
On Tue, 4 Oct 2022 16:19:24 GMT, Jorn Vernee wrote:
> This patch fixes incremental builds on Windows.
>
> There are 2 parts to this:
> 1. the build system needs to run the paths in the modified file list through
> fixpath. I've added a `convert` mode to `fixpath.sh`
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=55522
>>
>> One solution is to sav
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=55522
>>
>> One solution is to sav
On Mon, 31 Oct 2022 17:44:07 GMT, Andrew Haley wrote:
> Anyway, I plan to
>
> a. Restore the FPU CR after calls to dlopen(3).
> b. Detect FPU CR corruption at safepoints, and print a warning. At least
> the user might find out that something is wrong.
Doing (a) seems good. I can't say for sure
On Fri, 27 Jan 2023 21:11:00 GMT, Erik Joelsson wrote:
> After JDK-8300805, config.guess has changed output when running on WSL. This
> is caused by the autoconf-config.guess now reporting it as
> `x86_64-pc-linux-gnu` instead of `x86_64-unknown-linux-gnu`, and our wrapper
> script is expectin
1 - 100 of 229 matches
Mail list logo