Compiling OpenJDK8 with LLVM for mips64el

[Leslie Zhai]

Hi all,

Thanks for Aleksandar Beserminji great job:

https://reviews.llvm.org/D50437

It is not easy to reproduce the LLVMBUG-38221[1] by building OpenJDK8,  
it needs some workaround


https://raw.githubusercontent.com/xiangzhai/jdk8u-dev/master/Workaround-compile-with-llvm.patch

LLVM toolchain[2] is just able to compile OpenJDK8 for mips64el now:

http://hg.loongnix.org/

1. https://bugs.llvm.org/show_bug.cgi?id=38221#c10

2. $ clang -v
Loongson clang version 8.0.0 (g...@github.com:llvm-mirror/clang.git 
56fc90882612ab774dae937ca8d997c59364f7f8) 
(g...@github.com:llvm-mirror/llvm.git 
3419b04cf0c0a57577865f0d17fefb205deed048) (based on LLVM 8.0.0svn)

Target: mips64el-redhat-linux
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: 
/usr/bin/../lib/gcc/mips64el-redhat-linux/4.9.3

Found candidate GCC installation: /usr/lib/gcc/mips64el-redhat-linux/4.9.3
Selected GCC installation: /usr/bin/../lib/gcc/mips64el-redhat-linux/4.9.3
Candidate multilib: .;
Selected multilib: .;

--

Regards,
Leslie Zhai

Re: Linux + Clang + execstack

[Mikael Vidstedt]

> On Sep 4, 2018, at 7:06 PM, Martin Buchholz  wrote:
> 
> Here's Arthur's patch:
> 
> 8205457: gcc and clang should use the same ld flags
> http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/
> https://bugs.openjdk.java.net/browse/JDK-8205457
> 
> This applies -Wl,-z,noexecstack uniformly to all linker invocations where
> applicable.
> 
> TODO:
> All ld flags on Linux should be treated equally by gcc and clang
> The test TestCheckJDK and supporting infrastructure should stop advertising
> itself as only dealing with libraries.
> Maybe add GNU-stack annotations to all the Linux .s files as well?

I like to think that our .s files are effectively incomplete, and that adding 
the annotations makes them less incomplete. I am, however, not emotionally 
attached to this so I’ll leave it up to you and others to decide what to do 
with it :)

(it would also be interesting to see if we can perhaps move some of the .s code 
to C++ instead)

Cheers,
Mikael

> 
> 
> On Tue, Sep 4, 2018 at 4:01 PM, Martin Buchholz  wrote:
> 
>> I think we can all agree that passing flags to the linker to ensure
>> non-executable stack is the right thing to do.  But there's a question
>> whether *also* adding something to our assembly language source files will
>> be worth doing.  Neither mechanism is sure to work.  For the linker flag,
>> we need to be aware of and test for the presence of the linker flag, but we
>> might be using some other linker... Similarly, we might end up using some
>> other assembler, or we might need to mark the assembly source file in a
>> different way than "GNU-stack".
>> 
>> On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie <
>> magnus.ihse.bur...@oracle.com> wrote:
>> 
>>> On 2018-08-21 02:03, David Holmes wrote:
>>> 
 On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
 
> On Mon, Aug 20, 2018 at 4:18 PM David Holmes  > wrote:
> 
>Hi Arthur,
> 
>cc'ing build-dev as this is currently a build issue.
> 
>On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
>> Hi,
>> 
>> At Google we're trying to build hotspot on Linux with clang. One
>thing that
>> happens is that the resulting libjvm.so is stack executable. When
>running
>> hotspot we get warnings about the stack being executable.
>> 
>> Compiling an assembly file into the final .so results in the
>stack being
>> executable. In this case the file is linux_x86_64.s. This doesn't
>happen
>> with gcc because "-Wl,-z,noexecstack" is passed as a hotspot
>linker flag
>> with gcc in flags-ldflags.m4. When using clang that linker flag
> isn't
>> passed.
>> 
>> Doing something like the solution in
>> https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
>> fixes the problem without the use of linker flags.
> 
>You mean the source code directives for the linker?
> 
> Sorry, I wasn't specific enough, I meant the flags for the assembler.
> #if defined(__linux__) && defined(__ELF__)
> .section.note.GNU-stack, "", %progbits
> #endif
> 
> 
>I think I prefer to see this handled explicitly in the build as is
>currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4
> to
>pass the linker flags for gcc and clang?
> 
> I don't mind this solution, but it seems like the right thing to do is
> to fix things at the source level and remove extra unnecessary linker 
> flags.
> 
 
 Personally I see this as source code pollution. The concept of
 executable stacks has nothing to do with what is being expressed by the
 source code, or the language used for it.
 
 Just my 2c. I'll defer to build folk ... though they are still on
 vacation at the moment.
 
>>> 
>>> I agree with David. The executable stack is a build option. Even if you
>>> change the source code so the compiler/assember does the right thing, we
>>> would still want to keep the compiler option. (Otherwise one day you'll end
>>> up with executable stacks due to someone adding a new asm file and
>>> forgetting the "magic incantation".)
>>> 
>>> And, since we will keep the compiler option, there seems little point in
>>> also adding this stuff to the asm files.
>>> 
>>> To address your concerns on clang: we should reasonably be giving the
>>> same options to clang. There is no good reason, except for oversight, that
>>> this is not done already. (Cleaning up and unifying the compiler flags is
>>> an ongoing, but slowly moving, process.) So the correct fix is to update
>>> flags-ldflags.m4.
>>> 
>>> /Magnus
>>> 
>>> 
>>> 
>>> 
>>> 
 I removed "-Wl,-z,noexecstack" from the flags after adding the above
> assembler flags and libjvm.so is still correctly not stack executable. I
> don't really mind either way though. Maybe it's good to have an extra
> safeguard in the linker flags.
> 

Re: Linux + Clang + execstack

[Martin Buchholz]

Here's Arthur's patch:

8205457: gcc and clang should use the same ld flags
http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/
https://bugs.openjdk.java.net/browse/JDK-8205457

This applies -Wl,-z,noexecstack uniformly to all linker invocations where
applicable.

TODO:
All ld flags on Linux should be treated equally by gcc and clang
The test TestCheckJDK and supporting infrastructure should stop advertising
itself as only dealing with libraries.
Maybe add GNU-stack annotations to all the Linux .s files as well?


On Tue, Sep 4, 2018 at 4:01 PM, Martin Buchholz  wrote:

> I think we can all agree that passing flags to the linker to ensure
> non-executable stack is the right thing to do.  But there's a question
> whether *also* adding something to our assembly language source files will
> be worth doing.  Neither mechanism is sure to work.  For the linker flag,
> we need to be aware of and test for the presence of the linker flag, but we
> might be using some other linker... Similarly, we might end up using some
> other assembler, or we might need to mark the assembly source file in a
> different way than "GNU-stack".
>
> On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
>
>> On 2018-08-21 02:03, David Holmes wrote:
>>
>>> On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
>>>
 On Mon, Aug 20, 2018 at 4:18 PM David Holmes >>> > wrote:

 Hi Arthur,

 cc'ing build-dev as this is currently a build issue.

 On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
  > Hi,
  >
  > At Google we're trying to build hotspot on Linux with clang. One
 thing that
  > happens is that the resulting libjvm.so is stack executable. When
 running
  > hotspot we get warnings about the stack being executable.
  >
  > Compiling an assembly file into the final .so results in the
 stack being
  > executable. In this case the file is linux_x86_64.s. This doesn't
 happen
  > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot
 linker flag
  > with gcc in flags-ldflags.m4. When using clang that linker flag
 isn't
  > passed.
  >
  > Doing something like the solution in
  > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
  > fixes the problem without the use of linker flags.

 You mean the source code directives for the linker?

 Sorry, I wasn't specific enough, I meant the flags for the assembler.
 #if defined(__linux__) && defined(__ELF__)
 .section.note.GNU-stack, "", %progbits
 #endif


 I think I prefer to see this handled explicitly in the build as is
 currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4
 to
 pass the linker flags for gcc and clang?

 I don't mind this solution, but it seems like the right thing to do is
 to fix things at the source level and remove extra unnecessary linker 
 flags.

>>>
>>> Personally I see this as source code pollution. The concept of
>>> executable stacks has nothing to do with what is being expressed by the
>>> source code, or the language used for it.
>>>
>>> Just my 2c. I'll defer to build folk ... though they are still on
>>> vacation at the moment.
>>>
>>
>> I agree with David. The executable stack is a build option. Even if you
>> change the source code so the compiler/assember does the right thing, we
>> would still want to keep the compiler option. (Otherwise one day you'll end
>> up with executable stacks due to someone adding a new asm file and
>> forgetting the "magic incantation".)
>>
>> And, since we will keep the compiler option, there seems little point in
>> also adding this stuff to the asm files.
>>
>> To address your concerns on clang: we should reasonably be giving the
>> same options to clang. There is no good reason, except for oversight, that
>> this is not done already. (Cleaning up and unifying the compiler flags is
>> an ongoing, but slowly moving, process.) So the correct fix is to update
>> flags-ldflags.m4.
>>
>> /Magnus
>>
>>
>>
>>
>>
>>> I removed "-Wl,-z,noexecstack" from the flags after adding the above
 assembler flags and libjvm.so is still correctly not stack executable. I
 don't really mind either way though. Maybe it's good to have an extra
 safeguard in the linker flags.


  > The jtreg test test/hotspot/jtreg/runtime/exe
 cstack/TestCheckJDK.java
  > checks for the stack being executable.
  >
  > Any thoughts? If there are no objections, I can propose a patch
 that works
  > for both gcc and clang on Linux. Also, I'm not sure how/if macOS
 handles
  > this problem given that it uses clang.

 We don't seem to handle it at all on OS X. Does OS X prevent
 

Re: RFR: JDK-8210283: Support git as an SCM alternative in the build

[Erik Joelsson]

New webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.02/

Fixed the comment in SourceRevision.gmk.

Added an SCM identifier in the string so a typical .src-rev file now 
looks like this:


.:hg:3f189f451ff1+

or like this:

.:git:2e1f2c6d44e5+

/Erik


On 2018-09-04 15:00, Erik Joelsson wrote:
There are several instances of OpenJDK source being hosted in Git 
repositories instead of Mercurial. AdoptOpenJDK is one and some 
engineers use local conversions for their day to day work. Project 
Skara aims to investigate Git as well. To better support this, the 
build needs to be able to support Git as an alternative to Mercurial 
when creating the identification hash in the release file. It would 
also be convenient with a .gitignore file mirroring the .hgignore file.


This patch adds such support as well as a .gitignore file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210283

Webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.01/index.html

/Erik

Re: Linux + Clang + execstack

[Martin Buchholz]

I think we can all agree that passing flags to the linker to ensure
non-executable stack is the right thing to do.  But there's a question
whether *also* adding something to our assembly language source files will
be worth doing.  Neither mechanism is sure to work.  For the linker flag,
we need to be aware of and test for the presence of the linker flag, but we
might be using some other linker... Similarly, we might end up using some
other assembler, or we might need to mark the assembly source file in a
different way than "GNU-stack".

On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2018-08-21 02:03, David Holmes wrote:
>
>> On 21/08/2018 9:39 AM, Arthur Eubanks wrote:
>>
>>> On Mon, Aug 20, 2018 at 4:18 PM David Holmes >> > wrote:
>>>
>>> Hi Arthur,
>>>
>>> cc'ing build-dev as this is currently a build issue.
>>>
>>> On 21/08/2018 3:11 AM, Arthur Eubanks wrote:
>>>  > Hi,
>>>  >
>>>  > At Google we're trying to build hotspot on Linux with clang. One
>>> thing that
>>>  > happens is that the resulting libjvm.so is stack executable. When
>>> running
>>>  > hotspot we get warnings about the stack being executable.
>>>  >
>>>  > Compiling an assembly file into the final .so results in the
>>> stack being
>>>  > executable. In this case the file is linux_x86_64.s. This doesn't
>>> happen
>>>  > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot
>>> linker flag
>>>  > with gcc in flags-ldflags.m4. When using clang that linker flag
>>> isn't
>>>  > passed.
>>>  >
>>>  > Doing something like the solution in
>>>  > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks
>>>  > fixes the problem without the use of linker flags.
>>>
>>> You mean the source code directives for the linker?
>>>
>>> Sorry, I wasn't specific enough, I meant the flags for the assembler.
>>> #if defined(__linux__) && defined(__ELF__)
>>> .section.note.GNU-stack, "", %progbits
>>> #endif
>>>
>>>
>>> I think I prefer to see this handled explicitly in the build as is
>>> currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4
>>> to
>>> pass the linker flags for gcc and clang?
>>>
>>> I don't mind this solution, but it seems like the right thing to do is
>>> to fix things at the source level and remove extra unnecessary linker flags.
>>>
>>
>> Personally I see this as source code pollution. The concept of executable
>> stacks has nothing to do with what is being expressed by the source code,
>> or the language used for it.
>>
>> Just my 2c. I'll defer to build folk ... though they are still on
>> vacation at the moment.
>>
>
> I agree with David. The executable stack is a build option. Even if you
> change the source code so the compiler/assember does the right thing, we
> would still want to keep the compiler option. (Otherwise one day you'll end
> up with executable stacks due to someone adding a new asm file and
> forgetting the "magic incantation".)
>
> And, since we will keep the compiler option, there seems little point in
> also adding this stuff to the asm files.
>
> To address your concerns on clang: we should reasonably be giving the same
> options to clang. There is no good reason, except for oversight, that this
> is not done already. (Cleaning up and unifying the compiler flags is an
> ongoing, but slowly moving, process.) So the correct fix is to update
> flags-ldflags.m4.
>
> /Magnus
>
>
>
>
>
>> I removed "-Wl,-z,noexecstack" from the flags after adding the above
>>> assembler flags and libjvm.so is still correctly not stack executable. I
>>> don't really mind either way though. Maybe it's good to have an extra
>>> safeguard in the linker flags.
>>>
>>>
>>>  > The jtreg test test/hotspot/jtreg/runtime/exe
>>> cstack/TestCheckJDK.java
>>>  > checks for the stack being executable.
>>>  >
>>>  > Any thoughts? If there are no objections, I can propose a patch
>>> that works
>>>  > for both gcc and clang on Linux. Also, I'm not sure how/if macOS
>>> handles
>>>  > this problem given that it uses clang.
>>>
>>> We don't seem to handle it at all on OS X. Does OS X prevent
>>> executable
>>> stacks itself?
>>>
>>> A quick search, according to Wikipedia (https://en.wikipedia.org/wiki
>>> /Executable_space_protection#macOS), 64-bit executables on macOS aren't
>>> stack or heap executable. Not sure if that information is accurate though.
>>>
>>
>> Seems to be:
>>
>> https://developer.apple.com/library/archive/documentation/Se
>> curity/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html
>>
>> "macOS and iOS provide two features that can make it harder to exploit
>> stack and buffer overflows: address space layout randomization (ASLR) and a
>> non-executable stack and heap."
>>
>> Cheers,
>> David
>>
>>
>>> David
>>>
>>>
>

Re: RFR: JDK-8210283: Support git as an SCM alternative in the build

[Erik Joelsson]

On 2018-09-04 15:53, Joseph D. Darcy wrote:

I believe both hg and git currently use SHA-1 hashes.

Should the syntax used in the release file be expanded to indicate 
which SCM the hash is from?



That is a good point. I will see what I can do.

/Erik

Thanks,

-Joe

On 9/4/2018 3:00 PM, Erik Joelsson wrote:
There are several instances of OpenJDK source being hosted in Git 
repositories instead of Mercurial. AdoptOpenJDK is one and some 
engineers use local conversions for their day to day work. Project 
Skara aims to investigate Git as well. To better support this, the 
build needs to be able to support Git as an alternative to Mercurial 
when creating the identification hash in the release file. It would 
also be convenient with a .gitignore file mirroring the .hgignore file.


This patch adds such support as well as a .gitignore file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210283

Webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.01/index.html

/Erik

Re: RFR: JDK-8210283: Support git as an SCM alternative in the build

[Joseph D. Darcy]

I believe both hg and git currently use SHA-1 hashes.

Should the syntax used in the release file be expanded to indicate which 
SCM the hash is from?


Thanks,

-Joe

On 9/4/2018 3:00 PM, Erik Joelsson wrote:
There are several instances of OpenJDK source being hosted in Git 
repositories instead of Mercurial. AdoptOpenJDK is one and some 
engineers use local conversions for their day to day work. Project 
Skara aims to investigate Git as well. To better support this, the 
build needs to be able to support Git as an alternative to Mercurial 
when creating the identification hash in the release file. It would 
also be convenient with a .gitignore file mirroring the .hgignore file.


This patch adds such support as well as a .gitignore file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210283

Webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.01/index.html

/Erik

Re: RFR: JDK-8210283: Support git as an SCM alternative in the build

[Kim Barrett]

> On Sep 4, 2018, at 6:00 PM, Erik Joelsson  wrote:
> 
> There are several instances of OpenJDK source being hosted in Git 
> repositories instead of Mercurial. AdoptOpenJDK is one and some engineers use 
> local conversions for their day to day work. Project Skara aims to 
> investigate Git as well. To better support this, the build needs to be able 
> to support Git as an alternative to Mercurial when creating the 
> identification hash in the release file. It would also be convenient with a 
> .gitignore file mirroring the .hgignore file.
> 
> This patch adds such support as well as a .gitignore file.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210283
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.01/index.html
> 
> /Erik

[Just a comment, not a review (I don’t feel qualified to really review this 
change).]

The comment starting at line 36 of make/SourceRevision.gmk needs updating.

RFR: JDK-8210283: Support git as an SCM alternative in the build

[Erik Joelsson]

There are several instances of OpenJDK source being hosted in Git 
repositories instead of Mercurial. AdoptOpenJDK is one and some 
engineers use local conversions for their day to day work. Project Skara 
aims to investigate Git as well. To better support this, the build needs 
to be able to support Git as an alternative to Mercurial when creating 
the identification hash in the release file. It would also be convenient 
with a .gitignore file mirroring the .hgignore file.


This patch adds such support as well as a .gitignore file.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210283

Webrev: http://cr.openjdk.java.net/~erikj/8210283/webrev.01/index.html

/Erik

Re: RFR: 8165440: Add zero support for x86_64-linux-gnux32 target

[Erik Joelsson]

Looks ok to me.

/Erik


On 2018-09-04 14:29, David Holmes wrote:

Hi Adrian,

All changes that touch the build system must be reviewed by build-dev 
- now cc'd.


These changes seem reasonable, though I don't like adding changes in 
source code for such an obscure (and unsupported!) platform.


David

On 5/09/2018 3:45 AM, John Paul Adrian Glaubitz wrote:

Hi!

This rather small change adds build support for the x86_64-linux-gnux32
target. x32 is a variant of the x86_64 ABI with 64-bit registers and 
amd64

instruction set but 32-bit pointers [1].

One of the Linux distributions supporting x32 is Debian, see [2]. The
port is not official, but the large majority of packages build fine
and the toolchain is in good shape. Another distribution supporting
x32 is Gentoo.

Please review the change in [3]. I have changed the original patch
a bit that Debian uses downstream to make the changes more consistent
and cleaner.

Thanks,
Adrian


[1] https://en.wikipedia.org/wiki/X32_ABI
[2] http://debian-x32.org/
[2] http://cr.openjdk.java.net/~glaubitz/8165440/webrev.00/

Re: [8u] RFR: 8210352: [hotspot] --with-extra-cxx-flags should not lower optimization

[Erik Joelsson]

On 2018-09-04 14:06, David Holmes wrote:

Hi Severin,

On 5/09/2018 1:36 AM, Severin Gehwolf wrote:

Hi,

Could I please get reviews of this JDK 8-only change?

The issue at hand is that the JDK 8 build seems to be inconsistent with
later JDK builds (9+). When somebody passes
--with-extra-c{,xx}-flags="-O2" to the OpenJDK build on JDK 9+ the JVM
will get compiled with -O3 for a release type build. Not so on JDK 8.
It gets compiled with -O2. The reason we are passing extra C flags via
configure is to: a) get distro-wide optimization done b) allow for
hardened builds. Without the --with-extra-c{,xx}-flags="-O2" flag,
libjsig, libsaproc will get compiled with no optimization. That's what
I'd like to fix. The proposed patch allows one to force -O2 for the JVM
via OPT_EXTRAS make variable if so desired. Omitting OPT_EXTRAS=-O2
allows one to get hotspot libraries optimized with -O2 and better.
Thoughts?


I don't understand the motivation for this change. Compatibility with 
future versions is not a usual compatibility we care about. I'd also 
argue the behaviour in 8 seems more correct. If I set an extra cflag I 
expect it to be applied to all compilations - cross-compilation would 
be broken if that were not the case. I don't see why -On should be 
treated any differently.


I do agree with you, sort of. All user added flags are applied 
everywhere. The reason the optimization isn't overridden is because of 
the order the flags are applied on the command line. In JDK 9 (and in 8 
for JDK libs) we apply optimization flags after the custom flags from 
the user. (For Hotspot in 8 it seems the custom flags are added after 
the optimization flags.) IIRC we did this intentionally in the "new 
build" with the reasoning that we are pretty particular with the 
optimization flags in many cases so a global override is probably not a 
good idea.


The suggested patch, filtering specific -O flags from the user supplied 
flags does not look good to me. I would however be ok with changing the 
ordering of flags for libjvm so that the same behavior as in 9 and later 
(and as for JDK libs in 8) is achieved.


/Erik

David


Bug: https://bugs.openjdk.java.net/browse/JDK-8210352
webrev: 
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210352/webrev.01/


Thanks,
Severin

Re: RFR: 8165440: Add zero support for x86_64-linux-gnux32 target

[David Holmes]

Hi Adrian,

All changes that touch the build system must be reviewed by build-dev - 
now cc'd.


These changes seem reasonable, though I don't like adding changes in 
source code for such an obscure (and unsupported!) platform.


David

On 5/09/2018 3:45 AM, John Paul Adrian Glaubitz wrote:

Hi!

This rather small change adds build support for the x86_64-linux-gnux32
target. x32 is a variant of the x86_64 ABI with 64-bit registers and amd64
instruction set but 32-bit pointers [1].

One of the Linux distributions supporting x32 is Debian, see [2]. The
port is not official, but the large majority of packages build fine
and the toolchain is in good shape. Another distribution supporting
x32 is Gentoo.

Please review the change in [3]. I have changed the original patch
a bit that Debian uses downstream to make the changes more consistent
and cleaner.

Thanks,
Adrian


[1] https://en.wikipedia.org/wiki/X32_ABI
[2] http://debian-x32.org/
[2] http://cr.openjdk.java.net/~glaubitz/8165440/webrev.00/

Re: [8u] RFR: 8210352: [hotspot] --with-extra-cxx-flags should not lower optimization

[David Holmes]

Hi Severin,

On 5/09/2018 1:36 AM, Severin Gehwolf wrote:

Hi,

Could I please get reviews of this JDK 8-only change?

The issue at hand is that the JDK 8 build seems to be inconsistent with
later JDK builds (9+). When somebody passes
--with-extra-c{,xx}-flags="-O2" to the OpenJDK build on JDK 9+ the JVM
will get compiled with -O3 for a release type build. Not so on JDK 8.
It gets compiled with -O2. The reason we are passing extra C flags via
configure is to: a) get distro-wide optimization done b) allow for
hardened builds. Without the --with-extra-c{,xx}-flags="-O2" flag,
libjsig, libsaproc will get compiled with no optimization. That's what
I'd like to fix. The proposed patch allows one to force -O2 for the JVM
via OPT_EXTRAS make variable if so desired. Omitting OPT_EXTRAS=-O2
allows one to get hotspot libraries optimized with -O2 and better.
Thoughts?


I don't understand the motivation for this change. Compatibility with 
future versions is not a usual compatibility we care about. I'd also 
argue the behaviour in 8 seems more correct. If I set an extra cflag I 
expect it to be applied to all compilations - cross-compilation would be 
broken if that were not the case. I don't see why -On should be treated 
any differently.


David


Bug: https://bugs.openjdk.java.net/browse/JDK-8210352
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210352/webrev.01/

Thanks,
Severin

Re: RFR 8210318: idea.sh script doesn't work on Mac

[Maurizio Cimadamore]

Ah - thanks for the tip, I'll give that a try

Maurizio


On 04/09/18 18:50, Erik Joelsson wrote:

Hello,

$TARGET was just pseudo code. In your case it's $1.tmp.

/Erik


On 2018-09-04 10:34, Maurizio Cimadamore wrote:

Hi Erik,
would $TARGET be set by make?

Maurizio


On 04/09/18 16:55, Erik Joelsson wrote:

Hello,

When choosing a temp file in the build, we avoid using /tmp whenever 
possible. A common pattern is instead to write to $TARGET.tmp and 
then mv that to $TARGET. Though unlikely to cause an issue, 
/tmp/replacement is a global location which is potentially risky 
(file permissions, concurrent execution etc).


Otherwise looks good.

/Erik

On 2018-09-03 05:39, Maurizio Cimadamore wrote:

Hi,
following the latest updates to the idea.sh script, Mac users 
reported issues - mostly having to do with usage of 'sed' - more 
specifically:


* sed -i option is not portable - it has different formats in Mac 
vs. Linux. This patch does without -i, by moving the replaced file 
onto a temporary file, then moving such file on top of the template 
file in a subsequent step. This should be more robust.


* sed doesn't like newlines in replaced text in Mac. I've thus 
omitted the newline from the SOURCE template - as that was mostly 
cosmetic.


Thanks for Michael McMahon to report (and figure out how to deal 
with) these issues, and to Alan Bateman for testing the patch.


I also fixed another minor glitch, this time in the langtools-only 
template - which was still referring to the old ant file location 
in the various run configuration.


Webrev:

http://cr.openjdk.java.net/~mcimadamore/8210318/

Cheers
Maurizio

Re: RFR 8210318: idea.sh script doesn't work on Mac

[Erik Joelsson]

Hello,

$TARGET was just pseudo code. In your case it's $1.tmp.

/Erik


On 2018-09-04 10:34, Maurizio Cimadamore wrote:

Hi Erik,
would $TARGET be set by make?

Maurizio


On 04/09/18 16:55, Erik Joelsson wrote:

Hello,

When choosing a temp file in the build, we avoid using /tmp whenever 
possible. A common pattern is instead to write to $TARGET.tmp and 
then mv that to $TARGET. Though unlikely to cause an issue, 
/tmp/replacement is a global location which is potentially risky 
(file permissions, concurrent execution etc).


Otherwise looks good.

/Erik

On 2018-09-03 05:39, Maurizio Cimadamore wrote:

Hi,
following the latest updates to the idea.sh script, Mac users 
reported issues - mostly having to do with usage of 'sed' - more 
specifically:


* sed -i option is not portable - it has different formats in Mac 
vs. Linux. This patch does without -i, by moving the replaced file 
onto a temporary file, then moving such file on top of the template 
file in a subsequent step. This should be more robust.


* sed doesn't like newlines in replaced text in Mac. I've thus 
omitted the newline from the SOURCE template - as that was mostly 
cosmetic.


Thanks for Michael McMahon to report (and figure out how to deal 
with) these issues, and to Alan Bateman for testing the patch.


I also fixed another minor glitch, this time in the langtools-only 
template - which was still referring to the old ant file location in 
the various run configuration.


Webrev:

http://cr.openjdk.java.net/~mcimadamore/8210318/

Cheers
Maurizio

Re: [8u] RFR: 8210352: [hotspot] --with-extra-cxx-flags should not lower optimization

[Erik Joelsson]

Hello,

I understand your problem, but I'm really not sure I like this solution. 
What I mostly question is your desire for adding optimization to the 
libraries nobody has bothered adding optimizations on by default since 
forever. If this is important to you, then provide a patch adding opt 
flags to the specific libraries. In general, the OpenJDK build is very 
conscious about what optimization levels are used wherever it matters, 
so tinkering with them is likely not a good idea.


That said, I think a better fix would be to reorder the arguments so 
that the OPT flags are added after any extra flags variable.


/Erik


On 2018-09-04 08:36, Severin Gehwolf wrote:

Hi,

Could I please get reviews of this JDK 8-only change?

The issue at hand is that the JDK 8 build seems to be inconsistent with
later JDK builds (9+). When somebody passes
--with-extra-c{,xx}-flags="-O2" to the OpenJDK build on JDK 9+ the JVM
will get compiled with -O3 for a release type build. Not so on JDK 8.
It gets compiled with -O2. The reason we are passing extra C flags via
configure is to: a) get distro-wide optimization done b) allow for
hardened builds. Without the --with-extra-c{,xx}-flags="-O2" flag,
libjsig, libsaproc will get compiled with no optimization. That's what
I'd like to fix. The proposed patch allows one to force -O2 for the JVM
via OPT_EXTRAS make variable if so desired. Omitting OPT_EXTRAS=-O2
allows one to get hotspot libraries optimized with -O2 and better.
Thoughts?

Bug: https://bugs.openjdk.java.net/browse/JDK-8210352
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210352/webrev.01/

Thanks,
Severin

Re: 8210087: Classes in jdk.unsupported not accessible from jconsole plugin

[Erik Joelsson]

Looks good.

/Erik


On 2018-09-03 00:27, Alan Bateman wrote:


JDK-8210087 [1] is an issue with the launcher generated for jconsole. 
The launcher needs to be compiled with --add-modules ALL-DEFAULT so 
that plugins compiled (and run) in an unnamed module can make use of 
exported APIs in modules that aren't resolved by jdk.jconsole. The 
change is trivial:


diff -r cdef4df6b0e7 make/launcher/Launcher-jdk.jconsole.gmk
--- a/make/launcher/Launcher-jdk.jconsole.gmk    Fri Aug 31 10:22:04 
2018 -0400
+++ b/make/launcher/Launcher-jdk.jconsole.gmk    Mon Sep 03 07:56:56 
2018 +0100

@@ -28,6 +28,7 @@
 $(eval $(call SetupBuildLauncher, jconsole, \
 MAIN_CLASS := sun.tools.jconsole.JConsole, \
 JAVA_ARGS := --add-opens java.base/java.io=jdk.jconsole \
+ --add-modules ALL-DEFAULT \
      -Djconsole.showOutputViewer, \
 CFLAGS_windows := -DJAVAW, \
 LIBS_windows := user32.lib, \

jconsole is headful so I'm not planning to include a test at this time.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8210087

Re: RFR: JDK-6657100 Rename sparcWorks to solstudio in HotSpot

[Erik Joelsson]

On 2018-09-03 00:19, David Holmes wrote:

On 30/08/2018 10:36 PM, Magnus Ihse Bursie wrote:

Hi folks,

This bug report goes all the way back to 2008. :-) So instead of just 
letting it go on to it's second decade of existence, I went about and 
fixed it.


Ummm but now it's called Oracle Developer Studio.

Yes, we are aware of that, so ideally we should rename it all over. This 
bug was about unification however, and now it's at least unified. One 
could also note that the version we are currently using (12.4) was still 
called Solaris Studio. The rename happened in later versions.


/Erik

David

By now, not many references to sparcWorks exists anymore, so this is 
almost trivial.


I've verified by grep that no more "sparcworks" are present in the 
repo, neither in hotspot nor anywhere else.


Bug: https://bugs.openjdk.java.net/browse/JDK-6657100
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-6657100-rename-sparcWorks-to-solstudio/webrev.01 



/Magnus

Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux

[Magnus Ihse Bursie]

Looks good to me. 

/Magnus

> 4 sep. 2018 kl. 12:11 skrev Andrew Leonard :
> 
> Hi Brian/Goetz, 
> Yes, that seems sensible. I have created a new webrev with fdlibm compiler 
> option disabled, and mediaLib code fixed: 
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/ 
> I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3. 
> 
> Are we good to go? 
> Thanks 
> Andrew 
> 
> hg export: 
> # HG changeset patch 
> # User aleonard 
> # Date 1536055438 -3600 
> #  Tue Sep 04 11:03:58 2018 +0100 
> # Node ID c2523f285c503e8f82f1212b38de1cb54093255e 
> # Parent  3ee91722550680c18b977f0e00b1013323b5c9ef 
> 8209786: JDK12 fails to build on s390x with gcc 7.3 
> 
> diff -r 3ee917225506 -r c2523f285c50 make/lib/CoreLibraries.gmk 
> --- a/make/lib/CoreLibraries.gmkTue Sep 04 14:47:55 2018 +0800 
> +++ b/make/lib/CoreLibraries.gmkTue Sep 04 11:03:58 2018 +0100 
> @@ -68,7 +68,7 @@ 
>CFLAGS_linux_ppc64le := -ffp-contract=off, \ 
>CFLAGS_linux_s390x := -ffp-contract=off, \ 
>CFLAGS_linux_aarch64 := -ffp-contract=off, \ 
> -  DISABLED_WARNINGS_gcc := sign-compare misleading-indentation, \ 
> +  DISABLED_WARNINGS_gcc := sign-compare misleading-indentation 
> array-bounds, \ 
>DISABLED_WARNINGS_microsoft := 4146 4244 4018, \ 
>ARFLAGS := $(ARFLAGS), \ 
>OBJECT_DIR := $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/libfdlibm, \ 
> diff -r 3ee917225506 -r c2523f285c50 
> src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c 
> --- a/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c  
>   Tue Sep 04 14:47:55 2018 +0800 
> +++ b/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c  
>   Tue Sep 04 11:03:58 2018 +0100 
> @@ -1,5 +1,5 @@ 
>  /* 
> - * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved. 
> + * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights 
> reserved. 
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 
>   * 
>   * This code is free software; you can redistribute it and/or modify it 
> @@ -259,18 +259,18 @@ 
>} 
>   
>  #ifdef _LITTLE_ENDIAN 
> -  emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); 
> +  emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); 
>  #else 
> -  emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); 
> +  emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); 
>  #endif /* _LITTLE_ENDIAN */ 
>((mlib_u32*)da)[0] = (val1 & emask) | (((mlib_u32*)da)[0] &~ emask); 
>   
>  #else /* _NO_LONGLONG */ 
>   
>  #ifdef _LITTLE_ENDIAN 
> -  mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); 
> +  mlib_u64 emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); 
>  #else 
> -  mlib_u64 emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); 
> +  mlib_u64 emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); 
>  #endif /* _LITTLE_ENDIAN */ 
>   
>((mlib_u64*)da)[0] = (((mlib_u64*)dd_array)[sa[0]] & emask) | 
> (((mlib_u64*)da)[0] &~ emask); 
> @@ -395,9 +395,9 @@ 
>} 
>   
>  #ifdef _LITTLE_ENDIAN 
> -  emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); 
> +  emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); 
>  #else 
> -  emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); 
> +  emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); 
>  #endif /* _LITTLE_ENDIAN */ 
>((mlib_u32*)da)[0] = (dd1 & emask) | (((mlib_u32*)da)[0] &~ emask); 
>   
> @@ -413,9 +413,9 @@ 
>} 
>   
>  #ifdef _LITTLE_ENDIAN 
> -  emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8); 
> +  emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8); 
>  #else 
> -  emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8); 
> +  emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8); 
>  #endif /* _LITTLE_ENDIAN */ 
>((mlib_u64*)da)[0] = (dd & emask) | (((mlib_u64*)da)[0] &~ emask); 
>   
> @@ -565,9 +565,9 @@ 
>} 
>   
>  #ifdef _LITTLE_ENDIAN 
> -  emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8); 
> +  emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8); 
>  #else 
> -  emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8); 
> +  emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8); 
>  #endif /* _LITTLE_ENDIAN */ 
>da[0] = (dd & 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 
> 
> 
> 
> 
> From:Brian Burkhalter  
> To:Magnus Ihse Bursie  
> Cc:Andrew Leonard , "Lindenmaier, Goetz" 
> , 2d-dev <2d-...@openjdk.java.net>, build-dev 
> , core-libs-dev , 
> Philip Race  
> Date:31/08/2018 15:44 
> Subject:Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors 
> on zLinux 
> 
> 
> 
> 
> On Aug 31, 2018, at 2:28 AM, Magnus Ihse Bursie 
>  wrote: 
> 
> Magnus, 

[8u] RFR: 8210352: [hotspot] --with-extra-cxx-flags should not lower optimization

[Severin Gehwolf]

Hi,

Could I please get reviews of this JDK 8-only change?

The issue at hand is that the JDK 8 build seems to be inconsistent with
later JDK builds (9+). When somebody passes
--with-extra-c{,xx}-flags="-O2" to the OpenJDK build on JDK 9+ the JVM
will get compiled with -O3 for a release type build. Not so on JDK 8.
It gets compiled with -O2. The reason we are passing extra C flags via
configure is to: a) get distro-wide optimization done b) allow for
hardened builds. Without the --with-extra-c{,xx}-flags="-O2" flag,
libjsig, libsaproc will get compiled with no optimization. That's what
I'd like to fix. The proposed patch allows one to force -O2 for the JVM
via OPT_EXTRAS make variable if so desired. Omitting OPT_EXTRAS=-O2
allows one to get hotspot libraries optimized with -O2 and better.
Thoughts?

Bug: https://bugs.openjdk.java.net/browse/JDK-8210352
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210352/webrev.01/

Thanks,
Severin

Re: RFR 8210318: idea.sh script doesn't work on Mac

[Michael McMahon]

The change looks fine to me Maurizio. Maybe you could append a .$$ to 
the temporary
file name to make it less likely to overwrite something that already 
exists in /tmp


- Michael.

On 03/09/2018, 13:39, Maurizio Cimadamore wrote:

Hi,
following the latest updates to the idea.sh script, Mac users reported 
issues - mostly having to do with usage of 'sed' - more specifically:


* sed -i option is not portable - it has different formats in Mac vs. 
Linux. This patch does without -i, by moving the replaced file onto a 
temporary file, then moving such file on top of the template file in a 
subsequent step. This should be more robust.


* sed doesn't like newlines in replaced text in Mac. I've thus omitted 
the newline from the SOURCE template - as that was mostly cosmetic.


Thanks for Michael McMahon to report (and figure out how to deal with) 
these issues, and to Alan Bateman for testing the patch.


I also fixed another minor glitch, this time in the langtools-only 
template - which was still referring to the old ant file location in 
the various run configuration.


Webrev:

http://cr.openjdk.java.net/~mcimadamore/8210318/

Cheers
Maurizio

Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on zLinux

[Andrew Leonard]

Hi Brian/Goetz,
Yes, that seems sensible. I have created a new webrev with fdlibm compiler 
option disabled, and mediaLib code fixed:
http://cr.openjdk.java.net/~aleonard/8209786/webrev.02/
I've built and tested on xLinux and zLinux, with gcc 4.8.4 and 7.3.

Are we good to go?
Thanks
Andrew

hg export:
# HG changeset patch
# User aleonard
# Date 1536055438 -3600
#  Tue Sep 04 11:03:58 2018 +0100
# Node ID c2523f285c503e8f82f1212b38de1cb54093255e
# Parent  3ee91722550680c18b977f0e00b1013323b5c9ef
8209786: JDK12 fails to build on s390x with gcc 7.3

diff -r 3ee917225506 -r c2523f285c50 make/lib/CoreLibraries.gmk
--- a/make/lib/CoreLibraries.gmkTue Sep 04 14:47:55 2018 +0800
+++ b/make/lib/CoreLibraries.gmkTue Sep 04 11:03:58 2018 +0100
@@ -68,7 +68,7 @@
   CFLAGS_linux_ppc64le := -ffp-contract=off, \
   CFLAGS_linux_s390x := -ffp-contract=off, \
   CFLAGS_linux_aarch64 := -ffp-contract=off, \
-  DISABLED_WARNINGS_gcc := sign-compare misleading-indentation, \
+  DISABLED_WARNINGS_gcc := sign-compare misleading-indentation 
array-bounds, \
   DISABLED_WARNINGS_microsoft := 4146 4244 4018, \
   ARFLAGS := $(ARFLAGS), \
   OBJECT_DIR := $(SUPPORT_OUTPUTDIR)/native/$(MODULE)/libfdlibm, \
diff -r 3ee917225506 -r c2523f285c50 
src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c
--- a/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c   
  Tue Sep 04 14:47:55 2018 +0800
+++ b/src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c   
  Tue Sep 04 11:03:58 2018 +0100
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights 
reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -259,18 +259,18 @@
   }
 
 #ifdef _LITTLE_ENDIAN
-  emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8);
+  emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8);
 #else
-  emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8);
+  emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8);
 #endif /* _LITTLE_ENDIAN */
   ((mlib_u32*)da)[0] = (val1 & emask) | (((mlib_u32*)da)[0] &~ 
emask);
 
 #else /* _NO_LONGLONG */
 
 #ifdef _LITTLE_ENDIAN
-  mlib_u64 emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 
8);
+  mlib_u64 emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8);
 #else
-  mlib_u64 emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8);
+  mlib_u64 emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8);
 #endif /* _LITTLE_ENDIAN */
 
   ((mlib_u64*)da)[0] = (((mlib_u64*)dd_array)[sa[0]] & emask) | 
(((mlib_u64*)da)[0] &~ emask);
@@ -395,9 +395,9 @@
   }
 
 #ifdef _LITTLE_ENDIAN
-  emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8);
+  emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8);
 #else
-  emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8);
+  emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8);
 #endif /* _LITTLE_ENDIAN */
   ((mlib_u32*)da)[0] = (dd1 & emask) | (((mlib_u32*)da)[0] &~ emask);
 
@@ -413,9 +413,9 @@
   }
 
 #ifdef _LITTLE_ENDIAN
-  emask = (mlib_u64)((mlib_s64)(-1)) >> ((8 - (size - i)) * 8);
+  emask = (~(mlib_u64)0) >> ((8 - (size - i)) * 8);
 #else
-  emask = (mlib_s64)(-1) << ((8 - (size - i)) * 8);
+  emask = (~(mlib_u64)0) << ((8 - (size - i)) * 8);
 #endif /* _LITTLE_ENDIAN */
   ((mlib_u64*)da)[0] = (dd & emask) | (((mlib_u64*)da)[0] &~ emask);
 
@@ -565,9 +565,9 @@
   }
 
 #ifdef _LITTLE_ENDIAN
-  emask = (mlib_u32)((mlib_s32)(-1)) >> ((4 - (size - i)) * 8);
+  emask = (~(mlib_u32)0) >> ((4 - (size - i)) * 8);
 #else
-  emask = (mlib_s32)(-1) << ((4 - (size - i)) * 8);
+  emask = (~(mlib_u32)0) << ((4 - (size - i)) * 8);
 #endif /* _LITTLE_ENDIAN */
   da[0] = (dd & 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 




From:   Brian Burkhalter 
To: Magnus Ihse Bursie 
Cc: Andrew Leonard , "Lindenmaier, Goetz" 
, 2d-dev <2d-...@openjdk.java.net>, build-dev 
, core-libs-dev 
, Philip Race 
Date:   31/08/2018 15:44
Subject:Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler 
errors on zLinux




On Aug 31, 2018, at 2:28 AM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> 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 be 
"compiler fix" for libfdlibm, and "source fix" for libmlib_image.

I think we can safely say “disable compiler errors” for fdlibm as 
indicated by Joe Darcy’s comment in the issue (he owns fdlibm), and source 
code change for