GNU bug report logs - #69689
30.0.50; cannot native compile with -flto in native-comp-compiler-options

Previous Next

Full log

View this message in rfc822 format

From: StrawberryTea <look <at> strawberrytea.xyz>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: 69689 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: bug#69689: 30.0.50; cannot native compile with -flto in native-comp-compiler-options
Date: Sun, 17 Mar 2024 13:17:43 -0500

Andrea Corallo <acorallo <at> gnu.org> writes:

> Paul Eggert <eggert <at> cs.ucla.edu> writes:
>
>> On 3/11/24 06:38, Eli Zaretskii wrote:
>>
>>> configure.ac says "experimental", so I guess it's not yet reliable
>>> enough?
>>
>> It was added by Dmitry Antipov in 2012. I never use it, and didn't
>> even recall it until I looked at configure.ac recently.
>>
>> I've not have good luck with -lto elsewhere. It can make linking slow
>> and it tends to expose compiler bugs. Unless someone's using it
>> regularly I would consider it experimental.
>
> Also as a note.
>
> I doubt using native compilation with LTO could bring measurable
> advantages.
>
> All the Emacs C primitives we call from elns have a function pointer
> indirection as they can be redefined, so GCC can't inline them.  Few
> support functions are called directly but I would be surprised of any
> measurable effect there.
>
> Best Regards
>
>   Andrea

I see. I am going to report this to the GCC bug tracker to try and get
it fixed. I would like to use LTO with native compilation, even if it
would not bring any measurable advantages. And I feel there has to be
some GCC person that knows how to fix this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.