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

Geoff Nixon geoff.nixon at aol.com
Wed Mar 19 17:28:05 UTC 2014


Something like this (before I go and retest)?


```

# If we fail due to no -S flag, create an empty file to grep through to keep it simple.

$CC $CPPFLAGS $CFLAGS -S conftest.c -o conftest.s 2>/dev/null || touch conftest.s


grep __GNU_LTO conftest.s >/dev/null || grep ModuleID conftest.s >/dev/null &&
  gmp_compile="$CC $CPPFLAGS $CFLAGS -fno-lto -c conftest.c >&AC_FD_CC 2>&1"


grep __ildata conftest.s && ## Counteracted with '-no-ipo' rather than '-fno-lto'.
  gmp_compile="$CC $CPPFLAGS $CFLAGS -no-ipo  -c conftest.c >&AC_FD_CC 2>&1"


rm -f conftest.s
```


Geoff Nixon
geoff.nixon at aol.com




-----Original Message-----
From: Niels Möller <nisse at lysator.liu.se>
To: Geoff Nixon <geoff.nixon at aol.com>
Cc: gmp-devel <gmp-devel at gmplib.org>
Sent: Tue, Mar 18, 2014 1:13 pm
Subject: Re: Counteracting LTO and "strange objects" (FP format detection). [patch]


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.

 


More information about the gmp-devel mailing list