On Thu, 27 Jun 2024 01:34:36 GMT, Jan Kratochvil
wrote:
>> fastdebug:
>>
>>
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error
>> (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77),
>> pid=878152, tid=878158
>> #
On Thu, 27 Jun 2024 01:48:23 GMT, Jan Kratochvil
wrote:
>> make/autoconf/jdk-options.m4 line 449:
>>
>>> 447: if test "x$TOOLCHAIN_TYPE" = "xclang"; then
>>> 448: ASAN_CFLAGS="$ASAN_CFLAGS
>>> -fsanitize-address-use-after-return=never"
>>> 449: fi
>>
>>
On Mon, 24 Jun 2024 18:42:34 GMT, Kim Barrett wrote:
>> Jan Kratochvil has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Change the comment
>>- suggested by Thomas Stuefe
>
> make/autocon
On Mon, 24 Jun 2024 14:34:37 GMT, Jan Kratochvil
wrote:
>> fastdebug:
>>
>>
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error
>> (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77),
>> pid=878152, tid=878158
>> #
On Mon, 24 Jun 2024 14:34:37 GMT, Jan Kratochvil
wrote:
>> fastdebug:
>>
>>
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error
>> (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77),
>> pid=878152, tid=878158
>> #
On Sun, 23 Jun 2024 13:18:19 GMT, Jan Kratochvil
wrote:
>> fastdebug:
>>
>>
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error
>> (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77),
>> pid=878152, tid=878158
>> #
On Sat, 22 Jun 2024 13:58:32 GMT, Jan Kratochvil
wrote:
> fastdebug:
>
>
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error
> (/home/azul/azul/openjdk-git/src/hotspot/share/runtime/handles.inline.hpp:77),
> pid=878152, tid=878158
> #
On Sat, 22 Jun 2024 13:58:32 GMT, Jan Kratochvil
wrote:
> There is also [JDK-8323732](https://bugs.openjdk.org/browse/JDK-8323732), one
> has to use --disable-warnings-as-errors . But then it does not work anyway
> (in fastdebug).
>
>
> # A fatal error has been detected by the Java Runtime
On Fri, 21 Jun 2024 08:29:37 GMT, Matthias Baesken wrote:
>> Sometimes it would be helpful to have configure-support for adding
>> additional ubsan check options.
>> E.g. support new configure option
>> '--with-additional-ubsan-checks=' .
>
> Matthias Baesken has updated the pull request
On Tue, 18 Jun 2024 11:29:20 GMT, Magnus Ihse Bursie wrote:
> From the JBS description:
>
> We use various POSIX functions in the JDK in shared code, and possibly even
> in Windows-specific code. The UCRT optionally provides the relevant
> functionality under alternate names with leading
On Thu, 2 May 2024 09:54:14 GMT, Joachim Kern wrote:
> We need to find a better way to handle alloca on AIX.
>
> See the discussion in the PR for https://bugs.openjdk.org/browse/JDK-8329257,
> e.g. https://github.com/openjdk/jdk/pull/18536#discussion_r1568650313 in
> which three alternatives
On Tue, 30 Apr 2024 15:19:47 GMT, Joachim Kern wrote:
>> It might be easier to get input if you create a new PR with the change. This
>> discussion is hidden deep down in a closed PR.
>
> I will do after labor day and create a PR with this suggested solution in
> your JDK-8330539.
I think I
On Wed, 17 Apr 2024 20:49:37 GMT, Magnus Ihse Bursie wrote:
>> I'm aware of this discussion and looking into the issues, but a personal
>> matter has intervened and it will take
>> me a while to respond properly. Maybe next week.
>
> I opened https://bugs.openjdk.org/browse/JDK-8330539 so we
On Wed, 17 Apr 2024 13:02:33 GMT, Martin Doerr wrote:
>> If there are just 3 files using alloca, I strongly prefer solution 3. I
>> think solution 1 has already been rejected by Kim.
>>
>> (Also, for the record, it was me, not Julian, who expressed dislike about
>> the
On Wed, 10 Apr 2024 12:15:34 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus
On Wed, 10 Apr 2024 22:12:42 GMT, Kim Barrett wrote:
>> I can live with either, too.
>
> That build failure in shared code does not happen with Xcode clang, gcc, or
> Visual Studio, even though none of them appear to have a relevant define or
> include. So the clang variant
On Wed, 10 Apr 2024 14:19:59 GMT, Thomas Stuefe wrote:
>> When only looking at AIX code, I think the inclusion of alloca.h was
>> cleaner. Agreed. The new code makes AIX behave like other platforms and
>> avoids the AIX specific part in shared code.
>> I could live with either version.
>
> I
On Tue, 9 Apr 2024 19:20:22 GMT, Kim Barrett wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> version check not needed anymore
>
> src/hotspot/share/utilities/globalDefinit
On Tue, 2 Apr 2024 16:14:12 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus
On Wed, 3 Apr 2024 02:28:08 GMT, Julian Waters wrote:
>> https://github.com/openjdk/jdk/pull/18586
>
> @kimbarrett I've been doing things to permit gcc/Windows, not clang. clang
> has too many different distributions on Windows for me to settle on one, and
> generalising all of them to be able
On Tue, 2 Apr 2024 11:35:44 GMT, Joachim Kern wrote:
>> linux macos and now Aix use this file.
>
> Who is able to explain if
> `#if defined(LINUX) || defined(_ALLBSD_SOURCE) || defined(_AIX)`
> in this file is equivalent to
> `#if 1`
See my other comments and
On Tue, 2 Apr 2024 17:01:07 GMT, Kim Barrett wrote:
>> https://bugs.openjdk.org/browse/JDK-8329546 - I can take this if nobody else
>> grabs it soon.
>
> I'm waiting for a bunch of tests to complete, so decided to just take that
> issue.
https://github.com/o
On Tue, 2 Apr 2024 16:52:04 GMT, Kim Barrett wrote:
>> There was at one time an attempt at a gcc/Solaris port, but I think it was
>> never completed, and most vestiges removed. More recently, @TheShermanTanker
>> has been doing stuff to permit clang/Windows, and clan
On Tue, 2 Apr 2024 16:41:40 GMT, Kim Barrett wrote:
>> I cannot answer this question.
>> If this line is now obsolete it was also obsolete before including AIX,
>> because AIX didn't use this file beforehand.
>
> There was at one time an attempt at a gcc/Solaris port, bu
On Tue, 2 Apr 2024 11:20:49 GMT, Joachim Kern wrote:
>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 62:
>>
>>> 60: #include
>>> 61:
>>> 62: #if defined(LINUX) || defined(_ALLBSD_SOURCE) || defined(_AIX)
>>
>> What else is left? Could we just remove this line altogether now?
>
On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Require clang 13 in toolchain.m4
As I
On Mon, 4 Mar 2024 08:38:09 GMT, Kim Barrett wrote:
> Please review this change to update the HotSpot Style Guide's discussion of
> nullptr and its use.
>
> I suggest this is an editorial rather than substantive change to the style
> guide. As such, the normal HotSpot PR proc
On Tue, 5 Mar 2024 18:16:51 GMT, Vladimir Kozlov wrote:
>> Kim Barrett 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 contain
> Please review this change to update the HotSpot Style Guide's discussion of
> nullptr and its use.
>
> I suggest this is an editorial rather than substantive change to the style
> guide. As such, the normal HotSpot PR process can be used for this change.
Kim Barrett has u
On Thu, 15 Feb 2024 05:19:45 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of Clang
> to be used for building OpenJDK from 3.5 to 13.
>
> This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for
> that. A mini
On Thu, 15 Feb 2024 05:19:45 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of Clang
> to be used for building OpenJDK from 3.5 to 13.
>
> This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for
> that. A mini
e
> [[noreturn]]
> attribute (see JDK-8303805).
>
> Testing: mach5 tier1, which includes building with a recent version of
> Xcode/clang.
Kim Barrett has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains four commits:
- Mer
> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++. SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
>
> I need someone from the aix-ppc porters to test and review the change.
On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++. SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
>
> I need someone f
On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++. SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
>
> I need someone f
On Tue, 5 Mar 2024 09:10:50 GMT, Joachim Kern wrote:
>>> > What does this mean? That you are not using xlc at all? Or is it clang
>>> > but still with an xlc frontend, so all xlc flags etc need to stay?
>>>
>>> The `xlc` toolchain is for the compiler versions up to 16 (xlclang++); the
>>>
On Tue, 5 Mar 2024 07:12:09 GMT, Kim Barrett wrote:
>> Please review this change to update the HotSpot Style Guide's discussion of
>> nullptr and its use.
>>
>> I suggest this is an editorial rather than substantive change to the style
>> guide. As such, the
On Thu, 15 Feb 2024 11:10:32 GMT, Joachim Kern wrote:
> > What does this mean? That you are not using xlc at all? Or is it clang but
> > still with an xlc frontend, so all xlc flags etc need to stay?
>
> The `xlc` toolchain is for the compiler versions up to 16 (xlclang++); the
> `clang`
On Tue, 5 Mar 2024 07:20:33 GMT, Kim Barrett wrote:
> Thanks for reviews/responses. I'll go ahead with integration. We won't be
> reliant on the new version immediately, so we can still reconsider if it
> causes someone problems and they bring it up soon-ish.
Well, no I'm not. I d
On Thu, 15 Feb 2024 05:19:45 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of Clang
> to be used for building OpenJDK from 3.5 to 13.
>
> This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for
> that. A mini
On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of gcc
> to be used for building OpenJDK from 6.0 to 10.0.
>
> This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
> that. A minimum
On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of gcc
> to be used for building OpenJDK from 6.0 to 10.0.
>
> This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
> that. A minimum
On Mon, 4 Mar 2024 09:52:15 GMT, Aleksey Shipilev wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> respond to shipilev comments
>
> doc/hotspot-style.md line 738:
>
>> 7
On Mon, 4 Mar 2024 18:01:35 GMT, Vladimir Kozlov wrote:
>> I think it would be enough to write 1..2 sentences about this, and then
>> defer to N2431 already linked here for more details.
>
> I agree with Aleksey.
Good point. I decided just referring to the paper for rationale is sufficient.
> Please review this change to update the HotSpot Style Guide's discussion of
> nullptr and its use.
>
> I suggest this is an editorial rather than substantive change to the style
> guide. As such, the normal HotSpot PR process can be used for this change.
Kim Barrett has u
Please review this change to update the HotSpot Style Guide's discussion of
nullptr and its use.
I suggest this is an editorial rather than substantive change to the style
guide. As such, the normal HotSpot PR process can be used for this change.
-
Commit messages:
- update
On Mon, 4 Mar 2024 08:38:09 GMT, Kim Barrett wrote:
> Please review this change to update the HotSpot Style Guide's discussion of
> nullptr and its use.
>
> I suggest this is an editorial rather than substantive change to the style
> guide. As such, the normal HotSpot PR proc
On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of gcc
> to be used for building OpenJDK from 6.0 to 10.0.
>
> This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
> that. A minimum
On Thu, 15 Feb 2024 05:19:45 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of Clang
> to be used for building OpenJDK from 3.5 to 13.
>
> This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for
> that. A mini
On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++. SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
>
> I need someone f
On Wed, 14 Feb 2024 15:59:50 GMT, Kim Barrett wrote:
> I'd like to separate the version update discussions from C++17 specifics, so
> we can have focused discussions on the version choices. Of course, that's
> going to be informed by the possibility of C++17, but that's not the only
Please review this change that updates the minimum supported version of gcc
to be used for building OpenJDK from 6.0 to 10.0.
This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
that. A minimum of gcc 10 also obtains the primitives needed to support a
work-alick for
On Mon, 5 Feb 2024 21:39:06 GMT, Magnus Ihse Bursie wrote:
> Here is the full list:
> https://clang.llvm.org/docs/DiagnosticsReference.html#wpedantic
I know about that list, and that's not what I was asking for. I want to
understand the impact on *our* code. What warnings are arising from
On Thu, 15 Feb 2024 12:45:45 GMT, Thomas Stuefe wrote:
> Unfortunately this will break my workflow on Linux - I use clang to build on
> Ubuntu 20.04, which is not that old, but it ships with clang 12. This is not
> a deal breaker, just annoying.
That's unfortunate, but I think the
Please review this change that updates the minimum supported version of Clang
to be used for building OpenJDK from 3.5 to 13.
This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for
that. A minimum of Clang 13 also obtains a critical bug fix for the [[noreturn]]
attribute (see
Please review this change that updates the minimum supported version of IBM
Open XL C/C++. SAP dropped support for older versions in JDK 22, only
supporting the version specified in this change.
I need someone from the aix-ppc porters to test and review the change.
-
Commit
On Fri, 19 Jan 2024 14:04:50 GMT, Magnus Ihse Bursie wrote:
> Well, the only additional thing this PR does except raise the compiler
> version is to change the `--std` flag. It is a bit unclear what that means.
> For the JDK libraries, there are already code present that relies on C++17.
>
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 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
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
> 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`
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 m
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:
> #define DEBUG_ONLY(code) code;
>
> DEBUG_ONLY(foo());
> ```
>
> will result in a `; ;`. This breaks the C standard, but is benign, and we use
> it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but
> this is
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 Tue, 23 Jan 2024 15:37:19 GMT, Magnus Ihse Bursie wrote:
> With [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), the explicit
> addition of -D_FILE_OFFSET_BITS=64 for two hotspot files in
> JvmOverrideFiles.gmk became unnecessary.
>
> I didn't think of checking this in the
On Fri, 19 Jan 2024 10:52:40 GMT, Sam James wrote:
>> Sam James has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - sendfile64 -> sendfile
>>
>>Signed-off-by: Sam James
>> - buf64->buf
>>
>>Signed-off-by: Sam James
>
>
On Fri, 19 Jan 2024 10:30:54 GMT, Kim Barrett wrote:
> Consider (perhaps in a separate PR) forbidding the use of the xxx64
> functions, using FORBID_C_FUNCTION (from compilerWarnings.hpp ). I think
> it would be done in globalDefinitions_gcc.hpp, and probably co
On Fri, 19 Jan 2024 10:37:42 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regular
>> counterparts
On Fri, 19 Jan 2024 06:47:39 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regular
>> counterparts
On Fri, 15 Dec 2023 15:52:07 GMT, Kim Barrett wrote:
> gcc: https://gcc.gnu.org/gcc-9/changes.html
> "The C++17 implementation is no longer experimental."
Bumping to gcc10 rather than gcc9 would have the benefit that we could get a
work-alike for C++20
`std::is_constant_evalua
On Fri, 12 Jan 2024 07:49:17 GMT, Matthias Baesken wrote:
> We at SAP use and document xlC 17.1.1.4 for jdk22 (use the same for jdk23)
> https://wiki.openjdk.org/display/Build/Supported+Build+Platforms
>
> version 17.1.1.4 is already clang15 (at least that's what the compiler output
> is
On Thu, 11 Jan 2024 14:28:20 GMT, Martin Doerr wrote:
> Thanks! We may switch to clang 14 on MacOS at some point of time, but it's
> better to have that disentangled. Some people build JDK 11 and 23 on the same
> machine and that is easier if they don't have to switch Xcode.
I think the
On Wed, 10 Jan 2024 01:58:33 GMT, Kim Barrett wrote:
> Please review this change to enable -Wparentheses when building HotSpot. That
> warning is enabled by -Wall (which we use). That was overridden by explicitly
> disabling it, because there were a number of places in Hot
On Wed, 10 Jan 2024 06:20:09 GMT, David Holmes wrote:
>> Kim Barrett 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 two addi
rage for
> Oracle-supported platforms and community-supported platforms.
Kim Barrett 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 two additional co
On Thu, 11 Jan 2024 08:04:40 GMT, Julian Waters wrote:
> > Hi Martin, probably we can update our devkit if really needed. But
> > https://clang.llvm.org/cxx_status.html states that c++17 is supported for a
> > very long time, so probably clang 13.1 is sufficient too (or is there a
> > real
Please review this change to enable -Wparentheses when building HotSpot. That
warning is enabled by -Wall (which we use). That was overridden by explicitly
disabling it, because there were a number of places in HotSpot code that
triggered such warnings. Those places have all been fixed. In some
> On Jan 3, 2024, at 7:16 AM, Baesken, Matthias
> wrote:
>
> Btw. I found this rather recent discussion about reverting the forcing
> of setting -std=gnu++11 in autoconf :
>
>
> On Jan 2, 2024, at 4:19 AM, Baesken, Matthias
> wrote:
>
> Hi , was anyone seen the following issue ?
> After an update from autoconf 2.71 to 2.72 on macOS (x86_6$9 , the
> C++ flag detection changed in an unexpected way .It is an OpenJDK11 build
> .
> Previously with
On Fri, 15 Dec 2023 16:20:02 GMT, Kim Barrett 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 contai
On Fri, 15 Dec 2023 13:52:28 GMT, Martin Doerr wrote:
> In case you want to update the required compiler versions as part of this PR:
> We have tested -TOOLCHAIN_MINIMUM_VERSION_xlc="16.1.0.0011"
> +TOOLCHAIN_MINIMUM_VERSION_xlc="17.1.1.4" (Already discussed with Kim.)
Also discussed with the
On Sat, 19 Aug 2023 07:45:50 GMT, Andrew Haley wrote:
> Is it impractical to drop the obsolete features of C++11, working in the
> common subset of C++11 and C++17?
I'm not sure what is being suggested. Maybe some examples would help.
-
PR Comment:
On Fri, 15 Dec 2023 08:08:10 GMT, Julian Waters wrote:
>> Implementation of [JEP draft: Compile the JDK as
>> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
>
> Julian Waters has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes
On Fri, 15 Dec 2023 08:08:10 GMT, Julian Waters wrote:
>> Implementation of [JEP draft: Compile the JDK as
>> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
>
> Julian Waters has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes
On Fri, 15 Dec 2023 11:25:24 GMT, Julian Waters wrote:
>> Looks like this change has also already been made, by JDK-8319440.
>>
>> All of the other non-comment uses of "register" I found in HotSpot are gcc
>> local variable register specifications:
>>
On Fri, 15 Dec 2023 08:12:47 GMT, Julian Waters wrote:
>> No problem!
>
> There are, strangely, many more register keywords in the JDK codebase than
> just this one, but none of them throw the same errors, only this one does
Looks like this change has also already been made, by JDK-8319440.
On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote:
> Implementation of [JEP draft: Compile the JDK as
> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
Nearly ready. Still need to figure out the minimum compiler versions to
require.
On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeliński wrote:
> I'd like to propose a new toolchain for Windows using the clang-cl compiler
> frontend.
>
> Clang-cl is available as an optional feature in all Visual Studio editions,
> including the free-for-OSS-development community edition.
>
>
On Tue, 3 Oct 2023 07:45:42 GMT, David Holmes wrote:
>> Is Thomas around? Would like to get his opinion of what to do with this
>> particular snippet
>
> I know he was away until October but not exactly when in October.
Ick! I hadn't followed https://github.com/openjdk/jdk/pull/15096 closely,
On Mon, 2 Oct 2023 11:04:13 GMT, Daniel Jeliński wrote:
>> Please review this patch that reenables `delete-null-pointer-checks`
>> optimization in GCC and Clang.
>>
>> It also disables `nonnull-compare` warning that is now triggered in debug
>> builds. The problematic code will be addressed
On Fri, 29 Sep 2023 10:01:42 GMT, Daniel Jeliński wrote:
> Please review this patch that reenables `delete-null-pointer-checks`
> optimization in GCC and Clang.
>
> It also disables `nonnull-compare` warning that is now triggered in debug
> builds. The problematic code will be addressed by
On Tue, 19 Sep 2023 14:14:35 GMT, Antonios Printezis wrote:
>> The build failure happens when building on RISC-V with GCC 12.3. Is there a
>> better way to address this than disabling the stringop-overflow warnings for
>> the two files in question?
>
> Antonios Printezis has updated the pull
On Mon, 18 Sep 2023 19:29:14 GMT, Antonios Printezis wrote:
> How about something like this in `zPageAllocator.cpp` / `xPageAllocator.cpp`
> as a compromise?
>
> ```
> +PRAGMA_DIAG_PUSH
> +PRAGMA_STRINGOP_OVERFLOW_IGNORED
> // Record flushed pages as claimed
>
On Wed, 6 Sep 2023 14:29:56 GMT, Antonios Printezis wrote:
> The build failure happens when building on RISC-V with GCC 12.3. Is there a
> better way to address this than disabling the stringop-overflow warnings for
> the two files in question?
It seems to be complaining about atomic
On Thu, 7 Sep 2023 11:08:45 GMT, Andrew Haley wrote:
>> The build failure happens when building on RISC-V with GCC 12.3. Is there a
>> better way to address this than disabling the stringop-overflow warnings for
>> the two files in question?
>
> Just for the record, this is very likely
>
On Wed, 6 Sep 2023 14:29:56 GMT, Antonios Printezis wrote:
> The build failure happens when building on RISC-V with GCC 12.3. Is there a
> better way to address this than disabling the stringop-overflow warnings for
> the two files in question?
The fix for
On Fri, 25 Aug 2023 22:31:31 GMT, Erik Joelsson wrote:
> After [JDK-8313374](https://bugs.openjdk.org/browse/JDK-8313374), out of tree
> incremental builds with ccache started failing. The rewriting of the
> generated dependency (*.d) files creates object file paths with `/../` in
> them
On Tue, 22 Aug 2023 12:16:49 GMT, Johan Sjölen wrote:
> Hi,
>
> I'd like to propose that rvalue references and move semantics are now
> considered permitted in the style guide. This change would allow for move
> constructors to be written. This enables more performant code, if the move
> ctr
On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote:
> Implementation of [JEP draft: Compile the JDK as
> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
This change needs to be motivated. One way to do that would be to file CRs to
change the style guide to permit various features.
1 - 100 of 194 matches
Mail list logo
