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

2018-09-06 Thread Lindenmaier, Goetz
Yes, that's fine. 

I can sponsor it tomorrow. I'm not in the office today.

Best regards,
  Goetz.

> -Original Message-
> From: Andrew Leonard 
> Sent: Donnerstag, 6. September 2018 12:29
> To: Magnus Ihse Bursie ; Lindenmaier, Goetz
> 
> Cc: 2d-dev <2d-...@openjdk.java.net>; Brian Burkhalter
> ; build-dev ; core-
> libs-dev ; Philip Race
> 
> Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors on
> zLinux
> 
> Thanks Magnus,
> 
> Hi Goetz, we have agreement from both library owners, so I think we're good
> now?
> Thanks
> Andrew
> 
> 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:Magnus Ihse Bursie 
> To:Andrew Leonard 
> Cc:Brian Burkhalter , 2d-dev <2d-
> d...@openjdk.java.net>, build-dev , core-libs-dev
> , "Lindenmaier, Goetz"
> , Philip Race 
> Date:04/09/2018 16:41
> Subject:Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors 
> on
> zLinux
> 
> 
> 
> 
> 
> 
> Looks good to me.
> 
> /Magnus
> 
> 4 sep. 2018 kl. 12:11 skrev Andrew Leonard  <mailto:andrew_m_leon...@uk.ibm.com> >:
> 
> 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/
> <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) &

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

2018-09-06 Thread Andrew Leonard
Thanks Magnus,

Hi Goetz, we have agreement from both library owners, so I think we're 
good now?
Thanks
Andrew

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:   Magnus Ihse Bursie 
To: Andrew Leonard 
Cc: Brian Burkhalter , 2d-dev 
<2d-...@openjdk.java.net>, build-dev , 
core-libs-dev , "Lindenmaier, Goetz" 
, Philip Race 
Date:   04/09/2018 16:41
Subject:    Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler 
errors on zLinux



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 int

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

2018-09-04 Thread 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
> Phon

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

2018-09-04 Thread 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 f

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

2018-08-31 Thread Brian Burkhalter


On Aug 31, 2018, at 2:28 AM, Magnus Ihse Bursie  
wrote:

>> Magnus, Philip, Brian, Goetz, can we have a vote? => "Fix" or 
>> "DisableWarnings" ?
> 
> Note that this decision can be different for the two libraries. I'd argue 
> that the maintainer of each library decides. And if so, it seems to 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 
mediaLib as Phil indicated in e-mail.

Thanks,

Brian

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

2018-08-31 Thread Magnus Ihse Bursie




On 2018-08-31 11:14, Andrew Leonard wrote:

Hi,
So there seems to be varying opinion here, taking the 2D view point 
since it is going to be maintained, the opinion seems to be more with 
the fix (http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ 
<http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.00/>). This 
would be my personal preference also, but previous comments seemed to 
prefer compiler options.


Looking at each error:
- */libfdlibm/k_rem_pio2.c* : This is a simple "for" loop bound check, 
which with good programming practice should really have been there to 
prevent ArrayOutOfBounds.. or native overwrites.. Simple fix.
- *libmlib_image/mlib_ImageLookUp_Bit.c* : This is -ve bit shifting 
which is spec undefined, which in theory could mean it breaks in the 
future if we upgrade/change compiler... However, this is complex code, 
we need to be very sure the new fix is "correct", myself and my 
colleague here have examined it closely and are happy, but i'd 
appreciate your in-depth analysis please. 
It looks good. The intention of the old code has clearly been to have an 
32 or 64-bit wide all-1s bitmask, and this is what your fix delivers as 
well.





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.


/Magnus





Thanks
Andrew

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: Magnus Ihse Bursie 
To: Philip Race , Brian Burkhalter 

Cc: 2d-dev <2d-...@openjdk.java.net>, build-dev 
, Andrew Leonard 
, core-libs-dev 


Date: 31/08/2018 09:27
Subject: Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler errors 
on zLinux





On 2018-08-31 01:28, Philip Race wrote:
> Some day, I'd like to replace a lot of medialib functionality with
> something
> like the proposed Vector API. But that is far enough away that
> medialib needs
> to be maintained, and unlike a previous discussion about a similar
> issue in
> the JPEG library, we are on the hook for maintaining medialib.
> So if there is an actual logic error in medialib, I'd prefer to fix it.
> If the issue is a false positive, I'd be OK to disable the warning,
> but wrapped
> in a platform-specific manner. So is it a real error here ?

Gcc is emitting a warning due to shifting of negative values, which is
deemed undefined behavior by the spec.

Is this a real error? Well. Undefined behavior is no good. It can work
for now and then suddenly start breaking.

The originally suggested code change
(http://cr.openjdk.java.net/~aleonard/8209786/webrev.00 
<http://cr.openjdk.java.net/%7Ealeonard/8209786/webrev.00>) seems

reasonable to me. It is at the very least much clearer what the
intention is. And it's conformant with the spec.

So I'd advocate using that fix, if you want to continue supporting the
library.

/Magnus




>
> -phil.
>
> On 8/30/18, 3:37 PM, Brian Burkhalter wrote:
>> Hi Andrew,
>>
>> As noted in the issue comments, the fdlibm C code is obsolescent and
>> eventually to be superseded by equivalent Java implementations. As
>> for the mediaLib code being moribund I cannot speak but am copying
>> 2d-dev which owns java.desktop.
>>
>> Thanks,
>>
>> Brian
>>
>> On Aug 30, 2018, at 6:03 AM, Andrew Leonard
>> mailto:andrew_m_leon...@uk.ibm.com>>
>> wrote:
>>
>>> Thanks Magnus,
>>> Yes, these libraries are moribound it seems, hence their preference
>>> for compile options..
>>> Cheers
>>> Andrew
>>>
>>> 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
>>> <mailto:andrew_m_leon...@uk.ibm.com>
>>>
>>>
>>>
>>>
>>> From: Magnus Ihse Bursie >> <mailto:magnus.ihse.bur...@oracle.com>>
>>> To: Andrew Leonard >> <mailto:andrew_m_leon...@uk.ibm.com>>, Brian Burkhalter
>>> mailto:brian.burkhal...@oracle.com>>
>>> Cc: core-libs-...@openjdk.java.net
>>> <mailto:core-libs-...@openjdk.java.net>, build-dev
>>> mailto:build-dev@openjdk.java.net>>
>>> Date: 30/08/2018 13:49
>>> Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
>>> 
---

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

2018-08-31 Thread Andrew Leonard
Hi,
So there seems to be varying opinion here, taking the 2D view point since 
it is going to be maintained, the opinion seems to be more with the fix (
http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/). This would be my 
personal preference also, but previous comments seemed to prefer compiler 
options.

Looking at each error:
- /libfdlibm/k_rem_pio2.c : This is a simple "for" loop bound check, which 
with good programming practice should really have been there to prevent 
ArrayOutOfBounds.. or native overwrites.. Simple fix.
- libmlib_image/mlib_ImageLookUp_Bit.c : This is -ve bit shifting which is 
spec undefined, which in theory could mean it breaks in the future if we 
upgrade/change compiler... However, this is complex code, we need to be 
very sure the new fix is "correct", myself and my colleague here have 
examined it closely and are happy, but i'd appreciate your in-depth 
analysis please. 

Magnus, Philip, Brian, Goetz, can we have a vote? => "Fix" or 
"DisableWarnings" ?

Thanks
Andrew

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:   Magnus Ihse Bursie 
To: Philip Race , Brian Burkhalter 

Cc: 2d-dev <2d-...@openjdk.java.net>, build-dev 
, Andrew Leonard 
, core-libs-dev 

Date:   31/08/2018 09:27
Subject:        Re: [OpenJDK 2D-Dev] RFR JDK-8209786: gcc 7.3 compiler 
errors on zLinux



On 2018-08-31 01:28, Philip Race wrote:
> Some day, I'd like to replace a lot of medialib functionality with 
> something
> like the proposed Vector API. But that is far enough away that 
> medialib needs
> to be maintained, and unlike a previous discussion about a similar 
> issue in
> the JPEG library, we are on the hook for maintaining medialib.
> So if there is an actual logic error in medialib, I'd prefer to fix it.
> If the issue is a false positive, I'd be OK to disable the warning, 
> but wrapped
> in a platform-specific manner. So is it a real error here ?

Gcc is emitting a warning due to shifting of negative values, which is 
deemed undefined behavior by the spec.

Is this a real error? Well. Undefined behavior is no good. It can work 
for now and then suddenly start breaking.

The originally suggested code change 
(
http://cr.openjdk.java.net/~aleonard/8209786/webrev.00
) seems 
reasonable to me. It is at the very least much clearer what the 
intention is. And it's conformant with the spec.

So I'd advocate using that fix, if you want to continue supporting the 
library.

/Magnus




>
> -phil.
>
> On 8/30/18, 3:37 PM, Brian Burkhalter wrote:
>> Hi Andrew,
>>
>> As noted in the issue comments, the fdlibm C code is obsolescent and 
>> eventually to be superseded by equivalent Java implementations. As 
>> for the mediaLib code being moribund I cannot speak but am copying 
>> 2d-dev which owns java.desktop.
>>
>> Thanks,
>>
>> Brian
>>
>> On Aug 30, 2018, at 6:03 AM, Andrew Leonard 
>> mailto:andrew_m_leon...@uk.ibm.com>> 
>> wrote:
>>
>>> Thanks Magnus,
>>> Yes, these libraries are moribound it seems, hence their preference 
>>> for compile options..
>>> Cheers
>>> Andrew
>>>
>>> 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 
>>> <mailto:andrew_m_leon...@uk.ibm.com>
>>>
>>>
>>>
>>>
>>> From: Magnus Ihse Bursie >> <mailto:magnus.ihse.bur...@oracle.com>>
>>> To: Andrew Leonard >> <mailto:andrew_m_leon...@uk.ibm.com>>, Brian Burkhalter 
>>> mailto:brian.burkhal...@oracle.com>>
>>> Cc: core-libs-...@openjdk.java.net 
>>> <mailto:core-libs-...@openjdk.java.net>, build-dev 
>>> mailto:build-dev@openjdk.java.net>>
>>> Date: 30/08/2018 13:49
>>> Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
>>> 
 
>>>
>>>
>>>
>>>
>>> Andrew,
>>>
>>> If you want to make changes to the build system (files in make/*),
>>> please always include build-dev in the reviews.
>>>
>>> From a build point, this fix looks okay. My general preference is to
>>> fix shady code instead of disabling warnings, but in this case it's in
>>> two libraries that are either external or moribound, so if the
>>> maintainer's of the respective libraries want to avoid code changes, I
>>

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

2018-08-31 Thread Magnus Ihse Bursie

On 2018-08-31 01:28, Philip Race wrote:
Some day, I'd like to replace a lot of medialib functionality with 
something
like the proposed Vector API. But that is far enough away that 
medialib needs
to be maintained, and unlike a previous discussion about a similar 
issue in

the JPEG library, we are on the hook for maintaining medialib.
So if there is an actual logic error in medialib, I'd prefer to fix it.
If the issue is a false positive, I'd be OK to disable the warning, 
but wrapped

in a platform-specific manner. So is it a real error here ?


Gcc is emitting a warning due to shifting of negative values, which is 
deemed undefined behavior by the spec.


Is this a real error? Well. Undefined behavior is no good. It can work 
for now and then suddenly start breaking.


The originally suggested code change 
(http://cr.openjdk.java.net/~aleonard/8209786/webrev.00) seems 
reasonable to me. It is at the very least much clearer what the 
intention is. And it's conformant with the spec.


So I'd advocate using that fix, if you want to continue supporting the 
library.


/Magnus






-phil.

On 8/30/18, 3:37 PM, Brian Burkhalter wrote:

Hi Andrew,

As noted in the issue comments, the fdlibm C code is obsolescent and 
eventually to be superseded by equivalent Java implementations. As 
for the mediaLib code being moribund I cannot speak but am copying 
2d-dev which owns java.desktop.


Thanks,

Brian

On Aug 30, 2018, at 6:03 AM, Andrew Leonard 
mailto:andrew_m_leon...@uk.ibm.com>> 
wrote:



Thanks Magnus,
Yes, these libraries are moribound it seems, hence their preference 
for compile options..

Cheers
Andrew

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: Magnus Ihse Bursie >
To: Andrew Leonard >, Brian Burkhalter 
mailto:brian.burkhal...@oracle.com>>
Cc: core-libs-...@openjdk.java.net 
, build-dev 
mailto:build-dev@openjdk.java.net>>

Date: 30/08/2018 13:49
Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
 





Andrew,

If you want to make changes to the build system (files in make/*),
please always include build-dev in the reviews.

From a build point, this fix looks okay. My general preference is to
fix shady code instead of disabling warnings, but in this case it's in
two libraries that are either external or moribound, so if the
maintainer's of the respective libraries want to avoid code changes, I
accept that.

/Magnus


On 2018-08-30 14:18, Andrew Leonard wrote:
> Hi Brian,
> Thanks for taking a look at this, I have just done a rebuild with 
a new

> patch with appropriate gcc disable warnings for these libraries:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/ 

> This works fine, so if you think this is a more favourable 
approach for

> these libraries? i'd like to get this merged please.
> Thanks
> Andrew
>
> 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: Andrew Leonard >
> Cc: core-libs-...@openjdk.java.net 


> Date:   28/08/2018 15:52
> Subject:    Re: RFR JDK-8209786: gcc 7.3 compiler errors on 
zLinux

>
>
>
> Hi Andrew,
>
> It was suggested that it would be preferable to dial down the 
compilation
> settings for the fdlibm code rather than make a source code 
change. Was

> this investigated?
>
> Thanks,
>
> Brian
>
> On Aug 28, 2018, at 7:18 AM, Andrew Leonard 
mailto:andrew_m_leon...@uk.ibm.com>>

> wrote:
>
> We have discovered issues with gcc 7.3 on zLinux, combined with 
OpenJDK's
> default compiler options has highlighted a couple of native code 
issues,

> with undefined behaviours:
>   - validating loop test array bounds
>   - left shifts of negative values
> I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
> and attached the webrev fix here:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ 


>
> This has already been discussed and refined on the "s390x-port-dev"
> maillist
> and as it was pointed out, it should have been posted here...
>
> I'd like to request a sponsor for this fix please?
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with 
number

> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
PO6 3AU







Unless stated otherwise above:
IBM United 

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

2018-08-30 Thread Philip Race

Some day, I'd like to replace a lot of medialib functionality with something
like the proposed Vector API. But that is far enough away that medialib 
needs

to be maintained, and unlike a previous discussion about a similar issue in
the JPEG library, we are on the hook for maintaining medialib.
So if there is an actual logic error in medialib, I'd prefer to fix it.
If the issue is a false positive, I'd be OK to disable the warning, but 
wrapped

in a platform-specific manner. So is it a real error here ?

-phil.

On 8/30/18, 3:37 PM, Brian Burkhalter wrote:

Hi Andrew,

As noted in the issue comments, the fdlibm C code is obsolescent and 
eventually to be superseded by equivalent Java implementations. As for 
the mediaLib code being moribund I cannot speak but am copying 2d-dev 
which owns java.desktop.


Thanks,

Brian

On Aug 30, 2018, at 6:03 AM, Andrew Leonard 
mailto:andrew_m_leon...@uk.ibm.com>> wrote:



Thanks Magnus,
Yes, these libraries are moribound it seems, hence their preference 
for compile options..

Cheers
Andrew

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: Magnus Ihse Bursie >
To: Andrew Leonard >, Brian Burkhalter 
mailto:brian.burkhal...@oracle.com>>
Cc: core-libs-...@openjdk.java.net 
, build-dev 
mailto:build-dev@openjdk.java.net>>

Date: 30/08/2018 13:49
Subject: Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux




Andrew,

If you want to make changes to the build system (files in make/*),
please always include build-dev in the reviews.

From a build point, this fix looks okay. My general preference is to
fix shady code instead of disabling warnings, but in this case it's in
two libraries that are either external or moribound, so if the
maintainer's of the respective libraries want to avoid code changes, I
accept that.

/Magnus


On 2018-08-30 14:18, Andrew Leonard wrote:
> Hi Brian,
> Thanks for taking a look at this, I have just done a rebuild with a new
> patch with appropriate gcc disable warnings for these libraries:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.01/ 


> This works fine, so if you think this is a more favourable approach for
> these libraries? i'd like to get this merged please.
> Thanks
> Andrew
>
> 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: Andrew Leonard >
> Cc: core-libs-...@openjdk.java.net 


> Date:   28/08/2018 15:52
> Subject:Re: RFR JDK-8209786: gcc 7.3 compiler errors on zLinux
>
>
>
> Hi Andrew,
>
> It was suggested that it would be preferable to dial down the 
compilation

> settings for the fdlibm code rather than make a source code change. Was
> this investigated?
>
> Thanks,
>
> Brian
>
> On Aug 28, 2018, at 7:18 AM, Andrew Leonard 
mailto:andrew_m_leon...@uk.ibm.com>>

> wrote:
>
> We have discovered issues with gcc 7.3 on zLinux, combined with 
OpenJDK's

> default compiler options has highlighted a couple of native code issues,
> with undefined behaviours:
>   - validating loop test array bounds
>   - left shifts of negative values
> I have created bug https://bugs.openjdk.java.net/browse/JDK-8209786
> and attached the webrev fix here:
> http://cr.openjdk.java.net/~aleonard/8209786/webrev.00/ 


>
> This has already been discussed and refined on the "s390x-port-dev"
> maillist
> and as it was pointed out, it should have been posted here...
>
> I'd like to request a sponsor for this fix please?
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
PO6 3AU







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with 
number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
PO6 3AU