On Thu, 14 Nov 2024 07:26:41 GMT, Julian Waters <jwat...@openjdk.org> wrote:
>> make/hotspot/lib/JvmOverrideFiles.gmk line 43: >> >>> 41: ifeq ($(call check-jvm-feature, link-time-opt), true) >>> 42: BUILD_LIBJVM_g1ParScanThreadState.cpp_CXXFLAGS := -fno-lto >>> 43: endif >> >> Even with this change I still get ~200 warnings when building with gcc13.2, >> mostly -Wattribute-warning. This is consistent with what I reported >> previously >> with ATTRIBUTE_WARNING as a nop. So this change isn't sufficient. >> >> I'm also not sure it's desirable. We don't know the impact of LTO on top of >> flattening. It might be beneficial. This change ought to come with some >> performance measurements, if made at all. And not under the rubric of a >> warnings fix. > > There are quite a number of things in HotSpot that seemingly wouldn't work > with LTO enabled. One notable example is os::current_stack_pointer, which on > many platforms simply returns the frame pointer of os::current_stack_pointer > or the address of a local inside os::current_stack_pointer. With LTO enabled > this becomes eligible for inlining, and the "stack pointer" ends up becoming > the frame pointer of the caller, which is not correct. Fixing these issues > and making LTO viable is one of the things I hope to do, although not now Hmmm ... I thought we had LTO enabled in the past for Java SE Embedded ... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22069#discussion_r1841721903
