Re: gcc 7.3.1 build - warnings as errors in harfbuzz

2018-10-10 Thread Volker Simonis
Hi Matthias,

I've looked a little at this error and it is quite strange. First of
all, I can't reproduce it with a default gcc 7.3.0 and there doesn't
exist an official version of gcc 7.3.1 (at least I couldn't find it).
Also, I can't see the real error in the objected code. The values the
warning prints ("assuming directive output of 2147488582 bytes" and
"output 2 or more bytes (assuming 2147488583) into a destination of
size 127") seem to be excessively large. Every other reference for
this warning I could google reports much small numbers and I don't see
how a double could potentially use 2147488583 characters in the output
buffer.

Could this be a problem with the compiler you've used? Could you also
ask the people who compiled and patched it?

I did found the GCC bug "[7 Regression] -Wformat-overflow false
positive exceeding INT_MAX in glibc sysdeps/posix/tempname.c" [1]
which seem to resemble to the output you see, but that should have
been fixed  already in the 7.0 release.

Regards,
Volker

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79275

On Wed, Oct 10, 2018 at 3:14 PM Baesken, Matthias
 wrote:
>
> Hello  , when  compiling   jdk/jdk   with  gcc 7.3.1on linux x86_64 (or 
> also on   linux ppc64)   I run into this build error :
>
>
> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:
>  In function 'void hb_variation_to_string(hb_variation_t*, char*, unsigned 
> int)':
> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27:
>  error: '%g' directive output between 1 and 18446744073709551615 bytes may 
> cause result to exceed 'INT_MAX' [-Werror=format-truncation=]
>len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", 
> variation->value));
>   
> ~^
> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27:
>  note: assuming directive output of 2147488582 bytes
> cc1plus: all warnings being treated as errors
>
> (build is a product - build)
>
> Setting –disable-warnings-as-errors  works  as a workaround  ,  but of course 
> this is not really   what we want to do .
>
> Fixing  in theharfbuzz   sources  in OpenJDk  might be also not so nice 
> because it would clash with imports of new versions of harfbuzz .
> Do you think we could disable  the specific warning for the library 
> compilation ?
>
> Any other great suggestions ?
>
>
> Thanks, Matthias


Re: gcc 7.3.1 build - warnings as errors in harfbuzz

2018-10-10 Thread Erik Joelsson
GCC (since some version older than we support now) ignores disabling of 
unknown warning labels. This is a feature we depend on for these 
constructs. Without that it wouldn't be possible to list all the labels 
like this.


(We used to check for this feature in GCC in configure and only use the 
warning disabling flags if GCC properly ignored unknowns, but since we 
require a newer version than that now, we no longer need to)


/Erik


On 2018-10-10 09:10, Baesken, Matthias wrote:

Thanks.
I am a bit worried that

DISABLED_WARNINGS_gcc := format-truncation
DISABLED_WARNINGS_CXX_gcc := format-truncation


Could bring errors on older gcc versions , any ideas about this ?
(will test with gcc 4.8 of course as well )

Best regards, Matthias




-Original Message-
From: Erik Joelsson 
Sent: Mittwoch, 10. Oktober 2018 18:08
To: Baesken, Matthias ; 'build-
d...@openjdk.java.net' 
Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz

I think that's fine. This is the granularity we have.

/Erik


On 2018-10-10 09:02, Baesken, Matthias wrote:

Hi Erik,  so I think I could disable  the warning here :


Awt2dLibraries.gmk
-

$(eval $(call SetupJdkLibrary, BUILD_LIBFONTMANAGER, \
  NAME := fontmanager, \

  WARNINGS_AS_ERRORS_xlc := false, \
  DISABLED_WARNINGS_gcc := format-truncation sign-compare int-to-

pointer-cast \

  type-limits missing-field-initializers implicit-fallthrough \
  strict-aliasing undef unused-function, \
  DISABLED_WARNINGS_CXX_gcc := format-truncation  reorder delete-

non-virtual-dtor strict-overflow \

  maybe-uninitialized, \
   ...

(add   format-truncationfor gcc in the  warning-disabling section).
However this would disable it also for other versions of gcc  where the

issue never showed up .

Do you think this is fine  (and safe for older gcc) ?


Best regards, Matthias


-Original Message-
From: Erik Joelsson 
Sent: Mittwoch, 10. Oktober 2018 17:33
To: Baesken, Matthias ; 'build-
d...@openjdk.java.net' 
Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz

In this case, disabling the warning seems like the right thing to do.

/Erik


On 2018-10-10 06:14, Baesken, Matthias wrote:

Hello  , when  compiling   jdk/jdk   with  gcc 7.3.1on linux x86_64 (or also

on   linux ppc64)   I run into this build error :



/open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag

er/harfbuzz/hb-common.cc: In function 'void
hb_variation_to_string(hb_variation_t*, char*, unsigned int)':


/open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag

er/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between

1

and 18446744073709551615 bytes may cause result to exceed 'INT_MAX'

[-

Werror=format-truncation=]

  len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g",

variation-

value));


~^




/open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag

er/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of
2147488582 bytes

cc1plus: all warnings being treated as errors

(build is a product - build)

Setting –disable-warnings-as-errors  works  as a workaround  ,  but of

course this is not really   what we want to do .

Fixing  in theharfbuzz   sources  in OpenJDk  might be also not so nice

because it would clash with imports of new versions of harfbuzz .

Do you think we could disable  the specific warning for the library

compilation ?

Any other great suggestions  ?


Thanks, Matthias




RE: gcc 7.3.1 build - warnings as errors in harfbuzz

2018-10-10 Thread Baesken, Matthias
Thanks.
I am a bit worried that

DISABLED_WARNINGS_gcc := format-truncation
DISABLED_WARNINGS_CXX_gcc := format-truncation  


Could bring errors on older gcc versions , any ideas about this ?
(will test with gcc 4.8 of course as well )

Best regards, Matthias



> -Original Message-
> From: Erik Joelsson 
> Sent: Mittwoch, 10. Oktober 2018 18:08
> To: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' 
> Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz
> 
> I think that's fine. This is the granularity we have.
> 
> /Erik
> 
> 
> On 2018-10-10 09:02, Baesken, Matthias wrote:
> > Hi Erik,  so I think I could disable  the warning here :
> >
> >
> > Awt2dLibraries.gmk
> > -
> >
> > $(eval $(call SetupJdkLibrary, BUILD_LIBFONTMANAGER, \
> >  NAME := fontmanager, \
> >
> >  WARNINGS_AS_ERRORS_xlc := false, \
> >  DISABLED_WARNINGS_gcc := format-truncation sign-compare int-to-
> pointer-cast \
> >  type-limits missing-field-initializers implicit-fallthrough \
> >  strict-aliasing undef unused-function, \
> >  DISABLED_WARNINGS_CXX_gcc := format-truncation  reorder delete-
> non-virtual-dtor strict-overflow \
> >  maybe-uninitialized, \
> >   ...
> >
> > (add   format-truncationfor gcc in the  warning-disabling section).
> > However this would disable it also for other versions of gcc  where the
> issue never showed up .
> >
> > Do you think this is fine  (and safe for older gcc) ?
> >
> >
> > Best regards, Matthias
> >
> >> -Original Message-
> >> From: Erik Joelsson 
> >> Sent: Mittwoch, 10. Oktober 2018 17:33
> >> To: Baesken, Matthias ; 'build-
> >> d...@openjdk.java.net' 
> >> Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz
> >>
> >> In this case, disabling the warning seems like the right thing to do.
> >>
> >> /Erik
> >>
> >>
> >> On 2018-10-10 06:14, Baesken, Matthias wrote:
> >>> Hello  , when  compiling   jdk/jdk   with  gcc 7.3.1on linux x86_64 
> >>> (or also
> >> on   linux ppc64)   I run into this build error :
> >>>
> >>>
> >>
> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag
> >> er/harfbuzz/hb-common.cc: In function 'void
> >> hb_variation_to_string(hb_variation_t*, char*, unsigned int)':
> >>
> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag
> >> er/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between
> 1
> >> and 18446744073709551615 bytes may cause result to exceed 'INT_MAX'
> [-
> >> Werror=format-truncation=]
> >>>  len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g",
> variation-
> >>> value));
> >>>
> >>
> ~^
> >> 
> >>
> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag
> >> er/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of
> >> 2147488582 bytes
> >>> cc1plus: all warnings being treated as errors
> >>>
> >>> (build is a product - build)
> >>>
> >>> Setting –disable-warnings-as-errors  works  as a workaround  ,  but of
> >> course this is not really   what we want to do .
> >>> Fixing  in theharfbuzz   sources  in OpenJDk  might be also not so 
> >>> nice
> >> because it would clash with imports of new versions of harfbuzz .
> >>> Do you think we could disable  the specific warning for the library
> >> compilation ?
> >>> Any other great suggestions  ?
> >>>
> >>>
> >>> Thanks, Matthias



Re: gcc 7.3.1 build - warnings as errors in harfbuzz

2018-10-10 Thread Erik Joelsson

I think that's fine. This is the granularity we have.

/Erik


On 2018-10-10 09:02, Baesken, Matthias wrote:

Hi Erik,  so I think I could disable  the warning here :


Awt2dLibraries.gmk
-

$(eval $(call SetupJdkLibrary, BUILD_LIBFONTMANAGER, \
 NAME := fontmanager, \
   
 WARNINGS_AS_ERRORS_xlc := false, \
 DISABLED_WARNINGS_gcc := format-truncation sign-compare 
int-to-pointer-cast \
 type-limits missing-field-initializers implicit-fallthrough \
 strict-aliasing undef unused-function, \
 DISABLED_WARNINGS_CXX_gcc := format-truncation  reorder 
delete-non-virtual-dtor strict-overflow \
 maybe-uninitialized, \
  ...

(add   format-truncationfor gcc in the  warning-disabling section).
However this would disable it also for other versions of gcc  where the issue 
never showed up .

Do you think this is fine  (and safe for older gcc) ?


Best regards, Matthias


-Original Message-
From: Erik Joelsson 
Sent: Mittwoch, 10. Oktober 2018 17:33
To: Baesken, Matthias ; 'build-
d...@openjdk.java.net' 
Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz

In this case, disabling the warning seems like the right thing to do.

/Erik


On 2018-10-10 06:14, Baesken, Matthias wrote:

Hello  , when  compiling   jdk/jdk   with  gcc 7.3.1on linux x86_64 (or also

on   linux ppc64)   I run into this build error :




/open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag
er/harfbuzz/hb-common.cc: In function 'void
hb_variation_to_string(hb_variation_t*, char*, unsigned int)':
/open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag
er/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between 1
and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' [-
Werror=format-truncation=]

 len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", variation-
value));


~^

/open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag
er/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of
2147488582 bytes

cc1plus: all warnings being treated as errors

(build is a product - build)

Setting –disable-warnings-as-errors  works  as a workaround  ,  but of

course this is not really   what we want to do .

Fixing  in theharfbuzz   sources  in OpenJDk  might be also not so nice

because it would clash with imports of new versions of harfbuzz .

Do you think we could disable  the specific warning for the library

compilation ?

Any other great suggestions  ?


Thanks, Matthias




RE: gcc 7.3.1 build - warnings as errors in harfbuzz

2018-10-10 Thread Baesken, Matthias
Hi Erik,  so I think I could disable  the warning here :


Awt2dLibraries.gmk
-

$(eval $(call SetupJdkLibrary, BUILD_LIBFONTMANAGER, \
NAME := fontmanager, \
  
WARNINGS_AS_ERRORS_xlc := false, \
DISABLED_WARNINGS_gcc := format-truncation sign-compare int-to-pointer-cast 
\
type-limits missing-field-initializers implicit-fallthrough \
strict-aliasing undef unused-function, \
DISABLED_WARNINGS_CXX_gcc := format-truncation  reorder 
delete-non-virtual-dtor strict-overflow \
maybe-uninitialized, \
 ...

(add   format-truncationfor gcc in the  warning-disabling section).
However this would disable it also for other versions of gcc  where the issue 
never showed up .

Do you think this is fine  (and safe for older gcc) ?


Best regards, Matthias

> -Original Message-
> From: Erik Joelsson 
> Sent: Mittwoch, 10. Oktober 2018 17:33
> To: Baesken, Matthias ; 'build-
> d...@openjdk.java.net' 
> Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz
> 
> In this case, disabling the warning seems like the right thing to do.
> 
> /Erik
> 
> 
> On 2018-10-10 06:14, Baesken, Matthias wrote:
> > Hello  , when  compiling   jdk/jdk   with  gcc 7.3.1on linux x86_64 (or 
> > also
> on   linux ppc64)   I run into this build error :
> >
> >
> >
> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag
> er/harfbuzz/hb-common.cc: In function 'void
> hb_variation_to_string(hb_variation_t*, char*, unsigned int)':
> >
> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag
> er/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between 1
> and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' [-
> Werror=format-truncation=]
> > len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", 
> > variation-
> >value));
> >
> ~^
> 
> >
> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag
> er/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of
> 2147488582 bytes
> > cc1plus: all warnings being treated as errors
> >
> > (build is a product - build)
> >
> > Setting –disable-warnings-as-errors  works  as a workaround  ,  but of
> course this is not really   what we want to do .
> >
> > Fixing  in theharfbuzz   sources  in OpenJDk  might be also not so nice
> because it would clash with imports of new versions of harfbuzz .
> > Do you think we could disable  the specific warning for the library
> compilation ?
> >
> > Any other great suggestions  ?
> >
> >
> > Thanks, Matthias



Re: RFR: 8212008: Use of TREAT_EXIT_CODE_1_AS_0 hide problems with jtreg Java

2018-10-10 Thread Erik Joelsson

Looks good.

A side effect of this is that if no tests are found (also returns 1), 
make will fail. In our CI system, this will be interpreted as NOT_RUN 
"no tests found", which is actually an improvement from PASSED "total 0, 
passed 0, failed 0" as it will be more visible.


/Erik


On 2018-10-10 08:47, Christian Tornqvist wrote:

Hi,

When running JDK and Hotspot jtreg tests through make, TREAT_EXIT_CODE_1_AS_0 
is set to true. Any issue with the Java installation used to run jtreg won’t be 
reflected in the exit code. This has been seen a bunch of times in our internal 
CI system where we thought we ran tests but instead no tests were run at all 
because the jtreg Java installation had been deleted/corrupted.

Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8212008/webrev.00/ 

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


Thanks,
Christian




RFR: 8212008: Use of TREAT_EXIT_CODE_1_AS_0 hide problems with jtreg Java

2018-10-10 Thread Christian Tornqvist
Hi,

When running JDK and Hotspot jtreg tests through make, TREAT_EXIT_CODE_1_AS_0 
is set to true. Any issue with the Java installation used to run jtreg won’t be 
reflected in the exit code. This has been seen a bunch of times in our internal 
CI system where we thought we ran tests but instead no tests were run at all 
because the jtreg Java installation had been deleted/corrupted. 

Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8212008/webrev.00/ 

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


Thanks,
Christian

Re: RFR: 8212004: Optional compile_commands.json field not compatible with older libclang

2018-10-10 Thread Erik Joelsson

Looks good.

/Erik


On 2018-10-10 07:02, Robin Westberg wrote:

Hi all,

Please review this small change to remove the “output” field from the 
compile_commands.json file generated by “make compile-commands”. As it turns 
out, this optional field is incompatible with tooling built on libclang 
versions older than 4.0. As this field provides no real benefit for us, it can 
simply be dropped from the output.

Issue: https://bugs.openjdk.java.net/browse/JDK-8212004
Webrev: https://cr.openjdk.java.net/~rwestberg/8212004/webrev.00/
Testing: tier1, builds-tier5

Best regards,
Robin




Re: gcc 7.3.1 build - warnings as errors in harfbuzz

2018-10-10 Thread Erik Joelsson

In this case, disabling the warning seems like the right thing to do.

/Erik


On 2018-10-10 06:14, Baesken, Matthias wrote:

Hello  , when  compiling   jdk/jdk   with  gcc 7.3.1on linux x86_64 (or 
also on   linux ppc64)   I run into this build error :


/open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:
 In function 'void hb_variation_to_string(hb_variation_t*, char*, unsigned 
int)':
/open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27:
 error: '%g' directive output between 1 and 18446744073709551615 bytes may 
cause result to exceed 'INT_MAX' [-Werror=format-truncation=]
len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", 
variation->value));
   
~^
/open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27:
 note: assuming directive output of 2147488582 bytes
cc1plus: all warnings being treated as errors

(build is a product - build)

Setting –disable-warnings-as-errors  works  as a workaround  ,  but of course 
this is not really   what we want to do .

Fixing  in theharfbuzz   sources  in OpenJDk  might be also not so nice 
because it would clash with imports of new versions of harfbuzz .
Do you think we could disable  the specific warning for the library compilation 
?

Any other great suggestions  ?


Thanks, Matthias




RFR: 8212004: Optional compile_commands.json field not compatible with older libclang

2018-10-10 Thread Robin Westberg
Hi all,

Please review this small change to remove the “output” field from the 
compile_commands.json file generated by “make compile-commands”. As it turns 
out, this optional field is incompatible with tooling built on libclang 
versions older than 4.0. As this field provides no real benefit for us, it can 
simply be dropped from the output.

Issue: https://bugs.openjdk.java.net/browse/JDK-8212004
Webrev: https://cr.openjdk.java.net/~rwestberg/8212004/webrev.00/
Testing: tier1, builds-tier5

Best regards,
Robin

gcc 7.3.1 build - warnings as errors in harfbuzz

2018-10-10 Thread Baesken, Matthias
Hello  , when  compiling   jdk/jdk   with  gcc 7.3.1on linux x86_64 (or 
also on   linux ppc64)   I run into this build error :


/open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:
 In function 'void hb_variation_to_string(hb_variation_t*, char*, unsigned 
int)':
/open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27:
 error: '%g' directive output between 1 and 18446744073709551615 bytes may 
cause result to exceed 'INT_MAX' [-Werror=format-truncation=]
   len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", 
variation->value));
  
~^
/open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27:
 note: assuming directive output of 2147488582 bytes
cc1plus: all warnings being treated as errors

(build is a product - build)

Setting –disable-warnings-as-errors  works  as a workaround  ,  but of course 
this is not really   what we want to do .

Fixing  in theharfbuzz   sources  in OpenJDk  might be also not so nice 
because it would clash with imports of new versions of harfbuzz .
Do you think we could disable  the specific warning for the library compilation 
?

Any other great suggestions  ?


Thanks, Matthias