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
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
> 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,
> 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
> 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
>>
>>
> 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
> 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
> 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
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 < ((
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
> 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
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
> 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
> 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
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
> 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
> 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
> 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
> 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
[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
> On Aug 24, 2016, at 5:48 AM, Erik Joelsson wrote:
>
> Hello,
>
>
> On 2016-08-23 18:12, Phil Race wrote:
>> On 08/23/2016 08:47 AM, Erik Joelsson wrote:
>>> Hello,
>>>
>>> I do agree that maintaining the list of disabled warnings will be
>>> impossible unless we have a structured way of trac
> On Jul 1, 2016, at 4:17 PM, Phil Race wrote:
>
> Hi,
>
> You have 3 reviewers (2 client, 1 build) so I am OK for this to be pushed.
> If Kim comes back with some more information the a new fix can be devised ..
http://cr.openjdk.java.net/~ysuenaga/JDK-8160294/webrev.01/
looks ok to me too.
22 matches
Mail list logo
