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

[Davin McCall]

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