From mikael.vidstedt at oracle.com Tue Mar 10 00:57:03 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 09 Mar 2015 17:57:03 -0700 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code Message-ID: <54FE415F.10905@oracle.com> Please review this small change which removes the unused/dead frame::native_param_addr function along with the corresponding code in the SA. http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ Cheers, Mikael From david.holmes at oracle.com Tue Mar 10 01:45:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Mar 2015 11:45:25 +1000 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code In-Reply-To: <54FE415F.10905@oracle.com> References: <54FE415F.10905@oracle.com> Message-ID: <54FE4CB5.6060503@oracle.com> Hi Mikael, On 10/03/2015 10:57 AM, Mikael Vidstedt wrote: > > Please review this small change which removes the unused/dead > frame::native_param_addr function along with the corresponding code in > the SA. > > http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ Isn't NATIVE_FRAME_INITIAL_PARAM_OFFSET also dead now in the Java code. Similarly native_frame_initial_param_offset in the C code Will you also do the aarch64 changes? Thanks, David > Cheers, > Mikael > From chris.plummer at oracle.com Tue Mar 10 02:22:16 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 09 Mar 2015 19:22:16 -0700 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code In-Reply-To: <54FE415F.10905@oracle.com> References: <54FE415F.10905@oracle.com> Message-ID: <54FE5558.1090103@oracle.com> On 3/9/15 5:57 PM, Mikael Vidstedt wrote: > > Please review this small change which removes the unused/dead > frame::native_param_addr function along with the corresponding code in > the SA. > > http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ > > Cheers, > Mikael > Since you're removing unused frame APIs, maybe you can also remove frame::set_link(), which is also not used. I have no idea why it's there. Seems to be a very dangerous thing to do since the link (previous frame pointer) is setup by function prologue code, not by the JVM. cheers, Chris From mikael.vidstedt at oracle.com Tue Mar 10 22:45:09 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 10 Mar 2015 15:45:09 -0700 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code In-Reply-To: <54FE5558.1090103@oracle.com> References: <54FE415F.10905@oracle.com> <54FE5558.1090103@oracle.com> Message-ID: <54FF73F5.3050700@oracle.com> New version: http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.01/webrev/ Changes since webrev.00: * Removed native_frame_initial_param_offset/NATIVE_FRAME_INITIAL_PARAM_OFFSET * Removed set_link * Made corresponding changes for aarch64 * Removed the vmStruct constant abi_minframe_size, the only usage which was for NATIVE_FRAME_INITIAL_PARAM_OFFSET Cheers, Mikael On 2015-03-09 19:22, Chris Plummer wrote: > On 3/9/15 5:57 PM, Mikael Vidstedt wrote: >> >> Please review this small change which removes the unused/dead >> frame::native_param_addr function along with the corresponding code >> in the SA. >> >> http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ >> >> Cheers, >> Mikael >> > Since you're removing unused frame APIs, maybe you can also remove > frame::set_link(), which is also not used. I have no idea why it's > there. Seems to be a very dangerous thing to do since the link > (previous frame pointer) is setup by function prologue code, not by > the JVM. > > cheers, > > Chris From chris.plummer at oracle.com Tue Mar 10 22:59:55 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 10 Mar 2015 15:59:55 -0700 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code In-Reply-To: <54FF73F5.3050700@oracle.com> References: <54FE415F.10905@oracle.com> <54FE5558.1090103@oracle.com> <54FF73F5.3050700@oracle.com> Message-ID: <54FF776B.5040007@oracle.com> The set_link() removal looks good (thank you for taking care of this). Copyright year needs updating on all files. cheers, Chris On 3/10/15 3:45 PM, Mikael Vidstedt wrote: > > New version: > > http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.01/webrev/ > > Changes since webrev.00: > > * Removed > native_frame_initial_param_offset/NATIVE_FRAME_INITIAL_PARAM_OFFSET > * Removed set_link > * Made corresponding changes for aarch64 > * Removed the vmStruct constant abi_minframe_size, the only usage > which was for NATIVE_FRAME_INITIAL_PARAM_OFFSET > > Cheers, > Mikael > > On 2015-03-09 19:22, Chris Plummer wrote: >> On 3/9/15 5:57 PM, Mikael Vidstedt wrote: >>> >>> Please review this small change which removes the unused/dead >>> frame::native_param_addr function along with the corresponding code >>> in the SA. >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ >>> >>> Cheers, >>> Mikael >>> >> Since you're removing unused frame APIs, maybe you can also remove >> frame::set_link(), which is also not used. I have no idea why it's >> there. Seems to be a very dangerous thing to do since the link >> (previous frame pointer) is setup by function prologue code, not by >> the JVM. >> >> cheers, >> >> Chris > From david.holmes at oracle.com Wed Mar 11 00:46:30 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Mar 2015 10:46:30 +1000 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code In-Reply-To: <54FF73F5.3050700@oracle.com> References: <54FE415F.10905@oracle.com> <54FE5558.1090103@oracle.com> <54FF73F5.3050700@oracle.com> Message-ID: <54FF9066.5030602@oracle.com> Looks good to me Mikael. Just update copyrights as Chris said :) Thanks, David On 11/03/2015 8:45 AM, Mikael Vidstedt wrote: > > New version: > > http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.01/webrev/ > > Changes since webrev.00: > > * Removed > native_frame_initial_param_offset/NATIVE_FRAME_INITIAL_PARAM_OFFSET > * Removed set_link > * Made corresponding changes for aarch64 > * Removed the vmStruct constant abi_minframe_size, the only usage which > was for NATIVE_FRAME_INITIAL_PARAM_OFFSET > > Cheers, > Mikael > > On 2015-03-09 19:22, Chris Plummer wrote: >> On 3/9/15 5:57 PM, Mikael Vidstedt wrote: >>> >>> Please review this small change which removes the unused/dead >>> frame::native_param_addr function along with the corresponding code >>> in the SA. >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ >>> >>> Cheers, >>> Mikael >>> >> Since you're removing unused frame APIs, maybe you can also remove >> frame::set_link(), which is also not used. I have no idea why it's >> there. Seems to be a very dangerous thing to do since the link >> (previous frame pointer) is setup by function prologue code, not by >> the JVM. >> >> cheers, >> >> Chris > From dmitry.samersoff at oracle.com Wed Mar 11 14:21:38 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 11 Mar 2015 17:21:38 +0300 Subject: RFR (XS): 6313046: Remove unused frame::native_param_addr code In-Reply-To: <54FF73F5.3050700@oracle.com> References: <54FE415F.10905@oracle.com> <54FE5558.1090103@oracle.com> <54FF73F5.3050700@oracle.com> Message-ID: <55004F72.2080003@oracle.com> Mikael, SA changes looks OK for me. -Dmitry On 2015-03-11 01:45, Mikael Vidstedt wrote: > > New version: > > http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.01/webrev/ > > Changes since webrev.00: > > * Removed > native_frame_initial_param_offset/NATIVE_FRAME_INITIAL_PARAM_OFFSET > * Removed set_link > * Made corresponding changes for aarch64 > * Removed the vmStruct constant abi_minframe_size, the only usage which > was for NATIVE_FRAME_INITIAL_PARAM_OFFSET > > Cheers, > Mikael > > On 2015-03-09 19:22, Chris Plummer wrote: >> On 3/9/15 5:57 PM, Mikael Vidstedt wrote: >>> >>> Please review this small change which removes the unused/dead >>> frame::native_param_addr function along with the corresponding code >>> in the SA. >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/6313046/webrev.00/webrev/ >>> >>> Cheers, >>> Mikael >>> >> Since you're removing unused frame APIs, maybe you can also remove >> frame::set_link(), which is also not used. I have no idea why it's >> there. Seems to be a very dangerous thing to do since the link >> (previous frame pointer) is setup by function prologue code, not by >> the JVM. >> >> cheers, >> >> Chris > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From zoltan.majo at oracle.com Thu Mar 12 12:43:17 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 12 Mar 2015 13:43:17 +0100 Subject: [9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux Message-ID: <550189E5.60505@oracle.com> Hi, please review the following small patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8074869 Problem: On Linux, the C2 code generator can replace the value -0.0f with +0.0f (and also the value -0.0d with +0.0d). The reason is that in some *.ad files both the value -0.0f and +0.0f is treated as being +0.0f and can therefore be replaced with an immediate +0.0f embedded into an instruction. For example, in the sparc.ad file, the 'fpclass' function is used to decide if a float node's content is +0.0: predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO)); On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and FP_NZERO if the parameter is -0.0f. As a result, +0.0f and -0.0f are distinguished by the compiler. On Linux, however, 'fpclass' is not available and therefore 'fpclassify' is used. 'fpclassify' does not distinguish between ?0.0f, it returns FP_ZERO for both +0.0f and -0.0f. Solution: Instead of 'fpclass', use cast float->int and double->long to check if value is +0.0f and +0.0d, respectively. This logic is already use on some architectures, for example on x86_32 and on x86_64. As 'fpclass' is not used any more, remove its declarations from globalDefintions_*. The include of ieeefp.h must be kept as we rely on some other functionality from this header on solaris. Webrev: http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/ Testing: - JPRT testing on all supported platforms (does *not* include aarch64 and ppc64) - manual testing on aarch64: All DaCapo benchmarks with the small input size. I used the default JVM flags and tested the VM w/ and w/o the fix. All benchmarks pass except eclipse. For eclipse, the same Java-level failure appears both w/ and w/o the fix, so I think the problem with eclipse is not due to these changes. I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags. Eclipse fails in this case as well. Additionally, tradebeans and tradesoap fail with a Java-level failure. As the failure happens also with both builds (w/ and w/o the fix), I don't think the problem is caused by these changes either. - no testing on ppc64: I don't have access to a ppc64 machine. Could somebody with access to a ppc64 machine please build and test the VM with this patch (and then maybe confirm that it works)? Thank you and best regards, Zoltan From vladimir.kozlov at oracle.com Thu Mar 12 14:59:34 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Mar 2015 07:59:34 -0700 Subject: [9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux In-Reply-To: <550189E5.60505@oracle.com> References: <550189E5.60505@oracle.com> Message-ID: <5501A9D6.90405@oracle.com> Looks good to me. Thanks, Vladimir On 3/12/15 5:43 AM, Zolt?n Maj? wrote: > Hi, > > > please review the following small patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074869 > > > Problem: On Linux, the C2 code generator can replace the value -0.0f with +0.0f (and also the value -0.0d with +0.0d). > The reason is that in some *.ad files both the value -0.0f and +0.0f is treated as being +0.0f and can therefore be > replaced with an immediate +0.0f embedded into an instruction. > > For example, in the sparc.ad file, the 'fpclass' function is used to decide if a float node's content is +0.0: > > predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO)); > > On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and FP_NZERO if the parameter is -0.0f. As a result, > +0.0f and -0.0f are distinguished by the compiler. > > On Linux, however, 'fpclass' is not available and therefore 'fpclassify' is used. 'fpclassify' does not distinguish > between ?0.0f, it returns FP_ZERO for both +0.0f and -0.0f. > > > Solution: Instead of 'fpclass', use cast float->int and double->long to check if value is +0.0f and +0.0d, respectively. > This logic is already use on some architectures, for example on x86_32 and on x86_64. > > As 'fpclass' is not used any more, remove its declarations from globalDefintions_*. The include of ieeefp.h must be kept > as we rely on some other functionality from this header on solaris. > > > Webrev: http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/ > > > Testing: > - JPRT testing on all supported platforms (does *not* include aarch64 and ppc64) > > - manual testing on aarch64: > > All DaCapo benchmarks with the small input size. I used the default JVM flags and tested the VM w/ and w/o the fix. All > benchmarks pass except eclipse. For eclipse, the same Java-level failure appears both w/ and w/o the fix, so I think the > problem with eclipse is not due to these changes. > > I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags. Eclipse fails in this case as well. Additionally, > tradebeans and tradesoap fail with a Java-level failure. As the failure happens also with both builds (w/ and w/o the > fix), I don't think the problem is caused by these changes either. > > - no testing on ppc64: I don't have access to a ppc64 machine. Could somebody with access to a ppc64 machine please > build and test the VM with this patch (and then maybe confirm that it works)? > > > Thank you and best regards, > > > Zoltan > From vitalyd at gmail.com Thu Mar 12 15:28:54 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 12 Mar 2015 11:28:54 -0400 Subject: [9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux In-Reply-To: <550189E5.60505@oracle.com> References: <550189E5.60505@oracle.com> Message-ID: Hi Zoltan, Is -0.0{f,d} not replaced with an immediate because the immediate then increases instruction size? Just curious ... Thanks On Thu, Mar 12, 2015 at 8:43 AM, Zolt?n Maj? wrote: > Hi, > > > please review the following small patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074869 > > > Problem: On Linux, the C2 code generator can replace the value -0.0f with > +0.0f (and also the value -0.0d with +0.0d). The reason is that in some > *.ad files both the value -0.0f and +0.0f is treated as being +0.0f and can > therefore be replaced with an immediate +0.0f embedded into an instruction. > > For example, in the sparc.ad file, the 'fpclass' function is used to > decide if a float node's content is +0.0: > > predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO)); > > On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and > FP_NZERO if the parameter is -0.0f. As a result, +0.0f and -0.0f are > distinguished by the compiler. > > On Linux, however, 'fpclass' is not available and therefore 'fpclassify' > is used. 'fpclassify' does not distinguish between ?0.0f, it returns > FP_ZERO for both +0.0f and -0.0f. > > > Solution: Instead of 'fpclass', use cast float->int and double->long to > check if value is +0.0f and +0.0d, respectively. This logic is already use > on some architectures, for example on x86_32 and on x86_64. > > As 'fpclass' is not used any more, remove its declarations from > globalDefintions_*. The include of ieeefp.h must be kept as we rely on some > other functionality from this header on solaris. > > > Webrev: http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/ > > > Testing: > - JPRT testing on all supported platforms (does *not* include aarch64 and > ppc64) > > - manual testing on aarch64: > > All DaCapo benchmarks with the small input size. I used the default JVM > flags and tested the VM w/ and w/o the fix. All benchmarks pass except > eclipse. For eclipse, the same Java-level failure appears both w/ and w/o > the fix, so I think the problem with eclipse is not due to these changes. > > I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags. > Eclipse fails in this case as well. Additionally, tradebeans and tradesoap > fail with a Java-level failure. As the failure happens also with both > builds (w/ and w/o the fix), I don't think the problem is caused by these > changes either. > > - no testing on ppc64: I don't have access to a ppc64 machine. Could > somebody with access to a ppc64 machine please build and test the VM with > this patch (and then maybe confirm that it works)? > > > Thank you and best regards, > > > Zoltan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Mar 12 16:05:11 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Mar 2015 09:05:11 -0700 Subject: [9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux In-Reply-To: References: <550189E5.60505@oracle.com> Message-ID: <5501B937.6060906@oracle.com> On 3/12/15 8:28 AM, Vitaly Davidovich wrote: > Hi Zoltan, > > Is -0.0{f,d} not replaced with an immediate because the immediate then increases instruction size? Just curious ... I did not get the question. If you look on usage of immD0/immF0 it is replaced with 0 (or G0) value which we can easy embed into instructions. It is not easy to use 0x80000000 such way. It will need to be loaded into register in separate instruction. But I think -0. is rare so it should not be a problem. Regards, Vladimir > > Thanks > > On Thu, Mar 12, 2015 at 8:43 AM, Zolt?n Maj? > wrote: > > Hi, > > > please review the following small patch. > > Bug: https://bugs.openjdk.java.net/__browse/JDK-8074869 > > > Problem: On Linux, the C2 code generator can replace the value -0.0f with +0.0f (and also the value -0.0d with > +0.0d). The reason is that in some *.ad files both the value -0.0f and +0.0f is treated as being +0.0f and can > therefore be replaced with an immediate +0.0f embedded into an instruction. > > For example, in the sparc.ad file, the 'fpclass' function is used to decide if a float node's > content is +0.0: > > predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO)); > > On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and FP_NZERO if the parameter is -0.0f. As a > result, +0.0f and -0.0f are distinguished by the compiler. > > On Linux, however, 'fpclass' is not available and therefore 'fpclassify' is used. 'fpclassify' does not distinguish > between ?0.0f, it returns FP_ZERO for both +0.0f and -0.0f. > > > Solution: Instead of 'fpclass', use cast float->int and double->long to check if value is +0.0f and +0.0d, > respectively. This logic is already use on some architectures, for example on x86_32 and on x86_64. > > As 'fpclass' is not used any more, remove its declarations from globalDefintions_*. The include of ieeefp.h must be > kept as we rely on some other functionality from this header on solaris. > > > Webrev: http://cr.openjdk.java.net/~__zmajo/8074869/webrev.00/ > > > Testing: > - JPRT testing on all supported platforms (does *not* include aarch64 and ppc64) > > - manual testing on aarch64: > > All DaCapo benchmarks with the small input size. I used the default JVM flags and tested the VM w/ and w/o the fix. > All benchmarks pass except eclipse. For eclipse, the same Java-level failure appears both w/ and w/o the fix, so I > think the problem with eclipse is not due to these changes. > > I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags. Eclipse fails in this case as well. > Additionally, tradebeans and tradesoap fail with a Java-level failure. As the failure happens also with both builds > (w/ and w/o the fix), I don't think the problem is caused by these changes either. > > - no testing on ppc64: I don't have access to a ppc64 machine. Could somebody with access to a ppc64 machine please > build and test the VM with this patch (and then maybe confirm that it works)? > > > Thank you and best regards, > > > Zoltan > > From vitalyd at gmail.com Thu Mar 12 16:10:02 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 12 Mar 2015 12:10:02 -0400 Subject: [9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux In-Reply-To: <5501B937.6060906@oracle.com> References: <550189E5.60505@oracle.com> <5501B937.6060906@oracle.com> Message-ID: > > I did not get the question. If you look on usage of immD0/immF0 it is > replaced with 0 (or G0) value which we can easy embed into instructions. It > is not easy to use 0x80000000 such way. It will need to be loaded into > register in separate instruction. You sort of answered my question :). For instructions that can take an immediate of that size (i.e. 0x8000...), I thought it wasn't being done to minimize instruction encoding size, but loading the value into a register in a separate instruction is also valid. My overall question was why -0.0 was not embedded, and I think you've answered that. Thanks On Thu, Mar 12, 2015 at 12:05 PM, Vladimir Kozlov < vladimir.kozlov at oracle.com> wrote: > On 3/12/15 8:28 AM, Vitaly Davidovich wrote: > >> Hi Zoltan, >> >> Is -0.0{f,d} not replaced with an immediate because the immediate then >> increases instruction size? Just curious ... >> > > I did not get the question. If you look on usage of immD0/immF0 it is > replaced with 0 (or G0) value which we can easy embed into instructions. It > is not easy to use 0x80000000 such way. It will need to be loaded into > register in separate instruction. > > But I think -0. is rare so it should not be a problem. > > Regards, > Vladimir > > >> Thanks >> >> On Thu, Mar 12, 2015 at 8:43 AM, Zolt?n Maj? > > wrote: >> >> Hi, >> >> >> please review the following small patch. >> >> Bug: https://bugs.openjdk.java.net/__browse/JDK-8074869 < >> https://bugs.openjdk.java.net/browse/JDK-8074869> >> >> >> Problem: On Linux, the C2 code generator can replace the value -0.0f >> with +0.0f (and also the value -0.0d with >> +0.0d). The reason is that in some *.ad files both the value -0.0f >> and +0.0f is treated as being +0.0f and can >> therefore be replaced with an immediate +0.0f embedded into an >> instruction. >> >> For example, in the sparc.ad file, the 'fpclass' >> function is used to decide if a float node's >> content is +0.0: >> >> predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO)); >> >> On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and >> FP_NZERO if the parameter is -0.0f. As a >> result, +0.0f and -0.0f are distinguished by the compiler. >> >> On Linux, however, 'fpclass' is not available and therefore >> 'fpclassify' is used. 'fpclassify' does not distinguish >> between ?0.0f, it returns FP_ZERO for both +0.0f and -0.0f. >> >> >> Solution: Instead of 'fpclass', use cast float->int and double->long >> to check if value is +0.0f and +0.0d, >> respectively. This logic is already use on some architectures, for >> example on x86_32 and on x86_64. >> >> As 'fpclass' is not used any more, remove its declarations from >> globalDefintions_*. The include of ieeefp.h must be >> kept as we rely on some other functionality from this header on >> solaris. >> >> >> Webrev: http://cr.openjdk.java.net/~__zmajo/8074869/webrev.00/ < >> http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/> >> >> >> Testing: >> - JPRT testing on all supported platforms (does *not* include aarch64 >> and ppc64) >> >> - manual testing on aarch64: >> >> All DaCapo benchmarks with the small input size. I used the default >> JVM flags and tested the VM w/ and w/o the fix. >> All benchmarks pass except eclipse. For eclipse, the same Java-level >> failure appears both w/ and w/o the fix, so I >> think the problem with eclipse is not due to these changes. >> >> I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags. >> Eclipse fails in this case as well. >> Additionally, tradebeans and tradesoap fail with a Java-level >> failure. As the failure happens also with both builds >> (w/ and w/o the fix), I don't think the problem is caused by these >> changes either. >> >> - no testing on ppc64: I don't have access to a ppc64 machine. Could >> somebody with access to a ppc64 machine please >> build and test the VM with this patch (and then maybe confirm that it >> works)? >> >> >> Thank you and best regards, >> >> >> Zoltan >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Mar 13 15:54:03 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 Mar 2015 16:54:03 +0100 Subject: [9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux In-Reply-To: <550189E5.60505@oracle.com> References: <550189E5.60505@oracle.com> Message-ID: Hi Zoltan, I've tested the change on Linux/ppc64 and AIX and it works fine. However I don't really see the bug which you pretend to fix with this change. All the Linux architectures which are in the OpenJDK use the following predicate to check for +0.0: predicate((n->getf() == 0) && (fpclassify(n->getf()) == FP_ZERO) && (signbit(n->getf()) == 0)); In particular they explicitly check the sign bit of the float/double argument which should ensure correct operation. I wrote a small regression test (added to the new webrev for your convenience [1]) which proves the correct operation with the current code. If I remove the "signbit" check the regression test will fail. Nevertheless I think your change is good because it is a nice cleanup and simplification. So please go ahead and push it. Regards, Volker PS: I've also removed some trailing whitespace from your original change [1] http://cr.openjdk.java.net/~simonis/webrevs/2015/8074869/ On Thu, Mar 12, 2015 at 1:43 PM, Zolt?n Maj? wrote: > Hi, > > > please review the following small patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8074869 > > > Problem: On Linux, the C2 code generator can replace the value -0.0f with > +0.0f (and also the value -0.0d with +0.0d). The reason is that in some *.ad > files both the value -0.0f and +0.0f is treated as being +0.0f and can > therefore be replaced with an immediate +0.0f embedded into an instruction. > > For example, in the sparc.ad file, the 'fpclass' function is used to decide > if a float node's content is +0.0: > > predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO)); > > On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and > FP_NZERO if the parameter is -0.0f. As a result, +0.0f and -0.0f are > distinguished by the compiler. > > On Linux, however, 'fpclass' is not available and therefore 'fpclassify' is > used. 'fpclassify' does not distinguish between ?0.0f, it returns FP_ZERO > for both +0.0f and -0.0f. > > > Solution: Instead of 'fpclass', use cast float->int and double->long to > check if value is +0.0f and +0.0d, respectively. This logic is already use > on some architectures, for example on x86_32 and on x86_64. > > As 'fpclass' is not used any more, remove its declarations from > globalDefintions_*. The include of ieeefp.h must be kept as we rely on some > other functionality from this header on solaris. > > > Webrev: http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/ > > > Testing: > - JPRT testing on all supported platforms (does *not* include aarch64 and > ppc64) > > - manual testing on aarch64: > > All DaCapo benchmarks with the small input size. I used the default JVM > flags and tested the VM w/ and w/o the fix. All benchmarks pass except > eclipse. For eclipse, the same Java-level failure appears both w/ and w/o > the fix, so I think the problem with eclipse is not due to these changes. > > I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags. > Eclipse fails in this case as well. Additionally, tradebeans and tradesoap > fail with a Java-level failure. As the failure happens also with both builds > (w/ and w/o the fix), I don't think the problem is caused by these changes > either. > > - no testing on ppc64: I don't have access to a ppc64 machine. Could > somebody with access to a ppc64 machine please build and test the VM with > this patch (and then maybe confirm that it works)? > > > Thank you and best regards, > > > Zoltan > From zoltan.majo at oracle.com Fri Mar 13 18:25:39 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 13 Mar 2015 19:25:39 +0100 Subject: [9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux In-Reply-To: References: <550189E5.60505@oracle.com> Message-ID: <55032BA3.1090704@oracle.com> Hi Volker, thank you for testing this patch and also for providing the test! On 03/13/2015 04:54 PM, Volker Simonis wrote: > Hi Zoltan, > > I've tested the change on Linux/ppc64 and AIX and it works fine. > > However I don't really see the bug which you pretend to fix with this change. > All the Linux architectures which are in the OpenJDK use the following > predicate to check for +0.0: > > predicate((n->getf() == 0) && > (fpclassify(n->getf()) == FP_ZERO) && (signbit(n->getf()) == 0)); > > In particular they explicitly check the sign bit of the float/double > argument which should ensure correct operation. That is correct. However, the current code explicitly makes the assumption FP_ZERO on Linux is equivalent to Solaris's FP_PZERO. That is a wrong assumption and it can be misleading. This patch changes that part of the code. Moreover, with the new code we use the same cast-based checks on all architectures. > I wrote a small regression test (added to the new webrev for your > convenience [1]) which proves the correct operation with the current > code. If I remove the "signbit" check the regression test will fail. > > Nevertheless I think your change is good because it is a nice cleanup > and simplification. So please go ahead and push it. Thank you for your feedback! Best regards, Zoltan > > Regards, > Volker > > PS: I've also removed some trailing whitespace from your original change > > [1] http://cr.openjdk.java.net/~simonis/webrevs/2015/8074869/ Thank you! > > > On Thu, Mar 12, 2015 at 1:43 PM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the following small patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074869 >> >> >> Problem: On Linux, the C2 code generator can replace the value -0.0f with >> +0.0f (and also the value -0.0d with +0.0d). The reason is that in some *.ad >> files both the value -0.0f and +0.0f is treated as being +0.0f and can >> therefore be replaced with an immediate +0.0f embedded into an instruction. >> >> For example, in the sparc.ad file, the 'fpclass' function is used to decide >> if a float node's content is +0.0: >> >> predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO)); >> >> On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and >> FP_NZERO if the parameter is -0.0f. As a result, +0.0f and -0.0f are >> distinguished by the compiler. >> >> On Linux, however, 'fpclass' is not available and therefore 'fpclassify' is >> used. 'fpclassify' does not distinguish between ?0.0f, it returns FP_ZERO >> for both +0.0f and -0.0f. >> >> >> Solution: Instead of 'fpclass', use cast float->int and double->long to >> check if value is +0.0f and +0.0d, respectively. This logic is already use >> on some architectures, for example on x86_32 and on x86_64. >> >> As 'fpclass' is not used any more, remove its declarations from >> globalDefintions_*. The include of ieeefp.h must be kept as we rely on some >> other functionality from this header on solaris. >> >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/ >> >> >> Testing: >> - JPRT testing on all supported platforms (does *not* include aarch64 and >> ppc64) >> >> - manual testing on aarch64: >> >> All DaCapo benchmarks with the small input size. I used the default JVM >> flags and tested the VM w/ and w/o the fix. All benchmarks pass except >> eclipse. For eclipse, the same Java-level failure appears both w/ and w/o >> the fix, so I think the problem with eclipse is not due to these changes. >> >> I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags. >> Eclipse fails in this case as well. Additionally, tradebeans and tradesoap >> fail with a Java-level failure. As the failure happens also with both builds >> (w/ and w/o the fix), I don't think the problem is caused by these changes >> either. >> >> - no testing on ppc64: I don't have access to a ppc64 machine. Could >> somebody with access to a ppc64 machine please build and test the VM with >> this patch (and then maybe confirm that it works)? >> >> >> Thank you and best regards, >> >> >> Zoltan >> From zoltan.majo at oracle.com Fri Mar 13 18:29:11 2015 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 13 Mar 2015 19:29:11 +0100 Subject: [9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux In-Reply-To: References: <550189E5.60505@oracle.com> Message-ID: <55032C77.8090909@oracle.com> Thank you, Vladimir, Volker, and Dean, for the review! (Dean gave his feedback in a private discussion.) Here is the patch I intend to push: http://cr.openjdk.java.net/~zmajo/8074869/webrev.01/ The patch includes Volker's test. Thank you and best regards, Zoltan On 03/13/2015 04:54 PM, Volker Simonis wrote: > Hi Zoltan, > > I've tested the change on Linux/ppc64 and AIX and it works fine. > > However I don't really see the bug which you pretend to fix with this change. > All the Linux architectures which are in the OpenJDK use the following > predicate to check for +0.0: > > predicate((n->getf() == 0) && > (fpclassify(n->getf()) == FP_ZERO) && (signbit(n->getf()) == 0)); > > In particular they explicitly check the sign bit of the float/double > argument which should ensure correct operation. > > I wrote a small regression test (added to the new webrev for your > convenience [1]) which proves the correct operation with the current > code. If I remove the "signbit" check the regression test will fail. > > Nevertheless I think your change is good because it is a nice cleanup > and simplification. So please go ahead and push it. > > Regards, > Volker > > PS: I've also removed some trailing whitespace from your original change > > [1] http://cr.openjdk.java.net/~simonis/webrevs/2015/8074869/ > > > On Thu, Mar 12, 2015 at 1:43 PM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the following small patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8074869 >> >> >> Problem: On Linux, the C2 code generator can replace the value -0.0f with >> +0.0f (and also the value -0.0d with +0.0d). The reason is that in some *.ad >> files both the value -0.0f and +0.0f is treated as being +0.0f and can >> therefore be replaced with an immediate +0.0f embedded into an instruction. >> >> For example, in the sparc.ad file, the 'fpclass' function is used to decide >> if a float node's content is +0.0: >> >> predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO)); >> >> On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and >> FP_NZERO if the parameter is -0.0f. As a result, +0.0f and -0.0f are >> distinguished by the compiler. >> >> On Linux, however, 'fpclass' is not available and therefore 'fpclassify' is >> used. 'fpclassify' does not distinguish between ?0.0f, it returns FP_ZERO >> for both +0.0f and -0.0f. >> >> >> Solution: Instead of 'fpclass', use cast float->int and double->long to >> check if value is +0.0f and +0.0d, respectively. This logic is already use >> on some architectures, for example on x86_32 and on x86_64. >> >> As 'fpclass' is not used any more, remove its declarations from >> globalDefintions_*. The include of ieeefp.h must be kept as we rely on some >> other functionality from this header on solaris. >> >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/ >> >> >> Testing: >> - JPRT testing on all supported platforms (does *not* include aarch64 and >> ppc64) >> >> - manual testing on aarch64: >> >> All DaCapo benchmarks with the small input size. I used the default JVM >> flags and tested the VM w/ and w/o the fix. All benchmarks pass except >> eclipse. For eclipse, the same Java-level failure appears both w/ and w/o >> the fix, so I think the problem with eclipse is not due to these changes. >> >> I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags. >> Eclipse fails in this case as well. Additionally, tradebeans and tradesoap >> fail with a Java-level failure. As the failure happens also with both builds >> (w/ and w/o the fix), I don't think the problem is caused by these changes >> either. >> >> - no testing on ppc64: I don't have access to a ppc64 machine. Could >> somebody with access to a ppc64 machine please build and test the VM with >> this patch (and then maybe confirm that it works)? >> >> >> Thank you and best regards, >> >> >> Zoltan >> From vladimir.kozlov at oracle.com Fri Mar 13 19:03:47 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 13 Mar 2015 12:03:47 -0700 Subject: [9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux In-Reply-To: <55032C77.8090909@oracle.com> References: <550189E5.60505@oracle.com> <55032C77.8090909@oracle.com> Message-ID: <55033493.7010204@oracle.com> Good. Thanks, Vladimir On 3/13/15 11:29 AM, Zolt?n Maj? wrote: > Thank you, Vladimir, Volker, and Dean, for the review! (Dean gave his feedback in a private discussion.) > > Here is the patch I intend to push: > > http://cr.openjdk.java.net/~zmajo/8074869/webrev.01/ > > The patch includes Volker's test. > > Thank you and best regards, > > > Zoltan > > > On 03/13/2015 04:54 PM, Volker Simonis wrote: >> Hi Zoltan, >> >> I've tested the change on Linux/ppc64 and AIX and it works fine. >> >> However I don't really see the bug which you pretend to fix with this change. >> All the Linux architectures which are in the OpenJDK use the following >> predicate to check for +0.0: >> >> predicate((n->getf() == 0) && >> (fpclassify(n->getf()) == FP_ZERO) && (signbit(n->getf()) == 0)); >> >> In particular they explicitly check the sign bit of the float/double >> argument which should ensure correct operation. >> >> I wrote a small regression test (added to the new webrev for your >> convenience [1]) which proves the correct operation with the current >> code. If I remove the "signbit" check the regression test will fail. >> >> Nevertheless I think your change is good because it is a nice cleanup >> and simplification. So please go ahead and push it. >> >> Regards, >> Volker >> >> PS: I've also removed some trailing whitespace from your original change >> >> [1] http://cr.openjdk.java.net/~simonis/webrevs/2015/8074869/ >> >> >> On Thu, Mar 12, 2015 at 1:43 PM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the following small patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074869 >>> >>> >>> Problem: On Linux, the C2 code generator can replace the value -0.0f with >>> +0.0f (and also the value -0.0d with +0.0d). The reason is that in some *.ad >>> files both the value -0.0f and +0.0f is treated as being +0.0f and can >>> therefore be replaced with an immediate +0.0f embedded into an instruction. >>> >>> For example, in the sparc.ad file, the 'fpclass' function is used to decide >>> if a float node's content is +0.0: >>> >>> predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO)); >>> >>> On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and >>> FP_NZERO if the parameter is -0.0f. As a result, +0.0f and -0.0f are >>> distinguished by the compiler. >>> >>> On Linux, however, 'fpclass' is not available and therefore 'fpclassify' is >>> used. 'fpclassify' does not distinguish between ?0.0f, it returns FP_ZERO >>> for both +0.0f and -0.0f. >>> >>> >>> Solution: Instead of 'fpclass', use cast float->int and double->long to >>> check if value is +0.0f and +0.0d, respectively. This logic is already use >>> on some architectures, for example on x86_32 and on x86_64. >>> >>> As 'fpclass' is not used any more, remove its declarations from >>> globalDefintions_*. The include of ieeefp.h must be kept as we rely on some >>> other functionality from this header on solaris. >>> >>> >>> Webrev: http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/ >>> >>> >>> Testing: >>> - JPRT testing on all supported platforms (does *not* include aarch64 and >>> ppc64) >>> >>> - manual testing on aarch64: >>> >>> All DaCapo benchmarks with the small input size. I used the default JVM >>> flags and tested the VM w/ and w/o the fix. All benchmarks pass except >>> eclipse. For eclipse, the same Java-level failure appears both w/ and w/o >>> the fix, so I think the problem with eclipse is not due to these changes. >>> >>> I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags. >>> Eclipse fails in this case as well. Additionally, tradebeans and tradesoap >>> fail with a Java-level failure. As the failure happens also with both builds >>> (w/ and w/o the fix), I don't think the problem is caused by these changes >>> either. >>> >>> - no testing on ppc64: I don't have access to a ppc64 machine. Could >>> somebody with access to a ppc64 machine please build and test the VM with >>> this patch (and then maybe confirm that it works)? >>> >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> > From volker.simonis at gmail.com Mon Mar 16 13:38:31 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 16 Mar 2015 14:38:31 +0100 Subject: [9] RFR(S): 8074869: C2 code generator can replace -0.0f with +0.0f on Linux In-Reply-To: <55032C77.8090909@oracle.com> References: <550189E5.60505@oracle.com> <55032C77.8090909@oracle.com> Message-ID: Still good:) Regards, Volker On Fri, Mar 13, 2015 at 7:29 PM, Zolt?n Maj? wrote: > Thank you, Vladimir, Volker, and Dean, for the review! (Dean gave his > feedback in a private discussion.) > > Here is the patch I intend to push: > > http://cr.openjdk.java.net/~zmajo/8074869/webrev.01/ > > The patch includes Volker's test. > > Thank you and best regards, > > > Zoltan > > > On 03/13/2015 04:54 PM, Volker Simonis wrote: >> >> Hi Zoltan, >> >> I've tested the change on Linux/ppc64 and AIX and it works fine. >> >> However I don't really see the bug which you pretend to fix with this >> change. >> All the Linux architectures which are in the OpenJDK use the following >> predicate to check for +0.0: >> >> predicate((n->getf() == 0) && >> (fpclassify(n->getf()) == FP_ZERO) && (signbit(n->getf()) == >> 0)); >> >> In particular they explicitly check the sign bit of the float/double >> argument which should ensure correct operation. >> >> I wrote a small regression test (added to the new webrev for your >> convenience [1]) which proves the correct operation with the current >> code. If I remove the "signbit" check the regression test will fail. >> >> Nevertheless I think your change is good because it is a nice cleanup >> and simplification. So please go ahead and push it. >> >> Regards, >> Volker >> >> PS: I've also removed some trailing whitespace from your original change >> >> [1] http://cr.openjdk.java.net/~simonis/webrevs/2015/8074869/ >> >> >> On Thu, Mar 12, 2015 at 1:43 PM, Zolt?n Maj? >> wrote: >>> >>> Hi, >>> >>> >>> please review the following small patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074869 >>> >>> >>> Problem: On Linux, the C2 code generator can replace the value -0.0f with >>> +0.0f (and also the value -0.0d with +0.0d). The reason is that in some >>> *.ad >>> files both the value -0.0f and +0.0f is treated as being +0.0f and can >>> therefore be replaced with an immediate +0.0f embedded into an >>> instruction. >>> >>> For example, in the sparc.ad file, the 'fpclass' function is used to >>> decide >>> if a float node's content is +0.0: >>> >>> predicate((n->getf() == 0) && (fpclass(n->getf()) == FP_PZERO)); >>> >>> On Solaris, 'fpclass' returns FP_PZERO if the parameter is +0.0f and >>> FP_NZERO if the parameter is -0.0f. As a result, +0.0f and -0.0f are >>> distinguished by the compiler. >>> >>> On Linux, however, 'fpclass' is not available and therefore 'fpclassify' >>> is >>> used. 'fpclassify' does not distinguish between ?0.0f, it returns FP_ZERO >>> for both +0.0f and -0.0f. >>> >>> >>> Solution: Instead of 'fpclass', use cast float->int and double->long to >>> check if value is +0.0f and +0.0d, respectively. This logic is already >>> use >>> on some architectures, for example on x86_32 and on x86_64. >>> >>> As 'fpclass' is not used any more, remove its declarations from >>> globalDefintions_*. The include of ieeefp.h must be kept as we rely on >>> some >>> other functionality from this header on solaris. >>> >>> >>> Webrev: http://cr.openjdk.java.net/~zmajo/8074869/webrev.00/ >>> >>> >>> Testing: >>> - JPRT testing on all supported platforms (does *not* include aarch64 and >>> ppc64) >>> >>> - manual testing on aarch64: >>> >>> All DaCapo benchmarks with the small input size. I used the default JVM >>> flags and tested the VM w/ and w/o the fix. All benchmarks pass except >>> eclipse. For eclipse, the same Java-level failure appears both w/ and w/o >>> the fix, so I think the problem with eclipse is not due to these changes. >>> >>> I also tested with the "-Xcomp -XX:-TieredCompilation -server" flags. >>> Eclipse fails in this case as well. Additionally, tradebeans and >>> tradesoap >>> fail with a Java-level failure. As the failure happens also with both >>> builds >>> (w/ and w/o the fix), I don't think the problem is caused by these >>> changes >>> either. >>> >>> - no testing on ppc64: I don't have access to a ppc64 machine. Could >>> somebody with access to a ppc64 machine please build and test the VM with >>> this patch (and then maybe confirm that it works)? >>> >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> > From volker.simonis at gmail.com Thu Mar 19 14:17:22 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 19 Mar 2015 15:17:22 +0100 Subject: RFR(XS): 8075515: AIX: cleanup xlc options and use -bernotok to detect missing symbols at build time Message-ID: Hi, can somebody please review and sponsor this change (because it requires re-generation of generated-configure.sh): http://cr.openjdk.java.net/~simonis/webrevs/2015/8075515/ https://bugs.openjdk.java.net/browse/JDK-8075515 This change adds -bernotok (which is xlc's equivalent for gcc's '-z defs') to the jdk build to detect missing symbols already at compile time (for the hotspot build this was already done by change "8067923 AIX: link libjvm.so with -bernotok to detect missing symbols at build time..."). It also removes '-q64' from the CC, CXX and LD flags in flags.m4 because '-q64' is already set by PLATFORM_SET_COMPILER_TARGET_BITS_FLAGS in platform.m4. Thank you and best regards, Volker From erik.joelsson at oracle.com Thu Mar 19 14:20:57 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 19 Mar 2015 15:20:57 +0100 Subject: RFR(XS): 8075515: AIX: cleanup xlc options and use -bernotok to detect missing symbols at build time In-Reply-To: References: Message-ID: <550ADB49.6020509@oracle.com> Looks good to me. I can push it. /Erik On 2015-03-19 15:17, Volker Simonis wrote: > Hi, > > can somebody please review and sponsor this change (because it > requires re-generation of generated-configure.sh): > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8075515/ > https://bugs.openjdk.java.net/browse/JDK-8075515 > > This change adds -bernotok (which is xlc's equivalent for gcc's '-z > defs') to the jdk build to detect missing symbols already at compile > time (for the hotspot build this was already done by change "8067923 > AIX: link libjvm.so with -bernotok to detect missing symbols at build > time..."). > > It also removes '-q64' from the CC, CXX and LD flags in flags.m4 > because '-q64' is already set by > PLATFORM_SET_COMPILER_TARGET_BITS_FLAGS in platform.m4. > > Thank you and best regards, > Volker