Re: Configure unable to recognize mipsisa64r2el triplets

[Torbjörn Granlund]

Jiaxun Yang  writes:

  I'm trying to cross-compile GMP for a MIPS64r2 target. The triple is
  mipsisa64r2el-unknow-linux-gnu witch get from config.guess. And the
  expected ABI should be ABI=64. However, the ./configure told me that
  the only choice of ABI is o32.

I've never seen "mipsisa64r2el" before.

Where do you run config.guess given that you are cross compiling?

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

Re: [MPFR] Mac OS X power pc issue with C99

[Torbjörn Granlund]

paul zimmermann  writes:

 Dear Arnold,
  
  the "duplicate symbol ___gmpz_abs" seems to be a frequent issue on Mac OS:
  
  http://mail-index.netbsd.org/pkgsrc-users/2008/11/20/msg008688.html
  https://groups.google.com/forum/#!topic/sage-devel/LVASCTPZnXw
  
http://avr.2057.n7.nabble.com/Trouble-compiling-avr-gcc-gt-4-4-4-on-Mac-OS-X-Leopard-with-gcc-4-2-td8706i20.html
  
  The most useful answer I found is that one:
  
  https://gmplib.org/list-archives/gmp-bugs/2010-January/001747.html
  
[Admin: Please note that as per previous announcements, we don't put bug
reports for extremely obsolete GMP releases on the list.  Therefore,
there is no need to follow up on such reports.]

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

Re: parallel make bug in tune/ directory

[Torbjörn Granlund]

Vincent Lefevre  writes:

  The user always has the right to use the -j option if he wants to.

Thanks for clarifying that, Vincent!

Unfortunately, the result will be a build error in the tune subdir.  But
I assume the GMP developers have The Right to release GMP without
parallel developer subdir builds?  :-)
  
  '.NOTPARALLEL'
  
   If '.NOTPARALLEL' is mentioned as a target, then this invocation of
   'make' will be run serially, even if the '-j' option is given.  Any
   recursively invoked 'make' command will still run recipes in
   parallel (unless its makefile also contains this target).  Any
   prerequisites on this target are ignored.

Patch?

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

Re: parallel make bug in tune/ directory

[Torbjörn Granlund]

Win C  writes:

  This is a bug of the current mercurial repo in the tune/ directory:
  
  When I run `make -j6 allprogs` for the first time, an error was emitted:
  
  
  libtool: link: (cd .libs/libspeed.lax/libtests.a && ar x 
"/data/data/com.termux/files/home/gmp-unstable/tune/../tests/.libs/libtests.a")
  
  libtool:   error: cannot find the library 'libspeed.la' or unhandled argument 
'libspeed.la'
  
  make: *** [Makefile:626: tune-gcd-p] Error 1
  
  The error will not be emitted when I invoke the above command for the second 
time. How to fix this? Thanks!

Parallel build in the tune subdir are not supported.  Please build
normally therein.

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

Re: repl-vsnprintf.c:396:0: error: ISO C forbids an empty translation unit

[Torbjörn Granlund]

Dennis Clarke  writes:

  As a minor annoyance it does cause gcc ( recent versions 7.x ) to fail.
  Oddly enough ye Oracle Studio 12.6 cc running in strict c99 mode is fine
  and happy with everything. That is a new experience for me. However the
  performance on sparc is miserable.  We all know this and we know why.
  
I like Vincent's proposal; I had thought we needed to add something
which leaves garbage in the object files.

About sparc GMP performance, yes it's very poor except for T4-T5 where
it's acceptable.

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

Re: Configure fails on 32-bit platform

[Torbjörn Granlund]

Vincent Lefevre  writes:

  So, if I understand correctly, this means that if the user chooses
  to set -m32 in CFLAGS, he might have to try different ABI values
  before finding one that works (because -m32 does not necessarily
  imply 32-bit limbs). This is not nice.

It is not easy to find anything better than what we have today.

The current strategy was chosen to work best for most users, and work
best here means to give optimal GMP performance.  If the optimal "ABI"
does not work, the next best "ABI" is tried, and so on.

The optimal "ABI" can easily be 5 times faster then the 2nd best "ABI".

Clearly this has some drawbacks.  E.g., some 64-bit systems default to
generating 32-bit code, and this code might not link to the newly built
GMP.  

It is less common that people set CC/CFLAGS to bad values (or at least
we don't hear about that very often).  I don't think we should try to
accomodate that since it would result in lots of fragile complexity.
(If you don't agree, please see the logic for "ABI" -> (CFLAGS,mpn_path)
selection.)

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

Re: Configure fails on 32-bit platform

[Torbjörn Granlund]

Vincent Lefevre  writes:

  As written above, this is for C compilers. But GMP also has assembler
  code. So, you need to provide an option that will affect the assembler
  code. This is what ABI is for.
  
  That said, perhaps GMP might be improved to detect the ABI by a
  simple parsing of $CFLAGS when provided by the user (in case values
  like -m32 or -m64 are standard). The reason is that the user could
  have a generic CFLAGS for various software, while AFAIK, ABI is
  specific to GMP.

That would be nice but unfortunately is not going to work.

We use "ABI" in a somewhat non-standard way.  It mainly refers to the
limb size.  The same exact compiler flags might be correct for several
choices of "ABI".

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

Re: repl-vsnprintf.c:396:0: error: ISO C forbids an empty translation unit

[Torbjörn Granlund]

Dennis Clarke  writes:

  repl-vsnprintf.c:396:0: error: ISO C forbids an empty translation unit

Our nightly builds get a few of those too, as warnings.  I've decided I
can live with those as no platform seems to actually dislike the
resulting object files.
  

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

Re: GMP 6.1.2: 32-bit ARM build failure on 64-bit hardware with CFLAGS=-g

[Torbjörn Granlund]

  > What CFLAGS does GMP use if you don't override its detection?
  
  
  $ grep ^CFLAGS Makefile
  CFLAGS = -O2 -pedantic -fomit-frame-pointer -march=armv8-a -mfloat-abi=hard
  -mfpu=neon -mtune=cortex-a53
  
  Is it up to me to include all that in the CFLAGS that I specify?

If you override flags for choosing the architecture level and/or ABI,
you cannot expect things to work.

  If so, is there another easy with debug info, without knowing in
  advance what compiler flags configure would have autodetected?
  
Cut and paste?

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

Re: Incorrect detection of MMX support in Intel Family 5 CPU's

[Torbjörn Granlund]

Thanks for tracing your crashes to GMP and thanks for reporting it to
us.  You demonstrate a fragility in our CPU detection.

Please try these patches:

https://gmplib.org/repo/gmp/raw-rev/cd5e58236267
https://gmplib.org/repo/gmp/raw-rev/4117847f9e8b

If you can make both a plain build and one with --enable-fat, that would
be great.  Please report back success/failure by following up to this
message.

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

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

[Torbjörn Granlund]

(Related, I wonder what the effect would be of redefining umul_ppmm as C
expressions involving __uint128_t on compilers that support that).

  We do that already for some CPUs, but this has proven to be somewhat
  fragile, and in unexpected cases lead to libgcc calls.

We brave to do that for at least PowerPC-64, MIPS-64, s390x, Arm64.  For
alpha, gcc provides an _int_mult_upper which we use instead.

Apart from better scheduling, making gcc aware of the semantics allows
for algebraic optimisations and various foldings.

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

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

[Torbjörn Granlund]

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

  Using inline asm instead has the drawback that it leaves a little less
  opportunity for the compiler to schedule this instructions optimally. No
  idea if that matters in practice. Since it seems we don't really need
  count_*_zeros to support zero input, is there any advantage in using
  inline asm?
  
Sure, and that matters chiefly if the instructions have a long latency.
(Now, it is quite likely that CLZ and RBIT didn't get described to the
compiler scheduler, as they are usually not used.)

  (Related, I wonder what the effect would be of redefining umul_ppmm as C
  expressions involving __uint128_t on compilers that support that).
  
We do that already for some CPUs, but this has proven to be somewhat
fragile, and in unexpected cases lead to libgcc calls.

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

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

[Torbjörn Granlund]

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

  t...@gmplib.org (Torbjörn Granlund) writes:
  
  > The idea with that was to allow some usages that want to pass 0 to avoid
  > a condition.  Isn't that used?
  
  The idea makes sense, but I couldn't find any such use. I was thinking
  that any use like that would be accompanied by an #ifdef
  COUNT_LEADING_ZEROS_0, but I found no matches when greping through the
  sources. I could be missing something, of course.
  
  Or maybe it should be used at some places, but currently isn't.
  
I assume the hardwired values were there because these expanded to fully
defined instructions.

We might define these directly, at least for arm64, to CLZ and RBIT+CLZ,
respectively, instead of using gcc's builtin semi-defined variants?

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

Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

[Torbjörn Granlund]

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

  And below, a patch to delete all mention of COUNT_LEADING_ZEROS_0,
  except for tune/many.pl, which I'm not familiar with. What do you think?
  
The idea with that was to allow some usages that want to pass 0 to avoid
a condition.  Isn't that used?


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

Re: GMP doesn't honor march flag

[Torbjörn Granlund]

Paul Jähne  writes:

  I encountered a problem with GMP when using the march flag.
  
  I build GMP 6.1.1 with march=corei7 or march=westmere with GCC 5.4.0
  on a server with a Haswell processor (E5-2630 v3). When executing curl
  (version 7.47.0 on Ubuntu 16.04) which uses GMP to retrieve a https
  website on a system with a Westmere Processor (Intel Xeon E5645) it
  crashes with the error: Illegal instruction (core dumped).
  
No GMP bug.  You're not following the doumented procedures.  Don't
override CFLAGS like that, it is ineffective and as you omitted any -O
also a disaster for performance.

You might find it helpful to read the GMP manual's chapter "Installing
GMP".  There are many good suggestions there!


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

Re: register corruption under MS Windows / x86-64

[Torbjörn Granlund]

Vincent Lefevre  writes:

  One of those who saw the bug with MPFR 4 RC1 + GMP dev said that
  everything seems fine with the latest GMP dev:
  
https://sympa.inria.fr/sympa/arc/mpfr/2017-12/msg00067.html

Thanks.

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

Re: register corruption under MS Windows / x86-64

[Torbjörn Granlund]

  
  It is a flaw in our testing setup that this calling convention breach is
  not caught by the automated testing.  I will fix both bugs.  :-)
  
I have now pushed a fix for the mainline repo.  Testing would be
appreciated!

Improving test suite calling conventions checks (through
tests/x86call.asm) still needs to be done.

  Unfortunately the same issue might affect released versions of GMP.  It
  is not immediately clear, as all problem code lives in x86_64/fastsse,
  code which is then explicitly included from CPU specific subdirs.

This is still pending.

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

Re: register corruption under MS Windows / x86-64

[Torbjörn Granlund]

Vincent Lefevre  writes:

  There appears to be a bug in mpn/x86_64/fastsse/com-palignr.asm,
  which is now used by the GMP trunk. If I understand correctly,
  the optimized loop uses xmm6 and xmm7 without restoring their
  values. This is correct under Linux, but not under MS Windows,

You are right, and we seem to have been aware of this at some point:

  2013-09-16  Torbjorn Granlund  
* mpn/x86_64/fastsse/copyi-palignr.asm: Preserve xmm6-xmm8 under DOS.

It is a flaw in our testing setup that this calling convention breach is
not caught by the automated testing.  I will fix both bugs.  :-)

Unfortunately the same issue might affect released versions of GMP.  It
is not immediately clear, as all problem code lives in x86_64/fastsse,
code which is then explicitly included from CPU specific subdirs.

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

Re: GMP build issues on Solaris 10 UltraSPARC

[Torbjörn Granlund]

Sad Clouds  writes:

  https://gmplib.org/list-archives/gmp-commit/2013-May/001723.html
  
  +  [ultrasparct[12]])
  + gcc_cflags_cpu="-mcpu=niagara -mcpu=v9"
  + gcc_32_cflags_asm="-Wa,-Av8plusc -Wa,-xarch=v8plusc"
  + gcc_64_cflags_asm="-Wa,-Av9c -Wa,-xarch=v9c";;
  
  Using -xarch=v8plusc is wrong for UltraSPARC T1 and T2 processors, since they 
don't support VIS3 instructions set. This results in the following ld.so errors 
when using Sun assembler
  
  hardware capability (CA_SUNW_HW_1) unsupported: 0x400
  
  
  GNU assembler states that:
  
  ?-Av8plusc? and ?-Av9c? enable the UltraSPARC Niagara instructions, as well 
as the instructions enabled by ?-Av8plusb? and ?-Av9b?. 
  
  However this is wrong, since with Sun/Oracle compilers this option is used 
for SPARC64 VI processor.

Clearly, the GNU compiler/assembler and the Solaris compiler/assembler
do not agree about the meaning of what v8plusc means.  I suppose it is a
mistake in the GNU camp.

What do you suggest that we do for GMP?

Perhaps just pass v8plusb for T1/T2?  I mean, these CPUs are so
horrendously slow anyway that nobody in his right mind would perform any
computation on them anyway.
  

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

Re: [PATCH] Inline assembly division needs __volatile__

[Torbjörn Granlund]

Ximin Luo  writes:

  Any chance my patch could be tested and merged?

I tried applying it, but it fails for the current head.  Manual merging
is required.  (It applies flawlessly to GMP 6.1, though.)

If you could modify your patch to apply to the GMP head, then that would
help.  The repo is here: https://gmplib.org/repo/gmp/

  I did not ask other projects' opinions on this yet, since they seemed
  to have copied the code from GMP. Could you confirm that GMP is the
  original source?

I originally wrote it for use in GCC, glibc, and GMP.  I only actively
maintain the GMP version.

(The versions has diverged, unfortunately.  The GMP version now contains
some GMPisms which might need cleaning up if we want to make the
versions converge.)

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

Re: issues on gcc202

[Torbjörn Granlund]

paul zimmermann  writes:

  However I had to define INTERPRETER= in test-driver.
  
That requirement should be gone now.
  

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

Re: issues on gcc202

[Torbjörn Granlund]

paul zimmermann  writes:

  However I had to define INTERPRETER= in test-driver.
  
Yep, that's an undocumented feature of the snapshots.  :-)

We use that for our nightly builds for running valgrind and various
emulators.

  Also the "Testsuite summary" is still not very informative:
  
The test-driver stuff that came with an autotools update is not
too happpy with our multi-ddirectory tests layout.

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

Re: issues on gcc202

[Torbjörn Granlund]

  I find several issues on gcc202.fsffrance.org:
  
  1) gmp-6.1.2 configured with --disable-shared and gcc 7.2.0: libgmp.a
 contains an undefined symbol __gmpn_addlsh1_n_ip1:
 zimmerma@gcc202:/tmp/gmp-6.1.2$ cat e.c
 #include "gmp.h"
 int main()
 {
   mpz_t x;
   mpz_init_set_str (x, "1234567890", 10);
   mpz_sqrt (x, x);
 }
 zimmerma@gcc202:/tmp/gmp-6.1.2$ gcc -I/tmp/include e.c /tmp/lib/libgmp.a
 /tmp/lib/libgmp.a(lt86-sqrtrem.o): In function `mpn_dc_sqrtrem':
 sqrtrem.c:(.text+0x4b8): undefined reference to `__gmpn_addlsh1_n_ip1'
 /tmp/lib/libgmp.a(lt86-sqrtrem.o): In function `mpn_dc_sqrt':
 sqrtrem.c:(.text+0xa1c): undefined reference to `__gmpn_addlsh1_n_ip1'
 collect2: error: ld returned 1 exit status
  
That was fixed in the head some weeks ago.  This was a real GMP bug.

https://gmplib.org/repo/gmp/rev/2e244a86b5d2

  2) still with the same configuration, t-constants fails:
 zimmerma@gcc202:/tmp/gmp-6.1.2$ tests/t-constants 
 PP_INVERTED == 21cfe6cfc938b36b, but pp_inverted_calc == 1dde20a605db167d
 ...

This is not yet isolated.  It looks like a compiler or perhaps more
likely a linker bug.  Last night I reverted another change which
benefited gcc202, so now there will be more errors.

I am not actively working on this issue, but I will probably isolate it
at some point.

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

Re: assembly files on Solaris SPARC can only be processed with gcc

[Torbjörn Granlund]

Dennis Clarke  writes:

  somedays I don't include details and I get railed at .. other days I
  do and I get railed at .. life goes on.
  
Did Niels rail you?  I think that's a quite unfair assessment.  He's
pointing out a central issue here, your snub is the attitude problem
here, if any.

(To iterate and ask for more information is normal in any softwware help
situation.  To take such requests as critique is probably not the best
strategy.)

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

Re: Jacobi Symbol

[Torbjörn Granlund]

paul zimmermann  writes:

 15.3.5 Jacobi Symbol
 
  
 [This section is obsolete.  The current Jacobi code actually uses a very
 efficient algorithm.]
  
  I just checked the latest daily snapshot, it is still the same.
  
  When will this section be updated?
  
When a trusted GMP volunteer updates it.  :-)

The manual is getting obsolete in more ways, with the algorithms chapter
being most obsolete.

I've recently done some work to make the html manual's math fornulas
look better, unfortunately this triggered texinfo bugs.
  

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

Re: reporting bug of Segmentation fault which occurs while make check.(completed one )

[Torbjörn Granlund]

Jason Yu  writes:

  I encouter Segementation fault while I run "make check"(configure had run
  well).:
  
Any of the about 20 less obsolete GMP releases should be fine.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: FreeBSD links wrong library for tests if one is installed in $prefix

[Torbjörn Granlund]

Vincent Lefevre  writes:

  > The fbsd developers' GNU/Linux envy is projected at GPL hate which in
  > turn badly hurts their own system.
  
  This is not fair. The current behavior is the same as various Linux
  systems, including Debian until Jessie.

I was referring to that they use 10 years old binutils.

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

Re: fat_init violates host ABI on Win64

[Torbjörn Granlund]

Nicolas Hake  writes:

  the Windows x64 ABI requires callers to allocate a 32 byte "parameter
  area" before calling into a function, which the callee is allowed to
  use as it pleases[1]. fat_init does not do this before calling
  __gmpn_cpuvec_init, thus violating the ABI.
  
Right; apparently we're aware of this as such allocations are performed
in most cases in GMP.  There seem to be 5 forgotten places, the one you
found and 4 more.

  I'm not sure whether MSVC is a supported compiler (I assume it isn't,
  because --enable-fat requires support for variable-length arrays,
  which MSVC will not compile in C mode), but it's possible that other
  compilers may also use the parameter area as a scratch space, or even
  that gcc/clang start using it in future releases.
  
We should follow the ABI, of course.

Where do we (unconditionally) rely on variable-length arrays?

While such arrays are in the C standard since 18 years, it is missing
from C++.

  Attached patch solves this problem by just allocating 32 bytes of
  stack space before calling __gmpn_cpuvec_init, and discarding them
  afterwards.
  
Thanks.  Here is a slightly different patch:

diff -Nrc2 gmp-main.253deadf9fc8/mpn/x86_64/divrem_2.asm 
gmp-main/mpn/x86_64/divrem_2.asm
*** gmp-main.253deadf9fc8/mpn/x86_64/divrem_2.asm   Tue Apr 25 20:52:18 2017
--- gmp-main/mpn/x86_64/divrem_2.asmTue Apr 25 20:52:18 2017
***
*** 101,106 
--- 101,108 
  IFSTD(`   mov %r11, %rdi  ')
  IFDOS(`   mov %r11, %rcx  ')
+ IFDOS(`   sub $32, %rsp   ')
ASSERT(nz, `test $15, %rsp')
CALL(   mpn_invert_limb)
+ IFDOS(`   add $32, %rsp   ')
pop %r11
pop %r10
diff -Nrc2 gmp-main.253deadf9fc8/mpn/x86_64/fat/fat_entry.asm 
gmp-main/mpn/x86_64/fat/fat_entry.asm
*** gmp-main.253deadf9fc8/mpn/x86_64/fat/fat_entry.asm  Tue Apr 25 20:52:18 2017
--- gmp-main/mpn/x86_64/fat/fat_entry.asm   Tue Apr 25 20:52:18 2017
***
*** 168,172 
--- 168,174 
push%r9
push%rax
+ IFDOS(`   sub $32, %rsp   ')
CALL(   __gmpn_cpuvec_init)
+ IFDOS(`   add $32, %rsp   ')
pop %rax
pop %r9
diff -Nrc2 gmp-main.253deadf9fc8/mpn/x86_64/mod_1_1.asm 
gmp-main/mpn/x86_64/mod_1_1.asm
*** gmp-main.253deadf9fc8/mpn/x86_64/mod_1_1.asmTue Apr 25 20:52:18 2017
--- gmp-main/mpn/x86_64/mod_1_1.asm Tue Apr 25 20:52:18 2017
***
*** 199,204 
--- 199,206 
  IFSTD(`   mov %r12, %rdi  ')  C pass parameter
  IFDOS(`   mov %r12, %rcx  ')  C pass parameter
+ IFDOS(`   sub $32, %rsp   ')
ASSERT(nz, `test $15, %rsp')
CALL(   mpn_invert_limb)
+ IFDOS(`   add $32, %rsp   ')
neg %r12
mov %r12, %r8
diff -Nrc2 gmp-main.253deadf9fc8/mpn/x86_64/mod_1_2.asm 
gmp-main/mpn/x86_64/mod_1_2.asm
*** gmp-main.253deadf9fc8/mpn/x86_64/mod_1_2.asmTue Apr 25 20:52:18 2017
--- gmp-main/mpn/x86_64/mod_1_2.asm Tue Apr 25 20:52:18 2017
***
*** 184,189 
--- 184,191 
  IFSTD(`   mov %r12, %rdi  ')  C pass parameter
  IFDOS(`   mov %r12, %rcx  ')  C pass parameter
+ IFDOS(`   sub $32, %rsp   ')
ASSERT(nz, `test $15, %rsp')
CALL(   mpn_invert_limb)
+ IFDOS(`   add $32, %rsp   ')
mov %r12, %r8
mov %rax, %r11
diff -Nrc2 gmp-main.253deadf9fc8/mpn/x86_64/mod_1_4.asm 
gmp-main/mpn/x86_64/mod_1_4.asm
*** gmp-main.253deadf9fc8/mpn/x86_64/mod_1_4.asmTue Apr 25 20:52:18 2017
--- gmp-main/mpn/x86_64/mod_1_4.asm Tue Apr 25 20:52:18 2017
***
*** 191,196 
--- 191,198 
  IFSTD(`   mov %r12, %rdi  ')  C pass parameter
  IFDOS(`   mov %r12, %rcx  ')  C pass parameter
+ IFDOS(`   sub $32, %rsp   ')
ASSERT(nz, `test $15, %rsp')
CALL(   mpn_invert_limb)
+ IFDOS(`   add $32, %rsp   ')
mov %r12, %r8
mov %rax, %r11


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

Re: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

[Torbjörn Granlund]

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

  #if defined(__WIN32__) && define (__GNUC__)
  #define __USE_MINGW_ANSI_STDIO 1
  #endif
  
  I'd guess there are plenty of windows programs that depend on the
  non-standard behavior. So bug-compatibility makes some sense. But we
  don't want it.
  
It is not completely obvious to me that one can link things together
where some parts want to compliant stdio and some other parts want a
non-compliant stdio.

If it is possible, I agree with your proposal.

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

Re: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

[Torbjörn Granlund]

Claude Heiland-Allen  writes:

  > Could the macro __USE_MINGW_ANSI_STDIO be relevant?
  
  Yes, perfect!  I did
  
  CPPFLAGS=-D__USE_MINGW_ANSI_STDIO ./configure
  --host=x86_64-w64-mingw32 --prefix=$HOME/win64
  CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make -j 8
  CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make install
  CPPFLAGS=-D__USE_MINGW_ANSI_STDIO make check
  
  and the whole test suite passes now.
  
User choice is great; one can choose between malfunctioning libc or
explicitly ask for a correct one.

Should we pass this option for mingw on GMP's configure.ac?
Or do people expect broken libc on this platform...?


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

Re: Crash when attempting to call mpz_invert in a program that uses mpq_class and mpz_class

[Torbjörn Granlund]

Álvaro Begué  writes:

  mpz_class fraction_mod_m(mpq_class x, mpz_class m) {
mpz_t inverse;
mpz_class den = x.get_den();
mpz_invert(inverse, den.get_mpz_t(), m.get_mpz_t()); // Crashes
return mpz_class(inverse);
  }
  
No GMP bug.

Please re-read

https://gmplib.org/manual/GMP-Basics.html, in particular
https://gmplib.org/manual/Variable-Conventions.html in order to use GMP
in C-style correctly.

Why do you mix C++ style and C style?

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

Re: BUG REPORT

[Torbjörn Granlund]

Vaibhav Gautam  writes:

  PLEASE HELP!
  
The GMP developers cannot handle Microsoft's proprietary file formats,
and thus cannot read your attachments.

Plain old text is what you need to send in your message and in your
attachments.  Make sure you spell out what you think it wrong, a bunch
of attachments (even readable ones) might not immediately reveal the
perceived problem.


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

Re: mpf_get_d_2exp ignores sign of input

[Torbjörn Granlund]

paul zimmermann  writes:

  I disagree. The fine manual says "D * 2^EXP is the (truncated) OP value",
  which is wrong if say OP = -0.5.
  
  And why bother write 0.5<=abs(D)<1 instead of 0.5<=D<1 if D is always >= 0?
  
Right.  I am testing a fix, and am also rewriting the documentation to
be more readable.
  

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

Re: mpf_get_d_2exp ignores sign of input

[Torbjörn Granlund]

Claude Heiland-Allen  writes:

  mpf_get_d_2exp() always returns a non-negative value, even for negative
  input.  I think this is a bug.
  
The function works as documented.  No bug.

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

Re: Problem with gmp_randinit_set

[Torbjörn Granlund]

Pedro Gimeno  writes:

  With something like the attached? Perhaps. In fact I don't know why it
  isn't doing it now. Can that structure possibly come from disk or some
  other place that makes the pointers invalid? I guess not.

That patch makes a lot of sense...  I'll apply it now.

Perhaps we should expand testing wrt this?

We should check that seeding is effective, that gmp_randinit_set(b, a)
make a and b behave the same including that the seed follows, and that
further seeding affects both identically.  More?


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

Re: Problem with gmp_randinit_set

[Torbjörn Granlund]

Pedro Gimeno  writes:

  I chose xxtea for being simple and small (as can be seen in the patch)
  and for having variable block size, so I could encrypt just 1 block of
  19936 bits, eliminating the need to choose a suitable enciphering
  mode. For ciphers with smaller block size, ECB, OFB, CFB and CTR are
  definitely discarded; CBC and PCBC could perhaps work (I'm using names
  from https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation ). I
  tested xxtea's randomness properties and I was very satisfied with the
  results.
  
If a crypto function's output of even a plain seed sequence 0, 1, 2,
3...  does not fulfill the strictest randomness tests, then there is a
serious flaw in the crypto function!

I haven't read you xxtea patch yet, but let's first see that we agree on
the theory!

I believe the named modes ECB, CTR, ICM, whatnot don't necessarily apply
to PRNG use as we have no plaintext.  I see no reason for anything much
beyond this algorithm:

  counter = 0
  while more bits needed
random_bits = encrypt(counter)
append_to_result(random_bits)
counter = counter + 1

This is CRT (aka ICM) except that the result is not applied to anything.

How should the seed look like?  One could put it both in counter and in
the encryption function's key.  Or both.

I'd suggest to keep counter fixed in size.  I'd say to keep it to just
64 bits, or surely not more than 128 bits.  I.e., not a bignum.

Seeding should probably take put the low bits and use them for the
counter variable above, then of more bits are goves generate a
non-default key.  Why not the other way around?  Because accepting a new
key can require some time (and some people like reseeding), while
updating counter it very cheap.

The state of the generator will be key, counter value, and for
efficiency partial random_bits.  E.g., if the user asks for 32 bits of
randomness and we have AES128 as the encrypt function, only one in four
user calls will cause any encrypt operation.

Does this make sense to you?

  As a temporary fix, it would also work if minigmp's modular
  exponentiation could be used, to make the output compatible.
  
I don't follow what you're trying to say there, I'm afraid.

  > But I don't think we can leave MT broken or replace it (e.g.,
  > gmp_randinit_mt should use Mersenne Twister, period).  Shouldn't it be
  > possible to get both a and b (of the reporter's code) in the precis same
  > state after assigning one to the other, without significant dependency
  > changes in the MT code?
  
  With something like the attached? Perhaps. In fact I don't know why it
  isn't doing it now. Can that structure possibly come from disk or some
  other place that makes the pointers invalid? I guess not.
  
Thanks for this patch, I'll take a look now!

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

Re: Problem with gmp_randinit_set

[Torbjörn Granlund]

Pedro Gimeno  writes:

  Ah, yes, that was a problem that needed to be avoided. Thanks for
  looking into this.
  
  One possible fix would be to resurrect my patch for a different
  seeding routine, which was based on the xxtea encryption
  algorithm. That one is faster and uses far less mpz code, and I think
  it wouldn't be difficult to get rid of mpz usage totally. It was
  written in or before 2006, I believe, and I rebased it in 2009, so
  merging it with current code might be troublesome. Fortunately, that
  part of the code doesn't seem to have changed a lot.
  
  The problem is that it wouldn't be a good idea to apply that patch to
  stable versions, because it causes the sequences to be different.
  
  I've attached the patch as it was in 2009 (against revision
  af3f365253c5).
  
I like the idea of applying a symmetric cipher for PRNG; I have in fact
done some work towards using AES for that in GMP.  I don't know about
xxtea or its pros and cons, and perhaps that is superior to AES.  On
AES's plus side is that we can access hardware instructions in many
cases, and that a C implementation is quite small.

But I don't think we can leave MT broken or replace it (e.g.,
gmp_randinit_mt should use Mersenne Twister, period).  Shouldn't it be
possible to get both a and b (of the reporter's code) in the precis same
state after assigning one to the other, without significant dependency
changes in the MT code?

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

Re: Problem with gmp_randinit_set

[Torbjörn Granlund]

Pedro Gimeno <gmpdisc...@formauri.es> writes:

  Torbjörn Granlund wrote, On 2017-02-14 01:41:
  
  > One can change Mersenne_Twister_Generator_Noseed to
  > Mersenne_Twister_Generator to fix this (and move __gmp_randiset_mt to
  > randmts.c as mandated by Mersenne_Twister_Generator's scope), and then
  > your code supposedly runs without a crash.  But I don't see why one ever
  > wants Mersenne_Twister_Generator_Noseed, which suggests my understanding
  > of this code is very poor indeed.
  
  It's been about 15 years ago, but my recollection is that the rationale 
behind the _Noseed version was to avoid a dependency on randmts.c, and it seems 
I neglected to consider this use case.
  
  I agree with your fix.
  
I realised a serious flaw with that fix; it introduces a dependency from
mpn_random* to mpz.  That's not OK, I'm afraid.


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

Re: Problem with gmp_randinit_set

[Torbjörn Granlund]

   gmp_randinit_set(b, a);
   gmp_randseed_ui(b, 123456); /* crashes */
  
  AFAICT this is a gmp bug, but I don't rule out the possibility that
  it's a user bug.
  
This looks like a GMP bug.

I never looked properly through the GMP PRNG code, and looking at it now
I don't immediately understand its structure.  (This code was written by
an external contributor.)

What happens with your code is that GMP tries to call a seed application
function through a pointer, but that pointer was explicitly zeroed by
gmp_randinit_set (or in __gmp_randiset_mt to be exact).

One can change Mersenne_Twister_Generator_Noseed to
Mersenne_Twister_Generator to fix this (and move __gmp_randiset_mt to
randmts.c as mandated by Mersenne_Twister_Generator's scope), and then
your code supposedly runs without a crash.  But I don't see why one ever
wants Mersenne_Twister_Generator_Noseed, which suggests my understanding
of this code is very poor indeed.

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

Re: Inconsistency in version number.

[Torbjörn Granlund]

victor.su...@upc.edu writes:

   Hello,
  
  I have installed GMP 6.1.2 from source using default options for
  configure. As expected, in 'gmp.h' I find
  
  #define __GNU_MP_VERSION    6
  #define __GNU_MP_VERSION_MINOR  1
  #define __GNU_MP_VERSION_PATCHLEVEL 2
  
  However, the following C code
  
  #include 
  #include 
  #include 
  
  int
  main (void)
  {
    (void) printf ("GMP version: %s\n", gmp_version);
    return EXIT_SUCCESS;
  }
  
  yields
  
  'GMP version: 6.1.0'
  
  instead of 'GMP version: 6.1.2'.
  
Linking paths vary from system to system, so I cannot tell how you can
tell the linker to find you newly compiled libgmp file and now the 6.1.0
ones that also clearly exist on your system.

(GMP does not influence these things, so no GMP bug here.)

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

Re: building gmp-6.1 for s390 (31-bit) w/asm disabled failing with undefined sdiv_qrnnd

[Torbjörn Granlund]

Mike Frysinger  writes:

  OK, i've moved this to MPFR's tracker:

https://gforge.inria.fr/tracker/index.php?func=detail=21053_id=136=619

Thanks!

We're probably going to create many more problems for extension libs for
GMP 7.  It will be the first release to support symbol hiding, and while
we're not going to be fascist about our "private" symbols, we're going
to make truly internal things hidden.


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

Re: [PATCH] tune: fix spurious clock_gettime reference

[Torbjörn Granlund]

Mike Frysinger  writes:

  ../gmp-mparam.h:1:1: error: unknown type name 'clock_gettime'
   clock_gettime is 1.000ns accurate
  
  This is because the tune source has one printf that is not protected
  by the verbose flag leading it to be written to the output.
  
Patch applied, thanks.

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

Re: building gmp-6.1 for s390 (31-bit) w/asm disabled failing with undefined sdiv_qrnnd

[Torbjörn Granlund]

Mike Frysinger  writes:

  building gmp-6.1.0 & gmp-6.1.1 like so:
  ./configure \
--build=s390-ibm-linux-gnu --host=s390-ibm-linux-gnu \
--enable-shared --disable-assembly --enable-cxx --disable-static
  
  triggers this warning:
  udiv_w_sdiv.c: In function ‘__gmpn_udiv_w_sdiv’:
  udiv_w_sdiv.c:58:4: warning: implicit declaration of function ‘sdiv_qrnnd’ 
[-Wimplicit-function-declaration]
  sdiv_qrnnd (q, r, a1, a0, d);
  
  and the final lib has an undefined ref to the sdiv_qrnnd symbol.

Please try this https://gmplib.org/repo/gmp/rev/1890de258348 and comment
back.
  
  Torbjorn: you should have access to this system to reproduce -- lgentoo3.

I do indeed, and I added this case to the night builds.

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

Re: mpz reuse test takes too much time

[Torbjörn Granlund]

Vincent Lefevre  writes:

  But there may have been a temporary problem, as I now get:
  
  ./reuse  27.56s user 0.15s system 100% cpu 27.698 total
  
That's more in the expected range.  Amd bulldozers are not GMP speed
demons, with their 1/4 mul throughput, but they are not that slow.

  But note that since "reuse" is much slower than the other tests,
  one doesn't benefit much from the parallelization of the tests.

Indeed.  I don't lose too much sleep over that, and splitting up
tests/mpz/reuse,c into several tests would seem to have several
disadvantages.

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

Re: Manual for mpz_powm, mpz_powm_ui

[Torbjörn Granlund]

[Please follow up to gmp-discuss as this is not a bug report.]

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

Re: Invalid read in mpz_sub

[Torbjörn Granlund]

Vincent Lefevre  writes:

  I propose the attached patch. I think that 3.4 Variable Conventions
  is the best section for such information. So, I've moved a part of
  the paragraph in 3.5 Parameter Conventions to a new paragraph in 3.4
  with more information, and I've shortened the paragraph in 3.5 to
  make it deal with only parameter conventions.

It took me some time, but no I applied your patch.
I also made some other cleanups around these sections.

Thanks for the contribution!

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

Re: Invalid read in mpz_sub

[Torbjörn Granlund]

Vincent Lefevre  writes:

  However, the GMP manual says:
  
  [...] Here are some examples of how to declare such integers:
  
   mpz_t sum;
  
   struct foo { mpz_t x, y; };
  
   mpz_t vec[20];
  
  and doesn't forbid to copy the structure, for instance. I think it
  would be worth to mention that using several copies of a mpz_t is
  forbidden (or a write operation invalidates the other copies),
  here or in one of the next sections (BTW, the MPFR manual should
  be clarified too).

I agree this should be made explicit; users should not need to worry
about the inner workings of our types (such as the fact that they
contain a pointer).

Would you want to contribute a patch for our manual?

(I suppose it is fine to copy our types as long as you use all copies
read-only.  Now, copying them rather than passing around a reference to
a single copy is a poor idea wrt memory use.)

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

Re: [gmp-bugs] Build feedback for gmp-6.1.0

[Torbjörn Granlund]

Marc Glisse  writes:

  >/usr/bin/gcc -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. 
-DOPERATION_lshift \
  > -I/usr/uumath/include -I/usr/uumath/include -Wa,--noexecstack 
tmp-lshift.s -fPIC \
  > -DPIC -o .libs/lshift.o
  
  Do you have CFLAGS set or something? I find your list of flags
  surprisingly short.
  
Indeed.

  >tmp-lshift.s: Assembler messages:
  >tmp-lshift.s:106: Error: selected processor does not support `vdup.32 
d6,r3' in ARM mode
  
  What selected processor is that? Maybe adding -v to a gcc invocation
  would give information.

The /proc/cpuinfo suggest Cortex C9.  It has Neon, and we do attempt to
put the compiler/assembler into a mode where Neon insn are accepted.  Yet...
  
  >tmp-lshift.s:108: Error: selected processor does not support `vdup.32 
d7,r3' in ARM mode
  >tmp-lshift.s:114: Error: selected processor does not support `vshl.u64 
d18,d19,d7' in ARM mode
  >tmp-lshift.s:120: Error: selected processor does not support `vshl.u64 
d4,d19,d6' in ARM mode
  ...

indicates that Neon insn are not accepted.


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

Re: FAILED t-scan test of the arm-2009q3-67-arm-none-linux-gnueabi gmp-stable.

[Torbjörn Granlund]

I don't know what gmp-stable means.

You claim architecture arm-2009q3-67-arm-none-linux-gnueabi first and
x86_64 later.  Which is it?  (The former looks very strange.)

Please read https://gmplib.org/manual/Reporting-Bugs.html and write a
self-contained and complete report.


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