Re: C99 and GMP

2018-04-27 Thread Marc Glisse

On Fri, 27 Apr 2018, Marc Glisse wrote:


On Fri, 27 Apr 2018, paul zimmermann wrote:


quite interesting. Why is gmp/mpn not tested in the head coverage?


It is tested. It appears as /var/tmp/lcov/gmp/mpn because it is a set of
symlinks created at build time.


sorry I missed that. I see some of the files are not tested at all
(add_err3_n.c for example), and some have a low coverage (div_qr_1.c
for example). Are there any plans to improve that?


Even for the generic files, the coverage varies per target, maybe add_err3_n 
is better tested on ARM or something (not really answering your question).


Hmm, no, mpn_add_err3_n really seems completely unused. There is a refmpn 
implementation ready for comparisons...


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


Re: C99 and GMP

2018-04-27 Thread Marc Glisse

On Fri, 27 Apr 2018, paul zimmermann wrote:


quite interesting. Why is gmp/mpn not tested in the head coverage?


It is tested. It appears as /var/tmp/lcov/gmp/mpn because it is a set of
symlinks created at build time.


sorry I missed that. I see some of the files are not tested at all
(add_err3_n.c for example), and some have a low coverage (div_qr_1.c
for example). Are there any plans to improve that?


Even for the generic files, the coverage varies per target, maybe 
add_err3_n is better tested on ARM or something (not really answering your 
question).


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


Re: C99 and GMP

2018-04-27 Thread paul zimmermann
> > quite interesting. Why is gmp/mpn not tested in the head coverage?
> 
> It is tested. It appears as /var/tmp/lcov/gmp/mpn because it is a set of 
> symlinks created at build time.

sorry I missed that. I see some of the files are not tested at all
(add_err3_n.c for example), and some have a low coverage (div_qr_1.c
for example). Are there any plans to improve that?

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


Re: C99 and GMP

2018-04-27 Thread Marc Glisse

On Fri, 27 Apr 2018, paul zimmermann wrote:


https://gmplib.org/devel/lcov/shell/gmp/mini-gmp/mini-mpq.c.gcov.html


quite interesting. Why is gmp/mpn not tested in the head coverage?


It is tested. It appears as /var/tmp/lcov/gmp/mpn because it is a set of 
symlinks created at build time.


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


Re: C99 and GMP

2018-04-26 Thread Marco Bodrato
Ciao Marc,

Il Gio, 26 Aprile 2018 4:40 pm, Marc Glisse ha scritto:
> Marco had a mini-mpq that seemed to be in a working state. I guess it is
> missing tests, so too much work for 6.2. Is that a correct interpretation
> of the status?

I pushed it, so that you can see the status ;-)
I did not include the to/from double conversion function, they do not pass
my tests with the current mpz_get_d.

Testing coverage is good:
https://gmplib.org/devel/lcov/shell/gmp/mini-gmp/mini-mpq.c.gcov.html

What is missing? Documentation.
I mean, a few lines in mini-gmp/README

Also a correct documentation of lazy mpq is missing, but needed before the
release.

Ĝis,
m

-- 
http://bodrato.it/

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


Re: C99 and GMP

2018-04-26 Thread Marc Glisse

On Wed, 4 Apr 2018, Torbjörn Granlund wrote:


I'd suggest to make a 6.2 release of pretty much what we have today.


Marco had a mini-mpq that seemed to be in a working state. I guess it is 
missing tests, so too much work for 6.2. Is that a correct interpretation 
of the status?


(I am trying to think of things lying around that would be easy / safe to 
push)


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


Re: C99 and GMP

2018-04-04 Thread Marco Bodrato
Ciao,

Il Mer, 4 Aprile 2018 9:00 am, Niels Möller ha scritto:
> t...@gmplib.org (Torbjörn Granlund) writes:
>> I'd suggest to make a 6.2 release of pretty much what we have today.
>
> Sounds good to me. Looking through my entries in ChangeLog, most
> interesting change was the merge of my changes (originating several
> years ago) to change the conventions for what bdiv functions compute.

On my side, the main change was lazy allocation, both on the main library
and for mini-: mpz_init does not allocate any more, and _mp_alloc can be
0.

Ĝis,
m

-- 
http://bodrato.it/

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


Re: C99 and GMP

2018-04-04 Thread Torbjörn Granlund
  > I'd like to move to C99 soon.

  Nice. Any particular C99 features you'd like to use? Some of the
  features (from the list on https://en.wikipedia.org/wiki/C99):

I am aware of that there are no compelling features provided with C99,
and that the ones at all relevant to us will not bring new GMP user
features.

I would like to add "long long" arguments and return values to user
visible functions, though.  While that will not improve any semantics of
the interface for 64-bit *nix computers, it will slightly improve the
interface, and also improve the semantics for 32-bit systems and for
Windoze.

It would be nice to allow users to use old compilers for application
compiles, which means that we'll need to declare any "long long"
functions behind some cpp conditional (__STDC_VERSION__).  We should
make absolutely sure that slightly outdated gcc does not need any extra
command line arguments for compiling user code.

Shall we move to a newer C++ standard too?  I know we discussed this in
the past, but I don't remember the pros and cons of moving to any
particular standard.  I believe C++ is less critical as it is still not
compiled by default; we might therefore ask for a newer standard there.

About the new release; I'd like to call it 6.2.  I am not sure when to
invoke the magic increment to the most significant version digit, but it
is probably not now.

(I suppose GMP 7 could add the range extension features recently
discussed, and perhaps do some of the cleanups listed here:
 and then of course
Nisse's FFT code which he is eager to finish.)

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


Re: C99 and GMP

2018-04-04 Thread Niels Möller
t...@gmplib.org (Torbjörn Granlund) writes:

> I'd like to move to C99 soon.

Nice. Any particular C99 features you'd like to use? Some of the
features (from the list on https://en.wikipedia.org/wiki/C99):

* Better floating point support (e.g., standardized float.h).

* Standard inline (with semantics different from what older gcc did).

* Variable length arrays, which could replace some or all use of alloca
  (but this was demoted to an optional language feature in C11, so maybe
  not portable enough).

* Mid-block declarations.

* New types stdint.h, stdbool.h, complex.h. I imagine that changing int
  to bool where appropriate in the public functions would be an ABI
  break, though. New functions with intmax_t arguments may be useful (as
  discussed earlier), even if the concept of "intmax_t" will likely
  break over time in the same way as "long", which originally meant
  about the same thing.

* snprintf and vsnprintf now in the standard library.

* Standard variadic macros.

* restrict keyword (which we already use on compilers supporting it,
  right?)

* C++ style // comments 
 
> I'd suggest to make a 6.2 release of pretty much what we have today.

Sounds good to me. Looking through my entries in ChangeLog, most
interesting change was the merge of my changes (originating several
years ago) to change the conventions for what bdiv functions compute.

And a few bug-fixes in mini-gmp/ChangeLog.

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