GNU bug report logs - #20899
Bug in libtool: -fno-strict-alias not passed to linker stage when -flto is used

Previous Next

Full log

View this message in rfc822 format

From: Davin McCall <davmac <at> davmac.org>
To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: 20899 <at> debbugs.gnu.org
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

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-aliasing
>
> work 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

Previous Next

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