Re: Reduced number of allocated limbs after calling mpz_remove

[Torbjörn Granlund]

Niels Möller  writes:

  I don't have a strong opinion on how to fix this discrepancy between
  docs and implementation. But I feel rather strongly that mini-gmp
  shpuldn't make this promise, so code that rely on it will not work with
  mini-gmp.

It is, in my opinion, not a bug in the code, nor is is a bug in the
documentation.

What we indended to say in the docs is that a variable which once
contained something large then will occupy lots of RAM even if is later
is used for only small things.  (This in turn was an optimisation as
trimming the allocation after each operaton would slow down GMP very,
very much.)

That's the only thing we should promise, as it has obvious exceptions.

It is possible that the docs need clarification.  Perhaps a "in most
cases" can be inserted somewhere?

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

Re: Fix for BMI2 detection for Intel CPUs in fat builds

[Torbjörn Granlund]

Thanks, your proposed patch has been committed.

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

Re: Leading zeroes

[Torbjörn Granlund]

 writes:


  I encountered a bug while running the R version. While the isprime()
  function usually is able to handle strings, it apparently gets confused if
  there are leading zeroes.

You need to report this "R" bug to whomever is responsible for this "R
version".

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

Re: crash on __gmpz_init

[Torbjörn Granlund]

"igor pesando - Dept of Physics, University of Torino"
 writes:

  thanks for the quick answer on the first case.
  But the issue is also present if I use malloc in C.

People have explained what you did wrong, which was several things.

Something you might consider: It would have been pretty surprising if
mpz_init was fundamentally broken, a function essentially every GMP
application program have beeing using for 30 years, don't you think?
Looking closer in such situations, considering the possibility of ones
own mistakes, might be a better approach.

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

Re: crash on __gmpz_init

[Torbjörn Granlund]

Vincent Lefevre  writes:

  On 2024-01-22 11:02:21 +0100, Marc Glisse wrote:
  > Hello,
  > 
  >   mpz_class M[LINES][COLS];
  > 
  > you are trying to put an array with millions of elements on the stack, so
  > the stack overflows. Very large arrays need to be allocated on the heap in
  > C++ (new, malloc, or some wrapper like std::vector).

  Note that the user has a segmentation fault in __gmpz_init for
  test2_mem.c too (tc_7000x5000), which uses malloc(). See the
  gdb output.

Note that there are several typos for the dimensions in the examples, so
making sense of things is pretty hard.

Seeing segfaults in mpz_init for crazy stack offsets is expected for
stack overflow, I think.

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

Re: errors in make check

[Torbjörn Granlund]

Marc Glisse  writes:

  could you check with the latest snapshot from
  https://gmplib.org/download/snapshot/gmp-next/ ?

  If that does not help, can you try with a different compiler (a real
  gcc, or maybe a non-Apple llvm, you can probably get them through
  homebrew or macports)?

It would surprise me dearly if these test failures are not due to a
compiler bug.

We have gotten reports of problems with Apple's compilers serveral times
over the years.  Unfortunately, these days I cannot reproduce any of
them on x86 as I do not have access to the current compilers.  (The GMP
project has a few years old Mac x86 hardware, but Apple blocks the
installation of non-obsolete software on these machines.)

Also, isolating these compiler problems is likely a waste of effort.  We
do generally not work around compiler bugs in GMP.

My recommendation for Apple developers is: Get a well-tested compiler.
Avoid Apple's compilers.  The least buggy compiler is gcc, but clang
specifically for x86 is ok.

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

Re: Make check fail on GMP-6.3.0 after installing macOS Sonoma 14.0 (23A344)

[Torbjörn Granlund]

We are not in a position to debug this, as we don't have recent enough
Mac x86 hardware for running recent enough macos to run these later
problematic Apple compilers.  No, I am not making this up, Apple likes
to play these games with what is supported where.

An educated guess is that this is an Apple/clang compiler bug.  GMP has
triggered countless clang bugs over the years.

-- 
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.3.0 - make tuneup - Stop

[Torbjörn Granlund]

Zsolt Kalmandi  writes:

  ./configure --build=silvermont-pc-linux-gnu --enable-fat

A fat build is incompatible with tuneup.  I don't even know how it would
work.

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

Re: Build failure on macOS Sonoma 14.0 beta

[Torbjörn Granlund]

Marc Culler  writes:

  If you read my earlier messages you will see that I did try that and that
  it failed in exactly the same way.  I am not trying to get the GMP
  maintainers to do anything which is impossible (unless you count trying to
  get Apple to fix bugs -- something which is impossible for me but should be
  possible for a project of the stature of GMP).

Alas, I don't think the GMP project has Apple's ear.

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

Re: Build failure on macOS Sonoma 14.0 beta

[Torbjörn Granlund]

Marc Culler  writes:

  The build fails in the same way when I remove --enable-fat but use
  export CFLAGS="-arch x86_64 -mmacosx-version-min=10.9 -mno-avx -mno-avx2
  -mno-bmi2"

If it "fails in the same way" without --enable-fat, your machine has
gremlins.  The problem symbol is very specific to FAT builds.


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

Re: Build failure on macOS Sonoma 14.0 beta

[Torbjörn Granlund]

Marc Culler  writes:

  With no CFLAGS and using

  $ ./configure --with-pic --enable-fat --prefix=X

  I get almost the same error (the difference being the distance of the
  branch), namely:

It is not possible for the GMP maintainers to analyse the effects of
various options which we do not know about.  As I wrote before, please
just use --enable-fat.  The GMP manual is a great source for information
on how to build and use GMP.

I have no idea what effect --with-pic might have on a GMP build.  We do
not list that option in our manual.

It is a common problem that people pass lots of options to the compiler
by means of GMP's configure, which in turn breaks things.  My avenue to
sorting such problem out would be to cut down on those options, not
report any resulting failure as a bug.

The error you get, assuming it still happens without any unsupported
extra options, is clearly related to "fat" builds.  How Apple's
proprietary clang breaks it is curious.  My best guess is that it is a
compiler bug; clang has always been buggy and Apple's closed
source variant is worse that the open source variant.

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

Re: Build failure on macOS Sonoma 14.0 beta

[Torbjörn Granlund]

Marc Culler  writes:

  I am unable to build gmp-6.2.1 on macOS Sonoma beta using the command line
  tools released for that system.  The system is up to date. The hardware of
  the build system is "1.6 GHz Dual-Core Intel Core i5".

  The build commands I am using are:
  $ export GMPPREFIX=/a/path/on/my/system
  $ export CFLAGS="-arch x86_64 -mmacosx-version-min=10.9 -mno-avx -mno-avx2
  -mno-bmi2"
  $ ./configure --with-pic --build=x86_64-none-darwin
  --host=x86_64-none-darwin --enable-fat --prefix=${GMPPREFIX}/intel

  The error message I get is:
  ld: branch8 out of range 501588 in ___gmpn_add_nc_x86_64

  The error occurs when using: "Apple clang version 15.0.0
  (clang-1500.0.40.1)"

Have you tried letting GMP figure out how to best compile things?

You want to retain the --enable-fat option only.

Passing an arm long set of options usually makes the build worse, or
breaks it completely.

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

Re: Unsigned integer overflow in `toom_eval_pm2.c`

[Torbjörn Granlund]

Andrew Teylu  writes:

  When I run `multiply.c` from gmpbench [https://gmplib.org/gmpbench],
  I'm seeing an unsigned integer overflow in `toom_eval_pm2.c` on this
  line:

  neg ^= ((k & 1) - 1)

  I fully appreciate that unsigned integer overflow is implementation
  defined, but I am not sure if this is the intended behaviour of
  `mpn_toom_eval_pm2` or not.

In C, unsigned arithmetic is completely defined as computing mod 2^k,
where k is the bit size of the corresponding type.

I am not sure the arithmetic on unsigned types is what clang is unhappy
about, though.  Perhaps it dislikes the xor with "neg", which is a
signed variable.

Arithmetic on signed types as well as assignments between signed and
unsigned is not well-defined for certain operand ranges.

This is not a real problem with any compiler I am aware of.  Of course,
an evil compiler is free to make demons fly out our noses whenever we
trigger "undefined" signed integer operations.

I don't think it is worth our time trying to placate clang and its ever
growing world of warnings.  We would end up with utterly messy code
which nobody could read.


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

Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c

[Torbjörn Granlund]

Brett Kuntz  writes:

  Go to line 248 inside mpn/generic/mod_1.c 

  mp_limb_t pre[4]; 

There is no such thing on an unedited version of GMP 6.3, not on line
248 not anyplace else in that file.

  mpn_mod_1_1p_cps (pre, b); 

  Only initializes pre[0], pre[1], and pre[3]. ***NOT*** pre[2]. 

Your point?

  The final line: 

  return mpn_mod_1_1p (ap, n, b, pre); 

  Reads from pre[2] erroneously and gives incorrect results if your
  stack memory has anything other than a 0 there.

That line does not read any elements from pre[].  You have misunderstood
the semantics of C.

  But if you actually claim that an unedited GMP has a bug here, please 
  construct a test case which uses documented interfaces, and which 
  demonstrates the claimed bug. 

  1) Edit line 248 mpn/generic/mp_limb_t pre[4]; into: 

There is no file with that name.

  mp_limb_t pre[4] = { -1, -1, -1, -1 }; 

  2) Recompile GMP. 

  3) Use the mpn_mod_1() function as described on the following page and
  you will now get incorrect results:

It is clear that you have not tried that yourself.

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

Re: Uninitialized memory bug found in /mpn/generic/mod_1_1.c

[Torbjörn Granlund]

Brett Kuntz  writes:

  Take a look at function mpn_mod_1() in /mpn/generic/ mod_1.c on lines 248 - 
250

  mp_limb_t pre[4];
  mpn_mod_1_1p_cps (pre, b);

  mp_limb_t pre[4] is not initialized

It does not exist, only pre[0] through pre[3] does.

  and the mpn_mod_1_1p_cps() function
  never writes to pre[2]. So if we change that to mp_limb_t pre[4] = { -1,
  -1, -1, -1 }; as a test we'll quickly see that inside mpn_mod_1_1p_cps()
  the value cps[2] (pre[2]) is never written to and if we print out pre[4]
  after running it we'll get output like: 0x21CFE6CFC938B36BU,
  0xU, 0xU, 0x9581CA13918612E1U (pre[2] is
  -1)

  /mpn/generic/mod_1_1.c lines 260-266:

if (LIKELY (cnt != 0))
  {
mp_limb_t B1modb = -b;
B1modb *= ((bi >> (GMP_LIMB_BITS-cnt)) | (CNST_LIMB(1) << cnt));
ASSERT (B1modb <= b);   /* NB: not fully reduced mod b */
cps[2] = B1modb >> cnt;
  }

  cnt will ALWAYS equal 0 since there will be NO leading 0's when this is
  called since /mpn/generic/mod_1_1.c checks for the high bit being SET
  before calling.. which means this function only ever gets called with NO
  leading zeros!!!

Why are you so worked up?

The logic seems perfectly fine.

  ALSO there are unexplained differences between MOD_1_1P_METHOD 1 and
  MOD_1_1P_METHOD 2 when it comes to the function mpn_mod_1_1p_cps(). In
  one of them pre[4] is always set and in the other (method 2) pre[2] is
  skipped! Why are these two functions different? It looks like their job
  is to calculate the inverses for the following mod functions so one
  would expect them to be the same.

There are lots of "unexplained" things in the GMP internal functions.
But trust me, the GMP developers understand the sources.

  ALSO the x64 assembly versions of these codes also does not always set
  all 4 values of pre[4] and this has lead to incorrect results when using
  the exported function mpn_mod_1().

You hypothesise things here.  And you're wrong.

I benevolent reading of your claims here is that things will be bad if
you use one variant of the internal _cps function with another variant
of the corresponding internal mod function.  If that's what you're
trying to say, then you're right.  GMP is not edit proof, local user
edits might break it in all sorts of ways,

But if you actually claim that an unedited GMP has a bug here, please
construct a test case which uses documented interfaces, and which
demonstrates the claimed bug.

  I do not understand these functions enough

Shouting from the top of your lungs about a bug which is just the result
of reading the sources, without allowing yourself time to understand the
logic fully, is somewhat unfair.

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

Re: Valgrind reports use of uninitialised value for __gmpz_powm_sec on i686 host

[Torbjörn Granlund]

Trevor Spiteri  writes:

  Valgrind is reporting the use of uninitialised value(s) in
  __gmpz_powm_sec for i686 host, though I found no similar issue for
  x86_64 host. This issue started in 6.3.0, and was not there for 6.2.1.

I tried this, and it looks like a valgrind bug rather than a GMP bug.

I inserted a print of the single-limb result in mpz/powm_sec.c, just
after the call to mpn_powm_sec.  The result is 9 as expected, but
valgrind claims that 9 is not initialised.

Quite extraordinary that the result can be correct while valgrind says
nobody generated any result.

I also wrote well-defined garbage to that same location before the
mpn_sec_powm call.  That proves that the 9 just didn't happen to be
there, but that mpn_sec_powm wrote it there.  Still valgrind thinks the
location is not well-defined.

Possibly, valgrind tracks something which it thinks is not well-defined,
but that the error becomes delayed?

(I cannot reproduce this for a 64-bit build.)


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

Re: Outdated libtool creates trouble on macOS

[Torbjörn Granlund]

Marc Glisse  writes:

  Do you think we could increase AC_PREREQ to 2.70 (or even 2.71), which
  would allow a couple more cleanups? I don't think we want to support
  users rerunning autoconf with an older version than the one we use to
  generate the tarballs.

Sure.  Being compatible with older versions than what we use seems quite
unnecessary.

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

Re: Outdated libtool creates trouble on macOS

[Torbjörn Granlund]

Marc Glisse  writes:

  It looks recent enough that the piece of code causing trouble on macOS
  has been modified. I think we can go with that, we can always upgrade
  again later if needed.

We have been using the default shell.gmplib.org autotools tools for a
week now, for generating the public snapshots and the nightbuild
snapshots.  Things look good.

Thanks for this GMP contribution!

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

Re: Side-channel leakage in the mpz_powm_sec interface

[Torbjörn Granlund]

  > Therefore,
  > additional layers of side-channel obfuscation is needed, like standard
  > RSA message blinding, mod argument blinding, exponent blinding.

  sure, but I think that should be performed by upper level code, as how
  you do blinding depends on the algorithm and operation you're performing

I don't think it would be mathematically possible to do any of these
blinding operations in mpn_sec_powm.  Not unless you successfully factor
the modulus operand locally, but that might be a tad bit expensive, in
particular if the factoring is to be side channel silent. :-)

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

Re: Side-channel leakage in the mpz_powm_sec interface

[Torbjörn Granlund]

Niels Möller  writes:

  I know you've done more work on that recently, while I have no idea how
  "mod argument blinding" works...

A random ring extension.  Yes, mod argument invariance will still be
there, unless one changes extension for each multiply/squaring inside
the modexp loop, but an attacker cannot cause unlimited invariance.

  ... if GMP can provide advice and/or tools to do it, that's nice of
  course.

Educating people is good, and here we in particular want to make sure
nobody thinks GMP's "sec" functions are the silver bullet.

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

Re: Side-channel leakage in the mpz_powm_sec interface

[Torbjörn Granlund]

marco.bodr...@tutanota.com writes:

  This sounds not too complex to do. Even if, as usual, C code is prone to 
compiler optimizations...
  I think this is a good idea.

The concern for compilers messing up secure code is very valid.  An
example is that clang makes our mpn_sec_tabselect useless by inserting a
conditional branch instead of our mask; the generated code actually
adheres to the volatile declaration, but is utterly useless for its
intended purpose.

It is a pity that we cannot write certain sensitive code in C.  A C
language extension would be welcome, perhaps some kind of "strict
volatile", or an annotated conditional requiring that no branch or other
conditional execution is generated as a result of it.

A side note: CPU conditional move and conditional select instructions
are usually poorly defined.  Is there a true dependency on all inputs,
or only on the actually chosen input?  I've used my contacts at CPU
manufacturers to address this concern, but never seen any real interest.

Back to the main subject:

We should probably exclude certain sec_ functions when not all sensitive
functions are provided in asm, and thereby as a result of
--disable-assembly?  We should in essence not provide C versions of
e.g., mpn_sec_tabselect.

And we should perhaps provide a normalisation asm function for what
Niels proposes here?

I think we should document mpz_powm_sec as somewhat problematic, but
also fix it along the lines of Niels' proposal.  The right GMP level for
side-channel sensitive application is clearly mpn; we should say that.

We might want to be more cautions about what we promise also for mpn.
It is not necessarily sufficient to do what we do here, i.e. perform the
exact same instruction sequence an data reference sequence for any two
n-bit operand sets.  Careful power measurements typically can
fingerprint either or both operands of a bignum multiply.  Therefore,
additional layers of side-channel obfuscation is needed, like standard
RSA message blinding, mod argument blinding, exponent blinding.

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

Re: [cfarm-announces] New Arm Morello SoC machine: cfarm240

[Torbjörn Granlund]

Marc Glisse  writes:

  There is, it is called (u)intptr_t, the standard name for an integer
  type that can hold a pointer.

Right!

I only naively checked intmax_t, assuming max would mean max. :-)


There seem to be a problem with arithmetic on uintptr_t, though.  The
compiler generates a plain "mul" instruction for multiplying two of
these fat integers, which is not quite right.  Admittedly, the compiler
outputs an arm (no pun intended) long warning message:

foo.c:7:12: warning: binary expression on capability types 'uintptr_t' (aka 
'unsigned __intcap') and 'uintptr_t'; it is not clear which should be used as 
the source of provenance; currently provenance is inherited from the left-hand 
side [-Wcheri-provenance]

Not sure what that means, though.  But it probably means "I generate
garbage code from your sources, sorry about that".


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

Re: [cfarm-announces] New Arm Morello SoC machine: cfarm240

[Torbjörn Granlund]

Marc Glisse  writes:

  Hmm, but with that proposed patch, configure later fails with

  checking size of void *... 16
  checking size of unsigned short... 2
  checking size of unsigned... 4
  checking size of unsigned long... 8
  checking size of mp_limb_t... 8
  configure: error: Oops, mp_limb_t is 64 bits, but the assembler code
  in this configuration expects 32 bits.

  configure --disable-assembly does allow to build the library, but then
  quite a few tests fail with "bus error": t-toom6h, t-toom8h,
  t-toom8-sqr, t-div, t-mulmod_bnm1, ..., t-sizeinbase.

  So more work is needed on the GMP side :-(

Note the size of pointers, 16 bytes.  There is no integer type mathing
that, so if code tries to cast a pointer through some integer type for,
say, aligning it, things will break.

Apparently, this is some sort of research platform.  I have no idea how
hard a GMP port might be,

I've given up trying to make GMP run well on Arm since it is too hard
and too expensive to find hardware for 90% of the Arm cores.  There are
lots of "Fruit Pi" boards, but they all use a small set of processor
cores (essentially A55, A72, and A73) or cost and arm (no pun intended)
and a leg.

But GMP at least runs on most Arm cores, as long as they follow the
standard ABI.

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

Re: Outdated libtool creates trouble on macOS

[Torbjörn Granlund]

Marc Glisse  writes:

  If I run .bootstrap now on shell (freebsd 12.2) after removing
  /home/gmp/usr/bin from my PATH so I get the tools from /usr/local/bin,
  I have a number of errors, but I think that's just because libtool is
  not installed.

It is now.

  Torbjörn, I think we could start generating the GMP tarballs with newer
  autotools at this point (the newer the better, probably).

Yes, let's do that!

I very much appreciate this effort, BTW!

Are the autotools and (just installed) libtool on shell adequate?  They
are the most recent pre-packaged with FreeBSD.

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

Re: Possibly an annoying test in configure

[Torbjörn Granlund]

Dennis Clarke  writes:

  Pretty sure that should be "int main (void) { return 0; } ".

Surely that is not how the implicit main() declaration looks?  A new
compiler warning is warranted.  So add (int argc, const char **argv)!
Oops, unused parameters, darn.  We need to make a fake dependency on
these unused parameters...

Alternatively, we could develop GMP.

  How hard can it be to patch that in the configure.ac autotools stuff?

It is pointless to work around compiler idiosyncrasies without a plan,
and without clear indications that it solves a real problem.

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

Re: Possibly an annoying test in configure

[Torbjörn Granlund]

Niels Möller  writes:

  I would *not* want to support -Werror as something to be used in general
  by users, with arbitrary compiler versions, compile flag tweaks, etc.

Indeed.

There is a fashion among compiler maintainers to accept an ever
decreasing subset of C, making any effort at producing accepted code a
wild goose chase.

I think warnings have gone from useful to mostly annoying, and that's
already without "-Werror"-like flags.

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

Re: GMP Error Reporting

[Torbjörn Granlund]

"posihydr"  writes:

  The problem occurs when the formula in GMP and < Picture 1 is used
  to calculate PI, calculate the constant C to the 3/2 power, output
  "Floating point exception" after running the program, and use GDB
  debugging to find that the program receives signal SIGFPE when calling
  mpf_sqrt function.

This is a forum for reporting GMP bugs, not a place to get help with
debugging one's own programs.

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

Re: Outdated libtool creates trouble on macOS

[Torbjörn Granlund]

FX Coudert  writes:

  PS: second patchlet, to deal with these two macros:

  > warning: The macro `AC_HEADER_STDC' is obsolete.
  > warning: The macro `AC_HEADER_TIME' is obsolete.

If you, Marc, can take a look at those proposed changes, I think they
should be applied to the head gmp repo, not the gmp-6.3 one.

Currently and for another week, the nightly builds whack gmp-6.3, then
we will switch to the head repo.  That will then be a broad test of any
configure changes.

(After that, we can consider merging the changes to gmp-6.3 for inclusion
in a 6.3.1.)

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

Re: Outdated libtool creates trouble on macOS

[Torbjörn Granlund]

FX Coudert  writes:

  One other question: our Linux builder, which is running from Github Actions, 
fails to download from gmplib.org
  I thought only the mercurial repo was firewalled, is that not the case?

Github is firewalled off in its entirety.  The firewall cannot inspect
packets to make more fine-grained decisions.  Encryption prevents that.

I have no grudge against github, but also don't have time for people or
organisations who create interruptions.  Implementing some access
restrictions in the web server (i.e., not in the firewall) is not worth
the added complexity.

(There is not company or organisations behind GMP.  I fund the
infrastructure from my salary, and I and three other volunteers keep
developing it.)


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

Re: bug

[Torbjörn Granlund]

赵世忠  writes:

  The last digit should be '8', but mpf_get_str outputs '7'.

"Should be"?

Please read the GMP documentation, and if you still think there is a
bug, please write a bug report where you motivate what you think is not
right with GMP's current behaviour.

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

Re: integer overflow in mini-gmp due to integer promotion

[Torbjörn Granlund]

Vincent Lefevre  writes:

  The goal is to try to find bugs in MPFR. With limbs of small size,
  particular cases (such as some limbs being 0 or -1) could occur
  more often.

Have you looked at GMP's asl.h?  It allows for tiny limbs, but GMP needs
work before any small limbs size fully works.

The idea with that is exactly what you write above.

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

[Torbjörn Granlund]

philliprusso  writes:

  Any insight on why undefined reference to lexar_line when making gcc-11?

This mailing list is intended exclusively for GMP bug reports.  Other
software projects have their own bug reporting mechanisms.

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

Re: Bugs with Ventura system with Macos

[Torbjörn Granlund]

Michel Collin  writes:

  I used, for a long time C with GMP, on my Mac ( cryptography calculs
  ), and suddenly the applications I had made, who works very well on
  Monterey system, doesn’t work anymore on Ventura System.
  The compilation is OK but, for example, if I calculate a number with
  C-GMP, « rop » and when I try to calculate mpz_nextprime ( p, rop) the
  answer is « segmentation fault : 11 » .
  With my ancient Montereys System, everything was OK.
  My computer is a M1, a new one.
  Could you ask Apple about that ans had you news about these problems.

You will have more luck with a GMP snapshot; the last release does not
support arm under macos.

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

Re: mpz_probab_prime_p crashes?

[Torbjörn Granlund]

Philip Riebold  writes:

  The test program below, pt3.c is the simplest I could produce to demonstrate
  the problem.

If that simple program would trigger a genuine GMP bug, that would be
astonishing indeed.

I have no idea why your computer gets a segfault.  Perhaps the malloc
implementation is completely broken?  Perhaps you hit bad RAM cells?

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

Re: make check failed on debian old system using arm complier

[Torbjörn Granlund]

The reporter cross-compiles GMP, then apparently tries to execute Arm
binaries on x86_64, unsurprisingly with limityed success.

Not a GMP bug.  The gmp-bugs list is not the right place for discussing
possible remedies (such as emulation).

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

Re: Miscompilation on arm64 with GCC LTO

[Torbjörn Granlund]

Have you tried using a recent GMP snapshot?
If not, please do.

https://gmplib.org/download/snapshot/

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

Re: Miscompilation on arm64 with GCC LTO

[Torbjörn Granlund]

Arsen Arsenović  writes:

  I'm forwarding a message from Sam James, a fellow Gentoo developer, as
  he seems to be having some mail delivery issues.

He surely has some patience issues.

Please let Sam know about mailing list moderation and perhaps about that
the earth is round and thus have different time zones; sending three
copies of the same message within a couple of hours is not appreciated.


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

Re: Whitespace after minus sign in mpz_set_str

[Torbjörn Granlund]

Marc Glisse  writes:

  This was also discussed in
  https://gmplib.org/list-archives/gmp-bugs/2013-December/003257.html

  I don't know if anything changed...

Probably not.  This spacey "feature" is not expected to be widely used.

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

Re: 6.2.1 Bus error

[Torbjörn Granlund]

You know, we might do with some more detail on what your experience with
GMP might be.  Such as the platform, how you built GMP, what program you
ran which triggered a "Bus error".

If something is wrong with, say, a car, do you let the car repair shop
know anything about what the problem is, which car is afflicted, and how
to reproduce the problem?  Or do you just say "a car does not work" and
hope they will locate the car and look for some malfunction and then
repair it?

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

Re: Error related to GCC LTO optimization for GMP at ARM AArch64

[Torbjörn Granlund]

Some One  writes:

  Dear GMP devs,

  As I reported the same issue to gentoo bugzilla and retried to reproduce
  for them with all logs attached,
  I've found out that iproute2 magically started to compile OK.

  However, there were other sources whose compilation was broken.

Unfortunately, I don't have time to isolate this problem.

I long shot would be to disable assembly in the GMP build (by means of
.../configure --disable-assembly).  The arm64 asm in GMP 6.2.1 followed
the ABI docs of the time, which turned out to cause problems at least in
some environments.

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

Re: Error related to GCC LTO optimization for GMP at ARM AArch64

[Torbjörn Granlund]

Some One  writes:

  I've found the problem related to GCC LTO optimization for GMP for ARM
  aarch64
  under QEMU with ARM Neoverse-N1 virt-4.2 (Oracle Cloud) and ARM virt-7.2
  (Apple M1)
  both running the latest Gentoo with gmp-6.2.1-r5 compiled by both
  gcc version 11.3.1 20221209 and gcc version 12.2.1 20221231.

  To reproduce:
  1. Compile GMP with LTO optimization -- compiles OK
  2. Try to compile iproute2-6.1.0 or cmake-3.25.1 -- compilation hangs
  during the process

  Disabling LTO optimization for GMP solves the problem.

I would not expect any GMP developer to attempt to reproduce this
problem.  You're using a patched GMP ("-r5") in an environment which
would be very close to impossible to reproduce!

You need to isolate this problem and only then report it to the package
maintainer of the buggy program.

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

Re: Test Failures on m1 MacBook Ventura: stack-overflow on address

[Torbjörn Granlund]

Pasta Pasta  writes:

  Process 46677 launched:
  '/Users/user/Development/dash/src/test/test_dash' (arm64)
  Running 1 test case...
  Process 46677 stopped
  * thread #1, name = 'd-test', queue = 'com.apple.main-thread', stop
  reason = EXC_BAD_ACCESS (code=1, address=0x16fe0)
  frame #0: 0x000100cd9e00 test_dash`__gmpn_sub_n + 120
  test_dash`:
  ->  0x100cd9e00 <+120>: ldpx4, x5, [x1, #0x10]
  0x100cd9e04 <+124>: ldpx8, x9, [x2, #0x10]
  0x100cd9e08 <+128>: sbcs   x12, x6, x10
  0x100cd9e0c <+132>: sbcs   x13, x7, x11
  Target 0: (test_dash) stopped.
  (lldb) bt
  * thread #1, name = 'd-test', queue = 'com.apple.main-thread', stop
  reason = EXC_BAD_ACCESS (code=1, address=0x16fe0)
* frame #0: 0x000100cd9e00 test_dash`__gmpn_sub_n + 120
  frame #1: 0x000100cd84e4 test_dash`fp_subc_low + 24
  frame #2: 0x000100cd9970 test_dash`fp3_sqrn_low + 220
  ```

  This pointed us to GMP as being the issue. We established the
  following procedure for testing GMP:

Well, somebody calls the GMP low-level function mpn_sub_n, and that
function crashes.  I would say that this is not unlikely that the
calling function is buggy.

But there was a problem with GMP 6.2.1 wrt MacOS, which is that register
18 is reserved, but GMP's assembler uses it.  We fixed that in the GMP
repo long ago,  You might want to try a GMP snapshot.

  ```
  wget https://gmplib.org/download/gmp/gmp-6.2.1.tar.bz2
  tar xf gmp-6.2.1.tar.bz2
  cd gmp-6.2.1
  ./configure
  make
  make check

Works on my M1 running Ventura.  I might have a better compiler (Apple
clang version 13.0.0).  There has been major problems with compiler bugs
on Apple M1.

-- 
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.2.1 core2 x86_64 assembler error "operands invalid for `movq'"

[Torbjörn Granlund]

I seem to have misread the report.  I thought the

  movq mem,xmm

instructions were the problem.

I pushed a fix to the repo.  Please try 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.2.1 core2 x86_64 assembler error "operands invalid for `movq'"

[Torbjörn Granlund]

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

  So would be useful to try if replacement movq --> movd

  (i) solves the problem on (older) macos, and

  (ii) produces identical object code on systems with more up-to-date
  assemblers.

Note that the movq instances the old assembler complains about here read
from memory.  Using movd might yield surprises there.

-- 
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.2.1 core2 x86_64 assembler error "operands invalid for `movq'"

[Torbjörn Granlund]

Simon Sobisch  writes:

  That is an old MacBook with the most current "developer command line
  tools" that were available (from 2013/2014 if I remember correctly).

I am afraid obsolete systems might get less developer attention...

  Sigh. Sadly I don't know enough about assembly to patch it myself :-(
  But I can test because that machine is now available to me (it was
  passed to me instead of being thrown away; I did a reset, installed
  the most current software that was supported there and now try to get
  some programs running via terminal).

I know asm well, but alas, I don't know the quirks of these old tools.

If you're really eager to get these files to work, here is a cumbersome
method:

Build things on a current system.

Use objdump -dw (or otool under macos) to see the encoding for the
trouble instructions.

Replace the movq instructions with .byte sequences.  Re-compile on the
current system to make sure the objdump output stays the same.

Go back to the obsolete system and compile happily there.

-- 
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.2.1 core2 x86_64 assembler error "operands invalid for `movq'"

[Torbjörn Granlund]

Simon Sobisch  writes:

  config.status: linking ../mpn/x86_64/core2/popcount.asm to mpn/popcount.asm
  config.status: linking ../mpn/x86_64/core2/hamdist.asm to mpn/hamdist.asm

  tmp-popcount.s:181:suffix or operands invalid for `movq'
  tmp-hamdist.s:206:suffix or operands invalid for `movq'

Is this on a recent version of macos with current versions gcc+binutils
installed?  Or is either old variants?

This is not the same bug as we worked around for register-to-register
copying on x86-32 some years ago.  It is not cleer what syntax this
assembler might accept, and which also gives the right instruction (here
and on non-prolematic hosts).

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

Re: use of emphasize for math in the HTML GMP manual

[Torbjörn Granlund]

Vincent Lefevre  writes:

  GMP currently uses emphasize for math in the HTML GMP manual,
  via @math{...} (and MPFR has copied to it). For instance, for
  mpz_mul_2exp, one has "Set rop to op1 times 2 raised to op2." where
  the whole "op1 times 2 raised to op2" is emphasized, i.e. typically
  rendered in italics (or with a different color with lynx).

  While I agree that variables should be in italics (@var ensures
  that), having full text about math in italics seems wrong.

Our rendering of maths really ought to be much better.  I started a
rewrite of all maths formulas some years ago, but never finished it.

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

Re: Minor mistakes in the manual

[Torbjörn Granlund]

Thank you!

I have applied most of your change suggestions!

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

Re: clang warning about mini-gmp.c when used in Emacs

[Torbjörn Granlund]

"Marco Bodrato"  writes:

  gmp$ ./configure CC="gcc -Wall -Werror"
  [...]
  configure: error: could not find a working compiler, see config.log for
  details

  Yes, you are right... a too fussy compiler is not considered a working
  compiler by the "configure" script :-)

The language accepted by -Wall -Werror ain't C.  Unfortunately, GMP and
its configure snippets are written in C.

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

Re: 2 minor issues on Windows

[Torbjörn Granlund]

  There is some sort of sick competition between certain compilers to have
  the most warnings for valid C.  I don't think we should play their game,
  and as a result obfuscate the GMP sources.

Incidantally, arithmetic on unsigned types is well-defined.  Unlike that
of signed types.

Should not these compilers warn about *every* arithmetic operation on
signed integers?  Certainly, it should warn about signed negation,
unless it can prove the negated value is not INT_MIN, as -INT_MIN is
undefined in two's complement representation...

int
foo (int a, int b)
{
  return a + b - 1;
}

$ clank foo.c
warning: signed addition might overflow and yield undefined results
warning: signed subtraction might overflow and yield undefined results

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

Re: 2 minor issues on Windows

[Torbjörn Granlund]

Marco Bodrato  writes:

  -  *__gmp_rp = (- *__gmp_up) & GMP_NUMB_MASK;
  +  *__gmp_rp = (1 + ~ *__gmp_up) & GMP_NUMB_MASK;

Let's please not do this.

There is some sort of sick competition between certain compilers to have
the most warnings for valid C.  I don't think we should play their game,
and as a result obfuscate the GMP sources.

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

Re: mail archives are lost

[Torbjörn Granlund]

Yes, the archiving function is not yet back.  I will fix that as soon as
I can find the time.

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

Re: Errors making GMP621 on SCO Openserver 6.

[Torbjörn Granlund]

Marco Bodrato  writes:

  ==> /tmp/config.guess.log <==
  ./config.guess: syntax error at line 284: `(' unexpected

Perhaps the $(command ...) syntax is not known by the old SCO shell?
Really old /bin/sh only had `command ...`.

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

[ADMIN] GMP mailing list

[Torbjörn Granlund]

The GMP mailing lists have been down for several months, but I am now
working on resuming their operation.

If you get this message, chances are that things now work again.

The backgound is that a security update to the (FreeBSD) virtual server
broke the mailing list software (mailman).  I usually update manually
applications from FreeBSD's posts source tree, but that did not work
with the obsolete FreeBSD version which the server ran.  Therefore, I
installed a precompiled mailman update, but that did not work with the
MTA software (poatfix).  A mess, and I did not have time to try to fix
it until now.

The fix was a complete reinstall of the server.

-- 
Torbjörn
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Fwd: math/gmp FreeBSD 12.2 Ports build failure on sparc64

[Torbjörn Granlund]

I took the trouble of installing FreeBSD under qemu.  I think I
understand the problem:

sparc64-fbsd$ gcc -v
Using built-in specs.
Target: sparc64-undermydesk-freebsd
Configured with: FreeBSD/sparc64 system compiler
Thread model: posix
gcc version 4.2.1 20070831 patched [FreeBSD]
  

sparc64-fbsd$ as -v
GNU assembler version 2.17.50 [FreeBSD] 2007-07-03 (sparc64-unknown-freebsd) 
using BFD version 2.17.50 [FreeBSD] 2007-07-03


I've highlighted the problem with .  Yes, the provided toolchain is
hopelessly outdated.

I do not intend to spend more time on implementing workarounds for
shortcomings of a 14 year toolchain on a dead platform.  Sorry.

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

Re: Fwd: math/gmp FreeBSD 12.2 Ports build failure on sparc64

[Torbjörn Granlund]

Alex Dupre  writes:

  tmp-gcd_11.s: Assembler messages:
  tmp-gcd_11.s:210: Error: Illegal operands
  tmp-gcd_11.s:211: Error: Illegal operands
  tmp-gcd_11.s:212: Error: Illegal operands

  The m4-generated assembly codes above (w/ w/out PIC) differ in these lines:

  root@freebsd12:/usr/ports/math/gmp/work/gmp-6.2.1/mpn # diff 
tmp-gcd_11.s.noPIC tmp-gcd_11.s
  206,209c206,212
  <   sethi   %h44(ctz_table), %o5
  <   or  %o5, %m44(ctz_table), %o5
  <   sllx%o5, 12, %o5
  <   or  %o5, %l44(ctz_table), %o5
  ---
  >   rd  %pc, %o5
  >   sethi   %hi(_GLOBAL_OFFSET_TABLE_+4), %g4
  >   add %g4, %lo(_GLOBAL_OFFSET_TABLE_+8), %g4
  >   add %o5, %g4, %g4
  >   sethi   %gdop_hix22(ctz_table), %o5
  >   xor %o5, %gdop_lox10(ctz_table), %o5
  >   ldx [%g4 + %o5], %o5, %gdop(ctz_table)

I don't have any sparc64-freebsd system to run tests on.

Which lines cause these syntax errors?

What syntax for pic data references is accepted by the assembler on
FreeBSD?

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

Re: macOS version detection broken in configure

[Torbjörn Granlund]

Marc Glisse  writes:

  From a quick look at the mailing list and the git repository, it seems
  to have been entirely unmaintained for more than 2 years now :-(

https://www.gnu.org/software/libtool/

"Libtool is currently looking for a maintainer."

-- 
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.2.1 Aborting when running tuneup program in one.cold()

[Torbjörn Granlund]

Simon Sobisch  writes:

  Am 20.10.2021 um 16:19 schrieb Torbjörn Granlund:
  > When tuneup cannot measure things accurately, it bails out.

  That's interesting. Is there any thing I can do to help tuneup measure
  things accurately?

Make sure your system is idle except for the tuneup process.

  Can you please add that important information (abort of the program is
  no bug, just use the non-optimized version) to the documentation
 https://gmplib.org/manual/Performance-optimization
  ideally together with the answer to the related questions
  "What should -f NNN" relate to?" and "Should I manually build the
  average" (if this isn't an effect of "not accurately measured")?

If we find time, perhaps.

Running the tuneup program and make use of its results is mainly
intended for GMP devs.

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

Re: Configuration on IceLake

[Torbjörn Granlund]

Arturo Fernandez  writes:

  Just for clarification, I'm no longer seeing the 'm4-ccas: Permission
  denied' error. I started on a fresh system (cloud-based) running
  CentOS8.4, unpacked gmp-6.2.99-20211010014524 and simply run
  ./configure, which returned:
  Version: GNU MP 6.2.99
  Host type: nehalem-pc-linux-gnu

What evidence do you have for this system being an Ice Lake?

And even if it is, you're presumably using a virtualised system (being
in "the cloud") and virtualisers are sometimes configured to pretend the
CPU is of a different type than they actually are.

  This was my original problem, which is that configure is not picking
  up IceLake and assigning nehalem to the host type. I'm not sure if the
  GMPLIB Team is testing these new patches on IceLake HW but it might be
  worth considering before releasing a stable version.

Sneer will not inspire us helping you.

It might be the case that GMP doesn't recognise every family/model which
Intel uses for Ice lake.  If you show us that the cpuid instruction
returns for you system, then we can tell where the problem lies.

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

Re: Configuration on IceLake

[Torbjörn Granlund]

Arturo Fernandez  writes:

  Hello. I was finally able to get back and work on this
  configuration. Yesterday evening I downloaded the latest version
  (gmp-6.2.99-20211010014524) but it is still unable to recognize
  IceLake. The command configure is returning:
  Version: GNU MP 6.2.99
  Host type: nehalem-pc-linux-gnu
  ABI: 64
  Install prefix: /usr
  Compiler: gcc
  Static libraries: yes
  Shared libraries: yes

It is hard to provide support when the context is lost due do months
long delays.

I am sorry you keep seeing problems with executing exeutable GMP scripts
on several systems.  It is an unusual problem, and not something we can
fix on the GMP side.  We cannot make these scripts "more exeutable".

As I believe I told you, the few times we have had this reported, it has
been caused by ether a poorly chosen umask during tar file extraction,
or filesystem policy against executables.  Both these problems are with
your setup, not with GMP.

You need to debug this locally, if needed with some local help.

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

Re: See attached test results.

[Torbjörn Granlund]

Did you notice this part:

  tests are not linked to the newly compiled library
local version is: 6.2.1
linked version is: 6.2.0

That's what's wrong.  GMP's tests then exits to avoid generating
spurious test results.

Why it happens?  Well, some sort of linking path of your system
overrides the local lub.  There is nothing the GMP devs can do to resolv
that, 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: Segmentation fault with mpz_inp_raw on gcc45

[Torbjörn Granlund]

Vincent Lefevre  writes:

  In mpz/inp_raw.c, I think that abs_csize*8 yields an integer overflow
  on large sizes.

Indeed.

Going from byte count to bit count to limb count is non-trivial without
risking overflow, even if the end result will typically be smaller than
the incoming byte count (assuming we're not using gmp/asl.h with tiny
limbs...).

Below is a fix which works unless GMP_NUMB_BITS mod 8 != 0.  I think we
have this problem in more places in the library.  I spotted
mpz/import.c, but there might be more.

Perhaps, instead of the change below which triggers an errir in the
allocation statement later in the program flow, we could make an
explicit check of the byte count vs the max supported sizes, and
generate the overflow error locally.


*** /tmp/extdiff.b8_0au15/gmp.09a7d62c4438/mpz/inp_raw.cTue Sep 14 
19:05:51 2021
--- /home/tege/prec/gmp/mpz/inp_raw.c   Thu Sep 16 22:35:46 2021
***
*** 90,94 
  
/* round up to a multiple of limbs */
!   abs_xsize = BITS_TO_LIMBS (abs_csize*8);
  
if (abs_xsize != 0)
--- 90,99 
  
/* round up to a multiple of limbs */
!   if (GMP_NUMB_BITS % 8 != 0)
! abs_xsize = BITS_TO_LIMBS (abs_csize*8); /* FIXME: may overflow */
!   else
! abs_xsize = (abs_csize + (GMP_NUMB_BITS / 8) - 1) / (GMP_NUMB_BITS / 8);
! 
!   printf ("XXX %08lx %08lx\n", csize, abs_xsize);
  
if (abs_xsize != 0)


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

Re: Segmentation fault with mpz_inp_raw on gcc45

[Torbjörn Granlund]

I tried to reproduce this on several systems.  I failed; mpz_inp_raw
returns 0 for me as it should.

I cannot be sure I got test_dummy2.save right.  I did include the line
that asked to be ignored.  Should I have ignored it?  I added LF at each
appparent line end, including the ignore line.

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

Re: Segmentation fault with mpz_inp_raw on gcc45

[Torbjörn Granlund]

Paul Zimmermann  writes:

  I was thus expecting it to return 0 in case of an invalid file.

OK, so you deliberately sen d junk to mpz_inp_raw.  That is fine, but it
was not clear from your report.

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

Re: Segmentation fault with mpz_inp_raw on gcc45

[Torbjörn Granlund]

Paul Zimmermann  writes:

  $ cat test_dummy2.save
  -e

  # this is a comment line and should be ignored

You do understand that mpz_inp_raw expects a binary file with a size
field followed by that many byytes of data, don't you?

The file contents above make no sense.

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

Re: libgmp.a text relocation error on powerpc-*

[Torbjörn Granlund]

George Koehler  writes:

  This report is for GMP 6.2.1.  The powerpc32 asm in the static library
  libgmp.a contains a text relocation; this causes a linker error when I
  use LLD to link a program with libgmp.a.  I have no problem with the
  shared library.

  The fix is simple: delete the quotes on `PIC_ALWAYS' in m4-asm.def:

  --- mpn/asm-defs.m4.orig
  +++ mpn/asm-defs.m4
  @@ -1051,7 +1051,7 @@ dnl  Normally PIC is defined (or not) by libtool, but 
   dnl  systems which are always PIC.  PIC_ALWAYS established in config.m4
   dnl  identifies these for us.
   
  -ifelse(`PIC_ALWAYS',`yes',`define(`PIC')')
  +ifelse(PIC_ALWAYS,`yes',`define(`PIC')')
   
Oh, that's a dumb bug.

I am baffled how this error could have happened, as it should not have
solved the problem it was meant to solve.

Thanks for isolating and reporting this!

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

Re: Configuration on IceLake

[Torbjörn Granlund]

Arturo Fernandez  writes:

  Sorry for the late reply as things have been piling up. I have tried
  gmp-6.2.99-20210902195716 in different systems but it fails while
  building it. Here is an error:
  ../libtool: line 1766: ../mpn/m4-ccas: Permission denied

That error you need to debug locally.

The file m4-ccas in the snapshot has the execution bit set.  Prosumably
you have some strange umask value set, or a filesystem which does not
allow executables.

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

Re: Rounding error

[Torbjörn Granlund]

Paul Zimmermann  writes:

  Of course you can add say 100 guard bits, then the probability to get an
  incorrect rounding is about 2^-100...

You're joking, but this was sort-of my thinking when designing mpf!

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

Re: Configuration on IceLake

[Torbjörn Granlund]

Arturo Fernandez  writes:

  I wasn't expecting Nehalem so my guess is that it doesn't recognize
  IceLake and is assigning some default value.

We let all unknown "model" numbers mean nehalem.  This is so that both
unknown low-end cores and unknown high-end cores will at least work.

There have been plans to refine this by checking various features (such
as AVX) and from the result match the closest known microarch.  E.g. if
a "model" number appears which has all the features of, say, skylake,
assume skylake.

-- 
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.2.1 self-tests start failing with latest macOS Monterey beta

[Torbjörn Granlund]

Dominik Schloesser  writes:

  Since update to latest beta of upcoming macOS 12, `make check` fails with
  release gmp 6.2.1 (see attached log)

  I've retested with HEAD version gmp, and that runs without any error on
  this beta.

Perhaps this change is relevant:
  https://gmplib.org/repo/gmp/rev/5f32dbc41afc

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

Re: Crashes after upgrading to GMP 6.20+

[Torbjörn Granlund]

Michael Maroszek  writes:

  The code works flawlessly on the Boardwell architecture (and a lot more!).
  The issue arises only on the mentioned Celeron.

As I wrote before, GMP's fat mechanism knows of that processor.  So it
is not a simple oversight on our part which causes the problems you
observe.

There can be many explanations.

1. You ae using some sort of virtualiser, and running a fat binary in a
   guest.  That guest is told by the virtualiser that it has a CPU with
   instructions which are actually missing.

2. You have a compiler which by default generates instructions which are
   not supported by the actual processor.  (GMP makes sure not to enable
   such instructions for fat builds, but it doesn't know how to override
   all mechanisms which could control the compiler's defaults.)

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

Re: Crashes after upgrading to GMP 6.20+

[Torbjörn Granlund]

Michael Maroszek  writes:

  i am using an unpatched gmplib version and the problem was introduced with
  version 6.20 (still exists in 6.21). Reverting to 6.1.2 solves the problem.

There are no GMP versions 6.20 or 6.21.  Are these PHP releases, perhaps?

  The problem does not happen on all systems. Only a few users are affected,
  which use a specific NAS (and therefore CPU). Our app is running inside a
  docker container and there seems to be at least one related bug report on
  GitHub: https://github.com/home-assistant/core/issues/44538

  The affected CPU is: Intel Celeron J3455

A CPU model GMP knows of.  GMP matches it as goldmont.

  Unfortunately i don't have a full example app yet. It happens when using
  the GMP functions in PHP. If definitely required I would do the work and
  create a plain c app, but as far as i have seen the crash directly happens
  when using the gmp functions. (The crash always happens - it seems like the
  "fat" code doesn't detect the target system properly and uses an invalid
  optimization)

These are guesses.  I strongly suggest that you debug it.

Also, "crash" is is unnecessarily vague.

  #0Object "/usr/bin/foo", at 0x55e4ff7368d9, in __gmpz_set_str

  2021-04-01T12:29:38.2070642Z checking build system type...
  broadwell-pc-linux-gnu

If it is matched as broadwell-pc-linux-gnu, somebody is lying.  That's
hardly what the cpuid instruction on a J3455 returns.

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

Re: 68000 issue in longlong.h

[Torbjörn Granlund]

Thanks for your analysis, Niels!

I now agree that sticking an & in there is the right thing to do.

(I'm adding a test config for plain 68000 too; I thought we had one
already but that does not seem to be 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: AW: 68000 issue in longlong.h

[Torbjörn Granlund]

"se...@t-online.de"  writes:

  Can you explain why __umul_tmp1 should not be an "early-clobber output"?

Because it is not written to before we're done with the input.

(I wrote this code close to 30 years ago.  It is stll possible that it
is buggy, but it looks correct to me and it has been in use for a very
long time.  Sure, it is not much used today, as plain 68000 is not in
much use..)

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

Re: AW: 68000 issue in longlong.h

[Torbjörn Granlund]

gmp-bugs-ow...@gmplib.org writes:

  With his change the tests pass so I think the change is reasonable.

I disagree.  If I am right that the inline asm is correct, changing it
to avoid triggering a compiler bug is not a reasonable change.  But
perhaps I am wrong and the inline asm is buggy, but then somebody needs
to explain in what way it is buggy.

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

Re: 68000 issue in longlong.h

[Torbjörn Granlund]

"se...@t-online.de"  writes:

  Hello,
  I am compiling and testing libgmp for AmigaOS. Yes, I am crazy.
   
  I use
  Thanks to bebbo's gcc https://github.com/bebbo/amiga-gcc 
   I was quite successful. I had some 
  issues in the tests hovever.
  For instance t-conv, t-sqrt and t-sqrt_ui failed. The bugs disappeared when 
  I compiled without optimization and appeared when I used -O2, so I 
  suspected a compiler bug and reported that to the Amiga gcc6 maintainer. He 
  looked after the problem and found an issue inside libgmp's code.
   
  The bug is inside gmp's header longlong.h:1220, where asm for 68000 is 
  defined:
   
  wrong code:
  ...
  " | End inlined umul_ppmm" \
  : "=" (xh), "=" (xl), \
  "=d" (__umul_tmp1), "=" (__umul_tmp2) \
  : "%2" ((USItype)(a)), "d" ((USItype)(b))); \
   
  correction:
  ...
  " | End inlined umul_ppmm" \
  : "=" (xh), "=" (xl), \
  "=" (__umul_tmp1), "=" (__umul_tmp2) \<---  an & must be added 
  after the =
  : "%2" ((USItype)(a)), "d" ((USItype)(b))); \
   
The current code looks correct to me.  Please explain why you think it
is not correct.


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

Re: t-lucnum_ui segfaults

[Torbjörn Granlund]

Paul Dufresne  writes:

  make[4] : on entre dans le répertoire « 
/home/paul/gpc2/gcc-4.6.4/gmp-4.3.2/tests/mpz »

Are you seriously using GMP 4.3.2?  It is 11 years old!  Please use some
slightly less obsolete release.

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

Re: Warning when using gmp 64 bits in vcpkg

[Torbjörn Granlund]

Cristofer Martins  writes:

  The warning is as follows(MSVC) "warning C4146: unary minus operator
  applied to unsigned type, result still unsigned"
  Line 2240 inside gmp.h code "*__gmp_rp = (- *__gmp_up) & GMP_NUMB_MASK;"
  I hope its fixed since its create warnings for all files that includes gmp.h

No this is not "fixed" in GMP.  Negation is completely well-defined for
unsigned types.  If some compiler warns about negation, use a better
compiler, or else try to disable this bogus warning.

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

Re: memory leak huge number of digits mpz_mul,mpf_sqrt_ui

[Torbjörn Granlund]

Are you famiiar with valgrind?  It is a great tool for detecting memory
leaks.  I used it to oonfirm that GMP indeed does not leak for your test
cases.  (You seem to have forgotten to mention the system you used for
these experiments; I used an amd64 cpu running debian.)

Your analysis of what is a memory leak is incorrect.  You might need to
better understand the role of malloc/free (in the C library) and the
underlying system memory handling functions (sbrk/brk/mmap/munmap).  The
former do not necessarily give back its memory to the system.  That's
not a memory leak by normal definitions.  Or at least, an application
cannot affect this "leak".

Again: No GMP bug.

The GMP lists are not the right place for discussions about how malloc
interfaces to the kernel.  But I am sure there are great explanations
which you will be able to find on the Net.


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

Re: memory leak huge number of digits mpz_mul, mpf_sqrt_ui

[Torbjörn Granlund]

Your analysis is very likely incorrect.

You may cause the same "leak" without GMP.  Just malloc a set of large
chunks of different sizes.  Access them to make sure it is actually
there, then free them in some random order.  Often the free calls will
not have given back the memory to the system.  Still, that's no memory
leak in the sense you seem to suggest.


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

Re: small patch to suppress a warning

[Torbjörn Granlund]

I think there might be better places to discuss compiler warnings than
the gmp-bugs list.

I think most of us agree that compiler warnings for valid C code are
sometimes useful.  For example, valid warnings about unitialised
variables seem pretty uncontroversial.

But please continue the discussion on clang's warning chattiness
elsewhere...

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

Re: Arithmetic bug on ARM (STM 32 F4)

[Torbjörn Granlund]

  ttt =
  
3578942983869995381409279381784954092773488221200587338717407747084074518600438737913956360066709506626656635118978526559637095289631190671071178702312877654

  but ttt should be
  
5247183143879283565064056089869553515440215252945038779070795247972433237341511292686962488915110675351673985513318500576097977116134885013371639187873069514

  I give the code to reproduce the bug in attachment.

  GMP is built with the options:
  
CC=/home/titouan/Softs/gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux/gcc-arm-none-eabi-10-2020-q4-major/bin/arm-none-eabi-gcc
  ../configure CFLAGS="-nostartfiles --specs=nosys.specs -mcpu=cortex-m4"
  --host=arm-none-eabi --disable-assembly --prefix=YOUR_CHOICE

As you might guess, GMP's mod operation has been tested a lot during
GMP's 30 years of existence.  A completely fundamental bug like the one
you observe is of course still possible, but incredibly unlikely.

It is much more likely that the compiler you used for compiling GMP is
buggy.  That's indeed where you should start looking.

Unfortunatly, we cannot help.  We don't know what compiler you used, and
even if we did, we don't have access to it.


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

Re: Illegal instruction fix

[Torbjörn Granlund]

William Blanke  writes:

  At Chia, we are using GMP inside Python binary wheels. This means we
  compile GMP on one machine and then run this code on different machines,
  possibly with different CPUs.

  When GMP 6.2 was released, we encountered illegal instruction crashes on
  Intel CPUs older than Haswell. We traced this to the LZCNT instruction
  being run on these older CPUs even though fat binary was chosen on the post
  Haswell compile machine. Unfortunately, this still happens with GMP 6.2.1

  To fix this we have created the patch below. It chooses whether to use the
  LZCNT, MULX, and TZCNT instructions based on CPU support via runtime CPUID
  checks for LZCNT, BMI2, and BMI1 capabilities respectively.

  We would like to submit this for upstream inclusion in future versions of
  GMP. We hope that it helps and we thank you for all your efforts!

We don't do this type of runtime detection for single instructions, as
the choosing takes way more time than any basic old code sequence.

Now, it is somewhat surprising thet rep;bsr fails.  The rep should be
ignored for old processors.  OK, so maybe not.

Then the correct approach is to suppress that variant for fat builds
and fall back to the less-defined plain bsr.

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

Re: GMP website: old release (3.1.1) cannot be downloaded

[Torbjörn Granlund]

"Peter Jin"  writes:

  It appears that at least one of the old archived GMP releases (version
  3.1.1) cannot be downloaded from the GMP website. This is possibly due
  to bad permissions on the file (not readable by the web server?).

Or possibly due to an incorrect URL.  (I suggest that you use a browser
to explore the directory structure and then download the desired
obsolete release.)

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

Re: Problems compiling on HPE NonStop

[Torbjörn Granlund]

OK, I see a pretty garbled output from the configure run (which
incidentally seem to trigger some elementary limitations of the sed
command).  I also see an error message, which I understand comes from a
compiler which presumably is c99 compiant.

The error message makes little sense.  The function __gmpz_inp_str_nowhite
is declared in the included file gmp-impl.h.  If it ends up not being
declared, that must be due to the fact that we never ported GMP to
"nonstop", resulting in that gmp-impl.h does not detect that stdio.h was
included.

You need to debug the sed problem and see if you can generalise the
stdio.h detection mechanism of the include files.

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

Re: uint_least32_t is in stdint.h not in inttypes.h

[Torbjörn Granlund]

Vincent Lefevre  writes:

  So, including  if present should be sufficient, and
  this is what the above code does.

  That said, for C99 implementations, the #if tests would be useless,
  so that the above code is also designed for non-C99 implementations,
  which may have  and  with a behavior different
  from C99, i.e.  will not necessarily include 
  (but this also means that  will not necessarily have
  uint_least32_t).

The mainline gmp repository and the next major GMP release (7.0) will
require a C99 compiler.  I believe we have not fully determined which
C++ standard we will require (or, Marc, did we come to a conclusion?).
We will use C99 constructs and will gradually clean up code which
handles older environments.

In the meantime, GMP 6 will continue to support C89.  We actually
removed some accidental C99ism with the 6.2.1 release.

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

Re: with strict C99 the tests/mpz/convert.c needs #include

[Torbjörn Granlund]

Vincent Lefevre  writes:

  In the context of the call, the values will always be nonnegative
  so that this is OK, but there is a risk that some future developer
  might reuse this function in another context, where it would be
  incorrect on platforms with signed char (in particular, there is
  no warning in the comment).

Perhaps we could rename this function
note_that_this_funtion_is_called_str_casecmp_and_not_strcasecmp, to
avoid such looming disaster?  Or, to be more polite, perhaps
please_note_that_this_funtion_is_called_str_casecmp_and_not_strcasecmp?

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

Re: GMP Problem with % under C++

[Torbjörn Granlund]

Miki Hermann  writes:

  I am very well familiar with the % operator in %.

Swell.

  In the document, whose link you sent me, and which I have read before,
  it is mentioned that

  Function: mpz_class operator% (mpz_class a, mpz_class d)

  This means, that the % operator in GMP overloads the usual % operator
  in C++.

Correctamente.

  Just to recall you, for integer a and b, b > 0, the result of the
  modulus operator is an integer in the range 0..b-1. If a is negative,
  the result is equal to (k*b + a) % b for any positive integer k making
  the expression (k*b + a) positive. By definition for a >= 0 and b > 0,
  we have a = q*b + (a % b), where q is an integer called quotient.

Right, but that is irrelevant since % is not a mathematical modulus
operator.  Did you not just say you were "very well familiar" with it?

Did you *really* read the page Marc pointed you to.  This is all
mentioned there.  Please do read it and get on with your life.

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

Re: possible miscompilation on macOS Catalina 10.15.6

[Torbjörn Granlund]

Trevor Spiteri  writes:

  I maintain Rust language bindings to GMP and got a bug report from a
  user on macOS Catalina 10.15.6.  I do not know if this issue is caused
  by the particular system setup of the user or if it is more general, so
  I'm listing what information I have in case it is actually reproducible
  in a more general setting.

  The bindings compilation process compiles GMP using:

  ln -s path/to/extracted/gmp-6.2.0 gmp-src
  mkdir gmp-build
  cd gmp-build
  ../gmp-src/configure --enable-fat --disable-shared --with-pic
  make -j 8
  make -j 8 check

  The make check is failing and outputting this on standard error:

  ../../../gmp-src/test-driver: line 107: 4825 Segmentation fault: 11 "$@"
  > $log_file 2>&1
  make[5]: *** [test-suite.log] Error 1
  make[4]: *** [check-TESTS] Error 2
  make[3]: *** [check-am] Error 2
  make[2]: *** [check-recursive] Error 1
  make[1]: *** [check-recursive] Error 1
  make: *** [check] Error 2

  I don't have standard output, so I don't know which test actually failed.

  This is all the information I got; sorry if it is incomplete. (The
  user's issue was solved by using their already installed homebrew?
  libraries instead of compiling GMP anew.)

OK, so *some* compiler compiled GMP with and *some* GMP test program
reported a segfault.  I will right away start the natural deduction over
all possible instances of compilers and GMP test cases. Oh wait, I need
to consider all possible CPUs and relevant environment variables as
well.


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

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Torbjörn Granlund]

Andreas Buff  writes:

  thanks to your help, its building fine now without --disable-assembly,  
  but it crashes using it.

  I am totally not into ASM, so forgive unqualified report(s).

  Here is the backtrace:

  * thread #8, queue = 'PEPAsyncSession.queue', stop reason =  
  EXC_BAD_ACCESS (code=2, address=0x16fbcc000)
     * frame #0: 0x0001019baf58 PEPObjCAdapterFramework`__gmpn_add_n + 144
       frame #1: 0x0001019babe4 PEPObjCAdapterFramework`__gmpn_add + 68
       frame #2: 0x0001019e756c  
  PEPObjCAdapterFramework`__gmpn_toom2_sqr + 1020
       frame #3: 0x0001019c8030 PEPObjCAdapterFramework`__gmpn_sqr + 144
       frame #4: 0x0001019fe838 PEPObjCAdapterFramework`__gmpn_powm + 3416
       frame #5: 0x0001019b5678 PEPObjCAdapterFramework`__gmpz_powm + 2432

  Let me know if and how to provide more useful information if needed.

Your report is scarce of detail.  Perhaps there is a bug in your
program?

Another possibility is that GMP does not work right on Ios.  Since that
is a closed platform where developers need to pay Apple for programming,
you cannot excpect any effort from the GMP team with regards to
development or testing of GMP for Ios.

If somebody who pays the Apple programmer tax is willing to help you
debug your crash, we will certainly look at whatever GMP change might be
needed.

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

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Torbjörn Granlund]

Marco Bodrato  writes:

  Look for a filename starting with gmp-6.2.0-202010...

  Then please follow up here!

I changed how snapshots are managed.

1. There are now subdirs for each release series, plus "gmp-next".  The
   latter is made from the bleeding edge repo.

2. We have had an idea of an "active" repo, which is the same as the
   autobuilds use.  Now, both that active repo and the bleeding edge
   repo will have snapshots manufactured once per day.

I've long planned to change the snapshot mechanism even more:

3. Make snapshots just after checkins and only after checkins which pass
some tests.  If n checkins are made in a day, n snapshots are made,
where n might be 0.

4. Do that for all GMP repos.


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

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Torbjörn Granlund]

Andreas Buff  writes:

  Latest snapshot is from may though

Not quite.  Look better.

There is one made every day.

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

Re: COFF_TYPE on x86_64

[Torbjörn Granlund]

Jeremy Drake  writes:

  I anchored the link to a particular line:

My bad, I didn't see that.

  >   Strangely, the fix for this was only applied to x86, and not x86_64.  This
  >   patch applies the fix to x86_64.
  >
  > What *fix* are you talking about?

  https://gmplib.org/repo/gmp-6.2/rev/0a17b90462e6

You have to forgive me for not guessing that.  My memory of 17 year old
patches are a bit dim.

And considering that amd64 did not exist at the time of that patch, it
is not strange that it wasn't applied to the equally non-existing
mpn/x86_64 directory.

  I sent copied the necessary parts of that to the x86_64 path.

OK, I'll take a look.

  > I recently tried to install msys2 on a Windos 10 system here.  I had
  > some problems and tried to contact the msys2 people at their mailing
  > list.  The message was silently dropped.  Thus, I gave up on msys2 and
  > returned to cygwin.  That's our path forward now.

  I think they are no longer using sourceforge, and are on github.
  https://github.com/msys2/  They are also on https://gitter.im/msys2/msys2

You guess better than me.  Yes, I indeed mailed to the msys2 sourceforge
list.

And they set up the mailing list to silently drop (as opposed to at last
bounce or ideally forward) incoming mail?  Unimpressive.

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

Re: COFF_TYPE on x86_64

[Torbjörn Granlund]

Jeremy Drake  writes:

  On msys2's MINGW-packages, we recently hit an issue[1] which I eventually
  tracked down to the very issue documented in
  https://gmplib.org/repo/gmp-6.2/file/09e101b6f2ff/acinclude.m4#l2128

This is a link to a huge file.  Many things are mentioned there.

  > > My current theory is that for some unknown reason, gmp's assembly
  > > functions are resulting in symbols that bfd believes are data, not
  > > functions. Without dllimport, this is causing it to use the
  > > auto-import hack, which has the Windows loader modify addresses in the
  > > function itself, rather than using the jmp thunk which references the
  > > `__imp_` symbol. This cannot work correctly on x64 with large
  > > addresses, because the CALL instruction is taking a 32-bit relative
  > > operand. The only way this can work is with a jmp thunk (unless the
  > > compiler knew to generate an indirect CALL, which is what dllimport
  > > does).
  >
  > The 'unknown reason' I mentioned is that the functions were lacking
  > `.type 32`.
  >
  > > gmp's configure script checks for support for .type pseudo-op, but on
  > > mingw that is only allowed inside a .def, and must take an integer not
  > > `@function`, so gmp suppresses it altogether.

  Strangely, the fix for this was only applied to x86, and not x86_64.  This
  patch applies the fix to x86_64.

What *fix* are you talking about?

You need to give us some context.  Please allow yourself a little time
to word your message to give us a chance to follow you.

I recently tried to install msys2 on a Windos 10 system here.  I had
some problems and tried to contact the msys2 people at their mailing
list.  The message was silently dropped.  Thus, I gave up on msys2 and
returned to cygwin.  That's our path forward now.

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

Re: Hardcoded value of GMP_LIMB_BITS impedes bi-arch builds

[Torbjörn Granlund]

Jan Engelhardt  writes:

  When ./configure has run, the GMP_LIMB_BITS define in gmp.h is hardcoded 
  to 32 or 64, depending on arch. This makes it impossible to use that 
  header file for a x86_64-driven build with gcc -m32.
  It is my (naive) view that declaring

#define GMP_LIMB_BITS (sizeof(mp_limb_t) * CHAR_BIT)

  could address the issue in short order, though, upon last minute 
  searching, I find this problem to have been previously reported in 
  https://gmplib.org/list-archives/gmp-bugs/2012-March/002593.html with no 
  action taken.

No action taken indeed.

If you try compiling that change, you will quickly notice why no action
was taken.  Or, try something much simpler to see the problem:

#define FOO sizeof(int)
#if FOO == 4711
#endif

-- 
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, 6.2.0} config.guess detects wrong cputype/instruction sets

[Torbjörn Granlund]

Bernd Recktor  writes:

  coffeelake processes from intel are affected. Specifically in my case
  i9-9900KF and Pentium-Gold-G5400. The ./config.guess script recognizes
  kabylake-pc-linux-gnu or kabylakenoavx-pc-linux-gnu. Both compilers
  GCC-10.2 and GCC-8.3 recognize skylake using 'gcc -march = native -Q 
  --help = target | grep march'. If a Linux system is to be built
  natively, then non-executable binaries are generated.

Is it a hypotheses of yours that "non-executable binaries" are
generated, or have you actually tried it.  In the latter case, please
send us a complete bug report as per the instructions in the GMP manual.

Skylake is older than Kaby lake which is older than Coffee lake.  So
recognising Coffee Lake as Kaby lake coule be considered as less wrong
than recognising is as Skylake.

Now, as far as I know, Skylake and Kaby lake have the exact same
instructions.  Coffeelake does not lack any instructions implemented in
either.  That's why I am surprised by your claim of generation of
"non-executable binaries".

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

Re: commits not available on the mercurial page

[Torbjörn Granlund]

Paul Zimmermann  writes:

  on https://gmplib.org/repo/gmp/shortlog when I click on a commit,
  I get an almost empty page, and I cannot see the corresponding diff.

  Am I the only one? Is that a temporary problem?

Unfortunately, it is a recurring problem which started years ago.  I
have not been able to find the root cause.  I have upgraded Mercurial
dozens of times, but this bug persists.

We need to switch to git.

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

Re: overflow in mpz type with a simple mpz_add_ui

[Torbjörn Granlund]

Vincent Lefevre  writes:

  This is not properly documented, then. The manual says:

   'mpz_add_ui', 'mpz_sub_ui', 'mpf_add_ui' and 'mpf_sub_ui' benefit
   from an in-place operation like 'mpz_add_ui(x,x,y)', since usually
   ^^
   only one or two limbs of 'x' will need to be changed.  The same
   applies to the full precision 'mpz_add' etc if 'y' is small.  If
   'y' is big then cache locality may be helped, but that's all.

  Since this should be an in-place operation (as there is no carry),
  an overflow is unexpected here.

Overflow here is a result of the mathmatical result.  Whether things are
done "in place" or not is not part of it.

But overflow might be flagged one limb too early for addition; instead
of at 2^27-1 limbs for 32-bit hosts it might happen already at 2^27-2
limbs.  I cannot say that's particularly bad.

As it happens, overflow detetion for other cases is much more coarse,
such as powering.

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

Re: overflow in mpz type with a simple mpz_add_ui

[Torbjörn Granlund]

Vincent Lefevre  writes:

  So the overflow occurs in "mpz_add_ui (z, z, 1);", though this
  operation doesn't need a larger mpz_t and could even be done
  in place: no carry occurs here, and note that a carry for a
  huge number is very unlikely to occur.

No bug.  You're (presumably deliberately) dancing on the edge of mpz
overflow.  The overflow detection flags some false positives, which is
by design.

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

Re: Upstream patch to remove abort() that occur during memory overflow

[Torbjörn Granlund]

Marco Bodrato  writes:

  With ABI=64 I get:
  16777216 ^ 768614336404564651 = 256

  With ABI=32 I get:
  16777216 ^ 178956971 = 256

  Not a signal, nor an abort, simply an incorrect result :-)

That's undesirable.

I thought we cought overflows also in this difficult a^b case by
(indirectly means of allocation errors).

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