Re: RFR: 8286562: GCC 12 reports some compiler warnings [v10]

On Thu, 26 May 2022 10:55:28 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 >> on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should >> separate them by area. >> >> * -Wstringop-overflow >> *

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v9]

On Wed, 25 May 2022 09:16:43 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 >> on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should >> separate them by area. >> >> * -Wstringop-overflow >> *

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]

On Sun, 22 May 2022 16:45:11 GMT, Kim Barrett wrote: >> It might be GCC bug... >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 >> >> This issue is for integer literal, but [Comment >> 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) m

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v8]

On Sun, 22 May 2022 08:40:28 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 >> on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should >> separate them by area. >> >> * -Wstringop-overflow >> *

Integrated: 8286262: Windows: Cleanup deprecation warning suppression

On Sun, 15 May 2022 20:50:25 GMT, Kim Barrett wrote: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot >

Re: RFR: 8286262: Windows: Cleanup deprecation warning suppression [v2]

latter). But it might be better to not supress the > warnings and instead use the alternatives (JDK-8286781). > > Testing: > mach5 tier1 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

Re: RFR: 8286262: Windows: Cleanup deprecation warning suppression

On Tue, 17 May 2022 06:30:03 GMT, David Holmes wrote: >> Please review this cleanup of deprecation warning suppression when building >> for Windows. >> >> This change consists of several parts. >> >> (1) Remove the global deprecation warning suppression when building HotSpot >> for Windows. >>

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]

On Sun, 22 May 2022 08:45:48 GMT, Yasumasa Suenaga wrote: >> I don't think this warning has anything to do with that NULL check. But I'm >> still not understanding what it is warning about. The "region of size 0" part >> of the warning message seems important, but I'm not (yet?) seeing how it >>

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]

On Sun, 22 May 2022 08:35:54 GMT, Yasumasa Suenaga wrote: >> `Array::_data` is a pseudo flexible array member. "Pseudo" because C++ >> doesn't have flexible array members. The compiler is completely justified in >> complaining about the apparently out-of-bounds accesses. >> >> There is a "well-k

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]

On Tue, 17 May 2022 12:43:02 GMT, Yasumasa Suenaga wrote: >> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> line 103: >> >>> 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED >>> 102: *dest = op(bits, *dest); >>> 103: PRAGMA_DIAG_POP >> >> I see no stringop here. I

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]

On Tue, 17 May 2022 12:38:55 GMT, Yasumasa Suenaga wrote: >> src/hotspot/share/classfile/classFileParser.cpp line 5970: >> >>> 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED >>> 5969: _cp->symbol_at_put(hidden_index, _class_name); >>> 5970: PRAGMA_DIAG_POP >> >> I don't understand these warning suppr

Re: RFR: 8286262: Windows: Cleanup deprecation warning suppression

On Tue, 17 May 2022 06:30:03 GMT, David Holmes wrote: > Sorry Kim I'm having trouble seeing what change corresponds to (1) ?? The change to CompileJvm.gmk, removing 4996 (deprecation warnings) from the list of disabled warnings. > Also the PR talks only about hotspot, but you're changing the JD

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]

On Tue, 17 May 2022 03:05:09 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/sh

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v5]

On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 >> on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should >> separate them by area. >> >> * -Wstringop-overflow >> *

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v4]

On Thu, 12 May 2022 18:28:02 GMT, Kim Barrett wrote: >> Thanks for all to review this PR! I think we should separate this issue as >> following: >> >> * Suppress warnings >> * make/modules/java.desktop/lib/Awt2dLibraries.gmk >> * src/hotspot/s

RFR: 8286262: Windows: Cleanup deprecation warning suppression

Please review this cleanup of deprecation warning suppression when building for Windows. This change consists of several parts. (1) Remove the global deprecation warning suppression when building HotSpot for Windows. (2) Add macro definitions requesting suppression of selected sets of deprecatio

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v4]

On Thu, 12 May 2022 01:29:13 GMT, Yasumasa Suenaga wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Calculate char offset before realloc() > > Thanks for all to review this PR! I think we should separate this is

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v2]

On Wed, 11 May 2022 13:56:44 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/java.base/share/native/libjl

Re: RFR: 8286562: GCC 12 reports some compiler warnings [v2]

On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 >> on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should >> separate them by area. >> >> * -Wstringop-overflow >> *

Re: RFR: 8204541: Correctly support AIX xlC 16.1 symbol visibility flags [v2]

> On Mar 18, 2022, at 4:11 AM, Thomas Stuefe wrote: > > On Fri, 18 Mar 2022 08:03:11 GMT, Ichiroh Takiguchi > wrote: > >>> This change is just for AIX platform with IBM XL C/C++ 16.1. >>> By this change, lib's entry points are reduced by compilation and linkage >>> option changes. >>> >>> Wi

Re: RFR: 8253495: CDS generates non-deterministic output [v6]

On Fri, 11 Mar 2022 06:55:23 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments >> in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry

Re: RFR: 8253495: CDS generates non-deterministic output [v4]

On Fri, 11 Mar 2022 04:56:23 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments >> in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry

RFR: 8257589: HotSpot Style Guide should link to rfc7282

Please review this change to the link for the definition of "rough consensus". The current link is to a Wikipedia article that references rfc7282. We should instead link directly the the RFC. This change was requested during the review of JDK-8247976, but not made at that time. (I'm not sure whet

RFR: 8252577: HotSpot Style Guide should link to One-True-Brace-Style description

Please review this change to provide a link to the Wikipedia description of One-True-Brace-Style. As this is a HotSpot Style Guide change, it requires reviewers who are HotSpot Group Members, though comments from others are welcome. - Commit messages: - update html - add OTBS link

RFR: 8280916: Simplify HotSpot Style Guide editorial changes

Please review this change to the HotSpot Style Guide change process. The current process involves gathering consensus among the HotSpot Group Members. That's fine for changes of substance. But it seems overly weighty for editorial changes that don't affect the substance of the guide, but only it

Withdrawn: 8280916: Simplify HotSpot Style Guide editorial changes

On Sun, 30 Jan 2022 00:28:59 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide change process. > > The current process involves gathering consensus among the HotSpot Group > Members. That's fine for changes of substance. But it seems overly weight

Re: RFR: 8280916: Simplify HotSpot Style Guide editorial changes

On Sun, 30 Jan 2022 00:28:59 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide change process. > > The current process involves gathering consensus among the HotSpot Group > Members. That's fine for changes of substance. But it seems overly weight

RFR: 8280916: Simplify HotSpot Style Guide editorial changes

Please review this change to the HotSpot Style Guide change process. The current process involves gathering consensus among the HotSpot Group Members. That's fine for changes of substance. But it seems overly weighty for editorial changes that don't affect the substance of the guide, but only it

Re: RFR: 8280182: HotSpot Style Guide has stale link to chromium style guide

On Tue, 18 Jan 2022 23:09:12 GMT, Liam Miller-Cushon wrote: > Update links to the chromium style guide in the HotSpot Style Guide. The current change process for the style guide requires voting by HotSpot group members and a decision by the group lead (Vladimir). That seems overly heavyweight fo

Re: RFR: JDK-8276422 Add command-line option to disable finalization

On Thu, 18 Nov 2021 01:34:36 GMT, Stuart Marks wrote: > Pretty much what it says. The new option controls a static member in > InstanceKlass that's consulted to determine whether the finalization > machinery is activated for instances when a class is loaded. A new native > method is added so t

Re: RFR: JDK-8276422 Add command-line option to disable finalization

On Thu, 18 Nov 2021 06:43:01 GMT, Kim Barrett wrote: >> Pretty much what it says. The new option controls a static member in >> InstanceKlass that's consulted to determine whether the finalization >> machinery is activated for instances when a class is loaded. A new nat

Re: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1

On Fri, 9 Jul 2021 00:28:38 GMT, Yasumasa Suenaga wrote: > It is better if we can treat registers as a class **normally**. Similar > change happens for markWord in > [JDK-8229258](https://bugs.openjdk.java.net/browse/JDK-8229258). Should we > change like now? The potential difficulty with doi

Re: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1

On Thu, 8 Jul 2021 09:42:43 GMT, Yasumasa Suenaga wrote: > I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but > I saw following errors: > > > In file included from > /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, > fr

Re: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1

On Thu, 8 Jul 2021 09:42:43 GMT, Yasumasa Suenaga wrote: > I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but > I saw following errors: > > > In file included from > /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, > fr

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v5]

On Mon, 11 Jan 2021 02:14:17 GMT, Hao Sun wrote: >> 1. '-Wdeprecated-copy' >> As specified in C++11 [1], "the generation of the implicitly-defined >> copy constructor is deprecated if T has a user-defined destructor or >> user-defined copy assignment operator". The rationale behind is the >> wel

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy [v4]

On Wed, 6 Jan 2021 06:14:11 GMT, Hao Sun wrote: >> 1. '-Wdeprecated-copy' >> As specified in C++11 [1], "the generation of the implicitly-defined >> copy constructor is deprecated if T has a user-defined destructor or >> user-defined copy assignment operator". The rationale behind is the >> well

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2]

On Mon, 4 Jan 2021 06:59:54 GMT, Hao Sun wrote: >> src/hotspot/share/opto/node.hpp line 1396: >> >>> 1394: >>> 1395: DUIterator_Fast(const DUIterator_Fast& that) >>> 1396: { _outp = that._outp; debug_only(reset(that)); } >> >> `reset` tests `_vdui`, but nothing here has se

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2]

> On Jan 3, 2021, at 11:33 PM, Hao Sun > wrote: > > On Mon, 4 Jan 2021 01:18:47 GMT, Hao Sun > wrote: > >>>> _Mailing list message from [Kim Barrett](mailto:kim.barr...@oracle.com) on >>>> [build-dev](mailto:build-dev@openjdk.java.net):_ >> &

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2]

On Mon, 28 Dec 2020 10:28:09 GMT, Hao Sun wrote: >> 1. '-Wdeprecated-copy' >> As specified in C++11 [1], "the generation of the implicitly-defined >> copy constructor is deprecated if T has a user-defined destructor or >> user-defined copy assignment operator". The rationale behind is the >> wel

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2]

> On Jan 2, 2021, at 11:17 PM, Kim Barrett wrote: > >> On Dec 29, 2020, at 10:33 PM, Hao Sun >> wrote: >> >>> _Mailing list message from [Kim Barrett](mailto:kim.barr...@oracle.com) on >>> [build-dev](mailto:build-dev@openjdk.java.net):_ >

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2]

> On Dec 29, 2020, at 10:33 PM, Hao Sun > wrote: > >> _Mailing list message from [Kim Barrett](mailto:kim.barr...@oracle.com) on >> [build-dev](mailto:build-dev@openjdk.java.net):_ >> >> >> C++17 "guaranteed copy elision" is implemented in gcc

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion

> On Dec 24, 2020, at 3:44 PM, Xin Liu wrote: > > On Thu, 24 Dec 2020 17:27:39 GMT, Kim Barrett wrote: >> […] >> Since DUIterator_Last is just delegating both the copy constructor and >> assignment operator to the base class, their copy constructor and >> assig

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion

> On Dec 22, 2020, at 8:52 PM, Hao Sun > wrote: > > 1. '-Wdeprecated-copy' > As specified in C++11 [1], "the generation of the implicitly-defined > copy constructor is deprecated if T has a user-defined destructor or > user-defined copy assignment operator". The rationale behind is the > well-kn

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion

On Wed, 23 Dec 2020 01:45:58 GMT, Hao Sun wrote: > 1. '-Wdeprecated-copy' > As specified in C++11 [1], "the generation of the implicitly-defined > copy constructor is deprecated if T has a user-defined destructor or > user-defined copy assignment operator". The rationale behind is the > well-kno

Re: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion

On Wed, 23 Dec 2020 01:45:58 GMT, Hao Sun wrote: > 1. '-Wdeprecated-copy' > As specified in C++11 [1], "the generation of the implicitly-defined > copy constructor is deprecated if T has a user-defined destructor or > user-defined copy assignment operator". The rationale behind is the > well-kno

Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v11]

On Wed, 18 Nov 2020 19:31:44 GMT, Serguei Spitsyn wrote: > test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.cpp: > > The change below is not needed as the call to > nsk_jvmti_aod_disableEventAndFinish() does exactly the same: > > ``` > -nsk_jvmti_aod_disabl

Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v11]

On Mon, 16 Nov 2020 23:30:25 GMT, Coleen Phillimore wrote: >> This change turns the HashTable that JVMTI uses for object tagging into a >> regular Hotspot hashtable - the one in hashtable.hpp with resizing and >> rehashing. Instead of pointing directly to oops so that GC has to walk the >> t

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]

On Wed, 4 Nov 2020 09:31:13 GMT, Tagir F. Valeev wrote: > Hello! > > As an IDE developer, I'm thinking about IDE inspection that may suggest the > new method. My idea is to suggest replacing every `ref.get() == obj` with > `ref.refersTo(obj)`. Is this a good idea or there are cases when `ref.g

Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v4]

On Tue, 3 Nov 2020 21:40:39 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvmtiTagMap.cpp line 127: >> >>> 125: // The table cleaning, posting and rehashing can race for >>> 126: // concurrent GCs. So fix it here once we have a lock or are >>> 127: // at a safepoint. >> >> I th

Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v4]

On Wed, 4 Nov 2020 07:52:12 GMT, Kim Barrett wrote: >> So the design is that when the oops have new addresses, we set a flag in the >> table to rehash it. Not sure why this is wrong and why wouldn't it work for >> shenandoah? @zhengyu123 ? When we call WeakHandle

Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v5]

On Wed, 4 Nov 2020 00:08:10 GMT, Coleen Phillimore wrote: >> This change turns the HashTable that JVMTI uses for object tagging into a >> regular Hotspot hashtable - the one in hashtable.hpp with resizing and >> rehashing. Instead of pointing directly to oops so that GC has to walk the >> ta

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]

On Wed, 4 Nov 2020 09:31:13 GMT, Tagir F. Valeev wrote: >> The API looks good, thanks for getting this in. > > Hello! > > As an IDE developer, I'm thinking about IDE inspection that may suggest the > new method. My idea is to suggest replacing every `ref.get() == obj` with > `ref.refersTo(obj)

Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v3]

On Wed, 4 Nov 2020 07:41:39 GMT, Kim Barrett wrote: >>>Though it might be possible to go even further and eliminate >>>WeakProcessorPhases as a thing separate from OopStorageSet. >> >> This makes sense. Can we file another RFE for this? I was sort of surp

Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v4]

On Tue, 3 Nov 2020 21:31:35 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvmtiTagMap.cpp line 2979: >> >>> 2977: >>> 2978: // Concurrent GC needs to call this in relocation pause, so after the >>> objects are moved >>> 2979: // and have their new addresses, the table can be rehashe

Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v3]

On Tue, 3 Nov 2020 23:38:08 GMT, Coleen Phillimore wrote: >> Ok, so I'm not sure what to do with this: >> >> enum Phase { >> // Serial phase. >> JVMTI_ONLY(jvmti) >> // Additional implicit phase values follow for oopstorages. >> `};` >> >> I've removed the only thing in this enu

Integrated: 8188055: (ref) Add Reference::refersTo predicate

On Sun, 4 Oct 2020 03:59:59 GMT, Kim Barrett wrote: > Finally returning to this review that was started in April 2020. I've > recast it as a github PR. I think the security concern raised by Gil > has been adequately answered. > https://mail.openjdk.java.net/pipermail/hotspot-

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v7]

plitting avoids that complexity. > > Testing: > mach5 tier1 > Locally (linux-x64) verified the new test passes with various garbage > collectors. Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes t

Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v4]

On Tue, 3 Nov 2020 14:53:12 GMT, Coleen Phillimore wrote: >> This change turns the HashTable that JVMTI uses for object tagging into a >> regular Hotspot hashtable - the one in hashtable.hpp with resizing and >> rehashing. Instead of pointing directly to oops so that GC has to walk the >> ta

Re: RFR: 8212879: Make JVMTI TagMap table concurrent [v3]

On Tue, 3 Nov 2020 12:58:22 GMT, Coleen Phillimore wrote: >> This change turns the HashTable that JVMTI uses for object tagging into a >> regular Hotspot hashtable - the one in hashtable.hpp with resizing and >> rehashing. Instead of pointing directly to oops so that GC has to walk the >> ta

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]

On Fri, 16 Oct 2020 19:22:16 GMT, Mandy Chung wrote: >> I just want to note that if you have a `Reference ref` at hand, >> you can not just do: >> Referemce r = (Reference) ref; >> ...since those generic types are not related. You have to do something like: >> >> @SuppressWarnings({"unchecked",

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]

plitting avoids that complexity. > > Testing: > mach5 tier1 > Locally (linux-x64) verified the new test passes with various garbage > collectors. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: improv

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]

On Tue, 20 Oct 2020 16:35:02 GMT, Mandy Chung wrote: >>> @kimbarrett your reworded text is okay. I think "if it initially had some >>> other referent value" can be dropped. >>> >>> For a `Reference` constructed with a `null` referent, we can clarify in the >>> spec that such reference object w

Re: RFR: 8252407: Build failure with gcc-8+ and asan.

On Mon, 12 Oct 2020 11:36:17 GMT, eric.1iu wrote: > Summary: Fix stringop-truncation warnings casused by gcc. > > The newer gcc(gcc-8 or higher) would warn for calls to bounded string > manipulation functions such as 'strncpy' that may either truncate the > copied string or leave the destinatio

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2]

to take the address in the reference. That is, without changing `(relocInfo*)locs_buf` to `(relocInfo*)&locs_buf`. That second change is in the PR. > You will have to use a union (option (2) as proposed by Kim Barrett far > above. I proved that variant compiles on my > machine. > > - > > Changes requested by lucy (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/348

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2]

On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev > excludes the unre

Re: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

> On Sep 29, 2020, at 10:18 AM, Hohensee, Paul wrote: > Code that calls initialize_shared_locs is inconsistent even within itself. > E.g., in c1_Compilation.cpp, we have Agreed there seems to be a bit of a mess around that function. > Anyway, I just wanted to make the compiler warning go away,

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

> On Sep 29, 2020, at 3:59 AM, Matthias Baesken > wrote: > > On Fri, 25 Sep 2020 02:23:07 GMT, David Holmes wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/hotspot/share/runtime/sharedRuntime.cpp line 2851: >> >>> 2849

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

> On Sep 29, 2020, at 3:14 AM, Matthias Baesken > wrote: > > On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >>

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

> On Sep 25, 2020, at 6:22 AM, Lutz Schmidt wrote: > > On Fri, 25 Sep 2020 05:46:08 GMT, Kim Barrett wrote: > > Another note, actually, it's more like a question: > Has anyone had an eye on what happens in initialize_shared_locs(relocInfo* > buf, int length)? T

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

> On Sep 25, 2020, at 1:49 AM, Kim Barrett wrote: > > On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > […] > > I think changing the

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

> On Sep 25, 2020, at 1:49 AM, Kim Barrett wrote: > > On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul [I tried submitting this comment through the gi

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: > 127: NSColor* result = nil; > 128: > 129: if (colorIndex < ((

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul No, don't do this. In the original, double is used to obtain the desired alignmnent. Changing the element type to short reduces the alignment re

Re: RFR: 8250876: Build system preparation to macos on aarch64

> On Aug 13, 2020, at 6:54 AM, Magnus Ihse Bursie > wrote: > > On 2020-08-13 09:15, Kim Barrett wrote: >> I'm similarly surprised by this pre-existing bit in CoreLibraries.gmk: >> >> $(eval $(call SetupJdkLibrary, BUILD_LIBJIMAGE, \ >> ..

Re: RFR: 8250876: Build system preparation to macos on aarch64

> On Aug 13, 2020, at 3:15 AM, Kim Barrett wrote: > >> On Aug 1, 2020, at 3:24 AM, Vladimir Kempik wrote: >> >> Hello >> >> Please review this change for JDK-8250876 >> >> This changeset adds support for macos/aarch64 into build system. &g

Re: RFR: 8250876: Build system preparation to macos on aarch64

> On Aug 1, 2020, at 3:24 AM, Vladimir Kempik wrote: > > Hello > > Please review this change for JDK-8250876 > > This changeset adds support for macos/aarch64 into build system. > It will allow to crosscompile for macos/aarch64 using intel mac as well. > > This changeset does NOT address some

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

> On Jul 7, 2020, at 9:59 AM, Erik Joelsson wrote: > > Doc changes look good. > > /Erik > > On 2020-07-06 18:10, Kim Barrett wrote: >> I just noticed that doc/building.{md,html} describes minimum toolchain >> versions, >> so also needs to be updated. He

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

I just noticed that doc/building.{md,html} describes minimum toolchain versions, so also needs to be updated. Here’s the update, matching what’s now in the JEP: full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/ incr: https://cr.openjdk.java.net/~kbarrett/8246032/open.05.inc/ I also de

Re: RFR: JDK-8248548 Use DISABLED_WARNINGS for globally disabled warnings on Visual Studio in Hotspot

> On Jun 30, 2020, at 6:08 AM, Magnus Ihse Bursie > wrote: > > Currently hotspot/share/utilities/globalDefinitions_visCPP.hpp contains a lot > of #pragma warning( disable : ...). > > All these globally disabled warnings should move to the make files instead. > > I also cleaned out some versio

Re: RFR: JDK-8248548 Use DISABLED_WARNINGS for globally disabled warnings on Visual Studio in Hotspot

> On Jun 30, 2020, at 6:48 AM, Magnus Ihse Bursie > wrote: > > On 2020-06-30 12:32, Kim Barrett wrote: >>> On Jun 30, 2020, at 6:08 AM, Magnus Ihse Bursie >>> wrote: >>> >>> Currently hotspot/share/utilities/globalDefinitions_visCPP.hpp

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

> On Jun 24, 2020, at 7:01 AM, Magnus Ihse Bursie > wrote: > > On 2020-06-18 08:34, Kim Barrett wrote: >>> On Jun 15, 2020, at 7:41 AM, Kim Barrett wrote: >>> >>>> On Jun 14, 2020, at 12:45 AM, Philip Race wrote: >>>> >>>> Ki

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

> On Jun 15, 2020, at 7:41 AM, Kim Barrett wrote: > >> On Jun 14, 2020, at 12:45 AM, Philip Race wrote: >> >> Kim, >> >> >> Until it says in "the JDK" and not "in HotSpot" you have not addressed my >> main point. >&g

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

to require at least a major ABI change, and at the time the JEP was created there was no path to C++14 for the AIX/PPC port; both of those needed visibility and discussion that seemed best provided via the JEP process. > -phil. > > On 6/13/20, 8:48 PM, Kim Barrett wrote: >>> On Jun

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

> On Jun 10, 2020, at 2:26 AM, Kim Barrett wrote: > >> On Jun 8, 2020, at 4:07 PM, Philip Race wrote: > >> BTW the JEP (https://bugs.openjdk.java.net/browse/JDK-8208089) still says >>> For Solaris: Add the -std=c++14 compiler option. . >> >> So I

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

> On Jun 8, 2020, at 4:07 PM, Philip Race wrote: > > Hi Kim, > > Can we amend the JEP itself to be not solely about hotspot. > Since it affects other areas I think that > 1) They may need to be compiled with C++14 enabled whether they use new > features or not > 2) They may want - or need - to

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

> On Jun 5, 2020, at 7:57 PM, Magnus Ihse Bursie > wrote: > > On 2020-06-05 09:52, Kim Barrett wrote: >> [Changes are only to the build system, but since the changes have jdk-wide >> effect I’ve cc’d what I think are the relevant dev lists.] >> >> This chan

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

> On Jun 5, 2020, at 7:57 PM, Magnus Ihse Bursie > wrote: > > On 2020-06-05 13:59, Jim Laskey wrote: >> I know there was a discussion about this elsewhere but I would like to take >> the opportunity to correct this now >> >> make//autoconf/flags-cflags.m4:241 >> >> […] >> MacOSX has been payi

Re: RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

> On Jun 5, 2020, at 9:34 AM, Doerr, Martin wrote: > > Hi Kim, > > builds out of the box on AIX with IBM XL C/C++ for AIX, V16.1.0 (We already > use clang frontend by default.) > Very cool! Thanks for taking it for a spin.

RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Changes are only to the build system, but since the changes have jdk-wide effect I’ve cc’d what I think are the relevant dev lists.] This change is part of JEP 347; the intent is to target JDK 16. Please review this change to the building of C++ code in the JDK to enable the use of C++14 languag

Re: RFR: 8240259: Disable -Wshift-negative-value warnings

> On May 22, 2020, at 3:38 AM, Magnus Ihse Bursie > wrote: > > Looks good to me. Thanks. > > /Magnus > > On 2020-05-22 03:54, Kim Barrett wrote: >> Please review this change which disables warnings for left shift of a >> negative value when compiling HotS

RFR: 8240259: Disable -Wshift-negative-value warnings

Please review this change which disables warnings for left shift of a negative value when compiling HotSpot with gcc or clang. This warning isn't helpful, given that all compilers seem to do the obvious thing, and that obvious thing will soon-ish (C++20) be the specified thing. See the CR for more

Re: RFR: JDK-8244653 Suppress gcc 9.1 ABI change notes on aarch64

> On May 8, 2020, at 7:12 AM, Magnus Ihse Bursie > wrote: > > When building HotSpot with gcc9.x for aarch64, there are a couple of places > that trigger a "warning" (technically a "note") about an ABI change from > earlier versions. The message is > > : note: parameter passing for argument o

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

> On May 6, 2020, at 8:47 PM, Mikael Vidstedt > wrote: > > > New webrev available here: > > webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build/open/webrev/ > > > incremental: > http:

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

> On May 4, 2020, at 1:12 AM, Mikael Vidstedt > wrote: > > > Please review this change which implements part of JEP 381: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/build/open/webrev/ > JEP: https://bugs.op

Re: RFR: 8239357: Revert gcc implementation of offset_of

> On Apr 22, 2020, at 9:28 AM, Erik Joelsson wrote: > > Build change looks good. Thanks. > > /Erik > > On 2020-04-22 06:23, Kim Barrett wrote: >> Please review this change to undo the (small) portion of JDK-8238281 >> [1] related to the HotSpot offset_of

Re: RFR: 8239357: Revert gcc implementation of offset_of

> On Apr 22, 2020, at 9:57 AM, Magnus Ihse Bursie > wrote: > > On 2020-04-22 15:23, Kim Barrett wrote: >> Please review this change to undo the (small) portion of JDK-8238281 >> [1] related to the HotSpot offset_of macro for gcc/clang. That change >> should n

Re: RFR: 8239357: Revert gcc implementation of offset_of

> On Apr 22, 2020, at 10:33 PM, David Holmes wrote: > > On 22/04/2020 11:23 pm, Kim Barrett wrote: >> Please review this change to undo the (small) portion of JDK-8238281 >> [1] related to the HotSpot offset_of macro for gcc/clang. That change >> should not have bee

RFR: 8239357: Revert gcc implementation of offset_of

Please review this change to undo the (small) portion of JDK-8238281 [1] related to the HotSpot offset_of macro for gcc/clang. That change should not have been made. See CR for details. I did not reinstate the redefinition of offsetof; we shouldn't be using that macro, and having the warning ena

Re: RFR: JDK-8240224 Allow building hotspot without the serial gc

> On Mar 10, 2020, at 10:51 AM, Magnus Ihse Bursie > wrote: >>> Nits: >>> >>> *) src/hotspot/share/gc/shared/gcConfig.cpp changes are a bit strange: >>> - Epsilon should not ever be selected by ergonomics >>> - Why ZGC is selected before Shenandoah? [Oh, what a can of worms that >>> one is

Re: RFR: JDK-8240224 Allow building hotspot without the serial gc

> On Mar 10, 2020, at 7:22 PM, David Holmes wrote: > Also I'm not at all clear what happens if the only GC configured is one of > the experimental GCs for which we would normally have to set > -XX:+UnlockExperimentalVMOptions ?? Yes, it seems wrong to ever select an experimental GC by default.

  1   2   3   >