[8u] 8062808: Turn on the -Wreturn-type warning

[Liu, Xin]

Hi, Andrew, 

Here is the old message, but the information is still right.  It doesn't contain JDK-8229345.  It's almost a clean patch except for perfData.cpp.  It's a leftover of JDK-8064811. 

I'd like to backport JDK-8062808.  Enabling -Wreturn-type helps us to catch undefined code.  Could you review it and update label in that issue?
webrev: https://cr.openjdk.java.net/~xliu/8062808/webrev/

It's almost a clean patch. One single difference is that original patch doesn't include perfData.hpp. It has been changed in JDK-8064811. When we backported JDK-8064811 to jdk8u, I think we drop it by mistake.
I have verified it using the jdk8u repo. Both fastdebug and slowdebug work as expected.

thanks,
--lx


On 2/19/20, 9:24 PM, "Andrew Hughes" <gnu.andrew at redhat.com> wrote:

    
    
    On 07/02/2020 18:10, Andrew John Hughes wrote:
    > 
    > 
    > On 06/02/2020 15:55, Hohensee, Paul wrote:
    >> Reviving this one.
    >>
    >> Original issue: https://bugs.openjdk.java.net/browse/JDK-8062808
    >> Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ef7449e07592
    >> Webrev: http://cr.openjdk.java.net/~phh/8062808/webrev.8u.00/
    >>
    >> Applies clean except for the lack of -Wformat=2 in 8u's gcc.make, and the lack of klass_at_ignore_error in 8u's constantPool.hpp.
    >>
    >> Thanks,
    >> Paul
    >>
    > 
    > Yeah, I've been holding off on this, because it affects downstream
    > out-of-tree-ports and I was hoping to get the AArch64 port in first.
    > However, I think that's now looking like something for 8u262.
    > 
    > I also appreciated, during the recent release processes, that neither 8u
    > & 11u build with -Werror for me as they stand upstream, so I would like
    > to see this resolved. I'll take a look at the patch on Monday.
    > 
    > Thanks,
    > 
    
    It looks like the webrev also includes the JDK-8229345 change. Can you
    do a clean one with just 8062808?
    
    Also, I'm looking at 8036122 for another bug, and that also is based on
    -Wformat=2 being there from 8030350. With 8022263 applied first, it
    looks like 8022263->8030350->8036122 could be a series of clean
    backports. So, if you could hold off with this one a little longer until
    I get those integrated, I think that would help us both.
    
    Thanks,
    -- 
    Andrew :)
    
    Senior Free Java Software Engineer
    Red Hat, Inc. (http://www.redhat.com)
    
    PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
    Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222