While examining https://github.com/openjdk/jdk/pull/13000 which is a fix for ZGC on x86 to allow ASAN, I came across a couple of compilation errors when building with --enable-asan and slowdebug:
For target hotspot_variant-server_libjvm_objs_memoryService.o:
jdk/src/hotspot/share/services/memoryService.cpp: In static member function 'static Handle MemoryService::create_MemoryUsage_obj(MemoryUsage, JavaThread*)':
jdk/src/hotspot/share/services/memoryService.cpp:218:1: error: control reaches end of non-void function [-Werror=return-type]
218 | }
| ^
For target support_native_java.base_libjli_java.o:
/home/stumon01/repos/Arm/jdk/src/java.base/share/native/libjli/java.c: In function 'JavaMain':
jdk/src/java.base/share/native/libjli/java.c:556:1: error: control reaches end of non-void function [-Werror=return-type]
556 | }
These do not occur if you either change "-O0" to "-O1" or remove "-fsanitize=address".
The functions end in a macro that uses the patten "} while(0);" after the actual return. This confuses the compiler under these circumstances.
I've reproduced this with GCC 12.2.0, which is the current latest release. There is an existing, open bug which covers this scenario in GCC, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959 which has been open since GCC 7.1 .
It is straight forward to rewrite the code to force the last statement to be a return in the two cases.
For target hotspot_variant-server_libjvm_objs_memoryService.o:
jdk/src/hotspot/share/services/memoryService.cpp: In static member function 'static Handle MemoryService::create_MemoryUsage_obj(MemoryUsage, JavaThread*)':
jdk/src/hotspot/share/services/memoryService.cpp:218:1: error: control reaches end of non-void function [-Werror=return-type]
218 | }
| ^
For target support_native_java.base_libjli_java.o:
/home/stumon01/repos/Arm/jdk/src/java.base/share/native/libjli/java.c: In function 'JavaMain':
jdk/src/java.base/share/native/libjli/java.c:556:1: error: control reaches end of non-void function [-Werror=return-type]
556 | }
These do not occur if you either change "-O0" to "-O1" or remove "-fsanitize=address".
The functions end in a macro that uses the patten "} while(0);" after the actual return. This confuses the compiler under these circumstances.
I've reproduced this with GCC 12.2.0, which is the current latest release. There is an existing, open bug which covers this scenario in GCC, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80959 which has been open since GCC 7.1 .
It is straight forward to rewrite the code to force the last statement to be a return in the two cases.
- links to
-
Review(master) openjdk/jdk/22355