Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Niels Möller]

"Marco Bodrato"  writes:

> Il Dom, 20 Maggio 2018 9:57 pm, Niels Möller ha scritto:

>> You could consider making this into small step towards modularizing
>> mini-gmp. Something like
>
>> #ifndef MINI_GMP_FLOAT_SUPPORT
>
>> ...
>
> The idea is interesting. How should we modularize? Should we split mini-
> in many files (each #include-ing the ones it depends on) or should we have
> a single file with selector like the one you propose? The only module we
> have, currently is mini-mpq, as a file apart.

I think it should stay as one file. Not sure if it's worth the effort,
but I was thinking of trying to divide mini-gmp into modules including
things like

* Add and sub.

* Bitwise logic functions

* Mul

* Div

* Base conversion for power-of-2 bases

* Base conversion for non-power-of-2 bases, in particular, 10

* Float conversion

* Import/export

* Various higher level functions, roots, gcd, primality testing, ...

We'd need to sort out dependencies between the modules and likely
maintain that graph manually.

By default, compiling mini-gmp would include everything, but if the user
does something like

#define MINI_GMP_ENABLE_BASE_CONVERSION_POWER_OF_TWO 1
#define MINI_GMP_ENABLE_MUL 1
#include "mini.gmp.c"

only those routines and their dependencies would be included. We'd need a
pretty large block of #ifs at the top to implement the dependencies. So
the drawback is the complexity of the needed #ifdeffery, and the testing
thereof.

Uncler to me how far it's worth going in dividing code into smaller
modules. To have one or (even two, in the case of get_str) module per
function will not be easy to maintain.

Alternative might be to recommend applications that care about binary
size to compile mini-gmp.c with -ffunction-sections and let the linker
sort it out, or rely on link-time-optimization eliminating unused code.
But I doubt that LTO will detect, e.g., that mpz_get_str is only ever
called with power-of-two arguments, and eliminate the unused
mpn_get_str_other together with the division code it depends on.

> I'm already tempted to join at least mini-gmp.h and mini-mpq.h

Makes sense to me. Could consider renaming mini-gmp.c to mini-mpz.c, but
doesn't matter so much.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marco Bodrato]

Ciao,

Il Lun, 21 Maggio 2018 7:06 am, Niels Möller ha scritto:
> t...@gmplib.org (Torbjörn Granlund) writes:
>
>> Would it be beneficial to add some non-IEEE host to the GMP autobuild
>> setup?  We could revive vax using simh.

Yes, of course.

> Can VAX be supported using the generic code, without HAVE_DOUBLE_VAX_D?
> Testing the generic code seems more important than testing VAX-specific
> optimizations.

Right.
The current generic implementation is very similar to the implementation
in mini-gmp. So, in some sense, even testing mini-gmp only can be
interesting.

Otherwise, we may add a hook in the code to disable specific
optimisations, and trigger it for a while in our testing.

Ĝis,
m

-- 
http://bodrato.it/papers/

___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Torbjörn Granlund]

ni...@lysator.liu.se (Niels Möller) writes:

  I think so. Does current gcc support VAX, or what compiler would we use?

vaxpropp$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/lto-wrapper
Target: vax--netbsdelf
Thread model: posix
gcc version 4.8.5 (nb2 20150115)

So, yes!

  Can VAX be supported using the generic code, without HAVE_DOUBLE_VAX_D?
  Testing the generic code seems more important than testing VAX-specific
  optimizations.

I don't know this.

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> Would it be beneficial to add some non-IEEE host to the GMP autobuild
> setup?  We could revive vax using simh.

I think so. Does current gcc support VAX, or what compiler would we use?

Can VAX be supported using the generic code, without HAVE_DOUBLE_VAX_D?
Testing the generic code seems more important than testing VAX-specific
optimizations.


Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marco Bodrato]

Ciao,

Il Dom, 20 Maggio 2018 9:57 pm, Niels Möller ha scritto:
> "Marco Bodrato"  writes:

> You could consider making this into small step towards modularizing
> mini-gmp. Something like

> #ifndef MINI_GMP_FLOAT_SUPPORT

> ...

The idea is interesting. How should we modularize? Should we split mini-
in many files (each #include-ing the ones it depends on) or should we have
a single file with selector like the one you propose? The only module we
have, currently is mini-mpq, as a file apart.

Or a mix?

I'm already tempted to join at least mini-gmp.h and mini-mpq.h

> Independent of this suggestion, I have two minor comments on your
> change (43659273c9cf): I think the DONT_USE_FLOAT_H macro should have a
> GMP or MINI_GMP prefix. And it would be nice with a test, e.g, based on

Done.


Ĝis,
m

-- 
http://bodrato.it/papers/

___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Torbjörn Granlund]

I haven't followed this thread in detail, but let me just ask this:

Would it be beneficial to add some non-IEEE host to the GMP autobuild
setup?  We could revive vax using simh.

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Niels Möller]

"Marco Bodrato"  writes:

> float.h is only used for
>
> +#if defined(DBL_MANT_DIG) && FLT_RADIX == 2
> +#define GMP_DBL_MANT_BITS DBL_MANT_DIG
> +#else
> +#define GMP_DBL_MANT_BITS (53)
> +#endif
>
> This constant is used only by the new version of get_d, to convert the
> correct number of bits and avoid rounding.
> I mean, the functions do not "depend on" float.h , and we don't need to
> exclude them. Maybe we should decide for a different default value...

You could consider making this into small step towards modularizing
mini-gmp. Something like

#ifndef MINI_GMP_FLOAT_SUPPORT
#define MINI_GMP_FLOAT_SUPPORT 1
#endif

#if MINI_GMP_FLOAT_SUPPORT
#include 
#endif

...


#if MINI_GMP_FLOAT_SUPPORT
#if FLT_RADIX == 2
#define GMP_DBL_MANT_BITS DBL_MANT_DIG
#else
/* What are our options?

   Fail as unsupported? Display warning? Or document expected breakage
   on systems for non-binary floats? Or approximate as DBL_MANT_DIG *
   log2(FLT_RADIX) ? */
#define GMP_DBL_MANT_BITS (53)
#endif

I.e., use float.h constants unconditionally whenever float support is
enabled. And gmp/bootstrap.c would then #define MINI_GMP_FLOAT_SUPPORT
0.

Independent of this suggestion, I have two minor comments on the your
change (43659273c9cf): I think the DONT_USE_FLOAT_H macro should have a
GMP or MINI_GMP prefix. And it would be nice with a test, e.g, based on
your sample program converting integers 2^i +/- 1 to double and
comparing the results (before your fix, mini-gmp rounded to nearest,
producing identical doubles for large enough i).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marco Bodrato]

Ciao,

Il Sab, 19 Maggio 2018 11:16 pm, Niels Möller ha scritto:
> "Marco Bodrato"  writes:
>
>> diff -r 41e50c4fdc46 bootstrap.c

>> +#define DONT_USE_FLOAT_H 1
>>  #include "mini-gmp/mini-gmp.c"

>> diff -r 41e50c4fdc46 mini-gmp/mini-gmp.c

>> +#if !defined(DONT_USE_FLOAT_H)
>> +#include 
>> +#endif

> Makes sense to me, provided that the define also excludes whatever
> mini-gmp functions depend on float.h (which would be get_d and set_d,

float.h is only used for

+#if defined(DBL_MANT_DIG) && FLT_RADIX == 2
+#define GMP_DBL_MANT_BITS DBL_MANT_DIG
+#else
+#define GMP_DBL_MANT_BITS (53)
+#endif

This constant is used only by the new version of get_d, to convert the
correct number of bits and avoid rounding.
I mean, the functions do not "depend on" float.h , and we don't need to
exclude them. Maybe we should decide for a different default value...

Ĝis,
m

-- 
http://bodrato.it/papers/

___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Niels Möller]

"Marco Bodrato"  writes:

> diff -r 41e50c4fdc46 bootstrap.c
> --- a/bootstrap.c   Wed May 16 08:36:03 2018 +0200
> +++ b/bootstrap.c   Fri May 18 07:24:52 2018 +0200
> @@ -29,6 +29,7 @@
>  see https://www.gnu.org/licenses/.  */
>
>
> +#define DONT_USE_FLOAT_H 1
>  #include "mini-gmp/mini-gmp.c"
>
>  #define MIN(l,o) ((l) < (o) ? (l) : (o))
> diff -r 41e50c4fdc46 mini-gmp/mini-gmp.c
> --- a/mini-gmp/mini-gmp.c   Wed May 16 08:36:03 2018 +0200
> +++ b/mini-gmp/mini-gmp.c   Fri May 18 07:24:52 2018 +0200
> @@ -50,6 +50,9 @@
>
>  #include "mini-gmp.h"
>
> +#if !defined(DONT_USE_FLOAT_H)
> +#include 
> +#endif

Makes sense to me, provided that the define also excludes whatever
mini-gmp functions depend on float.h (which would be get_d and set_d,
possibly cmp_d), and is named accordingly.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marco Bodrato]

Ciao,

Il Mer, 14 Marzo 2018 8:10 pm, Niels Möller ha scritto:
> "Marco Bodrato"  writes:
>
>> #if defined(USE_FLOAT_H)
>>  #include 
>> #endif
>
> This won't work well for mini-gmp.

>>> I'd also say that  can be assumed to be available.
>>
>> mini-gmp is used to bootstrap GMP... should we assume something for
>> mini- if we do not a assume it for GMP?

Maybe, at the moment, we should always use float.h for mini-gmp, except
when bootstraping GMP?

I mean, something like:

diff -r 41e50c4fdc46 bootstrap.c
--- a/bootstrap.c   Wed May 16 08:36:03 2018 +0200
+++ b/bootstrap.c   Fri May 18 07:24:52 2018 +0200
@@ -29,6 +29,7 @@
 see https://www.gnu.org/licenses/.  */


+#define DONT_USE_FLOAT_H 1
 #include "mini-gmp/mini-gmp.c"

 #define MIN(l,o) ((l) < (o) ? (l) : (o))
diff -r 41e50c4fdc46 mini-gmp/mini-gmp.c
--- a/mini-gmp/mini-gmp.c   Wed May 16 08:36:03 2018 +0200
+++ b/mini-gmp/mini-gmp.c   Fri May 18 07:24:52 2018 +0200
@@ -50,6 +50,9 @@

 #include "mini-gmp.h"

+#if !defined(DONT_USE_FLOAT_H)
+#include 
+#endif



Ĝis,
m

-- 
http://bodrato.it/

___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Niels Möller]

t...@gmplib.org (Torbjörn Granlund) writes:

> ni...@lysator.liu.se (Niels Möller) writes:
>
>   Torbjörn, what do you think? Are you aware of any system we'd like to
>   support but which lacks float.h?
>
> I have no idea about the presence of float.h in practice.

The data point we have is that back in 2002, it was missing on the C
compiler supplied with SunOS (and my guess is that it was included with
the "SunPRO" compiler Sun wanted to sell you separately).

But we can use https://codesearch.debian.net/ to get a little more data.

If we first get the list of packages which contains the strings
CONFIG_HEADER and float.h (these are the packages where it would make
sense with a configure check for it), that's 2665 packages. Not sure how
to do that as a single query, so I searched for one string at a time,
downloaded the list of matching packages, and combined using sort +
comm.

Next, get the list och packages containing the string HAVE_FLOAT_H.
That's 232 packages.

If we intersect those lists, we get 192 packages (gmp being one of them)
with configure checks for float.h.

If we take the difference, packages which use CONFIG_HEADER, and
float.h, but don't use any HAVE_FLOAT_H symbol, that's 2470 packages.
Some of the notable ones on the list:

  binutils
  bison
  cvs
  dropbear (ssh implementation often used on obscure embedded systems)
  erlang
  expat
  findutils
  firefox
  gdb
  gforth
  gnulib (unclear why that's packaged though)
  libjpeg6g
  lsh-utils (not active but old and has been known to work on obscure unix 
systems like irix)
  ntp
  octave
  patch
  recode
  screen
  sox
  tar
  tcl8.6
  tcsh
  tk8.6
  xterm

So a lot of old programs, several of them widely portable, seem to use
float.h unconditionally.

> I think it mkes sense to move to C99, but then we should of course first
> decide to do that, then start depending on its features,

I'm not thinking of float.h as a C99 thing, even if c99 formally made it
a mandatory language feature.

It's no big deal to keep the configure test in gmp, but it would help to
use float.h unconditionally in mini-gmp. 

And then we'd get the situation that if there are any systems with
compilers lacking float.h, it will no longer be possible to build gmp
natively there, one would need to cross compile it on a system where the
native compiler has float.h. Which is a bit odd.

Regards,
/Niels


-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Torbjörn Granlund]

ni...@lysator.liu.se (Niels Möller) writes:

  Torbjörn, what do you think? Are you aware of any system we'd like to
  support but which lacks float.h?

I have no idea about the presence of float.h in practice.

I think it mkes sense to move to C99, but then we should of course first
decide to do that, then start depending on its features,

When we move to C99, it might make sense to up the C++ standard too.  I
am not the right person to weigh the benefits and drawback of any C++
standards level. I've mainly used C++11.

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Niels Möller]

"Marco Bodrato"  writes:

> Maybe in printf/repl-vsnprintf.c we may also remove the
>
> #ifdef DBL_MAX_10_EXP
>
> and unconditionaly set double_digits = DBL_MAX_10_EXP.

Like below, then.

Torbjörn, what do you think? Are you aware of any system we'd like to
support but which lacks float.h?

Regards,
/Niels

diff -r 384bf781a7ee printf/repl-vsnprintf.c
--- a/printf/repl-vsnprintf.c   Sun Mar 11 19:22:32 2018 +0100
+++ b/printf/repl-vsnprintf.c   Sun Mar 25 12:59:24 2018 +0200
@@ -44,9 +44,7 @@ see https://www.gnu.org/licenses/.  */
 #include  /* for NULL */
 #include 
 
-#if HAVE_FLOAT_H
 #include  /* for DBL_MAX_10_EXP etc */
-#endif
 
 #if HAVE_INTTYPES_H
 # include  /* for intmax_t */
@@ -102,7 +100,7 @@ int
   const char  *fmt;
   size_t  total_width, integer_sizeof, floating_sizeof, len;
   charfchar, type;
-  int width, prec, seen_prec, double_digits, long_double_digits;
+  int width, prec, seen_prec;
   int *value;
 
   /* preserve orig_ap for use after size estimation */
@@ -124,28 +122,6 @@ int
   floating_sizeof = MAX (floating_sizeof, sizeof (long double));
 #endif
 
-  /* IEEE double or VAX G floats have an 11 bit exponent, so the default is
- a maximum 308 decimal digits.  VAX D floats have only an 8 bit
- exponent, but we don't bother trying to detect that directly.  */
-  double_digits = 308;
-#ifdef DBL_MAX_10_EXP
-  /* but in any case prefer a value the compiler says */
-  double_digits = DBL_MAX_10_EXP;
-#endif
-
-  /* IEEE 128-bit quad, Intel 80-bit temporary, or VAX H floats all have 15
- bit exponents, so the default is a maximum 4932 decimal digits.  */
-  long_double_digits = 4932;
-  /* but if double == long double, then go with that size */
-#if HAVE_LONG_DOUBLE
-  if (sizeof (double) == sizeof (long double))
-long_double_digits = double_digits;
-#endif
-#ifdef LDBL_MAX_10_EXP
-  /* but in any case prefer a value the compiler says */
-  long_double_digits = LDBL_MAX_10_EXP;
-#endif
-
   for (;;)
 {
   fmt = strchr (fmt, '%');
@@ -253,7 +229,7 @@ int
  {
 #if HAVE_LONG_DOUBLE
(void) va_arg (ap, long double);
-   total_width += long_double_digits;
+   total_width += LDBL_MAX_10_EXP;
 #else
ASSERT_FAIL (long double not available);
 #endif
@@ -261,7 +237,7 @@ int
else
  {
(void) va_arg (ap, double);
-   total_width += double_digits;
+   total_width += DBL_MAX_10_EXP;
  }
break;
 
 

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marco Bodrato]

Ciao,

Il Mer, 14 Marzo 2018 7:10 pm, Niels Möller ha scritto:
> Patch below.

> diff -Nprc2 gmp.384bf781a7ee/printf/repl-vsnprintf.c
> gmp/printf/repl-vsnprintf.c
> *** gmp.384bf781a7ee/printf/repl-vsnprintf.c  2018-03-14 19:06:44.147928820
> +0100
> --- gmp/printf/repl-vsnprintf.c   2018-03-14 19:06:44.163928775 +0100
> *** see https://www.gnu.org/licenses/.  */
> *** 45,51 
>   #include 
>
> - #if HAVE_FLOAT_H
>   #include  /* for DBL_MAX_10_EXP etc */
> - #endif
>
>   #if HAVE_INTTYPES_H
> --- 45,49 

Maybe in printf/repl-vsnprintf.c we may also remove the

#ifdef DBL_MAX_10_EXP

and unconditionaly set double_digits = DBL_MAX_10_EXP.

Ĝis,
m

-- 
http://bodrato.it/

___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marc Glisse]

On Sat, 17 Mar 2018, Vincent Lefevre wrote:


On 2018-03-16 22:22:39 +0100, Marc Glisse wrote:

On Fri, 16 Mar 2018, Marco Bodrato wrote:


float.h was defined by C99, right?


I am pretty sure it was already in C89.


Yes, but was DBL_MANT_DIG necessarily an integer constant expression
(in case this is needed) at that time?


Indeed it wasn't (only FLT_RADIX was), but I would be surprised if 
implementations made it non-constant, and we probably don't need to use it 
as a constant anyway.


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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Vincent Lefevre]

On 2018-03-16 22:22:39 +0100, Marc Glisse wrote:
> On Fri, 16 Mar 2018, Marco Bodrato wrote:
> 
> > float.h was defined by C99, right?
> 
> I am pretty sure it was already in C89.

Yes, but was DBL_MANT_DIG necessarily an integer constant expression
(in case this is needed) at that time?

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marc Glisse]

On Fri, 16 Mar 2018, Marco Bodrato wrote:


float.h was defined by C99, right?


I am pretty sure it was already in C89.

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marco Bodrato]

Ciao,

Il Mer, 14 Marzo 2018 7:10 pm, Niels Möller ha scritto:
> "Marco Bodrato"  writes:

>> #if defined(USE_FLOAT_H)
>>  #include 
>> #endif
>
> This won't work well for mini-gmp.

My idea was, if mini-gmp is used "as-is", it supports IEEE doubles.
If some other double format is needed, the user needs to define
USE_FLOAT_H, if it exists for the target arch, or define
GMP_BITS_PER_DOUBLE with the required number of bits.

>> #if defined(DBL_MANT_DIG) && FLT_RADIX == 2
>>  #define GMP_BITS_PER_DOUBLE DBL_MANT_DIG
>> #endif
>>
>> #if !defined(GMP_BITS_PER_DOUBLE)
>>  #define GMP_BITS_PER_DOUBLE (53)
>> #endif

> [...] for float.h, I think we could use it unconditionally
> also in gmp.
>
> Patch below.

It looks correct to me. float.h was defined by C99, right? One year ago we
thought about requiring at least C99... This is a step towards that
direction.

Ĝis,
m

-- 
http://bodrato.it/

___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Niels Möller]

"Marco Bodrato"  writes:

> #if defined(USE_FLOAT_H)
>  #include 
> #endif

This won't work well for mini-gmp.

> #if defined(DBL_MANT_DIG) && FLT_RADIX == 2
>  #define GMP_BITS_PER_DOUBLE DBL_MANT_DIG
> #endif
>
> #if !defined(GMP_BITS_PER_DOUBLE)
>  #define GMP_BITS_PER_DOUBLE (53)
> #endif

Sounds like a reasonable work-around.

>> I'd also say that  can be assumed to be available.
>
> mini-gmp is used to bootstrap GMP... should we assume something for mini-
> if we do nota assume it for GMP?

Not really. But for float.h, I think we could use it unconditionally
also in gmp.

Patch below.

Regards,
/Niels

diff -Nprc2 gmp.384bf781a7ee/ChangeLog gmp/ChangeLog
*** gmp.384bf781a7ee/ChangeLog  2018-03-14 19:06:44.139928842 +0100
--- gmp/ChangeLog   2018-03-14 19:06:44.159928787 +0100
***
*** 1,2 
--- 1,8 
+ 2018-03-11  Niels Möller  
+ 
+   * configure.ac: Delete configure check for float.h (introduced in
+   2002, for compatibility with SunOS cc). Also delete all use of
+   HAVE_FLOAT_H.
+ 
  2018-02-28 Marco Bodrato 
  
diff -Nprc2 gmp.384bf781a7ee/configure.ac gmp/configure.ac
*** gmp.384bf781a7ee/configure.ac   2018-03-14 19:06:44.143928831 +0100
--- gmp/configure.ac2018-03-14 19:06:44.163928775 +0100
*** AC_HEADER_TIME
*** 2713,2717 
  
  # Reasons for testing:
- #   float.h - not in SunOS bundled cc
  #   invent.h - IRIX specific
  #   langinfo.h - X/Open standard only, not in djgpp for instance
--- 2713,2716 
*** AC_HEADER_TIME
*** 2737,2741 
  # default tests
  #
! AC_CHECK_HEADERS(fcntl.h float.h invent.h langinfo.h locale.h nl_types.h 
sys/attributes.h sys/iograph.h sys/mman.h sys/param.h sys/processor.h 
sys/pstat.h sys/sysinfo.h sys/syssgi.h sys/systemcfg.h sys/time.h sys/times.h)
  
  # On SunOS, sys/resource.h needs sys/time.h (for struct timeval)
--- 2736,2740 
  # default tests
  #
! AC_CHECK_HEADERS(fcntl.h invent.h langinfo.h locale.h nl_types.h 
sys/attributes.h sys/iograph.h sys/mman.h sys/param.h sys/processor.h 
sys/pstat.h sys/sysinfo.h sys/syssgi.h sys/systemcfg.h sys/time.h sys/times.h)
  
  # On SunOS, sys/resource.h needs sys/time.h (for struct timeval)
diff -Nprc2 gmp.384bf781a7ee/mpf/cmp_d.c gmp/mpf/cmp_d.c
*** gmp.384bf781a7ee/mpf/cmp_d.c2018-03-14 19:06:44.143928831 +0100
--- gmp/mpf/cmp_d.c 2018-03-14 19:06:44.163928775 +0100
*** see https://www.gnu.org/licenses/.  */
*** 31,37 
  #include "config.h"
  
- #if HAVE_FLOAT_H
  #include   /* for DBL_MAX */
- #endif
  
  #include "gmp-impl.h"
--- 31,35 
diff -Nprc2 gmp.384bf781a7ee/mpf/set_d.c gmp/mpf/set_d.c
*** gmp.384bf781a7ee/mpf/set_d.c2018-03-14 19:06:44.143928831 +0100
--- gmp/mpf/set_d.c 2018-03-14 19:06:44.163928775 +0100
*** see https://www.gnu.org/licenses/.  */
*** 31,37 
  #include "config.h"
  
- #if HAVE_FLOAT_H
  #include   /* for DBL_MAX */
- #endif
  
  #include "gmp-impl.h"
--- 31,35 
diff -Nprc2 gmp.384bf781a7ee/mpq/set_d.c gmp/mpq/set_d.c
*** gmp.384bf781a7ee/mpq/set_d.c2018-03-14 19:06:44.147928820 +0100
--- gmp/mpq/set_d.c 2018-03-14 19:06:44.163928775 +0100
*** see https://www.gnu.org/licenses/.  */
*** 31,37 
  #include "config.h"
  
- #if HAVE_FLOAT_H
  #include   /* for DBL_MAX */
- #endif
  
  #include "gmp-impl.h"
--- 31,35 
diff -Nprc2 gmp.384bf781a7ee/mpz/cmpabs_d.c gmp/mpz/cmpabs_d.c
*** gmp.384bf781a7ee/mpz/cmpabs_d.c 2018-03-14 19:06:44.147928820 +0100
--- gmp/mpz/cmpabs_d.c  2018-03-14 19:06:44.163928775 +0100
*** see https://www.gnu.org/licenses/.  */
*** 31,37 
  #include "config.h"
  
- #if HAVE_FLOAT_H
  #include   /* for DBL_MAX */
- #endif
  
  #include "gmp-impl.h"
--- 31,35 
diff -Nprc2 gmp.384bf781a7ee/mpz/cmp_d.c gmp/mpz/cmp_d.c
*** gmp.384bf781a7ee/mpz/cmp_d.c2018-03-14 19:06:44.147928820 +0100
--- gmp/mpz/cmp_d.c 2018-03-14 19:06:44.163928775 +0100
*** see https://www.gnu.org/licenses/.  */
*** 31,37 
  #include "config.h"
  
- #if HAVE_FLOAT_H
  #include   /* for DBL_MAX */
- #endif
  
  #include "gmp-impl.h"
--- 31,35 
diff -Nprc2 gmp.384bf781a7ee/mpz/set_d.c gmp/mpz/set_d.c
*** gmp.384bf781a7ee/mpz/set_d.c2018-03-14 19:06:44.147928820 +0100
--- gmp/mpz/set_d.c 2018-03-14 19:06:44.163928775 +0100
*** see https://www.gnu.org/licenses/.  */
*** 31,37 
  #include "config.h"
  
- #if HAVE_FLOAT_H
  #include   /* for DBL_MAX */
- #endif
  
  #include "gmp-impl.h"
--- 31,35 
diff -Nprc2 gmp.384bf781a7ee/printf/repl-vsnprintf.c gmp/printf/repl-vsnprintf.c
*** gmp.384bf781a7ee/printf/repl-vsnprintf.c2018-03-14 19:06:44.147928820 
+0100
--- gmp/printf/repl-vsnprintf.c 2018-03-14 19:06:44.163928775 +0100
*** see https://www.gnu.org/licenses/.  */
*** 45,51 
  #include 
  
- #if HAVE_FLOAT_H
  #include  /* for DBL_MAX_10_EXP etc */
- 

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marco Bodrato]

Ciao,

Il Mar, 13 Marzo 2018 5:46 pm, Vincent Lefevre ha scritto:
> On 2018-03-13 17:29:48 +0100, Marc Glisse wrote:
>> just assume that float.h is always available nowadays. Or even assume
>> that all double are 64-bit binary IEEE numbers...

#if defined(USE_FLOAT_H)
 #include 
#endif

#if defined(DBL_MANT_DIG) && FLT_RADIX == 2
 #define GMP_BITS_PER_DOUBLE DBL_MANT_DIG
#endif

#if !defined(GMP_BITS_PER_DOUBLE)
 #define GMP_BITS_PER_DOUBLE (53)
#endif

> I'd also say that  can be assumed to be available.

mini-gmp is used to bootstrap GMP... should we assume something for mini-
if we do nota assume it for GMP?

On the other side, while bootstraping, mini-gmp is not used for
conversions to/from double. In my opinion we can live with a mini-gmp that
by dafault is exact only for 64-bit binary IEEE numbers, as Marc suggests,
and can be adapted to other formats with some user intervention.

Ĝis,
m

-- 
http://bodrato.it/papers/

___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Vincent Lefevre]

On 2018-03-13 17:29:48 +0100, Marc Glisse wrote:
> +1 to that. For mini-gmp, maybe put all the functions using 'double' behind
> some macro or in a separate file so it is easy for a user to remove them,
> and document that they are only supported with a standard float.h header. Or
> just assume that float.h is always available nowadays. Or even assume that
> all double are 64-bit binary IEEE numbers...

I'd also say that  can be assumed to be available.

If some platform does not have it, then wait for a bug report and
possibly add a fallback, which should be much easier when knowing
the broken platform in question.

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marc Glisse]

On Tue, 13 Mar 2018, Niels Möller wrote:


I'd still prefer the simpler way of reying on float.h constants,
though


+1 to that. For mini-gmp, maybe put all the functions using 'double' 
behind some macro or in a separate file so it is easy for a user to remove 
them, and document that they are only supported with a standard float.h 
header. Or just assume that float.h is always available nowadays. Or even 
assume that all double are 64-bit binary IEEE numbers...


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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Vincent Lefevre]

On 2018-03-13 15:34:26 +0100, Torbjorn Granlund wrote:
> ni...@lysator.liu.se (Niels Möller) writes:
>   If we can make this thread safe with C11, I think it's fine to document
>   that mini-gmp requires C11 for thread safety. (I'd still prefer the
>   simpler way of reying on float.h constants, though).
> 
> Let's remind ourselves that we are not executing GMP on a standards
> document, but on actual computer systems.  :-)
> 
> Store reordering is an actual problem which we should keep in mind (but
> note that x86 implements total store ordering).  Non-atomic loads/stores
> is not as long as we keep to short types.

As I've said, I think that too short types can be a problem if,
in order to modify a variable v, the generated code must do:

1. Load data containing v (and other things).
2. Modify a part of the data (only the variable v).
3. Store the data back to memory.

For instance:

* A 32-bit variable on a CPU that has 64-bit stores but not 32-bit
  stores. (FYI, in the past, something like that had to be done on
  ARM with 16-bit "short int". I don't know about the other CPU's.
  Perhaps DEC Alpha, now obsolete.)

* Loading a variable v may also load a cache line. For CPU's where
  cache consistency is not enforced, this may also be an issue if
  this must be handled with specific instructions and the compiler
  optimizes based on undefined behavior (i.e. assuming that data
  race is not possible).

What you need in such a case is probably a short type inside a large
enough structure, where the other data are not used.

Alternatively, if C11 and the use of _Atomic can optionally be
supported (e.g. via the __STDC_VERSION__ and __STDC_NO_ATOMICS__
macros), this would ensure correctness on such platforms. On the
other platforms, it would be up to the user to check...

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Vincent Lefevre]

On 2018-03-13 15:12:27 +0100, Niels Möller wrote:
> Does C11 provide any way to initialize a local static variable, like in
> recent C++? I.e., not code running before main, but code running the
> first time the function is entered, and guaranteed to run just once?

I don't think so. 6.7.9p4 says "All the expressions in an initializer
for an object that has static or thread storage duration shall be
constant expressions or string literals." and function calls (in
particular) are not possible in constant expressions. So, nothing
portable.

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Torbjörn Granlund]

ni...@lysator.liu.se (Niels Möller) writes:

  Does C11 provide any way to initialize a local static variable, like in
  recent C++? I.e., not code running before main, but code running the
  first time the function is entered, and guaranteed to run just once?

  > I don't think volatile matters. AFAIK, what you need is _Atomic (C11).

  If we can make this thread safe with C11, I think it's fine to document
  that mini-gmp requires C11 for thread safety. (I'd still prefer the
  simpler way of reying on float.h constants, though).

Let's remind ourselves that we are not executing GMP on a standards
document, but on actual computer systems.  :-)

Store reordering is an actual problem which we should keep in mind (but
note that x86 implements total store ordering).  Non-atomic loads/stores
is not as long as we keep to short types.

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Niels Möller]

Vincent Lefevre  writes:

> More than an order issue, this is undefined behavior. In C11:
>
> 5.1.2.4 Multi-threaded executions and data races
>
>4  Two expression evaluations conflict if one of them modifies a
>   memory location and the other one reads or modifies the same
>   memory location.
>
>   25  The execution of a program contains a data race if it contains
>   two conflicting actions in different threads, at least one of
>   which is not atomic, and neither happens before the other. Any
>   such data race results in undefined behavior.

Does C11 provide any way to initialize a local static variable, like in
recent C++? I.e., not code running before main, but code running the
first time the function is entered, and guaranteed to run just once?

> I don't think volatile matters. AFAIK, what you need is _Atomic (C11).

If we can make this thread safe with C11, I think it's fine to document
that mini-gmp requires C11 for thread safety. (I'd still prefer the
simpler way of reying on float.h constants, though).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Vincent Lefevre]

On 2018-03-13 13:55:27 +0100, Torbjorn Granlund wrote:
> Vincent Lefevre  writes:
> 
>   On 2018-03-12 18:53:37 +0100, Marco Bodrato wrote:
>   > double
>   > mpz_get_d (const mpz_t u)
>   > {
>   >   static int c = 0;
>   >   static int __initialized = 0;
>   > 
>   >   if (__initialized != 1) {
>   > c = gmp_tests_dbl_mant_bits ();
>   > *((volatile int *) &__initialized) = 1;
>   >   }
> 
>   FYI, this is not thread-safe.
> 
> I suppose the externally visible store order is not guaranteed to be the
> same as the program store order, not even with "volatile".

More than an order issue, this is undefined behavior. In C11:

5.1.2.4 Multi-threaded executions and data races

   4  Two expression evaluations conflict if one of them modifies a
  memory location and the other one reads or modifies the same
  memory location.

  25  The execution of a program contains a data race if it contains
  two conflicting actions in different threads, at least one of
  which is not atomic, and neither happens before the other. Any
  such data race results in undefined behavior.

Actually the problem is not just on __initialized, but also on c:
if two threads test __initialized != 1 at the same time for their
first call, they will both execute

  c = gmp_tests_dbl_mant_bits ();

If the modification of c is not atomic, then may result in an
incorrect value for c, but also for other arbitrary variables
or more generally memory corruption (for instance, if int is
on 32 bits but CPU accesses are 64-bit only). Same problem with
__initialized if this has side effects on adjacent memory.

BTW, that's probably why the C standard says "undefined behavior"
and not just "indeterminate value".

> One variable, declared as volatile, should work fine though.

I don't think volatile matters. AFAIK, what you need is _Atomic (C11).

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Torbjörn Granlund]

Vincent Lefevre  writes:

  On 2018-03-12 18:53:37 +0100, Marco Bodrato wrote:
  > double
  > mpz_get_d (const mpz_t u)
  > {
  >   static int c = 0;
  >   static int __initialized = 0;
  > 
  >   if (__initialized != 1) {
  > c = gmp_tests_dbl_mant_bits ();
  > *((volatile int *) &__initialized) = 1;
  >   }

  FYI, this is not thread-safe.

I suppose the externally visible store order is not guaranteed to be the
same as the program store order, not even with "volatile".

One variable, declared as volatile, should work fine though.  Of course,
that assumes some value for the variable can be used to represent a
non-initialised state.  For c above, 0 seems to be a useable value as no
floating-point format with zero mantissa bits has yet been invented.

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Vincent Lefevre]

On 2018-03-12 18:53:37 +0100, Marco Bodrato wrote:
> double
> mpz_get_d (const mpz_t u)
> {
>   static int c = 0;
>   static int __initialized = 0;
> 
>   if (__initialized != 1) {
> c = gmp_tests_dbl_mant_bits ();
> *((volatile int *) &__initialized) = 1;
>   }

FYI, this is not thread-safe.

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Torbjörn Granlund]

"Marco Bodrato"  writes:

  You mean we should declare
  static volatile int c = 0;

Yes.

  Sounds like and oxymoron to me :-)

Please explain.


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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marco Bodrato]

Ciao,

Il Lun, 12 Marzo 2018 4:57 pm, Torbjörn Granlund ha scritto:
>   > ... if the compiler inlines the static gmp_tests_dbl_mant_bits
>   > function, and optimizes away the local variable n, directly
>   > updating c in the loop, then it can be a problem...

> Only the sensitive target variable would seem to need a volatile decl.

You mean we should declare
static volatile int c = 0;

Sounds like and oxymoron to me :-)

Or should we use another variable, similar in some way to the fat code?

double
mpz_get_d (const mpz_t u)
{
  static int c = 0;
  static int __initialized = 0;

  if (__initialized != 1) {
c = gmp_tests_dbl_mant_bits ();
*((volatile int *) &__initialized) = 1;
  }

...


Ĝis,
m

-- 
http://bodrato.it/

___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Torbjörn Granlund]

  > ... if the compiler inlines the static gmp_tests_dbl_mant_bits function,
  > and optimizes away the local variable n, directly updating c in the loop,
  > then it can be a problem... suggestions?
  > We can declare c as int and n as unsigned. But I fear this is not a real 
  > obstacle for an optimizer.

  Might help to declare c and/or n as volatile.

Only the sensitive target variable would seem to need a volatile decl.

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Niels Möller]

"Marco Bodrato"  writes:

> ... if the compiler inlines the static gmp_tests_dbl_mant_bits function,
> and optimizes away the local variable n, directly updating c in the loop,
> then it can be a problem... suggestions?
> We can declare c as int and n as unsigned. But I fear this is not a real 
> obstacle for an optimizer.

Might help to declare c and/or n as volatile.

>> If we could use float.h constants, we wouldn't need to worry.
>
> In GMP we can #if HAVE_FLOAT_H ... but in mini-gmp?

I think float.h is standard C (not sure which version, though).
Configure check needed only for obscure systems. If it really is still needed
for gmp, maybe we can have GMP define it, and let mini-gmp.c do something
like

#ifndef GMP_DOUBLE_MANTISA_DIGITS
# include 
# if FLT_RADIX == 2
#  define GMP_DOUBLE_MANTISA_DIGITS DBL_MANT_DIG
# endif
#endif

And later fall back to something generic and less precise if
GMP_DOUBLE_MANTISA_DIGITS is not defined.

I hope we don't need it though, since (i) it's a bit ugly, and (ii) gmp
needs mini-gmp for the build system, not the host system, and I don't
think we have any configure checks for float.h using CC_FOR_BUILD.

I hope we can do the simple thing and include float.h unconditionally.

Hmm, according to the ChangeLog, the configure test was added by Kevin Ryde in
2002, because the SunOS C compiler (the one bundled with the
system if you didn't buy the SunPRO compiler separately, I guess) didn't
provide it. Maybe it's time to delete that?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Niels Möller]

"Marco Bodrato"  writes:

> double
> mpz_get_d (const mpz_t u)
> {
>   static unsigned int c = 0;
>   int m;

I'd prefer more descriptive names for c and m.

>   if (c == 0)
> c = gmp_tests_dbl_mant_bits ();

This is *almost* thread-safe. If two threads race in calling this
function for the first time, it should still work provided that access
to c is atomic (it doesn't matter if gmp_tests_dbl_mant_bits is called
twice, producing the same result). That's probably the case on most
platforms, but not entirely kosher. It would break if the first thread
writes c, and the second threads reads a non-zero value of c with a mix
of the old value (zero) and the new value.

I know recent c++ defines the meaning of a static initializer like

  static unsigned int c = gmp_tests_dbl_mant_bits ();

so that the initializer is evaluated exactly once, after the first entry
to the function, but before any thread uses the value (likely generating
code using pthread_once). Has anything like that made it into recent C
standards?

If we could use float.h constants, we wouldn't need to worry.

>   l = u->_mp_d[--un];
>   gmp_clz (m, l);
>   m = m + c - GMP_LIMB_BITS;
>   if (m < 0)
> l &= GMP_LIMB_MAX << -m;
>
>   for (x = l; --un >= 0;)
> {
>   x = B*x;
>   if (m > 0) {
>   l = u->_mp_d[un];
>   m -= GMP_LIMB_BITS;
>   if (m < 0)
> l &= GMP_LIMB_MAX << -m;
>   x += l;
>   }
> }

Maybe rearrange loop so that 

   if (m < 0)
 l &= GMP_LIMB_MAX << -m;
   x += l;

is done after the loop, and not repeated prior to the loop?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marco Bodrato]

Ciao,

Il Mar, 6 Marzo 2018 11:58 pm, Marc Glisse ha scritto:
> It is also possible to determine it at runtime (comparing 2^n+{0,1,2} for
> instance should work whether we round up, down or to the nearest;
> tests/misc.c compares 2^n+1-2^n to 1, which also looks good), doing it

Well, stealing the tests_dbl_mant_bits code from tests-misc.c, I wrote the
following code for mini-gmp. It seams to work...

Comments?

-8<--8<
static unsigned int
gmp_tests_dbl_mant_bits (void)
{
  unsigned int n;
  volatile double x, y, d;

  n = 1;
  x = d = 1.0;
  do {
x *= 2.0;
y = x + d;
d = y - x;
  } while (d == 1.0 && ++n < sizeof(double) * CHAR_BIT);

  return n;
}

double
mpz_get_d (const mpz_t u)
{
  static unsigned int c = 0;
  int m;
  mp_limb_t l;
  mp_size_t un;
  double x;
  double B = 2.0 * (double) GMP_LIMB_HIGHBIT;

  un = GMP_ABS (u->_mp_size);

  if (un == 0)
return 0.0;

  if (c == 0)
c = gmp_tests_dbl_mant_bits ();

  l = u->_mp_d[--un];
  gmp_clz (m, l);
  m = m + c - GMP_LIMB_BITS;
  if (m < 0)
l &= GMP_LIMB_MAX << -m;

  for (x = l; --un >= 0;)
{
  x = B*x;
  if (m > 0) {
l = u->_mp_d[un];
m -= GMP_LIMB_BITS;
if (m < 0)
  l &= GMP_LIMB_MAX << -m;
x += l;
  }
}

  if (u->_mp_size < 0)
x = -x;

  return x;
}
-8<--8<


Ĝis,
m

-- 
http://bodrato.it/

___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marc Glisse]

On Fri, 9 Mar 2018, Torbjörn Granlund wrote:


 For GMP, it's desirable to fix also the non IEEE-version.

That would have some value, I suppose, although non-IEEE formats of
course have become largely obsolete.


This code is mostly used not for non-IEEE formats, but for cases where we 
fail to detect that it *is* IEEE. For instance when compiling to bitcode 
(gcc LTO, LLVM, webassembly, etc). Of course, better IEEE detection would 
help those more than fixing the fallback path.


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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Torbjörn Granlund]

Marc Glisse  writes:

  It is also possible to determine it at runtime (comparing 2^n+{0,1,2}
  for instance should work whether we round up, down or to the nearest;
  tests/misc.c compares 2^n+1-2^n to 1, which also looks good), doing it
  once and storing the result somewhere.

Oops, sorry for repeating your suggestion.

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Torbjörn Granlund]

ni...@lysator.liu.se (Niels Möller) writes:

  For mini-gmp, it's highly desirable for the get_d function to be fully
  compatible with gmp at least for the common case of standard IEEE
  floats. I'm fine with documenting different behavior for obscure
  floating point variants.

I agree, albeit not strongly.  :-)

  For GMP, it's desirable to fix also the non IEEE-version.

That would have some value, I suppose, although non-IEEE formats of
course have become largely obsolete.  We could test any new code on vax
under the simh emulator, and perhaps on a s390 system/emulator.

One should also test on IEEE systems by disabling the punning code.
And then manipulate the rounding mode!

  If I recall earlier discussion correctly, we really need to know the
  size of the mantissa, from the compiler or a configure check (and the
  latter is not applicable to mini-gmp).

Or even a run-time check.  It should not take too long, a binary search
for the first steps might make sense.

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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marc Glisse]

On Tue, 6 Mar 2018, Niels Möller wrote:


Marc Glisse  writes:


On Tue, 6 Mar 2018, Marco Bodrato wrote:


Which solutions do you suggest? I see 3 possible ways:
- removing the non "fully compatible" functions;
- adding them to the "with a few exceptions:" section;
- correct the behaviour of the functions...


As discussed for instance last October, the generic, non-IEEE version
of mpn_get_d has a similar issue. Maybe they could both be fixed at
the same time with the same code?


For mini-gmp, it's highly desirable for the get_d function to be fully
compatible with gmp at least for the common case of standard IEEE
floats. I'm fine with documenting different behavior for obscure
floating point variants.

For GMP, it's desirable to fix also the non IEEE-version.

Can we rely on FLT_RADIX and DBL_MANT_DIG (float.h, see
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/float.h.html),
to get correct rounding at least as long as FLT_RADIX == 2 ?


The code shouldn't be too hard to write using count_leading_zeros and 
DBL_MANT_DIG, but I have no idea how many platforms are missing 
DBL_MANT_DIG. I am not really interested in such platforms...



If I recall earlier discussion correctly, we really need to know the
size of the mantissa, from the compiler or a configure check (and the
latter is not applicable to mini-gmp).


It is also possible to determine it at runtime (comparing 2^n+{0,1,2} for 
instance should work whether we round up, down or to the nearest; 
tests/misc.c compares 2^n+1-2^n to 1, which also looks good), doing it 
once and storing the result somewhere.


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

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Niels Möller]

Marc Glisse  writes:

> On Tue, 6 Mar 2018, Marco Bodrato wrote:
>
>> Which solutions do you suggest? I see 3 possible ways:
>> - removing the non "fully compatible" functions;
>> - adding them to the "with a few exceptions:" section;
>> - correct the behaviour of the functions...
>
> As discussed for instance last October, the generic, non-IEEE version
> of mpn_get_d has a similar issue. Maybe they could both be fixed at
> the same time with the same code?

For mini-gmp, it's highly desirable for the get_d function to be fully
compatible with gmp at least for the common case of standard IEEE
floats. I'm fine with documenting different behavior for obscure
floating point variants.

For GMP, it's desirable to fix also the non IEEE-version.

Can we rely on FLT_RADIX and DBL_MANT_DIG (float.h, see
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/float.h.html),
to get correct rounding at least as long as FLT_RADIX == 2 ?

If I recall earlier discussion correctly, we really need to know the
size of the mantissa, from the compiler or a configure check (and the
latter is not applicable to mini-gmp).

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

[Marc Glisse]

On Tue, 6 Mar 2018, Marco Bodrato wrote:


Which solutions do you suggest? I see 3 possible ways:
- removing the non "fully compatible" functions;
- adding them to the "with a few exceptions:" section;
- correct the behaviour of the functions...


As discussed for instance last October, the generic, non-IEEE version of 
mpn_get_d has a similar issue. Maybe they could both be fixed at the same 
time with the same code?


Obviously this assumes that someone can find time to do it... Otherwise, I 
guess that option 2 could do, until a volunteer appears.


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