On Wed, 12 Jun 2024 04:58:47 GMT, Abhishek Kumar wrote:
> Looks like there was a typo for null character. It should be `'\0'` instead
> of `'/0'`.
> Build with clang toolchain with the help of [this
> PR](https://github.com/openjdk/jdk/pull/17019) and after the changes there is
> no warning.
ll to be clarified, as several, ranging
> from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason,
> the build system hack in place at the moment to compile the binutils backend
> on Windows is still left in place, for now.
Julian Waters has updated the pull request
ll to be clarified, as several, ranging
> from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason,
> the build system hack in place at the moment to compile the binutils backend
> on Windows is still left in place, for now.
Julian Waters has updated the pull request
On Wed, 15 May 2024 13:32:38 GMT, Magnus Ihse Bursie wrote:
> Hi Julian, sorry for not getting back to you.
>
> The problem from my PoV is that this is a very large and intrusive patch in
> the build of the actual product, for a claimed problem in the tangential
> hsdis library. I have not
On Thu, 9 May 2024 07:50:00 GMT, Julian Waters wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during t
On Thu, 9 May 2024 07:50:00 GMT, Julian Waters wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during t
On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during the build. Currently,
On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during the build. Currently,
On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during the build. Currently,
On Wed, 24 Apr 2024 09:15:21 GMT, Magnus Ihse Bursie wrote:
>> WIP
>>
>> This changeset contains hsdis for Windows/gcc Port. It supports both the
>> binutils and capstone backends, though the LLVM backend is left out due to
>> compatibility issues encountered during the build. Currently,
ll to be clarified, as several, ranging
> from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason,
> the build system hack in place at the moment to compile the binutils backend
> on Windows is still left in place, for now.
Julian Waters has updated the pull request
On Tue, 23 Apr 2024 14:25:22 GMT, Magnus Ihse Bursie wrote:
> There's a huge amount of changes for just hsdis... You might have to separate
> out the infrastructure changes that seem to amount to most of the changes
> here.
>
> This is going to take me a while to get through.
Sorry, it's
WIP
This changeset contains hsdis for Windows/gcc Port. It supports both the
binutils and capstone backends, though the LLVM backend is left out due to
compatibility issues encountered during the build. Currently, which gcc
distributions are supported is still to be clarified, as several,
On Tue, 16 Apr 2024 18:34:49 GMT, Magnus Ihse Bursie wrote:
> There is no good IDE support for Makefiles, especially not with the level of
> customization that we have done to make. I am positively struggling with
> navigating this file, time and time again.
I find Eclipse CDT to be rather
On Thu, 11 Apr 2024 09:33:09 GMT, Alexey Ivanov wrote:
> This clean-up PR removes unused Windows version macro from `ShellFolder2.cpp`.
>
> `IS_WINVISTA` was not used at all.
>
> `IS_WINXP` guarded support for icons with alpha channel. It is now safe to
> assume Java runs on a Windows version
On Thu, 4 Apr 2024 22:47:18 GMT, Magnus Ihse Bursie wrote:
>> This is a retake on https://github.com/openjdk/jdk/pull/15096.
>>
>> I tried to fix the remaining issues in that PR, but could not push them. In
>> the end, it seemed easier to create a new branch in my own personal fork.
>>
>> The
On Tue, 2 Apr 2024 15:45:59 GMT, Magnus Ihse Bursie wrote:
> This is a retake on https://github.com/openjdk/jdk/pull/15096.
>
> I tried to fix the remaining issues in that PR, but could not push them. In
> the end, it seemed easier to create a new branch in my own personal fork.
>
> The
On Mon, 1 Apr 2024 10:33:41 GMT, Julian Waters wrote:
>> Julian Waters has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Labels to empty line in awt_Window.cpp
>> - Labels to empty line in awt_Window
On Thu, 28 Mar 2024 07:36:04 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
On Sun, 21 Jan 2024 19:50:16 GMT, Phil Race wrote:
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
> See my comment
> "like in
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with four additional
commits since the last revision:
- Labels to empty line in awt_Window.cpp
- Labels to empty line in awt_Window.cpp
- Label to empty line in awt_Window.cpp
- Labe
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting in awt_Window.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Label to empty line in awt_Component.cpp
- Label to empty line in awt_Canvas.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/p
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Circumvent pData in awt_Window.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Circumvent pData in awt_Window.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Circumvent pData in awt_Window.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Circumvent pData in awt_Frame.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Circumvent pData in awt_Component.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openj
On Tue, 26 Mar 2024 20:03:36 GMT, Magnus Ihse Bursie wrote:
>> I see the advantage of collapsing self and parent into the same check, but
>> it doesn't seem like getting rid of pData is of much benefit, the checks for
>> null seem to remain the same either way
>
>> Sorry, I don't see a BOOL
On Tue, 26 Mar 2024 08:55:56 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting in
src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
Co-authored-by: Magnus Ihse Bursie
-
C
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Whitespace in awt_DnDDS.cpp
- Whitespace in awt_DnDDT.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
On Tue, 26 Mar 2024 07:44:22 GMT, Magnus Ihse Bursie wrote:
> > I have a concern since the null check bailout involves
> > THROW_NULL_PDATA_IF_NOT_DESTROYED, which is no longer accurate if we remove
> > the pData local.
>
> The name of the macro is not great, but it does not involve pData
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Comment in src/java.desktop/windows/native/libawt/windows/awt_DnDDS.cpp
Co-authored-by: Magnus Ihse Bursie
- Comment in src/java.desktop
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting in
src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
Co-authored-by: Magnus Ihse Bursie
-
C
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting in
src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp
Co-authored-by: Magnus Ihse Bursie
-
C
On Mon, 25 Mar 2024 09:02:22 GMT, Magnus Ihse Bursie wrote:
> > The only thing I'm uncertain about is the pData local, which I don't see
> > much benefit in removing since the null check associated with it still has
> > to remain for code semantics to be correct
>
> The point is that you can
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting change in
src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
Co-authored-by: Magnus Ihse Bursie
---
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Partially revert formatting in AccessBridgeJavaEntryPoints.cpp
- Partially revert formatting in AccessBridgeJavaEntryPoints.cpp
-
C
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting in awt_Frame.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Revert formatting in
src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
Co-authored-by: Magnus Ihse Bursie
- Revert for
On Mon, 25 Mar 2024 08:59:08 GMT, Magnus Ihse Bursie wrote:
>> I don't think I can commit this as there are 3 backticks at the end there :P
>
> Apologies. The point was that this was formatting changes that were not
> needed and should be reverted.
I know, I did want to commit your change
On Fri, 22 Mar 2024 12:27:31 GMT, Magnus Ihse Bursie wrote:
>> Julian Waters has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Revert Formatting in awt_Component.cpp
>> - Revert Formatting in awt_Window.cp
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert formatting in
src/java.desktop/windows/native/libawt/windows/awt_Window.cpp
Co-authored-by: Magnus Ihse Bursie
-
C
On Wed, 20 Mar 2024 06:38:59 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
On Mon, 18 Mar 2024 15:55:15 GMT, Magnus Ihse Bursie 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 84 commits:
>>
>> - Merge branch 'openjdk:master' into patch
On Sun, 21 Jan 2024 19:50:16 GMT, Phil Race wrote:
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
>> Fixed the formatting (at least in the marked cases), but am unsure what you
>> mean by set directly?
>
> See my comment
> "like in
On Mon, 18 Mar 2024 15:55:15 GMT, Magnus Ihse Bursie wrote:
> bot-keep-alive
>
> @TheShermanTanker Did you understand the remaining changes that Phil has
> requested? Do you think you'll be able to fix this?
Hi Magnus, yes I do plan on fixing this. I've just been a bit busy and tired is
all,
On Wed, 20 Mar 2024 06:22:50 GMT, Julian Waters wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 6366:
>>
>>> 6364: jobject parent = data->parentComp;
>>> 6365:
>>> 6366: AwtComponent *awtComponent = nullp
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Revert Formatting in awt_Component.cpp
- Revert Formatting in awt_Window.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/p
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert Formatting in awt_PrintJob.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openj
On Sat, 20 Jan 2024 00:17:02 GMT, Phil Race 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 79 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>> - Merge bran
On Mon, 11 Mar 2024 08:38:53 GMT, Joachim Kern wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> doc/building.html line 679:
>
>> 677: IBM Open XL C/C++
>> 678: The minimum
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie 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.
>>
On Mon, 4 Mar 2024 12:58:28 GMT, Claudio Nieder wrote:
> > Could I trouble you to mention what exactly was different?
>
> No trouble at all.
>
> `CCACHE_BASEDIR=/tmp/bceaed6d/jdk/`is completely missing. (The directory is
> where I checked out OpenJDK)
>
> `CCACHE_SLOPPINESS` has the value
On Mon, 4 Mar 2024 11:28:02 GMT, Magnus Ihse Bursie wrote:
> > I wonder if it's the SetupToolchain changes that has caused this. ccache is
> > collapsed into CC and CXX to my knowledge
>
> Yeah, it must have been. Would you like to take a look at it? Otherwise I'll
> file a bug and fix it.
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
On Tue, 27 Feb 2024 11:09:26 GMT, Magnus Ihse Bursie wrote:
> > can we get rid of LDCXX?
>
> Yeah, that is something I plan to look into. Linking C++ object files with
> gcc will fail; and it might be that linking pure C with g++ might be
> problematic. If this is the case, I hope we can at
On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
On Tue, 27 Feb 2024 08:07:38 GMT, Daniel Jeliński wrote:
> can we get rid of LDCXX? On my system LDCXX is mapped to `g++` and LD is
> `gcc`; I searched for the differences, and the only thing I could find is
> that `g++` implicitly adds `-lstdc++ -shared-libgcc`; I suppose we could
>
On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This is better described by a
>
On Sat, 3 Feb 2024 10:07:26 GMT, Sam James wrote:
>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>>
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using
On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using
On Mon, 5 Feb 2024 12:15:50 GMT, Magnus Ihse Bursie wrote:
> > Shouldn't this be -pedantic -Wpedantic, and wouldn't this be better
> > positioned at where HotSpot currently sets -permissive- for Microsoft
> > Visual C++ (In other words, TOOLCHAIN_CFLAGS_JVM and TOOLCHAIN_CFLAGS_JDK)?
> > The
On Mon, 5 Feb 2024 10:44:59 GMT, Magnus Ihse Bursie wrote:
> I am sorry, but all I can see is:
>
> > Just a few questions...
>
> and then your comment ends. And I can't find any other comment with a list of
> questions.
Eh? Aren't they in the code review section? But in any case:
>
On Mon, 5 Feb 2024 10:12:30 GMT, Magnus Ihse Bursie wrote:
> Any takers on this?
Have an obligatory +1 for the build changes I suppose, but isn't there the
ability to use DISABLED_WARNINGS or a #pragma clang for this?
-
PR Comment:
On Fri, 2 Feb 2024 15:27:39 GMT, Magnus Ihse Bursie wrote:
> While we do not have automatic testing of using clang instead of gcc on
> linux, we try to keep it in working condition. This is still the case for the
> JDK itself, but there is a native test which fails to compile with clang.
>
On Mon, 5 Feb 2024 09:32:09 GMT, Magnus Ihse Bursie wrote:
> > at least not for a future version applying to gcc builds.
>
> @kimbarrett @TheShermanTanker Please do not drag gcc into this PR. This is
> just about clang. Unless gcc makes a serious effort to shape up their
> inferior warning
On Mon, 5 Feb 2024 03:21:35 GMT, Kim Barrett wrote:
>> Inspired by (the later backed-out)
>> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
>> enable `-Wpedantic` for clang. This has already found some irregularities in
>> the code, like mistakenly using `#import`
On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote:
> Inspired by (the later backed-out)
> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
> enable `-Wpedantic` for clang. This has already found some irregularities in
> the code, like mistakenly using `#import`
On Sun, 4 Feb 2024 22:52:19 GMT, Magnus Ihse Bursie wrote:
> > Guess I could work on the gcc counterpart and find a way around the
> > inability to disable -Wpedantic with it in tandem with this change...
>
> I don't think that is possible. The double semicolon rule can only be
> disabled by
On Sat, 3 Feb 2024 10:07:26 GMT, Sam James wrote:
>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>>
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
On Fri, 2 Feb 2024 06:35:26 GMT, Sam James wrote:
>> This fixes building with GCC 14:
>> * ~Cherry-pick a fix from Harfbuzz upstream~
>> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>>
>> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
>> -Werror.
On Fri, 2 Feb 2024 09:26:28 GMT, Kim Barrett wrote:
>> Sam James has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - fix whitespace
>> - Revert "harfbuzz: Cherry-pick upstream fix for GCC 14"
>>
>>This reverts commit
On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote:
> Inspired by (the later backed-out)
> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
> enable `-Wpedantic` for clang. This has already found some irregularities in
> the code, like mistakenly using `#import`
On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie wrote:
> Inspired by (the later backed-out)
> [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to
> enable `-Wpedantic` for clang. This has already found some irregularities in
> the code, like mistakenly using `#import`
On Tue, 23 Jan 2024 00:58:27 GMT, Sergey Bylokhov wrote:
> The next bug in freetype was fixed upstream and fix already merged to OpenJDK:
> https://gitlab.freedesktop.org/freetype/freetype/-/issues/1245
> So now we can revert the workaround in the JDK:
>
On Sun, 21 Jan 2024 16:42:40 GMT, Sam James wrote:
> > No problem!
>
> Many thanks!
>
> > Just change your Pull Request title to 8324243 (The literal number) and
> > watch the magic happen :)
> > By the way, your name strikes me as familiar. Have I seen you before on the
> > gcc mailing
On Sat, 20 Jan 2024 10:15:02 GMT, Sam James wrote:
> This fixes building with GCC 14:
> * Cherry-pick a fix from Harfbuzz upstream
> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>
> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
> -Werror.
>
>
On Sat, 20 Jan 2024 10:15:02 GMT, Sam James wrote:
> This fixes building with GCC 14:
> * Cherry-pick a fix from Harfbuzz upstream
> * Apply other `-Wcalloc-transposed-args` fixes to the JDK sources
>
> -Wcalloc-transposed-args errors out with GCC 14 as the OpenJDK build uses
> -Werror.
>
>
ve code quality on Windows in the future.
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 84 commits:
- Merge branch 'openjdk:master' into patch-10
- awt_Window.cpp
- awt_Frame.cpp
- awt_Component.cpp
- awt_Canvas.cpp
On Sun, 21 Jan 2024 07:55:13 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
awt_Window.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org/jdk/pull/15096
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
awt_Frame.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org/jdk/pull/15096
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- awt_Component.cpp
- awt_Canvas.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openj
On Thu, 16 Nov 2023 03:44:53 GMT, Phil Race wrote:
>> I happened to ask around on the build-dev mailing lists about whether we
>> include msvcp.dll with the JDK, here is Erik's response:
>>
>>> Back in JDK 8 when we used Visual Studio 2010, we used to not ship
>>> msvcp*.dll. This changed when
On Thu, 11 Jan 2024 12:11:17 GMT, Magnus Ihse Bursie wrote:
> What is remaining to get this PR committable? It has such a long history that
> it is hard to get a grasp on the remaining issues.
>
> @TheShermanTanker Could you perhaps summarize the remaining hurdles?
It's largely complete by
On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
ve code quality on Windows in the future.
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 79 commits:
- Merge branch 'openjdk:master' into patch-10
- Merge branch 'openjdk:master' into patch-10
- Fix awt_Wi
On Wed, 10 Jan 2024 09:18:53 GMT, Matthias Baesken wrote:
> There have been concerns raised about
> [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) , so bring back
> the old behavior.
Not a review, just a quick tip: Such changes are by convention titled [BACKOUT]
In this case
On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
On Mon, 4 Dec 2023 11:29:07 GMT, Magnus Ihse Bursie 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 78 commits:
>>
>> - Merge branch 'openjdk:master' into patch-10
>>
On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
ve code quality on Windows in the future.
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 78 commits:
- Merge branch 'openjdk:master' into patch-10
- Fix awt_Window.cpp
- Fix awt_PrintJob.cpp
- -Zc:stringStrings n
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Fix awt_Window.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org/jdk/pull/15096
ve code quality on Windows in the future.
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Fix awt_PrintJob.cpp
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15096/files
- new: https://git.openjdk.org/jdk/pull/15096
1 - 100 of 335 matches
Mail list logo
