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: GNU MP 6.1.2 error undefined symbol __gmpn_invert_limb in test t-constants

[Emmanuel Thomé]

See there.

https://gmplib.org/devel/repo-usage.html

On Tue, Aug 29, 2017 at 08:06:30AM -0400, Dennis Clarke wrote:
> Is it standard?  Sometimes yes and sometimes no. Depends on the system.
> At least for software that can not be built inside a clean room scenario
> where you have nothing but a clean system, a kernel, a few toolchain
> tools and the gmp sources. The libgmp project is a rare one in which you
> really don't need much of anything to get a clean solid build.

Ergo, you could drop that rpath.

I agree that when you want to rebuild everything and the kitchen sink as
a user, you have to use such things (or --with-foo=, or LDFLAGS, the
latter two being possibly better when viable). But as far as diagnosing a
possible misbehaviour goes, you should first take it out.

> It didn't strike me as strange to build gmp with an rpath preset to
> exactly where I wanted it. I just built mpfr a moment ago with some env vars
> thus :

If you force the linker really hard on putting your target installation
directory first, you should be ready to face the problem that a
pre-existing library takes over. Which is exactly what is happening here.

Mpfr and gmp (up to 6.1.2) differ precisely in this aspect. See the
thread that vincent pointed to on this mailing list.

> ps: this all stems from my attempts to get a gcc compiler built
> https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg02494.html
> I am in to day 9 or 10 on this process.

Looks like Real Fun...

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

Re: GNU MP 6.1.2 error undefined symbol __gmpn_invert_limb in test t-constants

[Dennis Clarke]

[ apologies in advance .. another long long email from Dennis ]

On 8/29/17 3:18 AM, Emmanuel Thomé wrote:

On Mon, Aug 28, 2017 at 01:28:33PM -0400, Dennis Clarke wrote:

ppc64$ ./configure ABI=mode64 --enable-cxx --prefix=/usr/local \

--libdir=/usr/local/lib --build=powerpc970-unknown-linux-gnu

[...]

checking compiler gcc -m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec
-mfull-toc -mregnames ... yes


Hold on, where does that rpath come from ? Is it part of your standard
set of CFLAGS that come from your environment ?


Is it standard?  Sometimes yes and sometimes no. Depends on the system.
At least for software that can not be built inside a clean room scenario
where you have nothing but a clean system, a kernel, a few toolchain
tools and the gmp sources. The libgmp project is a rare one in which you
really don't need much of anything to get a clean solid build. Nearly
everything else ( like mozilla or apache or anything X-windows based
with GTK/Xlib etc etc ) needs a ton of libs and things for a clean
build. Even XTerm. In those cases the use of the rpath allows me to
ensure and force the whole process to look into libs previously built
into /usr/local/lib.  The situation is more messy on multi-arch systems
which would be the powerpc and sparc systems where ppc64 is also a big
or small endian system depending. However in the power/powerpc world no
one seems to bother with the ability to run little and big endian at the
same time and as a platform it seems to have fallen out of fashion.
Unless an IBM POWER system ( not powerpc ) is available and I am working
on that. Those are real performance monsters and Red Hat Enterprise
Linux is fully supported on them as well as an AIX implementation. As
soon as I lay my hands on one you can bet I will toss gmp on there.


As Vincent mentioned, I did encounter an issue where gmp was picking the
wrong lib for the tests. But that was related to idiosyncrasies of the
antiquated linker used by freebsd. You should not encounter such things
under gnu/linux, unless you ask it queer things. Which you seem to do
with that rpath.


It didn't strike me as strange to build gmp with an rpath preset to
exactly where I wanted it. I just built mpfr a moment ago with some env 
vars thus :


CFLAGS=-m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec -mfull-toc 
-mregnames


CXXFLAGS=-m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec 
-mfull-toc -mregnames


LC_ALL=C
LD_LIBRARY_PATH=/usr/local/lib
LD_OPTIONS=-R/usr/local/lib -L/usr/local/lib

No LD_RUN_PATH set there. I am surprised to see LD_LIBRARY_PATH which is
not set anywhere in my setup scripts and I generally avoid it. However I
have been building and re-building and re-building gmp in so many many
different ways on multiple systems I am not surprised that I have
something messy here.  I sort of see gmp as the first stepping stone up
a toolchain.  OKay, actually gnu make with libiconv and gnu gettext is
the real first and then the auto-tools bits and a few, very few, others.

On another topic I was just looking at freebsd and did download the
release 11.1 iso images.  I was going to see if a freebsd based install
was more stable and reliable than the messy debian ppc64 system I have
now. The debian folks have dropped support for ppc64 from their recent
installers however one can certainly run the previous release. That at
least gets me the basic tools. However gcc throws the odd ice ( internal
compiler error ) from time to time and I can trigger that with a few
lines of code.  I have openbsd 6.1 up and running but only on amd64 at
the moment and performance is really terrible thus far. Anyways, here
is an ice :

ppc64$ uname -a
Linux charon 3.16.0-4-powerpc64 #1 SMP Debian 3.16.43-2 (2017-04-30) 
ppc64 GNU/Linux


ppc64$ cat ice_me.c
#define _XOPEN_SOURCE 600

/* what is the limit on the initial estimation stage */
#define MAX_N1 16384
/* at what interval shall data be printed */
#define INTERVAL_N1 256

#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main()
{
uint32_t j, n;
long double psum = ( long double ) 0.0;
long double est_pi;

fprintf ( stdout, " n   est_pi   delta\n" );
fprintf ( stdout, "  -\n" );
/* initial stage of estimation */
for ( n=1; n<( MAX_N1 + 1 ); n++ ) {

psum = psum  +  ( (long double) 1.0
   /
( (long double) n * (long double) n ) );

if ( n%INTERVAL_N1 == 0 ) {
fprintf ( stdout, "\n  %9i", n );
/* fprintf ( stdout, "psum = %18.12Le", psum ); */
est_pi = sqrtl( psum * (long double) 6.0);
fprintf ( stdout, "%18.12Le", est_pi );
fprintf ( stdout, "%10.4Le",
 ( (long double) 3.14159265358979323846264 - est_pi ) );
}
}
fprintf ( stdout, "\n" );

fprintf ( stdout, "\nFinal est_pi 

issues on gcc202

[paul zimmermann]

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

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

With the latest snapshot (gmp-6.1.99-20170829), issue 1) is fixed, but not
issue 2).

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

[Niels Möller]

Dennis Clarke  writes:

> I was just flabberghasted ( I think that is the word ) at how impossibly
> horribly slow the results were that I was getting everywhere.  Not just
> on sparc but on powerpc and on amd64 systems. Those assembly bits are
> essential.

Right, that assembly code wasn't written only for the fun of it...

Then, sparc has been particularly hard to get good bignum performance;
the initial 64-bit sparc instruction set was awful for arithmetic (but
somewhat mended in the most recent versions, I think). IIRC, some
versions of the GMP sparc assembly code have chopped numbers into pieces
suitable for the floating point multiply instructions, just because
integer multiply was incredibly slow.

> Yes Sir I do. Now I just need to ponder if the whole process is worth
> the efforts that are going to be needed

Please, take a deep breath and calm down. Then start with a clean build
directory and try an as basic build as possible, without any extra
configuration. You might also want to build using GNU make, to rule out
problems related to make incompatibilities. Something like

  ./configure CC=c99 --disable-cxx
  gmake

And then examine and report any errors you get.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GNU MP 6.1.2 error undefined symbol __gmpn_invert_limb in test t-constants

[Emmanuel Thomé]

On Mon, Aug 28, 2017 at 01:28:33PM -0400, Dennis Clarke wrote:
> ppc64$ ./configure ABI=mode64 --enable-cxx --prefix=/usr/local \
> > --libdir=/usr/local/lib --build=powerpc970-unknown-linux-gnu
[...]
> checking compiler gcc -m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec
> -mfull-toc -mregnames ... yes

Hold on, where does that rpath come from ? Is it part of your standard
set of CFLAGS that come from your environment ?

As Vincent mentioned, I did encounter an issue where gmp was picking the
wrong lib for the tests. But that was related to idiosyncrasies of the
antiquated linker used by freebsd. You should not encounter such things
under gnu/linux, unless you ask it queer things. Which you seem to do
with that rpath.

Nevertheless, it might be interesting if you test with the head of the
development repository. A flag has been added that lessens the libtool
machinery, maybe it's more robust than the current tarball given the
flags you specify (but maybe not).

E.
___
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

[Marc Glisse]

On Mon, 28 Aug 2017, Niels Möller wrote:


To clarify, I'd expect libgmpxx to depend on the C++ standard library
supplied with the compiler used to build gmp. Then, I guess there are
different ways to resolve that dependency, the GNU C++ compiler uses a
shared library, named libstdc++, the Oracle compiler might do something
completely different (and I don't know what, since you haven't told me).


Oracle by default does not link the C++ standard library and runtime in
shared libraries. You usually have undefined symbols, and the final binary 
gets the link.


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