Re: GMP test fails with -flto

[Richard Biener]

On Wed, Jul 3, 2019 at 12:49 PM Torbjörn Granlund  wrote:
>
> Richard Biener  writes:
>
>   So yes, building a shared object with the data exported is probably
>   more future-proof ;)
>
> Indded.  But I don't know how to do that portably.
>
>   Let the perfect not be the enemy of the good here.
>
> Don't tease Vincent like that! :-)

Just put volatile on the thing and be done with it ;)

Richard.

>
> --
> Torbjörn
> Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Torbjörn Granlund]

Marc Glisse  writes:

  Without #include , some compilers reject it. Also, the string
  should be "%d %f" (or replace '+' with ',' in the arguments).

Thanks, fixed!


-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Torbjörn Granlund]

Richard Biener  writes:

  So yes, building a shared object with the data exported is probably
  more future-proof ;)

Indded.  But I don't know how to do that portably.

  Let the perfect not be the enemy of the good here.

Don't tease Vincent like that! :-)

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Torbjörn Granlund]

Vincent Lefevre  writes:

  C99 says: "An object that has volatile-qualified type may be modified
  in ways unknown to the implementation or have other unknown side
  effects. Therefore any expression referring to such an object shall
  be evaluated strictly according to the rules of the abstract machine,
  as described in 5.1.2.3."

You're missing the point here.


-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Vincent Lefevre]

On 2019-07-03 10:45:24 +0200, Richard Biener wrote:
> On Wed, Jul 3, 2019 at 9:49 AM Vincent Lefevre  wrote:
> > Here, after loop enrolling, the compiler could see that the arguments
> > are known and generate a fixed puts(). This kind of optimization must
> > not be done with a structure declared as volatile. But I think that
> > data in the structure could be rearranged (what matters is that when
> > run, the program will still do memory accesses and the behavior will
> > be the same); that's rather unlikely, though.
> 
> Could happen though but making the structure object volatile might help
> (the compiler could still see you don't use threads and it's regular data
> and nothing can happen and thus ignore even that...).

C99 says: "An object that has volatile-qualified type may be modified
in ways unknown to the implementation or have other unknown side
effects. Therefore any expression referring to such an object shall
be evaluated strictly according to the rules of the abstract machine,
as described in 5.1.2.3."

No need to use threads. A debugger is sufficient to modify a volatile
object (this is a way "unknown to the implementation").

Note that since there are no other side effects when reading volatile
data here (standard, readable memory), a read is required to be
generated only if the value (which is unknown, as it could have been
modified in a way unknown to the implementation) can affect the output
(which the printf does here).

> The only way to avoid it would be to do sth like
> 
>for (i = 0; i < 8; i++)
>  if (argv[1][2*i])
>foo.before[i] = foo.after[i] = ((char *))[i] = argv[1][2*i+1];
> 
> thus conditionally(! otherwise the compiler might optimize away the
> initializer...) overwrite it from program input.

I don't understand what you want to do here.

> There's also the possibility of the compiler altering the structure
> layout...

Yes. But I think that a copy of the structure and reading the copy
should be sufficient. And all types (at least those related to the
structure) should be volatile-qualified.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Torbjörn Granlund]

Richard Biener  writes:

  Yes, this should work.  It probably has a slightly higher chance of
  mismatching the start/end patterns elsewhere in the file, but well...

Thanks for checking my proposed patch!

Yes, I realise that we could get unlucky now, something which really
shouldn't happen with just the object file.  It's not neat, but it
should work.

A solution would be to make before[] and after[] huge enough that their
combined sizes are sure to be greater than 1/2 a plain executable.  Then
there is simply no space for a false match.  But as configure cannot
know the size of a plain executable, one would need to loop over
gradually larger before/after until

  2 * (sizeof(before)+sizeof(after)) > wc -c conftest

hold true.  :-)

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Richard Biener]

On Tue, Jul 2, 2019 at 12:41 PM Torbjörn Granlund  wrote:
>
> Richard Biener  writes:
>
>   On Mon, Jul 1, 2019 at 11:13 PM Torbjörn Granlund  wrote:
>   >
>   > Vincent Lefevre  writes:
>   >
>   >   Yes, with LTO, the object file does not contain the structure as is.
>   >   Thus the detection from "od -b conftest.$OBJEXT" does not work.
>   >
>   > That could be solved by generating a final executable, right?
> >
>   Yes.
>
> Does the patch below make sense?
>
> The main funcion is needed as we create an executable, its references to
> foo are needed, else LTO will remove foo altogether.

Yes, this should work.  It probably has a slightly higher chance of mismatching
the start/end patterns elsewhere in the file, but well...

Richard.

> *** /tmp/extdiff.MsIr0g/gmp-main.3300fbb5d615/acinclude.m4  Mon Jun 17 
> 00:11:50 2019
> --- /home/tege/prec/gmp-main/acinclude.m4   Tue Jul  2 12:37:53 2019
> ***
> *** 3307,3313 
> -123456789.0,
> { '\376', '\334', '\272', '\230', '\166', '\124', '\062', '\020' },
> ! };]
>   EOF
> ! gmp_compile="$CC $CFLAGS $CPPFLAGS -c conftest.c >_FD_CC 2>&1"
>   if AC_TRY_EVAL(gmp_compile); then
>   cat >conftest.awk <<\EOF
> --- 3307,3320 
> -123456789.0,
> { '\376', '\334', '\272', '\230', '\166', '\124', '\062', '\020' },
> ! };
> ! int main(){
> !   int i;
> !   for (i = 0; i < 8; i++) {
> ! printf ("%d %d %f\n", foo.before[i] + foo.after[i], foo.x);
> !   }
> !   return 0;
> ! }]
>   EOF
> ! gmp_compile="$CC $CFLAGS $CPPFLAGS conftest.c -o conftest >_FD_CC 2>&1"
>   if AC_TRY_EVAL(gmp_compile); then
>   cat >conftest.awk <<\EOF
> ***
> *** 3462,3470 
>   ]
>   EOF
> !   gmp_cv_c_double_format=`od -b conftest.$OBJEXT | $AWK -f conftest.awk`
> case $gmp_cv_c_double_format in
> unknown*)
> ! echo "cannot match anything, conftest.$OBJEXT contains" >_FD_CC
> ! od -b conftest.$OBJEXT >_FD_CC
>   ;;
> esac
> --- 3469,3477 
>   ]
>   EOF
> !   gmp_cv_c_double_format=`od -b conftest | $AWK -f conftest.awk`
> case $gmp_cv_c_double_format in
> unknown*)
> ! echo "cannot match anything, conftest contains" >_FD_CC
> ! od -b conftest >_FD_CC
>   ;;
> esac
>
>
> --
> Torbjörn
> Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Richard Biener]

On Mon, Jul 1, 2019 at 11:13 PM Torbjörn Granlund  wrote:
>
> Vincent Lefevre  writes:
>
>   Yes, with LTO, the object file does not contain the structure as is.
>   Thus the detection from "od -b conftest.$OBJEXT" does not work.
>
> That could be solved by generating a final executable, right?

Yes.

> --
> Torbjörn
> Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Torbjörn Granlund]

Richard Biener  writes:

  On Mon, Jul 1, 2019 at 11:13 PM Torbjörn Granlund  wrote:
  >
  > Vincent Lefevre  writes:
  >
  >   Yes, with LTO, the object file does not contain the structure as is.
  >   Thus the detection from "od -b conftest.$OBJEXT" does not work.
  >
  > That could be solved by generating a final executable, right?
>
  Yes.

Does the patch below make sense?

The main funcion is needed as we create an executable, its references to
foo are needed, else LTO will remove foo altogether.

*** /tmp/extdiff.MsIr0g/gmp-main.3300fbb5d615/acinclude.m4  Mon Jun 17 
00:11:50 2019
--- /home/tege/prec/gmp-main/acinclude.m4   Tue Jul  2 12:37:53 2019
***
*** 3307,3313 
-123456789.0,
{ '\376', '\334', '\272', '\230', '\166', '\124', '\062', '\020' },
! };]
  EOF
! gmp_compile="$CC $CFLAGS $CPPFLAGS -c conftest.c >_FD_CC 2>&1"
  if AC_TRY_EVAL(gmp_compile); then
  cat >conftest.awk <<\EOF
--- 3307,3320 
-123456789.0,
{ '\376', '\334', '\272', '\230', '\166', '\124', '\062', '\020' },
! };
! int main(){
!   int i;
!   for (i = 0; i < 8; i++) {
! printf ("%d %d %f\n", foo.before[i] + foo.after[i], foo.x);
!   }
!   return 0;
! }]
  EOF
! gmp_compile="$CC $CFLAGS $CPPFLAGS conftest.c -o conftest >_FD_CC 2>&1"
  if AC_TRY_EVAL(gmp_compile); then
  cat >conftest.awk <<\EOF
***
*** 3462,3470 
  ]
  EOF
!   gmp_cv_c_double_format=`od -b conftest.$OBJEXT | $AWK -f conftest.awk`
case $gmp_cv_c_double_format in
unknown*)
! echo "cannot match anything, conftest.$OBJEXT contains" >_FD_CC
! od -b conftest.$OBJEXT >_FD_CC
  ;;
esac
--- 3469,3477 
  ]
  EOF
!   gmp_cv_c_double_format=`od -b conftest | $AWK -f conftest.awk`
case $gmp_cv_c_double_format in
unknown*)
! echo "cannot match anything, conftest contains" >_FD_CC
! od -b conftest >_FD_CC
  ;;
esac


-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Richard Biener]

On Mon, Jul 1, 2019 at 5:27 PM Vincent Lefevre  wrote:
>
> On 2019-07-01 16:59:06 +0200, Marc Glisse wrote:
> > On Mon, 1 Jul 2019, Vincent Lefevre wrote:
> > > I suggest another solution:
> > >
> > > First try like now. If the format is unknown, check whether the
> > > object file contains the string ".gnu.lto" (which should mean
> > > that GCC was used with LTO), and in this case, try again with
> > > "-fno-lto" as the patch was doing.
> >
> > We also have problems with clang's version of LTO. IIRC using emscripten to
> > compile GMP has a similar issue.
>
> With clang 7 and above, "ThinLTO" appears in the object file.

-fno-lto also works with clang?

When not cross-compiling the configure test could also be executable
doing the matching itself.  Breaks for cross which is likely why you've
done it as it is now?  For cross-compiling building a shared object
might work though, it should no longer contain only LTO bytecode
but also the data.

Richard.

> --
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Torbjörn Granlund]

Vincent Lefevre  writes:

  Yes, with LTO, the object file does not contain the structure as is.
  Thus the detection from "od -b conftest.$OBJEXT" does not work.

That could be solved by generating a final executable, right?

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Vincent Lefevre]

On 2019-07-01 16:59:06 +0200, Marc Glisse wrote:
> On Mon, 1 Jul 2019, Vincent Lefevre wrote:
> > I suggest another solution:
> > 
> > First try like now. If the format is unknown, check whether the
> > object file contains the string ".gnu.lto" (which should mean
> > that GCC was used with LTO), and in this case, try again with
> > "-fno-lto" as the patch was doing.
> 
> We also have problems with clang's version of LTO. IIRC using emscripten to
> compile GMP has a similar issue.

With clang 7 and above, "ThinLTO" appears in the object file.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Vincent Lefevre]

On 2019-07-01 16:36:23 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre  writes:
> 
>   I suggest another solution:
> 
>   First try like now. If the format is unknown, check whether the
>   object file contains the string ".gnu.lto" (which should mean
>   that GCC was used with LTO), and in this case, try again with
>   "-fno-lto" as the patch was doing.
> 
> That might work, but it is a bit more complex that ideally.  I believe
> some grep commands do not cope well with binaries.

Alternatively or additionally, use strings + grep (strings is part
of POSIX and first appeared in Issue 4; however it is not listed
in the GNU Coding Standards).

Otherwise "od -b" with awk, possibly in the same awk script as the
detection itself.

> I have forgotten why lto hurts the GMP_C_DOUBLE_FORMAT test.  (That's
> the problematic test, right?)

Yes, with LTO, the object file does not contain the structure as is.
Thus the detection from "od -b conftest.$OBJEXT" does not work.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Marc Glisse]

On Mon, 1 Jul 2019, Vincent Lefevre wrote:


On 2019-07-01 13:44:04 +0200, Marc Glisse wrote:

On Mon, 1 Jul 2019, Martin Liška wrote:

> On 6/24/19 8:57 PM, Marc Glisse wrote:
> > On Mon, 24 Jun 2019, Martin Liška wrote:
> > 
> > > Using -flto one can see a test failure:
> > 
> > This is well known, see the archives for details. It is a combination of 2 issues:

> > - (thin) LTO prevents configure from guessing the floating point format
> > - a bug in the generic GMP code (fixed in master IIRC)
> > 
> 
> Hi.
> 
> I've got a patch for the wrong configure of floating point format.


That's going to break every non-gcc compiler, isn't it?


I suggest another solution:

First try like now. If the format is unknown, check whether the
object file contains the string ".gnu.lto" (which should mean
that GCC was used with LTO), and in this case, try again with
"-fno-lto" as the patch was doing.


We also have problems with clang's version of LTO. IIRC using emscripten 
to compile GMP has a similar issue.


--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Torbjörn Granlund]

Vincent Lefevre  writes:

  I suggest another solution:

  First try like now. If the format is unknown, check whether the
  object file contains the string ".gnu.lto" (which should mean
  that GCC was used with LTO), and in this case, try again with
  "-fno-lto" as the patch was doing.

That might work, but it is a bit more complex that ideally.  I believe
some grep commands do not cope well with binaries.

I have forgotten why lto hurts the GMP_C_DOUBLE_FORMAT test.  (That's
the problematic test, right?)

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Vincent Lefevre]

On 2019-07-01 13:44:04 +0200, Marc Glisse wrote:
> On Mon, 1 Jul 2019, Martin Liška wrote:
> 
> > On 6/24/19 8:57 PM, Marc Glisse wrote:
> > > On Mon, 24 Jun 2019, Martin Liška wrote:
> > > 
> > > > Using -flto one can see a test failure:
> > > 
> > > This is well known, see the archives for details. It is a combination of 
> > > 2 issues:
> > > - (thin) LTO prevents configure from guessing the floating point format
> > > - a bug in the generic GMP code (fixed in master IIRC)
> > > 
> > 
> > Hi.
> > 
> > I've got a patch for the wrong configure of floating point format.
> 
> That's going to break every non-gcc compiler, isn't it?

I suggest another solution:

First try like now. If the format is unknown, check whether the
object file contains the string ".gnu.lto" (which should mean
that GCC was used with LTO), and in this case, try again with
"-fno-lto" as the patch was doing.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Marc Glisse]

On Mon, 1 Jul 2019, Martin Liška wrote:


On 6/24/19 8:57 PM, Marc Glisse wrote:

On Mon, 24 Jun 2019, Martin Liška wrote:


Using -flto one can see a test failure:


This is well known, see the archives for details. It is a combination of 2 
issues:
- (thin) LTO prevents configure from guessing the floating point format
- a bug in the generic GMP code (fixed in master IIRC)



Hi.

I've got a patch for the wrong configure of floating point format.


That's going to break every non-gcc compiler, isn't it?

--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Martin Liška]

On 6/24/19 8:57 PM, Marc Glisse wrote:
> On Mon, 24 Jun 2019, Martin Liška wrote:
> 
>> Using -flto one can see a test failure:
> 
> This is well known, see the archives for details. It is a combination of 2 
> issues:
> - (thin) LTO prevents configure from guessing the floating point format
> - a bug in the generic GMP code (fixed in master IIRC)
> 

Hi.

I've got a patch for the wrong configure of floating point format.

Can you please Mark upstream it?
Thanks,
Martin
diff --git a/acinclude.m4 b/acinclude.m4
index 3c3ecf5..9c2675e 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -3308,7 +3308,7 @@ struct foo foo = {
   { '\376', '\334', '\272', '\230', '\166', '\124', '\062', '\020' },
 };]
 EOF
-gmp_compile="$CC $CFLAGS $CPPFLAGS -c conftest.c >_FD_CC 2>&1"
+gmp_compile="$CC $CFLAGS $CPPFLAGS -fno-lto -c conftest.c >_FD_CC 2>&1"
 if AC_TRY_EVAL(gmp_compile); then
 cat >conftest.awk <<\EOF
 [
diff --git a/configure b/configure
index 12ddffd..a7890ed 100755
--- a/configure
+++ b/configure
@@ -24563,7 +24563,7 @@ struct foo foo = {
   { '\376', '\334', '\272', '\230', '\166', '\124', '\062', '\020' },
 };
 EOF
-gmp_compile="$CC $CFLAGS $CPPFLAGS -c conftest.c >&5 2>&1"
+gmp_compile="$CC $CFLAGS $CPPFLAGS -fno-lto -c conftest.c >&5 2>&1"
 if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$gmp_compile\""; } >&5
   (eval $gmp_compile) 2>&5
   ac_status=$?
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP test fails with -flto

[Marc Glisse]

On Mon, 24 Jun 2019, Martin Liška wrote:


Using -flto one can see a test failure:


This is well known, see the archives for details. It is a combination of 2 
issues:

- (thin) LTO prevents configure from guessing the floating point format
- a bug in the generic GMP code (fixed in master IIRC)

--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs