Link time optimization does not work with Clang

[DoDoENT]

When using compile option -flto (in LOCAL_CFLAGS) with Clang on NDK r12 and also '-Wl,-flto' in LOCAL_LDFLAGS, linker fails with these three errors for each source file:

• sourceFile.o:1:3: invalid character
• sourceFile.o:1:3: syntax error, unexpected $end
• sourceFile.o: not an object or archive

When using GCC, LTO work as expected, except when targetting armeabi-v7a, when we get the following error when using LOCAL_ARM_NEON := true:

• lto1: fatal error: target specific builtin not available
• ld.gold: fatal error: lto-wrapper failed

and this one when only several files are tagged with NEON tag:

• Error: selected processor does not support Thumb mode vdup.32 q0,mask0

We believe this error is related to this bug in chromium project which was apparently fixed in GCC 5 and not present in clang. However, when trying with clang, we get the error described above.

Please advise how to turn on LTO on Clang or enable LTO on GCC with armeabi-v7a.

[DanAlbert]

After a bunch of fiddling with our test for -flto, I managed to produce those error messages.

The problem is that -Wl,-flto does not actually enable LTO.

From gold(1):

-f SHLIB, --auxiliary SHLIB Auxiliary filter for shared object symbol table

You want -flto in your LOCAL_LDFLAGS. No -Wl in this case.

[DoDoENT]

Thanks, -flto works. Unfortunately, both clang + libc++ + LTO and clang + libstdc++ + LTO still produce around 1MB larger binary than GCC + libstdc++ without LTO (GCC + libstdc++ + LTO works perfectly for non-armv7 targets, and fails on armv7 as described in my first post). I know next release of NDK will remove GCC, so I am attempting to find a workaround for this issue.

[DanAlbert]

Oops, accidentally deleted the second half of my reply when I found the cause:

When using GCC, LTO work as expected, except when targetting armeabi-v7a, when we get the following error when using LOCAL_ARM_NEON := true:

lto1: fatal error: target specific builtin not available
ld.gold: fatal error: lto-wrapper failed
and this one when only several files are tagged with NEON tag:

Error: selected processor does not support Thumb mode vdup.32 q0,mask0

Did this work with prior releases? If it's a regression I might be able to get someone to look in to it.

I know next release of NDK will remove GCC

Just FYI, it's not quite that soon. Until libc++ is 100% reliable GCC needs to stay because libstdc++ 4.9 doesn't support clang in <thread>, <atomic>, and the like, so removing it would remove support for some pretty important parts of C++.

I don't know exactly when this will happen, but I'll certainly call it out in the release notes at least a release ahead of the actual removal.

[DoDoENT]

Did this work with prior releases? If it's a regression I might be able to get someone to look in to it.

I've just tried with r11c and r10d. On both r11c and r10d I get the same error as in r12. Guys at chromium project have identified this as a bug in GCC which appears to be fixed in GCC 5. Is it possible to backport the fix from GCC 5 to GCC 4.9 or update GCC in NDK? I know you said you won't do it, but since GCC needs to stay around because of libstdc++, maybe it would be worth to update GCC to 6.1 (it has full c++14 support and much better clang-like diagnostic messages)?