get_d_2exp test failures: clang -emit-llvm/-flto/-O4; icc -ipo/-fast

[bathtubdev]

Dr. Lefèvre is correct on all accounts.

> Then the code depends on some macros defined at configure time,
> but your bug report is incomplete: one doesn't have an idea of what
> macros are defined. You need to provide the config.log file.

(Apologies.)

> But here LTO shouldn't matter, unless it has an effect on the definition of the macros.

... It does.

The clang/LLVM LTO implementation operates by using the driver and
front end to generate a high level AST; it then perform some
optimizations and lowers the code to LLVM IR emitting IR bitcode in
lieu of a native object file. At link time, the linker (gold or ld64)
loads the LLVM backend again via a shared library, performs
whole-program optimization and only then emits the final linked image.
(I assume icc operates similarly.)

The bug is in the configure script, where it tries to grep an object
to determine the floating point format; it fails because the object
file, well, isn't a (traditional) object file. Filter out the flags
that trigger LTO here and we get the correct result:


Index: acinclude.m4
===============
--- acinclude.m4
+++ acinclude.m4
@@ -3112,0 +3113,5 @@
+dnl
+dnl  Some compilers (notably, clang and icc) do not generate machine code
+dnl  object files when compiling with linktime or interprocedural optimization,
+dnl  instead emitting an intermediate representation for use in later passes.
+dnl  Therefore, flags enabling any such optimizations must be filtered out.
@@ -3133 +3138,3 @@
-gmp_compile="$CC $CFLAGS $CPPFLAGS -c conftest.c >&AC_FD_CC 2>&1"
+CC_NO_LTO=$(echo $CC $CFLAGS $CPPFLAGS | sed -e 's/-O4/-O3/g' -e 's/-flto//g'\
+                          -e 's/-emit-llvm//g' -e 's/-ipo//g' -e 's/-fast//g')
+gmp_compile="$CC_NO_LTO -c conftest.c >&AC_FD_CC 2>&1"
@@ -3332,2 +3339 @@
-    AC_MSG_WARN([Could not determine float format.])
-    AC_MSG_WARN([Conversions to and from "double" may be slow.])
+    AC_MSG_ERROR([Could not determine float format.])


I'm editorializing with the last patch above. But I think it would be
prudent; this test failure rather clearly demonstrates that the
consequences are more severe than the warning suggests, no?

I should also point out this is perhaps not a 100% satisfactory
solution. There are some exotic targets (i.e., Emscripten and the C++
backend) for which there is no such thing as a 'native' object file at
all... :)

Best,
G.