|
From: | Davin McCall |
Subject: | bug#20899: Bug in libtool: -fno-strict-alias not passed to linker stage when -flto is used |
Date: | Sat, 27 Jun 2015 10:30:01 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
Hi Bob, On 26/06/15 03:31, Bob Friesenhahn wrote:
On Thu, 25 Jun 2015, Davin McCall wrote:Hi,I have discovered what I believe is a bug in libtool: It does not pass the "-fno-strict-aliasing" compilation flag to the link stage. This is not normally a problem, but is certainly a problem is "-flto" (link time optimization) is used. In this case code that works correct only without strict aliasing will incorrectly after being linked.Does -Wl,--fno-strict-aliasingwork for you? It might be necessary to also specify -fno-strict-aliasing if the compiler also uses this.Bob
No. -Wl passes an option to the linker, but the linker does not accept the -fno-strict-aliasing option, and so using -Wl,-fno-strict-aliasing results in a link failure. It's my understanding that in LTO mode, gcc acts as a somewhat more complex frontend to the linker than usual, but it still passes -Wl,XXX options directly to the underlying linker. GNU ld then interprets '-fno-strict-aliasing' as its own '-f' option, used for a different purpose.
FWIW the libtool script contains a small bit of code with a comment header reading "Flags to be passed through unchanged, with rationale:". It includes -flto, but not -fno-strict-aliasing. If I add -fno-strict-aliasing to the list here, it does seem to work as I want, that is, -fno-strict-aliasing is visible on the link stage command line.
Davin
[Prev in Thread] | Current Thread | [Next in Thread] |