Counteracting LTO and "strange objects" (FP format detection). [patch]

[Niels Möller]

Geoff Nixon <geoff.nixon at aol.com> writes:

> I'm please to say that I *believe* I have now found a more robust
> solution. Patch:
>
> https://gist.github.com/g--n/9611363#file-gmp-lto-fix-patch
>
> I believe the patch resolves the issue (at least for me); it
> successfully applies against the 5.1.3 release and both the main devel
> and the 5.1 maintenance branches.

If I remember the context, the idea was to disable these lto things when
doing the configure test for floating point format, which examines the
generated object file.

Maybe this can work. For reference, here's the main part:

  +# 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"

Some comments:

I don't think it should rely on "-o -", better use -o conftest.s. And
then you can also do multiple on the output without rerunning the
compiler.

grep -q is not portable, use grep > /dev/null instead. 

Not sure if all compilers support -S. All compilers this test is
intended to detect do, I guess, but it may need to handle the case that
-S fails (and then do nothing).

> libtool: link: clang -Ofast -flto -fpic -Wno-error -o t-bswap
> t-bswap.o ./.libs/libtests.a /Users/user/gmp/.libs/libgmp.a
> ../.libs/libgmp.a
> <inline asm>:1:7: error: invalid operand for instruction
>        subq    $8589934592, (%rax)
>                ^~~~~~~~~~~
> LLVM ERROR: Error parsing inline asm

This is a 34 bit constant, binary 1000000000000000000000000000000000. I
don't know x86 assembly well enough to say if that large immediate
operands are valid, bit it seems a bit fishy. You'd have to investigate
where this constant comes from.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.