"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 spli
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, withou
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)
S
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_
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 m
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
g
"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 an
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
>> +#en
"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-g
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
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 b
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 t
"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?
Regard
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-1
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 t
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?
--
Vince
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
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
"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
Soun
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
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 tha
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 on
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, th
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 "
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. A
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
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) {
>
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 *) &__initia
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-saf
"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://gmpli
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
> ... 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 o
On Sun, 2018-03-11 at 00:15 +0100, Niels Möller wrote:
>
> 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?
__at
"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
> o
Ciao,
Il Dom, 11 Marzo 2018 12:15 am, Niels Möller ha scritto:
> "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.
In my working version they was named celo and mnk :-)
>> if (c ==
"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
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
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 d
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 re
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 no
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
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
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 generi
43 matches
Mail list logo