Re: EXC_I386_INVOP in GMP 6.1.2 on OS X

[Torbjörn Granlund]

  ->  0x1000d04f5 <+213>: mulxq  (%rsi), %r9, %rax

You have configured your GMP for a too new CPU.  The mulx instruction is
available in Intel Broadwell, Skylake and newer, and in Amd Excavator,
Zen.

Presumably, you have configured GMP on a new system and then run it on
an older system.

-- 
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 Bug Report (gmp_fprintf(), "implicit declaration of function" warning)

[Torbjörn Granlund]

"mlg ."  writes:

  Long story short, with gcc, the function/macro "gmp_fprintf()" gives
  an"implicit declaration of function" warning. Please see the attached file
  for the complete report.

Please see the GMP manual, specifically see this page:

https://gmplib.org/manual/Headers-and-Libraries.html

-- 
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, acinclude.m4, configure

[Torbjörn Granlund]

"Ralf Gerhauser"  writes:

  checking whether make supports nested variables... yes
  checking whether to enable maintainer-specific portions of Makefiles... no
  checking ABI=64
  checking compiler gcc -O2
  -I/home/rage/Development/OpenWrt/openwrt/staging_dir/host/include
  -I/home/rage/Development/OpenWrt/openwrt/staging_dir/host/include
  ... no, mpn_lshift_com optimization 2, program does not run
  checking ABI=x32
  checking compiler gcc -O2
  -I/home/rage/Development/OpenWrt/openwrt/staging_dir/host/include
  -I/home/rage/Development/OpenWrt/openwrt/staging_dir/host/include
  ... no, mpn_lshift_com optimization 2, program does not run
  checking ABI=32
  checking compiler gcc -O2
  -I/home/rage/Development/OpenWrt/openwrt/staging_dir/host/include
  -I/home/rage/Development/OpenWrt/openwrt/staging_dir/host/include
  ... no, mpn_lshift_com optimization 2, program does not run
  configure: error: could not find a working compiler, see config.log for 
details

You seems to have passed--explicitly or via environment variables--a
non-working compiler to GMP's configure.  Make sure to get a good
configure run by cleaning up that (i.e., plain "configure" without
overriding any variables, and first unsetting any CC, CFLAGS, etc,
variables).

Then work from there.

  My second try was to compile it on a Lubuntu 18.04 system.  It did, without 
any problems.
  Next I checked the compiler versions: gcc-4.8 on my SuSE system, gcc-7 on the 
Lubuntu system.
  I installed gcc-7 on SuSE - gmp-6.1.2 still failed in the same manner.

Are you saying that two compilers on one system make GMP configure fail?
My advice a few lines above should help!

  Next I found and downloaded the file "snapshot" from ftp://gmplib.org/pub/ 
which unpacks as
  version gmp-6.1.99-20180106. I tried to compile this on SuSE, and it worked 
either.

I don't understand that sentence.  Did it work or did it not work?

A snapshot from more than a year ago might not be an ideal place to
look, but if you're saying that the snapshot is fine and 6.1.2 is not,
it seems that the issue at hand has been solved.  Right?


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

Re: Problems with mpfr_set_str() and decimal numbers

[Torbjörn Granlund]

You might want to let the MPFR developers know about this.  GMP != MPFR.

-- 
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 test suite fails with core dump

[Torbjörn Granlund]

Your two reports seem to refer to the same issue.  I cannot make out
much relevant information from either report.

Both your reports quite this text:

  For bug reporting instructions, please see:
  .

If you want us to help you reslve your issue, please follow that quoted
text and read that page!

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

Re: [PATCH] missing va_end() in some IO functions (gmp 6.1.2)

[Torbjörn Granlund]

Vincent Lefevre  writes:

  >   #define va_copy(dst,src) \
  > do { memcpy (&(dst), &(src), sizeof (va_list)); } while (0)
  >   #endif

  But will va_arg necessarily work when va_copy is just a memcpy
  (at least in the case where va_end is *not* empty)? This seems
  optimistic.

A good question.  This is old code, and I don't know how broadly it was
tested outside the realm of gcc.

To check this, we'd need some environments with just a c90 compiler
which also does not provide va_copy as a courtesy.

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

Re: [PATCH] missing va_end() in some IO functions (gmp 6.1.2)

[Torbjörn Granlund]

My bad, part of Jakub's patch is needed for standards compliance.

In gmp-impl.h, we have this:

  /* va_copy is standard in C99, and gcc provides __va_copy when in strict C89
 mode.  Falling back to a memcpy will give maximum portability, since it
 works no matter whether va_list is a pointer, struct or array.  */
  #if ! defined (va_copy) && defined (__va_copy)
  #define va_copy(dst,src)  __va_copy(dst,src)
  #endif
  #if ! defined (va_copy)
  #define va_copy(dst,src) \
do { memcpy (&(dst), &(src), sizeof (va_list)); } while (0)
  #endif

We still support ISO C90 (alias ANSI C89) so we cannot just scrap that
code.  That means that we mustn't call va_end when memcpy was used by
means of the code above.

I won't put this at the top of my TODO list.  Making the GMP code more
complex for the sake of standard complience is much less important than
making GMP work on existing systems.

Is stdarg.h va_end non-empty anywhere?


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

Re: [PATCH] missing va_end() in some IO functions (gmp 6.1.2)

[Torbjörn Granlund]

Jakub Martisko  writes:

  I believe there are some missing va_end() calls in some of the IO
  functions of GMP 6.1.2. See attached patch for details.

Are you sure that's how stdarg works?

I see no problems with GMP's current code.  I believe your patch is
incorrect in several ways.

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

Re: Stray backslashes in html docs

[Torbjörn Granlund]

Trevor Spiteri  writes:

  In the html documentation, I found a few backslashes that shouldn't be
  there:

  https://gmplib.org/manual/FFT-Multiplication.html#FFT-Multiplication

  mp\_bits\_per\_limb

  
https://gmplib.org/manual/Low_002dlevel-Functions.html#index-mpn_005fsec_005fpowm

  GMP\_NUMB\_BITS

  
https://gmplib.org/manual/Low_002dlevel-Functions.html#index-mpn_005fsec_005finvert

  \log (twice)

Yes, the html manual is quite ugly.  It was written with pdf and info
output in mind.  Not only do we leak backslashes, the same symbol
appears in plain and slanted font.

I don't particularly like the syntax a^b either, and since superscripts
do exist in html, we should use them.

I tried to make a major revision a while ago, but ran into texinfo bugs.
I tend to run into bugs.  The particular bug this time was that texinfo
decided to randomly change font and layout of the "Function: foo ..."
stuff in the presense of certain formatting commands.

I tried hard to find expression variants which did not trigger texinfo
bugs, but the work was slow as I needed to check 3 output formats.

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

Re: Asserts considered harmful (or GMP spills its sensitive information)

[Torbjörn Granlund]

Jeffrey Walton  writes:

  Here's what I witness on a BananaPi and a couple of other boards. Can
  you provide info on the ARM boards you are using? I have about 8 of
  them for testing, and I may be able to duplicate your [successful]
  result.

Marco and others have told you to read the GMP manual.  People have
explained what you do wrong and it is clear that you know very well why
your CFLAGS messing breaks things.  Yet, you insist on spreading the lie
that GMP "does not build".

  Returning a failure from mpn_sec_powm would be a most welcomed
  improvement.

You have repeated this several times already.

The GMP API is what it is.  If you don't like it, well, we're so sorry.

  It would be a welcomed improvement if GMP does it in
  other places, too. Crashing is least welcomed behavior for many uses
  cases, including those where availability and confidentiality is a
  concern.

You have repeated this several times, and people have patiently replied
and explained how to handle this safely.

  Gracefully handling failure serves several purposes. First, returning
  failure is what developers expect to happen.

Really?  Did you talk to them?

  If a program uses a function incorrectly then it is expected to
  fail. Developers are usually good about checking return values at call
  sites.

I have yet to find one program which checks all return values.

  Second, when GMP crashes it is setting a policy for the application.

Any API sets policies.

We've had enough of your nagging and aggressiveness and your threats in
private email.  Your messages to the GMP lists will henceforth be
automatically discarded.

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

Re: Asserts considered harmful (or GMP spills its sensitive information)

[Torbjörn Granlund]

  The assert that Jeffrey has hit is in sec_powm.c, 

ASSERT_ALWAYS (enb >= windowsize);

  As far as I can see, "enb" is the input argument to the win_size function,
  and "windowsize" is the return value. I'm waiting for more information,
  since it works fine in my build. Possible explanations I see are

A reasonable assumption is that this user has modified the sources to
cause this bug.  The motive would be to support his auxesis about how
insecure GMP is.

Let's move on.  No bug to be found here.

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

[ADMIN] Foul language and swearwords

[Torbjörn Granlund]

We have rejected a couple of messages sent to this list on a recent
subject because they contained profanity.

Keeping a reasonably civil tone is required on these mailing list.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: tmp-lshift.s:106: Error: selected processor does not support ARM mode `vdup.32 d6, r3'

[Torbjörn Granlund]

Jeffrey Walton  writes:

  No. Me overriding your flags is:

  ./configure 
  make CFLAGS="..."

  In this case I stomp on your flags.

Now I get it.  You don't set CFLAGS, nor do you override it.  You stomp
on it.  Glad we have that crucial distinction clarified!

  > If you want your build to proceed, start without overriding CFLAGS.
  > Does that work?  Great, work from there.

  No, we cannot work from there. GMP selects screwed up release flags.
  They are dangerous and insecure.

Now, now!  How good your build failed then, keeping you out of immediate
danger.  ;-)

  GMP is the only project I know that cannot handle simple release build
  flags. And I build 66 of them here:
  https://github.com/noloader/Build-Scripts .

You might want to take a look at GMP before you talk loudly about it.
We have lots of assembly code which need much more complex configuration
than your average Joe Package.

Surely GMP's configuration system can be improved in various ways.
Making it somehow handle contradictory tuples and CFLAGS is not an
improvement, though.  (What do you think GMP should do in your case?
Silently change configuration tuple?  Edit CFLAGS to match the tuple?
Do you really want that sort if resilience against user errors?)

  GMP really should follow GNU Coding Standards. It is not that hard.

You might want to read Niels' reply.  And RT Fine M might do you well
too.

(This is the end of this dicussion for me.  Feel free to continue here
or elsewhere.)

Happy GNU Year!


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

Re: tmp-lshift.s:106: Error: selected processor does not support ARM mode `vdup.32 d6, r3'

[Torbjörn Granlund]

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

  For the specific case of neon, one alternative might be to explicitly
  add the pseudo-op

 .fpu neon 

  in all neon asm files, which should make them less dependent on flags
  passed on the compiler command line. It looks like the definition of
  ASM_START in mpn/arm/arm-defs.m4 can add that for us. So should we be
  using

ASM_START(`neon')

I believe we do, now.

But that does not solve the problem with incorrect user-supplied CFLAGS;
there are many other insns which are present in just some
sub-architectures

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

Re: tmp-lshift.s:106: Error: selected processor does not support ARM mode `vdup.32 d6, r3'

[Torbjörn Granlund]

Jeffrey Walton  writes:

  No, I don't override the CFLAGS. I set them like:

CFLAGS="-g2 -O3 -DNDEBUG -march=native" ./configure ...

You override set CFLAGS, you just set it?

  What is wrong is obvious. The build is broken.

What do you expect us to do?  Edit broken user supplied CFLAGS to work
for every possible breakage?

If you want your build to proceed, start without overriding CFLAGS.
Does that work?  Great, work from there.

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

Re: tmp-lshift.s:106: Error: selected processor does not support ARM mode `vdup.32 d6, r3'

[Torbjörn Granlund]

Jeffrey Walton  writes:

  I'm working on my BananaPi. It is a Cortex-A7 with ARMv7-a.

  Compile results in the following. According to Stallman I believe you
  are supposed to add the necessary options to compile the file
  independent of CFLAGS, and it should not need to be override-able by
  the user because it is required. Also see
  https://www.gnu.org/prep/standards/html_node/Command-Variables.html .

   gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I..
  -DOPERATION_lshift -I/usr/local/include -DNDEBUG -g2 -O2 -march=native
  -fPIC -Wa,--noexecstack tmp-lshift.s -fPIC -DPIC -o .libs/lshift.o
  tmp-lshift.s:  gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I..
  -D__GMP_WITHIN_GMP -I.. -DOPERATION_rshift -I/usr/local/include
  -DNDEBUG -g2 -O2 -march=native -fPIC -Wa,--noexecstack tmp-rshift.s
  -fPIC -DPIC -o .libs/rshift.o
  Assembler messages:
  tmp-lshift.s:106: Error: selected processor does not support ARM mode
  `vdup.32 d6,r3'
  tmp-lshift.s:108: Error: selected processor does not support ARM mode
  `vdup.32 d7,r3'
  tmp-lshift.s:114: Error: selected processor does not support ARM mode
  `vshl.u64 d18,d19,d7'
  tmp-lshift.s:120: Error: selected processor does not support ARM mode
  `vshl.u64 d4,d19,d6'
  ...

Are you implicitly saying that you're overriding CFLAGS (at "make" time)
and then things fail and that it shouldn't fail?

If I guess right, my recommendation is that you don't override CFLAGS in
a build-breaking manner.

If I guess wrong, please spell our what you do and what you think is
wrong in GMP.

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

Re: Mercurial: GMP repo clone failure

[Torbjörn Granlund]

Markku Pulkkinen  writes:


  Tried to clone GMP repo but it failed. The command and response was:

  hg clone --debug -v https://gmplib.org/repo/gmp/
  using https://gmplib.org/repo/gmp/
  sending capabilities command
  destination directory: gmp
  query 1; heads
  sending batch command
  requesting all changes
  sending getbundle command
  (sent 3 HTTP requests and 1435 bytes; received 684 bytes in responses)
  abort: HTTP request error (incomplete response; expected 8192 bytes got
  8143)
  (this may be an intermittent network failure; if the error persists,
  consider contacting the network or server operator)

Thanks for reporting this problem!

Now it should work again.

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

Re: Website security certificate expired

[Torbjörn Granlund]

Guru Vamsi Policharla  writes:

  I couldn't find an alternate contact point so I'm doing this here. The
  website security certificate for the gmplib.org website seems to have
  expired. Just wanted to give you guys a heads up before it
  caused any trouble.

The cert was renewed weeks ago, we just needed to remember to install
it.  :-(

(This will be resolved in he course of the day.)

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

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

[Torbjörn Granlund]

Richard Biener  writes:

  :/  But then with GCC we want deterministic behavior -- ISL
  added some "computation budget" and error reporting if that was
  taken up.  Maybe gmp/mpfr/mpc could consider adding such a thing
  (reporting budget overruns via a signal could be acceptable if
  the API churn would be too bad for another way).

I'll leave this up to the mpc maintainers.

  > I simplified your test case using 1 as the real part and an integer for
  > the imaginary part.  With the real part set to 1, the computation
  > finishes in about 10 seconds, with every doubling of it the runtime
  > almost triples.  (If my observation generalises to an extended real part
  > range, the compilation for your test case should terminate in about
  > 10*3^log2(4.045689747817175388336181640625e+8/1)/3600/24/365 years.)

  Ick.  I wonder if the actual ctan result is infinite or we just
  fail to compute it in an efficient manner...

The result should be extremely small, so returning Inf would be
quite inaccurate.  :-)

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

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

[Torbjörn Granlund]

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

  I simplified your test case using 1 as the real part and an integer for
  the imaginary part.  With the real part set to 1, the computation
  finishes in about 10 seconds, with every doubling of it the runtime
  almost triples.  (If my observation generalises to an extended real part
  range, the compilation for your test case should terminate in about
  10*3^log2(4.045689747817175388336181640625e+8/1)/3600/24/365 years.)

I meant to write:

I simplified your test case using 1 as the real part and an integer for
the imaginary part.  With the imaginary part set to 1, the computation
finishes in about 10 seconds, with every doubling of it the runtime almost
triples.  (If my observation generalises to an extended imaginary part
range, the compilation for your test case should terminate in about
10*3^log2(4.045689747817175388336181640625e+8/1)/3600/24/365 years.)

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

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

[Torbjörn Granlund]

Richard Biener  writes:

  > __real x = 3.09126495087690770626068115234375e+8;
  > __imag x = -4.045689747817175388336181640625e+8;
  > volatile _Complex double y = ctan (x);
  > return 0;
  >   }
  > 
  > If we get a test case somewhat closer to GMP, then it is likely
  > somebody will look at it.
  > 
  > I expect the maintainers of library called by gcc (mpc?) would be helped
  > by seeing the actual call to their library.

  OK, I can reproduce the issue with mpc 1.1.0, mpfr 3.1.4 and gmp 6.1.0
  using

  #include 
  #include 

  int main()
  {
mpc_t m;
mpc_init2 (m, 53);
mpfr_set_str (mpc_realref (m), "3.09126495087690770626068115234375e+8", 
  10, GMP_RNDN);
mpfr_set_str (mpc_imagref (m), "-4.045689747817175388336181640625e+8", 
  10, GMP_RNDN);
mpfr_clear_flags ();
mpc_tan (m, m, 0);
return 0;
  }

  As I questioned in the first followup I wonder if GCC can tell mpc
  to not exceed 53bits of precision for the result?  Even with denormals
  a precision of 303084 bits isn't possible?

Use setrlimit(RLIMIT_CPU, ...) and a signal handler?  :-)

I simplified your test case using 1 as the real part and an integer for
the imaginary part.  With the real part set to 1, the computation
finishes in about 10 seconds, with every doubling of it the runtime
almost triples.  (If my observation generalises to an extended real part
range, the compilation for your test case should terminate in about
10*3^log2(4.045689747817175388336181640625e+8/1)/3600/24/365 years.)


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

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

[Torbjörn Granlund]

[moved from gmp-devel]


Richard Biener  writes:

  For
>
  #include 
>
  int main()
  {
_Complex double x;
__real x = 3.09126495087690770626068115234375e+8;
__imag x = -4.045689747817175388336181640625e+8;
volatile _Complex double y = ctan (x);
return 0;
  }

If we get a test case somewhat closer to GMP, then it is likely
somebody will look at it.

I expect the maintainers of library called by gcc (mpc?) would be helped
by seeing the actual call to their library.

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

Re: gmp-4.3.2 bug

[Torbjörn Granlund]

"zhaolong.y...@dosee.ai"  writes:

  After configure, make, I make check and 1 test failed. Like

GMP 4.3.2 is almost 10 years old.  Please consider using a current
release.

  Then, I ignored it and make install. When I install gcc-6.4.0, it report 
gmp.h header error.

That's unrelated and not a GMP bug.  Ask some GCC help forum if you
cannot solve it yourself.  Or perhaps use a web search engine.

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

Re: GMP tuneup crashes

[Torbjörn Granlund]

Failures with the tuneup program not getting accurate timing is
unfortunately normal.  For some reason, GCD measurements are particular
fragile.

Try mesuring on an idle system, it should work better.

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

Re: mpz_invert gives wrong result for > 64bit numbers under Valgrind

[Torbjörn Granlund]

Jan Hartman  writes:

  I know it's stated in the GMP Manual that Valgrind might not support
  instructions recently added to an ISA, but this seems like it should
  work. I hope I provided enough details to verify and reproduce this.

I would argue that at any rate, it is not a GMP bug when valgrind
doesn't work properly for GMP.  It is something for the valgrind devs to
worry about.

(Some time ago, we reported an issue with GMP for newer Intel and AMD
processors.  Perhaps this is the same issue.  You might want to check a
newer valgrind version.)

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

Re: How to fix this problem?

[Torbjörn Granlund]

"thewill"  writes:

  When I ./configure the GMP-ECM,there had a error.

That's too bad.  Did you discuss this problem with the authors of that
ECM program?

If you contact them, I recommend that you mention what "this problem"
is, as that might help them diagnose the problem.

  Thank you very much!

You're welcome!
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Error in make and install

[Torbjörn Granlund]

"amirhosseinalik...@outlook.com" 
writes:

  ../libtool: line 1766: ../mpn/m4-ccas: Permission denied

I have no idea why your system does not allow the running of programs on
that file system.  It is not a GMP bug.  Please ask for sysadmin help
locally.

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

Re: configure failure for --host=armv7-apple-darwin with assembly

[Torbjörn Granlund]

Taner Sener  writes:

  Compiled your line into assembly. Output is below, it is a long. Attached
  archive includes assembly files for all three architectures: armv7, armv7s,
  arm64; armv7 and armv7s is the same but arm64 format is different.

  .section__TEXT,__text,regular,pure_instructions

  .ios_version_min 7, 0

  .syntax unified

  .section__DATA,__data

  .globl  _foo@ @foo

  .p2align2

  _foo:

  .long   3735928559  @ 0xdeadbeef

  .subsections_via_symbols

Thanks.

I expect ".long" to be tested by GMP's configure, so what makes this
fail is beyond me.

As far as I know, it is not really possible to work with Free Software
for Apple's iOS, unless one is willing to pay Apple's programming tax.
Unfortunately, I am not about to do that.


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

Re: Likely GMP bug

[Torbjörn Granlund]

Vincent Lefevre  writes:

  But shouldn't it be the goal of the compiler to generate the fastest
  code for the target?

Yeah, that's a good idea.  :-)

This might require more analysis than what we can expect from the
compiler, as (x >> 1) >> c is not the same thing as x >> (1+c) (at least
not if the CPU truncates counts).

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

Re: configure failure for --host=armv7-apple-darwin with assembly

[Torbjörn Granlund]

Taner Sener  writes:

  checking how to define a 32-bit word... configure: error: cannot determine
  how to define a 32-bit word

Well, how do you define a 32-bit word in this assembly variant?

(You might want to compile something like "int foo = 0xdeadbeef;" into
assembly and check the output to see the used syntax.)

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

Re: Likely GMP bug

[Torbjörn Granlund]

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

  10% speedup.

A great speedup for an important functions.

(It will be a slowdown for one obsolete platform, 64-bit Pentium 4.
There, a 64-bit right shift has a latency 7 or 8 cycles depending on
where the count is located.  I will not lose sleep over this, in
particular as it will typically use asm.)

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

Re: Failure building on HP-UX with more than 2 threads (internal bug #4308)

[Torbjörn Granlund]

Mișu Moldovan  writes:

  Just wanted to let you know I found a workaround for this particular
  issue.  We are able to build GMP on HP-UX with more than 2 threads
  using the HP-UX C++ compiler, when invoked as an ANSI C compiler, for
  example with CC="/opt/aCC/bin/aCC -Ae".  Maybe worth documenting on
  your side?

Are you saying that a parallel build fails with one compiler and works
with another, and that the "make" command is somehow of less importance?

The only somewhat realistic way the compiler could cause parallel builds
failures is if it uses hardwired temp filenames.  But I'd be extremely
surprised if that were the case.

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

Re: Likely GMP bug

[Torbjörn Granlund]

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

  But you may be right that it's important for performance to avoid a
  redundant count_trailing_zeros on u.

It is slow on several machines, but it has become more common to provide
good leading/trailing bit count for newer microarchs.

  It seems tricky to avoid that, without code duplication or complications
  in the code flow. For my personal preference, tradeoff threshold between
  goto and duplicated code is around 5-10 duplicated code lines.

  Thinking about micro optimizations... Consider

  >   count_trailing_zeros (c, ulimb);
  >   ulimb = (ulimb >> 1) >> c;

  vs

  >   count_trailing_zeros (c, ulimb);
  >   ulimb >>= (c + 1);

Right shift has OK performance almost everywhere.  (And obsolete
exceptions is x86-64 Pentium 4 where it takes some 8 cycles and stalls
the pipeline.)

On newer Intel x86-64 shifting is fast for immediate counts but takes 2
cycles with 1/2 thoughput for dynamic counts.  The latest generations
provides a new set of shifts for dynamic counts which are fast,
e.g. shrx.

AMD chips have great right shift performance with no exceptions.

No RISCs have any problems here.

  I wonder if maybe it's preferable to always use the first variant? Both
  should compile to three instructions (assuming we have a ctz
  instruction), ctz + shift + shift, or ctz + add + shift. But with the
  first variant, the first shift can be issued in parallel with ctz,
  reducing the critical path of the gcd loop.

  We'd need some benchmarking to see if it makes a difference.

Suppressing redundant count_trailing_zeros should make more difference.

Ref: https://gmplib.org/~tege/x86-timing.pdf

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

Re: Likely GMP bug

[Torbjörn Granlund]

"Marco Bodrato"  writes:

  The test suite now checks for this bug, for every run with
  --disable-assembly. So yes, you can remove the failure file, it will be
  recreated if some asm implementation is affected :-)

I beleieve all x86 asm for gcd_1 was whacked tonight (we only have two
implementatons, actually).

All non-x86 gcd_1 code should be tested within a week.

https://gmplib.org/devel/systemup.html

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

Re: Likely GMP bug

[Torbjörn Granlund]

"Marco Bodrato"  writes:

  The test suite now checks for this bug, for every run with
  --disable-assembly. So yes, you can remove the failure file, it will be
  recreated if some asm implementation is affected :-)

Ehum?

With --disable-assembly asm code tends to be excluded...

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

Re: Likely GMP bug

[Torbjörn Granlund]

I assume this bug is now fixed, and so I will remove the test failure file.

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

Re: Likely GMP bug

[Torbjörn Granlund]

"Marco Bodrato"  writes:

  It was hard, but we got it:
  https://gmplib.org/repo/gmp/rev/1f8a8fefb5c2

Thanks!

It really worries me that our crazy broad testing did not catch this
until now.  This makes me much less confident about GMP's correctness,
actually.

I realise that a plain assembly enabled build will not trigger this for
any current platform, so few people will be afffected in practice.

  The bug is triggered not only for 32-bit limbs, but also for other sizes.
  On any machine, if the undefined behaviour is not the one we hope,

  ./configure --disable-assembly && make
  make check TESTS= && tests/mpz/t-gcd_ui

  should fail.
  It does, with ABI=64 on shell.

  Of course I also healed the bug, to avoid too many red lines in the next
  "GMP testing status": https://gmplib.org/repo/gmp/rev/e4849ae7c974 .
  This is just a workaround, waiting for a code reorganisation by someone
  who knows better than me the various algorithm alternatives.

Replacement code should not jump into loops.  This bug (but not the
shortcoming of the test suite) should teach us that lesson.

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

Re: Likely GMP bug

[Torbjörn Granlund]

"Marco Bodrato"  writes:

  Or we can simply "strip U maybe" before entering the loop.

  I suggest:

I agree with that change, perhaps without the

goto next_line
next_line:

part.  :-)

We might want to revisit this code for other reasons too.  I expect
gcd_1 to be quite important.  The hardwired 16 bit difference for using
plain division is unlikely to be universally optimal.  We might even
want to tune for that.

We never did anything about slow count_loading_zeros/count_trailing_zeros,
The USE_ZEROTAB might not be the best way for code clarity; instead we
could define some count_trailing_zeros_best_for_small_counts and define
that to count_trailing_zeros when that is fast.

For now, I'd suggest to just rip out USE_ZEROTAB.

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

Re: Likely GMP bug

[Torbjörn Granlund]

As I am traveling I haven't had a chance to take a closer look, but
perhaps this bug is the result of the slightly unconventional code style
user here?  Jumping into loops and pseudo-dead if statement bodies might
not be the best style for avoiding subtle bugs.

I think we should rewrite relevant parts and avoid these constructs.

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

Re: Likely GMP bug

[Torbjörn Granlund]

Dennis Clarke  writes:

  I have run all the testsuite, both with the assembly and without, on a
  pure 32-bit Debian machine and see no errors anywhere.

Our machine runs gentoo with gcc 6.4.0.  (Not sure if the exact machine
matters.)

datan$ somepath/gmp/configure CFLAGS="-m32 -g -fsanitize=undefined 
-fno-sanitize-recover" --disable-shared --disable-assembly ABI=32 && make && 
make check TESTS= INTERPRETER=)

datan$ GMP_CHECK_RANDOMIZE=140064609456624 tests/mpq/t-cmp_ui
gcd_1.c:187:13: runtime error: shift exponent 32 is too large for 32-bit type 
'long unsigned int'


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

Re: Likely GMP bug

[Torbjörn Granlund]

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

  And code is essentially 

count_trailing_zeros (c, t);
ulimb >>= (c + 1);

  The intention is to shift right to get rid of both trailing zero bits,
  and the redundant least significant one bit.

  That fails with undefined behavior if by chance t == 2^31, so that c ==
  31.

And ubsan complains about exactly that.

  I don't see how that can happen, though, since ulimb, vlimb < 2^31
  through out the loop, and t = (ulimb - vlimb) mod 2^32.

The setting GMP_CHECK_RANDOMIZE=140064609456624 seems to trigger it, but
that could of course also be bugs in the compiler.

  And I also wonder why USE_ZEROTAB is set to 0 here.

That might be good as count_trailing_zeros is usually fast.

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

Likely GMP bug

[Torbjörn Granlund]

If somebody could take a look at

https://gmplib.org/devel/tm/gmp/check/failure/ivygentoo32.gmplib.org-dyn-noasm-ubsan:32.txt

I would appreciate it.  (I  am traveling.)

-- 
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: configure MPN_PATH="generic" fails on 64 bit

[Torbjörn Granlund]

Karsten Scheibler  writes:

  Compiling gmp-6.1.2 on Ubuntu 16.04.4 (x86_64) with a ./configure
  works without problems.
  But when trying to disable the assembly routines using:

  ./configure MPN_PATH="generic"

  configure fails with the following error:

  configure: error: no version of invert_limb_table found in path: generic

  In contrast, when using 32 bit configure has no problems (make
  finishes without problems as well):

  ./configure ABI=32 MPN_PATH="generic" CFLAGS="-m32"

  Furthermore, gmp-6.1.99-20180418 behaves the same.

Playing with GMP's various internal variables (be it configure, make, or
library variables) is strongly discouraged.  Please use the documented
methods for configuration, build and use of GMP.

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

Re: tuneup: speed_measure() could not get 4 results within 1.0%

[Torbjörn Granlund]

Nikita Zlobin  writes:

  There is issue with tune system. I tried to compile from sources and
  tune on two laptops, one with intel b950, seconf - i5 (don't remember
  exact cpu number), both sandybridge (i5 - with avx).

We are aware of that tuning of the various GCD thresholds don't work
properly.  This has been broken for a very long time.  I have not spent
enough time on it to understand why it does not work.  If somebody else
could do that, it would be very good.

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

Re: Configure unable to recognize mipsisa64r2el triplets

[Torbjörn Granlund]

Jiaxun Yang  writes:

  > I've never seen "mipsisa64r2el" before.

  Yes, it's rare. However, according to config.sub from GCC [1], it's not
  illegal.

Good! We woudn't want to be gaoled for a CPU moniker!

  I ran it on a LFS rootfs provided by Loongson (A Chinese MIPS64r2
  processor).

  [1]https://github.com/gcc-mirror/gcc/blob/master/config.sub

It seems that GMP's configfsf.sub also has that.  Now, I have no idea
what it means.  Is is just a novel name for mips64r2el or is it somehow
a different ABI?

If you make the obvious change to configure.ac, then build twice, once
with --disable-shared and once with --disable-static, does

  make && make check

run to without any errors.  (OK, you told me you were cross compiling,
so perhaps that will require some intermediary command.  And "make check
TESTS=" for just building the tests would perhaps be useful.)

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

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:

  Attached. Before this change, "make tune" was failing (I don't have
  to specify -j explicitly since this is the default config on my
  machines, hence the particular importance of .NOTPARALLEL). After
  this change, "make tune" runs sequentially and I don't get a build
  failure for tune ("make tune" failed with an abort just because
  "speed_measure() could not get 4 results within 1.0%" I assume).

Thanks! (Applied by Marco.)

-- 
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: Configure fails on 32-bit platform

[Torbjörn Granlund]

Jeffrey Walton  writes:

  Configure seems to be misdetecting this 32-bit platform. The machine
  is CentOS 6, i686 .
  
  The environment is:
  
  PKG_CONFIG+PATH: /usr/local/lib/pkgconfig
   CPPFLAGS: -I/usr/local/include -DNDEBUG
 CFLAGS: -g2 -O2 -m32 -march=native -fPIC
   CXXFLAGS: -g2 -O2 -m32 -march=native -fPIC
LDFLAGS: -L/usr/local/lib -m32 -Wl,-R,/usr/local/lib
  -Wl,--enable-new-dtags
 LDLIBS: -ldl -lpthread
  
   Then:
  
  $ ./configure
  ...
  
  configure: error: Oops, mp_limb_t is 32 bits, but the assembler code
  in this configuration expects 64 bits.
  You appear to have set $CFLAGS, perhaps you also need to tell GMP the
  intended ABI, see "ABI and ISA" in the manual.
  
  $ uname -a
  Linux localhost.localdomain 2.6.32-696.20.1.el6.i686 #1 SMP Fri

Please read the helpful message from GMP's configure, which you quoted
above.

-- 
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: ARM Cortex-A7 feature misdetection

[Torbjörn Granlund]

Jeffrey Walton  writes:

  > You should edit the .asm source files under mpn/arm/neon. Before m4
  > processing.
  
There are at least two neon subdirs under mpn/arm.

  I see one file that looks interesting (lshiftc.asm):
  
  $ ls mpn/arm/neon/
  README   lorrshift.asm  sec_tabselect.asm
  hamdist.asm  lshiftc.asmpopcount.asm
  
  Does this look about right:
  
  # mpn/arm/neon/lshiftc.asm
  ...
  
  ASM_START()
  TEXT
  ALIGN(64)
  .fpu neon
  PROLOGUE(mpn_lshiftc)
  IFLSH(` mov r12, n, lsl #2  ')
  IFLSH(` add rp, rp, r12 ')
  IFLSH(` add ap, ap, r12 ')
  
I think this is perhaps not as clean as one would want it to be.
Perhaps add a parameter to ASM_START, or add a new macro which could be
made empty for machines which do not need or accept the new directive.

(About your error: Your adting the lshiftc.asm file. Note the c at the
end.  Wrong file.)


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

Re: ARM Cortex-A7 feature misdetection

[Torbjörn Granlund]

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

  What I've done in other neon assembly files is to add a
  
.fpu neon
  
  pseudo-op early in the file. Seems less brittle to me than passing the
  corresponding command line options, in particular for fat builds (i.e.,
  some files with neon assembly, used at runtime only after some check of
  available instructions), where one might not want the C compiler to emit
  any neon instructions.
  
If we add support for fat arm builds, then that's what we'll need to do!

I don't know if it could cause some portability problems to add it.

-- 
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: Failure building on HP-UX with more than 2 threads (internal bug #4308)

[Torbjörn Granlund]

Mișu Moldovan  writes:

  On HP-UX, we run into a failure in building GMP.  Probably not a fault
  of your library, but I suppose you would like to know of this anyway,
  as per https://gmplib.org/manual/Reporting-Bugs.html.
  
  In short, when using more than 2 threads for compiling GMP, the
  building fails.  In the attached bug report I've tried to follow the
  indications in the above link.  Do let me know if there's anything
  more we can do to document the issue.  And please let us know your
  thoughts on this.  Thanks!
  
  How to reproduce
  

  You have to use "parallelization" with HP-UX's make:

  export MAKE="make -P"
  export PARALLEL=3



  Configure log
  =

[snip]


  Build error output
  ==

  Making target"mpn/mp_bases.c"
  ./gen-bases table 64 0 >mpn/mp_bases.c || (rm -f mpn/mp_bases.c; exit 
1)
  Making target"mpn/mp_bases.lo"
  /bin/sh ./libtool  --tag=CC--mode=compile /opt/aCC/bin/cc -w 
-DHAVE_CONFIG_H  -I.  -D__GMP_WITHIN_GMP+O2 -c -o mpn/mp_bases.lo 
mpn/mp_bases.c
  libtool: compile:  /opt/aCC/bin/cc -w -DHAVE_CONFIG_H -I. -D__GMP_WITHIN_GMP 
+O2 -c mpn/mp_bases.c -o mpn/mp_bases.o
  Making target"config.h"
  At end of source: error #2018: expected a ")"

  "mpn/mp_bases.c", line 127: error #2274: improperly terminated macro 
invocation
  /* 115 */ { 9, CNST_LIMB(0x25659a3711bc827d), 
CNST_LIMB(0xdb0e4126bcc86bd7), CNST_LIMB(0x30

   ^

IIUC, you here somewhere issue a command "make" which reads the MAKE and
PARALLEL environment variables, then that command fails.

Unfortunately, we do not support parallel builds except with GNU make.
I will check to so that this is properly documented in our manual.


-- 
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]

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

  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.

Alas, I got around to this now.

There were a number of problems:

1. The pseudo-insn setx didn't work on gcc202.  I worked around this by
   expanding the needed insn, and also to go with the 44-bit addressing
   model (instead of the expensive 64bit).  44-bit addrs is the default
   on both gcc202 and NetBSD 7.x at least.  (I suppose we should allow
   an configure option for this, but since my SPARC access is extremely
   limited I cannot test any such features. Besides, SPARC is not in
   much use.)

2. The relocs used for PIC in sparc32/sparc-defs.m4 fails on gcc202.  I
   updated with PICkier choices.

3. The C sec_invert and the Sparc T3 asm cnd_add_n/cnd_sub_n did not
   agree about how to specify the condition.  Should true be 1 or any
   non-zero value?  I decided for the latter and updated the asm.

-- 
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:

  I'm just trying to figure out how to squeeze some performance out of a
  few weird processor types.
  
You have my sympathy there, and I am willing to help, time permitting.
:-)

-- 
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: Assertion failure in mpz_divexact()

[Torbjörn Granlund]

Francesco Biscani  writes:

  I am experiencing an assertion failure in mpz_divexact() using the latest
  GMP from the unstable branch. I am attaching a test program exhibiting the
  issue.
  
Thanks for the bug report!

This bug is now fixed in the main GMP repo.

-- 
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: make 'ASMFLAGS' behavior similar to 'CFLAGS' and 'CXXFLAGS' variables

[Torbjörn Granlund]

I don't plan to work on this, and I am not sure that doing major work in
this area is worth the potential portability destabilisation.  (Please
use this list for bug reports and gmp-discuss for other subjects.)

sav...@ukr.net writes:

  Currently, if 'CFLAGS' and 'CXXFLAGS' variables not defined by User,
  they're autodetected during GMP configuration and used for appropriate
  compiler 'gcc' and 'g++' respectively during build.  For some reason
  'ASMFLAGS' variable don't autodetected at all; if defined by User, it
  doesn't used for assembler check during configuration, and used with
  'CFLAGS' and 'CXXFLAGS' during build.
  
  Even if don't take into account, that "the same things are done in
  different way", this makes binding of GMP to a particular assembler (GCC
  or GCC-like). As a consequence, 3rd party assembler (e.g. YASM,
  yasm.torall.net) can't be used for GMP build, since it receive GCC C and
  C++ compiler keys, instead of expected from 'ASMFLAGS' variable, and
  throw error.
  
  This could be changed by setting 'ASMFLAGS' as the only variable, used
  with 'CCAS', and initializing 'ASMFLAGS' from 'CFLAGS', if it wasn't
  defined by User (patch added in attachment).  Tested build and check
  using mingw-w64 for  configurations with
  and without YASM as 3rd party assembler, and found no regressions (all
  tasks finished successfully). Didn't tested tune, as it's not available
  for this compiler; expected, that it should be built without errors too.
  
  Don't know the reason, why 'CCAS' variable was used with 'CPPFLAGS' in
  addition to 'CFLAGS' (object files, built from 'mpn/*.asm' files, are
  linked only with 'gmp' C library, but not 'gmpxx' C++ library; in
  addition, 'CXXFLAGS' could contain C++ compiler specific keys,
  e.g. '-std=gnu++11', which would be passed to C compiler 'gcc'). Thus
  this patch initialize 'ASMFLAGS' from 'CFLAGS' variable only, but not
  'CXXFLAGS'.
  
  Environment: Windows 10 x64, mingw-w64 6.3.0 x86_64, MSYS2 20161025
  x86_64,GMP-6.2.0-dev (changeset 17426:330407782736).
  
  Alexander
  
  
  ___
  gmp-bugs mailing list
  gmp-bugs@gmplib.org
  https://gmplib.org/mailman/listinfo/gmp-bugs

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
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: FreeBSD links wrong library for tests if one is installed in $prefix

[Torbjörn Granlund]

Emmanuel Thomé  writes:

  freebsd's ld, which is a venerable GNU binutils 2.17.50 dated 2007-07-50
  (yes, I'm talking about the current freebsd), does not emit new dtags
  (runpath vs rpath) by default.
  
Ouch, I hadn't noticed that.

Our test environment includes many (virtualised) fbsd systems but they
might all have a non-archaic binutils installed in /usr/local.

The fbsd developers' GNU/Linux envy is projected at GPL hate which in
turn badly hurts their own system.  They are sure that the GPLs are
commercially non-viable in theory, and that GNU/Linux is 100 times more
successful in practice does not affect their theory faith.
  

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

Re: documentation bug

[Torbjörn Granlund]

paul zimmermann  writes:

  >Anyway, on page 111 of the manual (section 15.7.1, Prime Testing)
  >https://gmplib.org/gmp-man-6.1.2.pdf
  >where it describes the algorithm for mpz_probab_prime_p, it says,
  >
  >"For an odd input n, and with n = q*2^k + 1 where q is odd, this algorithm
  >selects a random base x and tests whether
  >   x^q mod n is 1 or -1,
  >or an
  >   x^(q2^j) mod n is 1, for 1 <= j <= k.
  >If so then n is probably prime, if not then n is definitely composite."
  >
  >It looks like they are trying to describe the strong probable prime test.
  >However, in a strong probable prime test, the second check should be
  >   x^(q2^j) mod n is -1, for 1 <= j < k.
  >
  >The manual is wrong, right? Do you know if the code is correctly written?
  
Also reported directly to GMP...

We seem to have been more lucky with the implementation than with the
documentation.

Perhaps this suggests that we should stop writing seperate
documentation?  After all, the .c and .asm files document the library in
detail, including all bugs.  :-)

-- 
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]

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

  I wonder if one could use some m4 macrology to reduce clutter. Maybe
  one macro for the pattern
  
  IFSTD(`   sub $8, %rsp')
  IFDOS(`   sub $40, %rsp   ')
ASSERT(nz, `test $15, %rsp')
CALL(   mpn_add_n)
  IFSTD(`   add $8, %rsp')
  IFDOS(`   add $40, %rsp   ')
  
  used when it's known that rsp = 8 (mod 16), and another one when it's
  known that rsp = 0 (mod 16).
  
  There seems to be a few uses of CALL that want to do this differently,
  though, e.g., gcd_1.asm, maybe it would also help to move (and rename)
  its conditional definition of STACK_ALLOC.
  
One could consider more advanced stack frame management.  Incorporating
stack adjustments in the CALL macro might make sense, but then other
stack allocation (push and direct sub X,%rsp) needs to be taken into
account, and ideally any direct allocation should incorporate allignment
with adjustments in CALL then suppressed.

I haven't bothered with this since only a handful functions perform
calls.

-- 
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

New bug list policy

[Torbjörn Granlund]

Almost all mail to this list contains very poor bug reports,
such as a dump of a line

  FAIL: t-foo

without any hint of platform/compiler, or else reports where the user
cannot compile anything, or reports about the ancient GMP 4.3.2.

These reports are just list and archive noise, and therefore we will no
longer forward such messages to this list.  Instead moderators will
reject the reports with a short message.


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

Re: undefined reference to __gmpn_cpuvec

[Torbjörn Granlund]

Alexios Angeletakis  writes:

  So I download GMP and do just ./configure without any options, and
  this is the output:
  
[snip many errors]
  
  So is this an error?
  
Something very fundamental is broken with your build environmnt.  (As
you might imagine, GMP does link with its tests properly on GNU/Linux.)

-- 
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]

Vincent Lefevre  writes:

  One can look at the preprocessor output. :-)
  
Please do that for all relevant versions.  :-)

  With -D__USE_MINGW_ANSI_STDIO:
  
  static __attribute__ ((__unused__)) __inline__ __attribute__((__cdecl__))
  __attribute__((__format__ (gnu_printf, 1, 2))) __attribute__ ((__nonnull__ 
(1)))
  int printf (const char *__format, ...)
  {
register int __retval;
__builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format 
);
__retval = __mingw_vprintf( __format, __local_argv );
__builtin_va_end( __local_argv );
return __retval;
  }

Looks good.

-- 
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: gmp 64 bit configure failure on Solaris/SPARC

[Torbjörn Granlund]

Norm Jacobs  writes:

  Pilot error.  Just supplying the triples that I want resolved my problem.

Ideally,

  configure
  make
  make check

should recognise the CPU and use the best ABI available.

If that does not work, then we want to improve the config* files.
  

-- 
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: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

[Torbjörn Granlund]

Claude Heiland-Allen  writes:

  Using this source:
  
  https://gmplib.org/download/gmp/gmp-6.1.2.tar.lz
  
  I compiled and then ran the test suite as advised by make install, and
  got a failure.  I'm cross-compiling for Windows 64bit from Linux 64bit,
  amd64 architecture.  This is what I did:
  
  ./configure --host=x86_64-w64-mingw32 --prefix=$HOME/win64
  make -j 8
  make install
  make check
  
I assume you're using some emulator for the 'make check' part.

  t-scanf.c:1477: GNU MP assertion failed: ret == (-1)
  FAIL t-scanf.exe (exit status: 3)
  
It is not realistic for us to work on this problem as there are
countless of things which might be wrong.

Did the configure find the right compiler?
Did the compile find the proper target include files?
Is the emulator working properly?
Etc.

If you decide to debug this, please let us know if it is GMP-related.

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

Re: gmp 64 bit configure failure on Solaris/SPARC

[Torbjörn Granlund]

Norm Jacobs  writes:

 --- gmp-6.1.1/configure.ac.orig 2017-01-04 20:22:16.789422430 +
 +++ gmp-6.1.1/configure.ac  2017-01-04 20:47:35.488157345 +
 @@ -1318,7 +1318,7 @@
   # reject ABI=64 in favour of ABI=32 if the user has forced the flags 
to
   # 32-bit mode.
   #
 -abilist="32"
 +abilist="64 32"
   cclist="gcc acc cc"
   any_testlist="sizeof-long-4"
   GMP_INCLUDE_MPN(sparc32/sparc-defs.m4)
  
That's not the correct fix.

What needs to be fixed is CPU recognition, i.e., to have config.guess
return the proper CPU type, then make that type (assuming it is unknown
by GMP) be known to the sparc-64 code in configure.ac and also by
config.sub.

-- 
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: gmp errors on my Iot intel galileo gen-2

[Torbjörn Granlund]

Vaibhav Gautam  writes:

  hello, i ran make check in my gmp  and found that i am getting failedd
  scripts running can you please tell me how can i fix them?? didn't heard
  anything from their developer's.
  
Please read https://gmplib.org/manual/Reporting-Bugs.html and send more
complete information.

The GMP developers don't have access to any Intel Quark system, so
without the requested information, we cannot even start working on this.

-- 
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: Report bug in GMP library.

[Torbjörn Granlund]

Thông Nguyễn Văn  writes:

  #include 
  
  int main()
  {
  mpz_t x,y;
  mpz_inits(x,y);  // use "mpz_init(x);mpz_init(y);" to get correct.
  }
  
You need to append a NULL argument.  (See the GMP manual for usage
details.)

No GMP 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