On Thu, 23 Jan 2025 05:34:00 GMT, Julian Waters wrote:
>> src/jdk.accessibility/windows/native/jaccessinspector/jaccessinspector.cpp
>> line 1212:
>>
>>> 1210: }
>>> 1211:
>>> 1212: static_cast(lastError);
>>
>> This falls int
n32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11:
> warning: typedef 'PENTRY' locally defined but not used
> [-Wunused-local-typedefs]
> 1595 | } ENTRY, *PENTRY;
> | ^~
> C:/users/vertig0/downloads/eclipse-
On Mon, 8 Sep 2025 14:25:02 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Tue, 28 Jan 2025 17:38:29 GMT, Alexey Ivanov wrote:
>> I see no reason to keep it.
>>
>> If it's needed during debugging, there are many ways to find the handle.
>>
>> Otherwise, the edit control is accessed by its id: `cAccessInfoText`.
>
> It looks like this feature doesn't work:
> [JDK-8
On Tue, 28 Jan 2025 17:33:42 GMT, Alexey Ivanov wrote:
>> I'll submit a new bug to address this problem.
>>
>> It's not just a matter of an unused variables, it's the logic error: if the
>> buffer is too small, *a new buffer is allocated*, yet this new buffer isn't
>> deleted afterwards, nor i
On Thu, 23 Jan 2025 05:37:29 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
variable]
> 367 | DWORD retval = -1;
> | ^~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c:
> In function 'shutdownAccessBridge':
> C:/users/vertig0/downlo
On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Thu, 8 May 2025 18:30:11 GMT, Sergey Bylokhov wrote:
> The -Wtype-limits warning was previously disabled in the OpenJDK build for
> LCMS 2.14+ due to upstream issues: https://github.com/openjdk/jdk/pull/11217
> The issue was reported to the LCMS project:
> https://github.com/mm2/Little-CMS/i
On Mon, 28 Apr 2025 19:47:03 GMT, Sergey Bylokhov wrote:
> Multiple similar issues detected in PLATFORM_API_MacOSX_Ports.cpp more info
> about https://github.com/llvm/llvm-project/issues/62836
>
> jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_Ports.cpp:127:39:
> error: varia
On Thu, 23 Jan 2025 05:37:29 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Thu, 23 Jan 2025 05:37:29 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
ps://bugs.openjdk.org/browse/JDK-8342870
>
> On 11/12/2024 17:24, Philip Race wrote:
> > Yes, there are JBS sub-components for these.
> >
> > -phil.
> >
> >
> > On 12/11/24 5:25 AM, Julian Waters wrote:
> >> Hi all,
> >>
> >> In
On Mon, 10 Feb 2025 19:07:49 GMT, Alexander Zvegintsev
wrote:
> Filed as a separate issue to keep the #23426 clean.
>
> Fix is the same as in the
> `src/java.desktop/unix/native/libpipewire/include/spa/param/audio/raw.h` part
> of the [JDK-8309703](https://bugs.openjdk.org/browse/JDK-8309703)
On Fri, 31 Jan 2025 12:16:54 GMT, Matthias Baesken wrote:
> > I don't think there is much point in being able to vary the opt level; it
> > is more about spending the time to find the most appropriate opt level, and
> > once you've done that, you can update the makefile directly.
>
> You want
On Tue, 21 Jan 2025 14:33:57 GMT, Alexey Ivanov wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains eight commits:
>>
>> - Merge branch 'openjdk:master' into a
On Tue, 21 Jan 2025 13:40:42 GMT, Alexey Ivanov wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains eight commits:
>>
>> - Merge branch 'openjdk:master' into a
On Tue, 21 Jan 2025 21:18:27 GMT, Alexey Ivanov wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains eight commits:
>>
>> - Merge branch 'openjdk:master' into a
On Tue, 21 Jan 2025 13:43:17 GMT, Alexey Ivanov wrote:
>> Will do, thanks
>
> I agree `retval` was probably used as a return value of the function; now
> there are explicit `return` statements.
I'll remove retval in a moment
-
PR Review Comment: https://git.openjdk.org/jdk/pull/21
variable]
> 367 | DWORD retval = -1;
> | ^~
> C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/jdk.accessibility/windows/native/bridge/AccessBridgeCalls.c:
> In function 'shutdownAccessBridge':
> C:/users/vertig0/downl
On Mon, 20 Jan 2025 23:35:33 GMT, Alexander Zuev wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains eight commits:
>>
>> - Merge branch 'openjdk:master' into a
On Mon, 20 Jan 2025 23:35:23 GMT, Alexander Zuev wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains eight commits:
>>
>> - Merge branch 'openjdk:master' into a
On Mon, 20 Jan 2025 23:18:41 GMT, Alexander Zuev wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains eight commits:
>>
>> - Merge branch 'openjdk:master' into a
On Tue, 7 Jan 2025 09:56:11 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Wed, 15 Jan 2025 14:12:11 GMT, Matthias Baesken wrote:
>> src/java.desktop/share/native/libjsound/MidiOutDevice.c line 97:
>>
>>> 95: /* Handle error codes. */
>>> 96: if (ret < -1) {
>>> 97: ERROR1("Java_com_sun_media_sound_MidiOutDevice_nGetTimeStamp:
>>> MIDI_IN_GetTimeSta
On Wed, 15 Jan 2025 12:43:52 GMT, Matthias Baesken wrote:
>> When enabling the jsound ERROR and TRACE reporting (see
>> src/java.desktop/share/native/libjsound/Configure.h
>> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32
>> ), we run into so
On Wed, 15 Jan 2025 12:43:52 GMT, Matthias Baesken wrote:
>> When enabling the jsound ERROR and TRACE reporting (see
>> src/java.desktop/share/native/libjsound/Configure.h
>> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/native/libjsound/Configure.h#L32
>> ), we run into so
On Mon, 13 Jan 2025 18:53:18 GMT, Christoph Langer wrote:
> This does not look wrong. However, is %lld the standard format string for
> printing out jlong values?
That should depend on the platform, lld is a long long int, while jlong can be
either a long long or just a long
-
PR
On Tue, 17 Dec 2024 18:00:04 GMT, Magnus Ihse Bursie wrote:
> > I am not sure if this is already on my list of reasons I don't like C++.
>
> I did not know about this until I tried to resolve this bug (it took some
> time to figure out the problem). I can surely put it on my such list. :)
Turn
On Tue, 12 Nov 2024 14:30:05 GMT, Julian Waters wrote:
> [JDK-8305590](https://bugs.openjdk.org/browse/JDK-8305590) removed
> `-fcheck-new` when building with gcc. It turns out Visual Studio has a
> similar option, though inverted in behavior and default.
>
> It seems like
On Mon, 18 Nov 2024 05:48:57 GMT, Julian Waters wrote:
>> [JDK-8305590](https://bugs.openjdk.org/browse/JDK-8305590) removed
>> `-fcheck-new` when building with gcc. It turns out Visual Studio has a
>> similar option, though inverted in behavior and default.
&g
On Tue, 7 Jan 2025 09:56:11 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Tue, 7 Jan 2025 09:56:11 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Tue, 19 Nov 2024 17:58:59 GMT, Phil Race wrote:
>> Julian Waters 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 three addi
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The pull
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request incrementally with one additional
commit since the last
On Mon, 18 Nov 2024 05:48:57 GMT, Julian Waters wrote:
>> [JDK-8305590](https://bugs.openjdk.org/browse/JDK-8305590) removed
>> `-fcheck-new` when building with gcc. It turns out Visual Studio has a
>> similar option, though inverted in behavior and default.
&g
On Mon, 23 Dec 2024 08:18:40 GMT, Thomas Stuefe wrote:
>> src/java.desktop/share/native/common/awt/debug/debug_trace.h line 66:
>>
>>> 64: /* each file includes this flag indicating module trace status */
>>> 65: #ifdef __cplusplus
>>> 66: [[maybe_unused]]
>>
>> I don't really know what to do a
On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Wed, 18 Dec 2024 19:53:10 GMT, Magnus Ihse Bursie wrote:
> > DllMain is a default name, not a required name. You could just rename them
> > and add /entry to the linker command line, eg /entry:AwtDllMain
>
> That was an interesting piece of information I did not know. That could be
> used t
On Tue, 19 Nov 2024 17:58:59 GMT, Phil Race wrote:
>> Julian Waters 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 three addi
On Tue, 17 Dec 2024 11:51:51 GMT, Magnus Ihse Bursie wrote:
> To be able to properly support static builds on Windows in
> [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use
> `DllMain`, for two reasons:
>
> 1) This is not called for statically linked libraries, and
> 2)
On Fri, 13 Dec 2024 14:30:37 GMT, Magnus Ihse Bursie wrote:
> There has been a latent problem in `GDIHashtable` since time immemorial, but
> due to sheer luck it has not caused any issues for us. However, I managed to
> provoke it when I was doing some build changes.
>
> This is the problem:
>
On Wed, 11 Dec 2024 20:55:41 GMT, Magnus Ihse Bursie wrote:
>> @magicus Sorry for the ping, but I'm a bit confused. Do you know what bug
>> report site Phil is referring to when he says to submit a bug to AWT
>> instead? Is it just the JBS? (There's a little bit of a problem if it is, it
>> is
On Fri, 25 Oct 2024 10:11:57 GMT, Magnus Ihse Bursie wrote:
>> It's a checkout error from the original gigantic Pull Request, sorry. I
>> don't plan to raise the JDK to C++17 in this one. But I'm not sure what to
>> do with this now, since maybe_unused is C++17. I don't think anyone is going
>
On Wed, 20 Nov 2024 05:41:58 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Wed, 20 Nov 2024 05:41:58 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 21 Nov 2024 07:09:23 GMT, Kim Barrett wrote:
> > One thing I have a query on: Does this need the problem with the ADLC
> > operator new to be fixed before it can be integrated?
>
> For those following along, the bug being referred to is this:
> https://bugs.openjdk.org/browse/JDK-83426
On Mon, 18 Nov 2024 05:48:57 GMT, Julian Waters wrote:
>> [JDK-8305590](https://bugs.openjdk.org/browse/JDK-8305590) removed
>> `-fcheck-new` when building with gcc. It turns out Visual Studio has a
>> similar option, though inverted in behavior and default.
&g
On Sun, 27 Oct 2024 06:24:49 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The pul
On Tue, 19 Nov 2024 17:58:59 GMT, Phil Race wrote:
> There's not much I like about this PR. I think it would be better to withdraw
> it and submit a bug against A11Y for people to look at what should really be
> done about these cases. Which could include "do nothing".
Thanks for taking a look
t;
> The documentation for /Zc:throwingNew is somewhat vague and confusing, so
> some investigation is probably needed to verify it really has the desired
> effect for us.
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The pull r
On Tue, 12 Nov 2024 14:30:05 GMT, Julian Waters wrote:
> [JDK-8305590](https://bugs.openjdk.org/browse/JDK-8305590) removed
> `-fcheck-new` when building with gcc. It turns out Visual Studio has a
> similar option, though inverted in behavior and default.
>
> It seems like
[JDK-8305590](https://bugs.openjdk.org/browse/JDK-8305590) removed
`-fcheck-new` when building with gcc. It turns out Visual Studio has a similar
option, though inverted in behavior and default.
It seems like /Zc:throwingNew- (the default) corresponds to gcc -fcheck-new,
and /Zc:throwingNew cor
On Sun, 27 Oct 2024 06:24:49 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Sun, 27 Oct 2024 06:24:49 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Fri, 8 Nov 2024 02:32:42 GMT, Alex Menkov wrote:
> Can someone confirm that use of `__stdcall` has no affect on name
> decorations, as there is no mention here about anything being ignored:
>
> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170
>
> I would h
On Thu, 7 Nov 2024 12:08:50 GMT, Aleksey Shipilev wrote:
>> src/hotspot/os/windows/os_windows.cpp line 510:
>>
>>> 508: // Thread start routine for all newly created threads.
>>> 509: // Called with the associated Thread* as the argument.
>>> 510: static unsigned thread_native_entry(void* t) {
>
On Wed, 6 Nov 2024 01:44:48 GMT, Alex Menkov wrote:
> I think you may be throwing the baby out with the bath water when it comes to
> `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see
> anything that states `__stdcall` is ONLY for 32-bit!
To my knowledge the only thing __
On Sun, 27 Oct 2024 06:24:49 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Wed, 30 Oct 2024 11:19:03 GMT, Magnus Ihse Bursie wrote:
>> src/hotspot/share/adlc/main.cpp line 494:
>>
>>> 492: }
>>> 493:
>>> 494: #if !defined(_WIN32) || defined(_WIN64)
>>
>> Removing the conditionalization is fine for this change. But see also
>> https://bugs.openjdk.org/browse/JDK-
On Sun, 27 Oct 2024 06:24:49 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Tue, 29 Oct 2024 14:37:43 GMT, Aleksey Shipilev wrote:
>> @shipilev There _is_ a way to implement SpinPause on Windows/x64 though, if
>> support is really as simple as a single pause instruction. Should I help
>> implement this separately (After this PR is integrated, to avoid conflicts)?
>
On Tue, 29 Oct 2024 14:44:03 GMT, Magnus Ihse Bursie wrote:
>> I stand corrected: I forgot about Windows/ARM64. To correct myself: Due to a
>> bug, this file, which is meant for Windows/x64, is used by Windows/ARM64
>> instead. The consequences of this are unknown
>
> What bug are you referring
On Mon, 28 Oct 2024 19:25:09 GMT, Aleksey Shipilev wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>> T
On Tue, 29 Oct 2024 06:59:22 GMT, Julian Waters wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build suppor
On Tue, 29 Oct 2024 09:32:21 GMT, David Holmes wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>> This
On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie wrote:
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase.
On Fri, 25 Oct 2024 10:11:57 GMT, Magnus Ihse Bursie wrote:
>> It's a checkout error from the original gigantic Pull Request, sorry. I
>> don't plan to raise the JDK to C++17 in this one. But I'm not sure what to
>> do with this now, since maybe_unused is C++17. I don't think anyone is going
>
On Thu, 24 Oct 2024 22:07:52 GMT, Magnus Ihse Bursie wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
On Thu, 24 Oct 2024 07:11:16 GMT, David Holmes wrote:
> > the way I did it I'd have to force push
>
> That should not be the case. You can just anti-delta changes.
I did it in a really inefficient way, by checking out all files except for the
files that I wanted to stay. I could not figure out
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has refreshed the contents of this pull request, and previous
commits have been remov
On Wed, 23 Oct 2024 16:51:23 GMT, Chris Plummer wrote:
>> I wasn't sure whether the global memHandle not being used was a bug, so I
>> commented out the local one. I missed the line 88 one because it wasn't
>> flagged. If it really isn't needed I'll remove that one instead
>
> I'm not sure what
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
After 8339120, gcc began catching many different instances of unused code in
the Windows specific codebase. Some of these seem to be bugs. I've taken the
effort to mark out all the relevant globals and locals that trigger the unused
warnings and addressed all of them by commenting out the code a
On Tue, 22 Oct 2024 18:03:12 GMT, Chris Plummer wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
After 8339120, gcc began catching many different instances of unused code in
the Windows specific codebase. Some of these seem to be bugs. I've taken the
effort to mark out all the relevant globals and locals that trigger the unused
warnings and addressed all of them by commenting out the code a
On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Tue, 22 Oct 2024 09:40:35 GMT, David Holmes wrote:
> > Aren't the dt_shmem and jdwp changes related to HotSpot?
>
> Nope. That's core-svc - the non-hotspot side of serviceability. :)
Oh, well I guess you learn something new everyday :)
-
PR Comment: https://git.openjdk.org/jdk/
On Tue, 22 Oct 2024 01:40:11 GMT, David Holmes wrote:
> > and whatever team is responsible for HotSpot debugging.
>
> I don't see anything hotspot related here.
>
> I think you would be better off splitting this up into distinct issues and
> PRs for different areas. I expect the client team in
After 8339120, gcc began catching many different instances of unused code in
the Windows specific codebase. Some of these seem to be bugs. I've taken the
effort to mark out all the relevant globals and locals that trigger the unused
warnings and addressed all of them by commenting out the code a
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Wed, 9 Oct 2024 07:50:20 GMT, Matthias Baesken wrote:
>> There is some old awt/2d coding where warnings occur when running with ubsan
>> enabled binaries.
>> However at most of these locations the coding should work (at least on our
>> supported platform set) so the warnings can be disabled
On Fri, 27 Sep 2024 06:46:24 GMT, Matthias Baesken wrote:
> And it was reviewed by erikj and ihse, I think those are members of the
> OpenJDK build group
Erik and Magnus are indeed part of the build team. Erik is the Skara tool lead
but does build work as well, while Magnus is pretty much the
On Thu, 26 Sep 2024 14:44:53 GMT, Matthias Baesken wrote:
>> It has been discussed that checking the return value of pthread_create
>> should be done.
>> See the discussion here https://github.com/openjdk/jdk/pull/20812 about the
>> splashscreen coding .
>
> Matthias Baesken has updated the pul
On Thu, 26 Sep 2024 11:51:19 GMT, Matthias Baesken wrote:
> > jni_md.h seems like a pretty big sledgehammer for something that seems to
> > only be in one file, for just java.desktop. Is this macro planned to be
> > used outside of java.desktop?
>
> Yes I have a couple (currently 2) more I wou
On Wed, 25 Sep 2024 12:17:59 GMT, Matthias Baesken wrote:
> There is some old awt/2d coding where warnings occur when running with ubsan
> enabled binaries.
> However at most of these locations the coding should work (at least on our
> supported platform set) so the warnings can be disabled at
On Thu, 26 Sep 2024 07:04:52 GMT, Christoph Langer wrote:
> I found some strange handling of the return value on macOS. Here we check
> already the return value of pthread_create ; but then it seems we add the
> errno twice when calling JLI_ReportErrorMessageSys, once in the calling
> params a
On Wed, 25 Sep 2024 12:17:59 GMT, Matthias Baesken wrote:
> There is some old awt/2d coding where warnings occur when running with ubsan
> enabled binaries.
> However at most of these locations the coding should work (at least on our
> supported platform set) so the warnings can be disabled at
On Wed, 4 Sep 2024 23:06:00 GMT, Jiangli Zhou wrote:
>> As a prerequisite for Hermetic Java, we need a statically linked `java`
>> launcher. It should behave like the normal, dynamically linked `java`
>> launcher, except that all JDK native libraries should be statically, not
>> dynamically, l
On Tue, 3 Sep 2024 06:16:06 GMT, David Holmes wrote:
>>> Also doesn't a call like this trigger the warning about ignoring a function
>>> result, or have we disabled that one?
>>
>> Such a warning would be horrible to have enable. Then you would have to read
>> the value of every function that
On Mon, 2 Sep 2024 11:43:20 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:66
On Mon, 2 Sep 2024 04:09:19 GMT, David Holmes wrote:
> > This does make me wonder: What if the new method for checking if the VM was
> > statically linked was inlined? Then the problem comes back yet again as the
> > object files need to be recompiled once more. This is possible if Link Time
>
1 - 100 of 472 matches
Mail list logo
