build issues after 8211029 on gcc4.8 and our porting Linux platforms (ppc64(le)/ s390x)

[Magnus Ihse Bursie]

On 2018-09-25 16:33, Baesken, Matthias wrote:
> Hello, it looks like
>
> 8211029: Have a common set of enabled warnings for all native libraries
>
> breaks a lot of our Linux based builds.
> Our gcc 4.8   misses some of the introduced command line options :
>
> cc1plus: error: unrecognized command line option "-Wno-misleading-indentation" [-Werror]
> cc1plus: error: unrecognized command line option "-Wno-implicit-fallthrough" [-Werror]
> cc1plus: error: unrecognized command line option "-Wno-int-in-bool-context" [-Werror]
You can just ignore this. It's a red herring.

The way gcc error handling works is that if you pass -Wno-FOOBAR, and 
that version of gcc does not recoginze FOOBAR as a warning, it will just 
silently ignore it -- as long as there is no other warnings/errors in 
the file.

If, on the other hand, something else causes a warning or an error (I'm 
not sure if a warning is enough, it might need to be an error or a 
warning promoted to error), gcc will then *also* print out the 
-Wno-FOOBARs it does not recognize.
> Additionally ,  the added -Werror=switch  triggers a LOT of errors on our  porting platforms, e.g.  linux ppc64 le :
>
> /build_ci_jdk_jdk_linuxppc64le/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:719:10: error: enumeration value '_Double_valueOf' not handled in switch [-Werror=switch]
> /build_ci_jdk_jdk_linuxppc64le/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:719:10: error: enumeration value '_forEachRemaining' not handled in switch [-Werror=switch]
> /build_ci_jdk_jdk_linuxppc64le/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:719:10: error: enumeration value 'ID_LIMIT' not handled in switch [-Werror=switch]
> /build_ci_jdk_jdk_linuxppc64le/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:719:10: error: enumeration value 'LAST_COMPILER_INLINE' not handled in switch [-Werror=switch]
> /build_ci_jdk_jdk_linuxppc64le/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:719:10: error: enumeration value 'FIRST_MH_SIG_POLY' not handled in switch [-Werror=switch]
> /build_ci_jdk_jdk_linuxppc64le/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:719:10: error: enumeration value 'FIRST_MH_STATIC' not handled in switch [-Werror=switch]
> /build_ci_jdk_jdk_linuxppc64le/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:719:10: error: enumeration value 'LAST_MH_SIG_POLY' not handled in switch [-Werror=switch]
> /build_ci_jdk_jdk_linuxppc64le/src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp:719:10: error: enumeration value 'FIRST_ID' not handled in switch [-Werror=switch]
>
> Could we get rid of  the  -Werror=switch   at least for now ?
> Maybe it should be disabled for ppc64 / ppc64le  /  s390x  like it has been done for zero ?
It is of course possible to disable the warning for certain build 
setups, yes. This could be done on a per OS, CPU or gcc version basis 
(or a combination thereof).

However, you might want to make certain that it does not make more sense 
to actually fix the code. The "switch" warning detected code for s390 
that was described as "sneaky" and a "fun source of bugs". You should be 
able to use --disable-warnings-as-errors as an intermediate fix to stop 
this from breaking the build.

Some warnings has already been fixed, or is in the process of being 
fixed, see e.g. JDK-8211145, JDK-8211207 and JDK-8211071. All of which, 
I believe, choose to fix the code instead of disabling the warning.

> 4.13+
> 4.14 ifeq ($(call check-jvm-feature, zero), true)
> 4.15-  DISABLED_WARNINGS_gcc += return-type
> 4.16+  DISABLED_WARNINGS_gcc += return-type switch
> 4.17 endif
>
>
> Regarding the unrecognized command line options ,  I suggest to still support older gcc versions;
> what would be the minimal gcc version that supports 8211029 ?
So, I tested this patch with gcc 4.8. However, I don't have access to a 
ppc64 nor s390x testing environment. The problem here, I think, is not 
in terms of gcc version but on target CPU. The intention was at least 
not to change the support for any currently supported compiler, but was 
merely in the logistics of me being able to test all kinds of build 
environments before the push.

/Magnus


>
> Best regards, Matthias