On Tue, 6 Feb 2024 01:36:58 GMT, Jonathan Gibbons wrote:
>> Please review a patch to add support for Markdown syntax in documentation
>> comments, as described in the associated JEP.
>>
>> Notable features:
>>
>> * support for `///` documentation comments in `JavaTokenizer`
>> * new module `jd
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/commit/9ee9f288497268d64ddd48783ecb68f7e5
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 `#impo
On Mon, 5 Feb 2024 15:42:40 GMT, Kim Barrett wrote:
> I thought we didn't, because we were instead supposed to use INTPTR_FORMAT and
the (currently?) equivalent PTR_FORMAT. Those macros aren't legacy, they are
to provide consistent output across platforms. "%p" provides implementation
defined out
Add policy statement about lint warnings to various langtools modules.
-
Commit messages:
- JDK-8325268: Add policy statement to langtools makefiles concerning warnings
Changes: https://git.openjdk.org/jdk/pull/17718/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17718&rang
On Mon, 5 Feb 2024 21:03:04 GMT, Joe Darcy wrote:
> The jdk.javadoc module doesn't need the this-escape warning disabled to
> build; it should be enabled.
This pull request has now been integrated.
Changeset: 729ae1d7
Author:Joe Darcy
URL:
https://git.openjdk.org/jdk/commit/729ae1d
> Please review a patch to add support for Markdown syntax in documentation
> comments, as described in the associated JEP.
>
> Notable features:
>
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java`
> libra
On Tue, 6 Feb 2024 00:14:40 GMT, Jesper Wilhelmsson
wrote:
> Removed ea from the version string
This pull request has now been integrated.
Changeset: bff5e903
Author:Jesper Wilhelmsson
URL:
https://git.openjdk.org/jdk22/commit/bff5e903591276b4c9bdb2714370931d31598579
Stats: 1 l
On Tue, 6 Feb 2024 00:14:40 GMT, Jesper Wilhelmsson
wrote:
> Removed ea from the version string
Marked as reviewed by mikael (Reviewer).
-
PR Review: https://git.openjdk.org/jdk22/pull/106#pullrequestreview-1864071852
Removed ea from the version string
-
Commit messages:
- 8319547: Remove EA from the JDK 22 version string with first RC promotion
Changes: https://git.openjdk.org/jdk22/pull/106/files
Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=106&range=00
Issue: https://bugs.openjdk.org/
On Mon, 5 Feb 2024 21:03:04 GMT, Joe Darcy wrote:
> The jdk.javadoc module doesn't need the this-escape warning disabled to
> build; it should be enabled.
Marked as reviewed by erikj (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/17715#pullrequestreview-1864049267
On Wed, 18 Oct 2023 06:12:29 GMT, Xiaohong Gong wrote:
> Currently the vector floating-point math APIs like
> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
> which causes large performance gap on AArch64. Note that those APIs are
> optimized by C2 compiler on X86 p
The jdk.javadoc module doesn't need the this-escape warning disabled to build;
it should be enabled.
-
Commit messages:
- JDK-8325266: Enable this-escape javac warning in jdk.javadoc
Changes: https://git.openjdk.org/jdk/pull/17715/files
Webrev: https://webrevs.openjdk.org/?repo=jd
On Mon, 5 Feb 2024 16:19:59 GMT, Magnus Ihse Bursie wrote:
> Is there anything in this proposed PR that you gentlemen disagree with or
> object to? Or is this fine to push as a step in our ongoing pursuit of
> increasing the code quality, that can (and will) be followed by many more?
Yes. As
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
On Mon, 5 Feb 2024 21:03:04 GMT, Joe Darcy wrote:
> The jdk.javadoc module doesn't need the this-escape warning disabled to
> build; it should be enabled.
Marked as reviewed by jjg (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/17715#pullrequestreview-1863818840
On Fri, 2 Feb 2024 23:38:41 GMT, Joe Darcy wrote:
> In its initial form, the changes are tested on Linux. Later on, I'll do
> cross-platform builds to make sure there aren't any, say, windows-specific
> changes that are needed as well.
>
> I can file a follow-up umbrella bug with the original
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 `#impo
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 `#impo
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 `#impo
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.
> Thi
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 `#impo
On Mon, 5 Feb 2024 15:42:40 GMT, Kim Barrett wrote:
>>> I consider the "format '%p' expects argument of type 'void*" warnings to be
>>> not at all helpful. Fortunately we don't use '%p' in HotSpot,
>>
>> We do use it in hotspot. Not a huge amount as we have the legacy format
>> specifiers for
On Mon, 5 Feb 2024 06:15:08 GMT, David Holmes wrote:
> > I consider the "format '%p' expects argument of type 'void*" warnings to be
> > not at all helpful. Fortunately we don't use '%p' in HotSpot,
>
> We do use it in hotspot. Not a huge amount as we have the legacy format
> specifiers for PT
> On Feb 5, 2024, at 4:31 AM, Magnus Ihse Bursie wrote:
>
> 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
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warni
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` ins
On Mon, 5 Feb 2024 14:03:45 GMT, Magnus Ihse Bursie wrote:
> I hope finally the AIX part of this PR is done.
Thanks for the AIX related effort ; I put it again into our internal build/test
queue.
-
PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927105669
On Tue, 5 Dec 2023 10:35:05 GMT, Magnus Ihse Bursie wrote:
> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
> their encoding of choice when they see this locale, but use an arbitrarily
> encoding, which might not properly handle all UTF-8 characters. Since in
> practi
> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
> their encoding of choice when they see this locale, but use an arbitrarily
> encoding, which might not properly handle all UTF-8 characters. Since in
> practice, all our encoding is utf8, we should tell our tools this a
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
Magnus Ihse Bursie has updated the pull request incrementally with one
additional commit since the last revision:
Rede
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Mon, 5 Feb 2024 10:38:26 GMT, Magnus Ihse Bursie wrote:
>> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
>> their encoding of choice when they see this locale, but use an arbitrarily
>> encoding, which might not properly handle all UTF-8 characters. Since in
>> pr
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 `#impo
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 `#impo
On Mon, 5 Feb 2024 12:38:03 GMT, Magnus Ihse Bursie wrote:
> It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have
> not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef
> _ALLBSD_SOURCE`, which I presume is not defined on AIX.
>
> I recommend that
On Mon, 5 Feb 2024 10:38:26 GMT, Magnus Ihse Bursie wrote:
>> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
>> their encoding of choice when they see this locale, but use an arbitrarily
>> encoding, which might not properly handle all UTF-8 characters. Since in
>> pr
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 2
On Mon, 5 Feb 2024 10:38:26 GMT, Magnus Ihse Bursie wrote:
>> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
>> their encoding of choice when they see this locale, but use an arbitrarily
>> encoding, which might not properly handle all UTF-8 characters. Since in
>> pr
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Mon, 5 Feb 2024 12:17:33 GMT, Joachim Kern wrote:
> Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on
> AIX to 32-Bit. _LARGE_FILES really does not help in this case!
Thanks for confirming. I think we do not want to fallback on AIX, so the <*>64
variant needs to
On Mon, 5 Feb 2024 10:49:07 GMT, Julian Waters wrote:
> The other concern I had was that there are a ton of disabled warnings added
> by this change, but I guess that's already been answered by that other reply
Just to be clear: these warnings have never been turned on. They are implicitly
tur
On Mon, 5 Feb 2024 12:07:45 GMT, Matthias Baesken wrote:
> Current commit compiles nicely on AIX. One issue we might still have
> statvfs/statvfs64 is not mentioned here in the table of functions/structs
> redefined on AIX
> https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-th
On Mon, 5 Feb 2024 10:49:07 GMT, Julian Waters 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 2
> options are
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Mon, 5 Feb 2024 10:37:59 GMT, Magnus Ihse Bursie wrote:
> I'll have a look. It is definitely cleaner if it works.
Yeah, no, as expected it did not work.
-
PR Comment: https://git.openjdk.org/jdk/pull/17688#issuecomment-1926726543
> 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` instead of `#include`. In this
> patch, I disable warnings f
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:
> Shouldn't
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: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.
> Thi
> We're currently setting LC_ALL=C. Not all tools will default to utf-8 as
> their encoding of choice when they see this locale, but use an arbitrarily
> encoding, which might not properly handle all UTF-8 characters. Since in
> practice, all our encoding is utf8, we should tell our tools this a
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: https://git.openjdk.org/jdk/pull/17688#issuecomme
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.
> Thi
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 han
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.
> Thi
On Mon, 5 Feb 2024 09:17:11 GMT, Andrew Haley wrote:
> Sure, you can always install a newer GCC than the system one, but it's
> another thing that makes it harder for people to build OpenJDK. Having said
> that, C++17 is nice to have.
@theRealAph I am still just hearing hand-waving "perhaps s
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 Mon, 5 Feb 2024 03:07:43 GMT, Kim Barrett 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 handling, I don't th
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` ins
On Wed, 17 Jan 2024 11:19:03 GMT, Magnus Ihse Bursie wrote:
> We have been stuck on a very old gcc for a long time, due to various reasons.
> Partly because old gcc versions were not as terrible as old versions of
> cl.exe, and partly to support odd linux platforms where newer gcc versions
> w
On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
On Mon, 5 Feb 2024 08:26:55 GMT, Martin Doerr wrote:
> A trivial ADLC build fix. The ADLC_LANGSTD_CXXFLAGS should get passed.
LGTM. Thanks!
-
Marked as reviewed by ihse (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/17705#pullrequestreview-1862219166
On Mon, 5 Feb 2024 08:26:55 GMT, Martin Doerr wrote:
> A trivial ADLC build fix. The ADLC_LANGSTD_CXXFLAGS should get passed.
Marked as reviewed by jwaters (Committer).
-
PR Review: https://git.openjdk.org/jdk/pull/17705#pullrequestreview-1862133568
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 Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request increme
69 matches
Mail list logo
