RFR: 8343698: Linux x86_64 lto build gives a lot of warnings and fails lto-wrapper: fatal error: make returned 2 exit status

David Holmes dholmes at openjdk.org
Thu Nov 14 07:59:26 UTC 2024


On Thu, 14 Nov 2024 07:26:41 GMT, Julian Waters <jwaters at 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


More information about the build-dev mailing list