Counteract effect of LTO on GMP's FP format detection.

gmp-lto-fix.patch

index: a/acinclude.m4 b/acinclude.m4
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -3273,0 +3274,38 @@
+
+
+# Test generated assembly for markers of unusual "objects" that cause test to fail.
+
+# Compilers sometimes generate "strange objects" - things that are not machine code,
+# but instead, some type of intermediately processed data (i.e., LTO/IPO/WPA/IR).
+
+# To head that off (without depending on "honest" compiler flags):
+# Should the compiler emit "strange objects" like this when *compiling* a code snippet,
+# it will likewise emit "strange assembler" if it is asked to generate assembly instead.
+# This "assembly" will have an unmistakable marker to distinguish it when compiled.
+# Thus, to avoid these, something to the effect of:
+
+#  echo 'int foo;' | $WEIRD_CC $WEIRD_CPPFLAGS $WEIRD_CFLAGS -S | grep __WeirdSymbol
+
+# It doesn't matter at all if its being affected by means of a variable, flag, wrapper,
+# default, etc. We only need to know enough about the formate to *counteract it*.
+
+## Known markers:
+
+# gcc   -flto : "_GNU_LTO" | First section name. Otherwise, looks like weird AT&T asm.
+# icc   -fast : "__ildata" | Only 1 section - every line after this is: '.byte [0-9]+'
+# clang -flto : "ModuleID" | All LLVM IR begins with a ModuleID (the source file).
+
+#  OpenCL SPIR, Google's pNaCl, and emscripten are also use LLVM IR object notation.
+
+
+# Check for these markers, drop in a counteracting flag if needed, and we're good.
+
+  gmp_gen_asm="$CC $CPPFLAGS $CFLAGS -S conftest.c -o -"
+
+  $gmp_gen_asm | grep -q __GNU_LTO || $gmp_gen_asm | grep -q ModuleID &&
+     gmp_compile="$CC $CPPFLAGS $CFLAGS -fno-lto -c conftest.c >&AC_FD_CC 2>&1"
+
+  $gmp_gen_asm | grep -q __ildata &&
+     gmp_compile="$CC $CPPFLAGS $CFLAGS -no-ipo -c conftest.c >&AC_FD_CC 2>&1"
+
+