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

[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

[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: Bug in gmp/mpfr/mpc, never ending ctan computation

[Richard Biener]

On Mon, 19 Nov 2018, Vincent Lefevre wrote:

> On 2018-11-19 14:17:13 +0100, Niels Möller wrote:
> > You might want to add an entry for "Exponent range" to the concept index
> > in the manual.
> 
> The concept index already has "Exponent", and the corresponding
> paragraph is:
> 
>An “exponent” is a component of a regular floating-point number.  Its
> C data type is ‘mpfr_exp_t’.  Valid exponents are restricted to a subset
> of this type, and the exponent range can be changed globally as
> described in *note Exception Related Functions::.  Special values do not
> have an exponent.
> 
> I think that this is quite explicit.
> 
> > I guess gcc should set things up similarly to the example on that page,
> > "This is an example of how to emulate binary double IEEE 754
> > arithmetic", with the caveat "This emulates a double IEEE 754 arithmetic
> > with correct rounding in the subnormal range, which may not be the case
> > for your hardware".
> 
> AFAIK, GCC already changes the exponent range to the binary64 one
> (the lack of subnormals is not an issue, because in case of underflow,
> GCC ignores the computations done with MPFR).

GCC does ignore results in case of overflow or underflow but it
doesn't currently limit mpfrs exponent range.  Or rather most
languages don't - I do see mpfr_set_e{min,max} calls being
done in the Fortran frontend only, but only temporarily and
seemingly only to call mpfr_subnormalize.

> But for its internal computations, I assume that mpc extends the
> exponent range (if it didn't you would have the same kind of problem,
> but much more often). Here it seems that the issue is that the maximum
> supported exponent range is not large enough for the chosen algorithm
> (which may not be the right one for this kind of input).

It happens that limiting the range makes the CPOW computation fast.

Richard.

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

[Richard Biener]

On Mon, 19 Nov 2018, Niels Möller wrote:

> Vincent Lefevre  writes:
> 
> > MPFR has a bounded (user configurable) exponent range, with underflow
> > and overflow exceptions for out-of-range results, like in IEEE 754.
> 
> Good! I didn't find that in the manual until I knew the phrase to search
> for. It's in
> https://www.mpfr.org/mpfr-current/mpfr.html#Exception-Related-Functions,
> and relevant functions are mpfr_set_emin, mpfr_set_emax and mpfr_subnormalize.
> 
> You might want to add an entry for "Exponent range" to the concept index
> in the manual.

Indeed I didn't find these functions either ...

> I guess gcc should set things up similarly to the example on that page,
> "This is an example of how to emulate binary double IEEE 754
> arithmetic", with the caveat "This emulates a double IEEE 754 arithmetic
> with correct rounding in the subnormal range, which may not be the case
> for your hardware".

OK, GCC doesn't use those, for the testcase if I set emax/emin to the
range from 128bit IEEE then the folding finishes quickly.

It looks like emin/emax is global and not per mpfr_t so for GCC we
have to jump through some additional hoops.  I'll see to adjust
GCC to set the limits based on the maximum range ever needed
(largest FP mode supported by the target) and look for fallout.

Richard.

> Regards,
> /Niels
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Bug in gmp/mpfr/mpc, never ending ctan computation

[Richard Biener]

On Mon, 19 Nov 2018, Torbjörn Granlund wrote:

> Richard Biener  writes:
> 
>   :/  But then with GCC we want deterministic behavior -- ISL
>   added some "computation budget" and error reporting if that was
>   taken up.  Maybe gmp/mpfr/mpc could consider adding such a thing
>   (reporting budget overruns via a signal could be acceptable if
>   the API churn would be too bad for another way).
> 
> I'll leave this up to the mpc maintainers.
> 
>   > I simplified your test case using 1 as the real part and an integer for
>   > the imaginary part.  With the real part set to 1, the computation
>   > finishes in about 10 seconds, with every doubling of it the runtime
>   > almost triples.  (If my observation generalises to an extended real part
>   > range, the compilation for your test case should terminate in about
>   > 10*3^log2(4.045689747817175388336181640625e+8/1)/3600/24/365 years.)
> 
>   Ick.  I wonder if the actual ctan result is infinite or we just
>   fail to compute it in an efficient manner...
> 
> The result should be extremely small, so returning Inf would be
> quite inaccurate.  :-)

I see.  So I guess one issue might be that mpfr numbers have a
precision (mantissa bits?) but no restriction on the exponent?
That is, for ctan eventually zero _is_ a validly rounded result
and the computation should simply terminate...

Richard.

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs