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

From: Davin McCall <[email-masked]>
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