2d-...@openjdk.java.net>; Brian Burkhalter
> ; build-dev ; core-
> libs-dev ; Philip Race
>
> Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
> zLinux
>
> Thanks Magnus,
>
> Hi Goetz, we have agreement from both library owners, so I think w
From: Magnus Ihse Bursie
To: Andrew Leonard
Cc: Brian Burkhalter , 2d-dev
<2d-...@openjdk.java.net>, build-dev ,
core-libs-dev , "Lindenmaier, Goetz"
, Philip Race
Date: 04/09/2018 16:41
Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler
errors on zLinu
d & emask) | (da[0] &~ emask);
> }
>
>
>
>
>
>
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: andrew_m_leon...@uk.ibm.com
&
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com
From: Brian Burkhalter
To: Magnus Ihse Bursie
Cc: Andrew Leonard , "Lindenmaier, Goetz"
, 2d-dev <2d-...@openjdk.java.net>, build-dev
, core-libs-dev
On Aug 31, 2018, at 2:28 AM, Magnus Ihse Bursie
wrote:
>> Magnus, Philip, Brian, Goetz, can we have a vote? => "Fix" or
>> "DisableWarnings" ?
>
> Note that this decision can be different for the two libraries. I'd argue
> that the maintainer of each library decides. And if so, it seems to
o: Philip Race , Brian Burkhalter
Cc: 2d-dev <2d-...@openjdk.java.net>, build-dev
, Andrew Leonard
, core-libs-dev
Date: 31/08/2018 09:27
Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors
on zLinux
net email: andrew_m_leon...@uk.ibm.com
From: Magnus Ihse Bursie
To: Philip Race , Brian Burkhalter
Cc: 2d-dev <2d-...@openjdk.java.net>, build-dev
, Andrew Leonard
, core-libs-dev
Date: 31/08/2018 09:27
Subject:Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 com
On 2018-08-31 01:28, Philip Race wrote:
Some day, I'd like to replace a lot of medialib functionality with
something
like the proposed Vector API. But that is far enough away that
medialib needs
to be maintained, and unlike a previous discussion about a similar
issue in
the JPEG library, we ar
Some day, I'd like to replace a lot of medialib functionality with something
like the proposed Vector API. But that is far enough away that medialib
needs
to be maintained, and unlike a previous discussion about a similar issue in
the JPEG library, we are on the hook for maintaining medialib.
So
