> On Jun 3, 2019, at 4:32 AM, Andrew Haley wrote:
>
> On 6/3/19 7:58 AM, Nick Gasson wrote:
>>
>>> If I'm reading the gcc documentation for __sync_add_and_fetch
>>> correctly, I think the following (completely untested) should work,
>>> and won't cause Andrew to (I think rightly) complain about
This is a fix for a problem brought up on this list [1]. The main issue
is that when cross compiling, and creating a buildjdk during the build,
the UnixConstants.java cannot necessarily be reused between the target
JDK and the buildjdk. While investigating this, I came to the conclusion
that we
Looks good.
/Erik
On 2019-06-03 01:36, Robin Westberg wrote:
Hi Erik,
On 31 May 2019, at 18:15, Erik Joelsson wrote:
Hello Robin,
On 2019-05-31 05:26, Robin Westberg wrote:
Hi Erik,
On 29 May 2019, at 17:22, Erik Joelsson wrote:
Thanks, looks good!
Thanks for reviewing! Unfortunately
Hi,
On 6/3/19 11:36 AM, Nick Gasson wrote:
>
>> We need to know what it's used for to know which solution is right. I'm
>> guessing the primary use case is asynchronous runtime stack probes, used
>> by debugging tools.
>>
>
> Yes, we also have os::stack_shadow_pages_available() which uses it to
Hi Andrew,
We need to know what it's used for to know which solution is right. I'm
guessing the primary use case is asynchronous runtime stack probes, used
by debugging tools.
Yes, we also have os::stack_shadow_pages_available() which uses it to
calculate how much space there is between the
On 6/3/19 10:08 AM, Nick Gasson wrote:
> Hi Andrew,
>
> On 03/06/2019 16:32, Andrew Haley wrote:
>>
>> I don't think there's any need to boycott the whole compiler because
>> of this bug. It would make more sense to try to get clang fixed.
>>
>> Maybe for now put the cast in #ifdef CLANG ?
>>
>
>
Hi Andrew,
On 03/06/2019 16:32, Andrew Haley wrote:
I don't think there's any need to boycott the whole compiler because
of this bug. It would make more sense to try to get clang fixed.
Maybe for now put the cast in #ifdef CLANG ?
I think I'd rather put the __atomic_fetch_add in an #ifdef C
Hi Erik,
> On 31 May 2019, at 18:15, Erik Joelsson wrote:
>
> Hello Robin,
>
> On 2019-05-31 05:26, Robin Westberg wrote:
>> Hi Erik,
>>
>>> On 29 May 2019, at 17:22, Erik Joelsson wrote:
>>>
>>> Thanks, looks good!
>> Thanks for reviewing! Unfortunately I had to do a few more general change
On 6/3/19 7:58 AM, Nick Gasson wrote:
>
>> If I'm reading the gcc documentation for __sync_add_and_fetch
>> correctly, I think the following (completely untested) should work,
>> and won't cause Andrew to (I think rightly) complain about
>> type-punning reinterpret_casts.
>>
>> Though I wonder if
On 3/06/2019 5:06 pm, Moshe Zuisman wrote:
Hi.
Probably I do not understand something in source control system of Open
JDK projeck.
I have gone to :
https://hg.openjdk.java.net/jdk/jdk11
and clicked last label:
"9 months ago jwilhelm Added tag jdk-11+28 for changeset
76072a077ee1default tip"
On 6/3/19 9:06 AM, Moshe Zuisman wrote:
> I have gone to : https://hg.openjdk.java.net/jdk/jdk11
That is not the latest jdk11 source. It is a stabilization tree for jdk11 GA --
notice the last
commit there.
Up-to-date 11u tree is here:
http://hg.openjdk.java.net/jdk-updates/jdk11u
-Aleksey
Hi.
Probably I do not understand something in source control system of Open JDK
projeck.
I have gone to :
https://hg.openjdk.java.net/jdk/jdk11
and clicked last label:
"9 months ago jwilhelm Added tag jdk-11+28 for changeset
76072a077ee1default tip"
arrived to:
https://hg.openjdk.java.net/jdk/jdk11
Hi Kim,
> If I'm reading the gcc documentation for __sync_add_and_fetch
> correctly, I think the following (completely untested) should work,
> and won't cause Andrew to (I think rightly) complain about
> type-punning reinterpret_casts.
>
> Though I wonder if this is a clang bug. (See below.)
>
>
13 matches
Mail list logo
