Re: Possibly an annoying test in configure

[Dennis Clarke]

On 8/21/23 11:31, Arsen Arsenović wrote:


Torbjörn Granlund  writes:


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.


These should be fixed upstream in Autoconf already:
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=8b5e2016c7ed2d

This is a somewhat well known change in Clang (and upcoming, though not
current, GCC), and is also a change that was done in ISO C over twenty
years ago.

We, as well as Fedora, and likely others have been fixing these in
various programs for a while:
https://wiki.gentoo.org/wiki/Modern_C_porting

Dennis, would you mind testing with Autoconf 2.72c to see if the issue
persists?  You can fetch it from
https://alpha.gnu.org/gnu/autoconf/autoconf-2.72c.tar.xz


This is not entirely off-topic for GMP/MPFR but certainly out on the
bitter edge. Maybe best to move this off to a maillist for autotools.

Thus, I will get onto that for a few systems. Likely :

1) FreeBSD 14.0 ALPHA2 on the RISC-V rv64imafdc
2) FreeBSD 14.0 ALPHA2 on aarch64
3) Gentoo Linux on sparcv9
4) other stuff running around me ... :)



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

Re: Possibly an annoying test in configure

[Dennis Clarke]

On 8/20/23 05:48, Torbjörn Granlund wrote:

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.



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

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


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

Possibly an annoying test in configure

[Dennis Clarke]

This may be the same sort of bug I saw in MPFR a few weeks ago
wherein I see :

https://sympa.inria.fr/sympa/arc/mpfr/2023-08/msg6.html


With GMP ver 6.3.0 I run into the same sort of thing :

conftest.c:2:10: error: a function declaration without a prototype is 
deprecated in all versions of C [-Werror,-Wstrict-prototypes]

int main () { return 0; }
 ^
  void
1 error generated.
configure:5985: $? = 1
failed program was:

int main () { return 0; }
configure:7072: result: no
configure:7310: error: could not find a working compiler, see config.log 
for details



This is seen on FreeBSD 14.0 on a RISC-V machine ( the SiFive board )
however I bet it happens just about anywhere if one goes with strict
C99 CFLAGS.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Arithmetic bug on ARM (STM 32 F4)

[Dennis Clarke]

On 1/21/21 3:17 PM, Torbjörn Granlund wrote:
>   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.
> 
> 

I just checked on Debian sid with gcc 10.2 and sparc64 and IBM Power9
ppc64le and also on Oracle Fujitsu SPARC64 with Oracle Studio 12.6 as
well as on Debian sid i686 and also FreeBSD UNIX with LLVM/Clang on
amd64 and then a few other sundy systems. All work perfectly.

/***
 * The Open Group Base Specifications Issue 6
 * IEEE Std 1003.1, 2004 Edition
 *
 *  An XSI-conforming application should ensure that the feature
 *  test macro _XOPEN_SOURCE is defined with the value 600 before
 *  inclusion of any header. This is needed to enable the
 *  functionality described in The _POSIX_C_SOURCE Feature Test
 *  Macro and in addition to enable the XSI extension.
 ***/
#define _XOPEN_SOURCE 600

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

#include 

int main(int argc, char *argv[])
{

mpz_t t;
mpz_init(t);
mpz_t tt;
mpz_init(tt);
mpz_t ttt;
mpz_init(ttt);

mpz_t result_check, expected_result;
mpz_init(result_check);
mpz_init(expected_result);

mpz_set_str( tt,
"25975415027868818028037643145183730078267964363630309107863975221668725232906664910091356673487591948237515304861352649057814029879720636142810833722202669061030484458925649047021859875730105532595466846094449735851132072400310565642",
10);

mpz_set_str(t,
"6864797660130609714981900799081393217269435300143305409394463459185543183397655394245057746333217197532963996371363321113864768612440380340372808892707005449",
10);

mpz_mod(ttt, tt, t);

printf("tt = ");
gmp_printf("%Zd", tt);
printf("\n");

printf("t = ");
gmp_printf("%Zd", t);
printf("\n");

printf("ttt = ");
gmp_printf("%Zd", ttt);
printf("\n");


mpz_set_str(expected_result,

"5247183143879283565064056089869553515440215252945038779070795247972433237341511292686962488915110675351673985513318500576097977116134885013371639187873069514",
10);


mpz_sub(result_check, expected_result, ttt);
printf("\n check the diff on the expected result = ");
gmp_printf("%Zd",result_check);
printf("\n");


mpz_clear(t);
mpz_clear(tt);
mpz_clear(ttt);

mpz_clear(expected_result);
mpz_clear(result_check);

return EXIT_SUCCESS;

}


As soon as I have some arm data I will be sure to pass that along.



-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: FAIL: t-printf on Debian sparc64 with gcc-10 patched for gcc bugid 97939

[Dennis Clarke]

Follow up to myself, after going in some circles I did land on :

Breakpoint 1, check_one (want=0x101dfc0 "   123",
fmt=0x11267a8 "%10Nd") at t-printf.c:312
312   check_obstack_vprintf (want, fmt, ap);
(gdb) print want
$364 = 0x101dfc0 "   123"
(gdb) print fmt
$365 = 0x11267a8 "%10Nd"
(gdb) print ap
$366 = (va_list) 0x7fef180
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
__memcpy_large () at ../sysdeps/sparc/sparc64/memcpy.S:370
370 stb %g5, [%o0 - 2]  /* Store
   */
(gdb) where
#0  __memcpy_large () at ../sysdeps/sparc/sparc64/memcpy.S:370
#1  0x0100a9f0 in tests_allocate (size=1099511750592) at
memory.c:102
#2  0x01007620 in check_one (want=0x101dfc0 "   123",
fmt=0x11267a8 "%10Nd") at t-printf.c:312
#3  0x01007af4 in check_z () at t-printf.c:424
#4  0x0100a6d0 in main (argc=1, argv=0x7fef628) at
t-printf.c:945
(gdb) quit
A debugging session is active.

Inferior 1 [process 52726] will be killed.

Quit anyway? (y or n) y
ceres$



   * * * So I wonder if that is repeatable. * * *




ceres$ TERM=dumb LC_ALL=en_US.UTF-8 /usr/bin/gdb -q t-printf
Reading symbols from t-printf...
(gdb) dir /opt/bw/build/glibc-2.31/
Source directories searched: /opt/bw/build/glibc-2.31:$cdir:$cwd
(gdb) break t-printf.c:312
Breakpoint 1 at 0x7608: file t-printf.c, line 312.
(gdb) ignore 1 119
Will ignore next 119 crossings of breakpoint 1.
(gdb) run
Starting program: /tmp/t-printf

Breakpoint 1, check_one (want=0x101dfb0 " 0",
fmt=0x11267a8 "%10Nd") at t-printf.c:312
312   check_obstack_vprintf (want, fmt, ap);
(gdb) print want
$1 = 0x101dfb0 " 0"
(gdb) print fmt
$2 = 0x11267a8 "%10Nd"
(gdb) print ap
$3 = (va_list) 0x7fef180
(gdb) cont
Continuing.

Breakpoint 1, check_one (want=0x101dfc0 "   123",
fmt=0x101dfa8 "%10Zd") at t-printf.c:312
312   check_obstack_vprintf (want, fmt, ap);
(gdb) print want
$4 = 0x101dfc0 "   123"
(gdb) print fmt
$5 = 0x101dfa8 "%10Zd"
(gdb) print ap
$6 = (va_list) 0x7fef180
(gdb) step
check_obstack_vprintf (want=0x101dfc0 "   123",
fmt=0x101dfa8 "%10Zd", ap=0x7fef180) at t-printf.c:276
276   want_len = strlen (want);
(gdb) step
strlen () at ../sysdeps/sparc/sparc64/strlen.S:30
30  mov %o0, %o1
(gdb) cont
Continuing.

Breakpoint 1, check_one (want=0x101dfc0 "   123",
fmt=0x11267a8 "%10Nd") at t-printf.c:312
312   check_obstack_vprintf (want, fmt, ap);
(gdb) print want
$7 = 0x101dfc0 "   123"
(gdb) print fmt
$8 = 0x11267a8 "%10Nd"
(gdb) print ap
$9 = (va_list) 0x7fef180
(gdb) step
check_obstack_vprintf (want=0x101dfc0 "   123",
fmt=0x11267a8 "%10Nd", ap=0x7fef180) at t-printf.c:276
276   want_len = strlen (want);
(gdb) step
strlen () at ../sysdeps/sparc/sparc64/strlen.S:30
30  mov %o0, %o1
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
__memcpy_large () at ../sysdeps/sparc/sparc64/memcpy.S:370
370 stb %g5, [%o0 - 2]  /* Store
   */
(gdb) where
#0  __memcpy_large () at ../sysdeps/sparc/sparc64/memcpy.S:370
#1  0x0100a9f0 in tests_allocate (size=1099511750592) at
memory.c:102
#2  0x01007620 in check_one (want=0x101dfc0 "   123",
fmt=0x11267a8 "%10Nd") at t-printf.c:312
#3  0x01007af4 in check_z () at t-printf.c:424
#4  0x0100a6d0 in main (argc=1, argv=0x7fef628) at
t-printf.c:945
(gdb)

Something odd is afoot when *want = "   123" and the fmt string
is "%10Nd".  I will see if I can step around in this until I can find
why the SIGSEGV.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

FAIL: t-printf on Debian sparc64 with gcc-10 patched for gcc bugid 97939

[Dennis Clarke]

c0 "   123",
fmt=0x11267a8 "%10Nd") at t-printf.c:312
#3  0x01007af4 in check_z () at t-printf.c:424
#4  0x0100a6d0 in main (argc=1, argv=0x7fef628) at
t-printf.c:945
(gdb)

This feels like deep water at this point because after glancing around
inside tests/memory.c at both tests_allocate() and tests_free_nosize()
due to :

37:#define obstack_chunk_alloc tests_allocate
38:#define obstack_chunk_free  tests_free_nosize

I just go single stepping around madly for a while and that includes
into the sources of glibc-2.31 and I simply got lost.  Is there an
easier way to track this down?


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Debian Linux SPARC64 issue with FAIL t-printf (exit status: 139)

[Dennis Clarke]

sparc64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/sparc64-linux-gnu/10/include
 /usr/local/include
 /usr/include/sparc64-linux-gnu
 /usr/include
End of search list.
GNU C17 (Debian 10.2.0-23) version 10.2.0 (sparc64-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.2.1, MPFR
version 4.1.0, MPC version 1.2.0, isl version isl-0.23-GMP

GGC heuristics: --param ggc-min-expand=97 --param ggc-min-heapsize=127133
Compiler executable checksum: cafff3a7c98fd704fb364e25e7dbfea3
COLLECT_GCC_OPTIONS='-v' '-fsanitize=undefined' '-v' '-c' '-mcpu=v9'
 as -v -v -s -K PIC -Av9 -64 -no-undeclared-regs -relax -o foo.o
/tmp/ccngg5fZ.s
GNU assembler version 2.35.1 (sparc64-linux-gnu) using BFD version (GNU
Binutils for Debian) 2.35.1
COMPILER_PATH=/usr/lib/gcc/sparc64-linux-gnu/10/:/usr/lib/gcc/sparc64-linux-gnu/10/:/usr/lib/gcc/sparc64-linux-gnu/:/usr/lib/gcc/sparc64-linux-gnu/10/:/usr/lib/gcc/sparc64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/sparc64-linux-gnu/10/:/usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/:/usr/lib/gcc/sparc64-linux-gnu/10/../../../../lib/:/lib/sparc64-linux-gnu/:/lib/../lib/:/usr/lib/sparc64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/sparc64-linux-gnu/10/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-fsanitize=undefined' '-v' '-c' '-mcpu=v9'
root@ceres:~#

That was fast.

I will build libgmp 6.2.1 and run the tests on this new install and
updated gcc.

-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Debian Linux SPARC64 issue with FAIL t-printf (exit status: 139)

[Dennis Clarke]

On 11/18/20 1:30 AM, Paul Zimmermann wrote:
>Dear Dennis,
> 
>> With an old old Sun Nera server running very latest Debian sid I was
>> surprised to see : [...]
> 
> does the same error occur with previous GMP versions, or is it specific to
> 6.2.1?

After hours of running this in circles for both 6.2.0 and 6.2.1
with both gcc 9.3.0 ( Debian 9.3.0-18 ) and also the latest
gcc 10.2.0 (Debian 10.2.0-17) I can report that the test t-printf
does fail every time. With a consistent configure :

./configure ABI=64 --enable-cxx --prefix=/opt/bw
--libdir=/opt/bw/lib --disable-assembly
--enable-shared --enable-static --enable-fft

So that is strange.

I can also try gcc 8.x but that will need another day.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

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

Re: Debian Linux SPARC64 issue with FAIL t-printf (exit status: 139)

[Dennis Clarke]

07: 92464 Segmentation fault  "$@" >
$log_file 2>&1
FAIL: t-ops2qf
../../test-driver: line 107: 92470 Segmentation fault  "$@" >
$log_file 2>&1
FAIL: t-ops2f
../../test-driver: line 107: 92476 Segmentation fault  "$@" >
$log_file 2>&1
FAIL: t-ops3
../../test-driver: line 107: 92482 Segmentation fault  "$@" >
$log_file 2>&1
FAIL: t-ostream
PASS: t-prec
PASS: t-ternary
PASS: t-unary
PASS: t-do-exceptions-work-at-all-with-this-compiler
PASS: t-ops2z
PASS: t-assign
PASS: t-constr
../../test-driver: line 107: 92530 Bus error   "$@" >
$log_file 2>&1
FAIL: t-rand

Testsuite summary for GNU MP 6.2.1

# TOTAL: 22
# PASS:  13
# SKIP:  0
# XFAIL: 0
# FAIL:  9
# XPASS: 0
# ERROR: 0

See tests/cxx/test-suite.log
Please report to gmp-bugs@gmplib.org, see
https://gmplib.org/manual/Reporting-Bugs.html

make[5]: *** [Makefile:989: test-suite.log] Error 1
make[5]: Leaving directory
'/opt/bw/build/gmp-6.2.1_debian_5.9.0-2-sparc64.002/tests/cxx'
make[4]: *** [Makefile:1097: check-TESTS] Error 2
make[4]: Leaving directory
'/opt/bw/build/gmp-6.2.1_debian_5.9.0-2-sparc64.002/tests/cxx'
make[3]: *** [Makefile:1315: check-am] Error 2
make[3]: Leaving directory
'/opt/bw/build/gmp-6.2.1_debian_5.9.0-2-sparc64.002/tests/cxx'
make[2]: *** [Makefile:823: check-recursive] Error 1
make[2]: Leaving directory
'/opt/bw/build/gmp-6.2.1_debian_5.9.0-2-sparc64.002/tests'
make[1]: *** [Makefile:997: check-recursive] Error 1
make[1]: Leaving directory
'/opt/bw/build/gmp-6.2.1_debian_5.9.0-2-sparc64.002'
make: *** [Makefile:1289: check] Error 2
Command exited with non-zero status 2
real 2952.94
user 2617.54
sys 252.12
ceres$

So I will revert back to 6.2.0 and see what I get from the original
starting conditions.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Debian Linux SPARC64 issue with FAIL t-printf (exit status: 139)

[Dennis Clarke]

   64
  Install prefix:/opt/bw
  Compiler:  /usr/bin/gcc
  Static libraries:  yes
  Shared libraries:  yes

ceres$

ceres$ uname -a
Linux ceres 5.9.0-2-sparc64 #1 Debian 5.9.6-1 (2020-11-08) sparc64 GNU/Linux
ceres$

Everything compiles up fine but this one test seems spooky. Mostly
because I have not seen it fail anywhere else.  Ever. I just tried
on Debian sid for ppc64 big-endian with no issues at all.  I know
the CFLAGS may look a bit trdious and even bonkers but I have had
no problems with my other software ( yet ) and it does sort of
enforce a very strict C99 way of things :

ceres$ pwd
/opt/bw/build/gmp-6.2.1_debian_5.9.0-2-sparc64.001
ceres$
ceres$ find . | grep 't-print'
./t-printf.tmp
./tests/misc/t-printf.tmp
./tests/misc/t-printf.o
./tests/misc/t-printf.log
./tests/misc/t-printf
./tests/misc/t-printf.trs
./tests/misc/t-printf.c
ceres$
ceres$ file ./tests/misc/t-printf
./tests/misc/t-printf: ELF 64-bit MSB shared object, SPARC V9, relaxed
memory ordering, version 1 (SYSV), dynamically linked, interpreter
/lib64/ld-linux.so.2,
BuildID[sha1]=1f5967f839d54651b535b9c98d2a024df84d39b0, for GNU/Linux
3.2.0, with debug_info, not stripped
ceres$
ceres$ ldd ./tests/misc/t-printf
linux-vdso.so.1 (0xf80100042000)
libgmp.so.10 =>
/opt/bw/build/gmp-6.2.1_debian_5.9.0-2-sparc64.001/.libs/libgmp.so.10
(0xf8010024c000)
libc.so.6 => /lib/sparc64-linux-gnu/libc.so.6 (0xf8010042)
/lib64/ld-linux.so.2 (0xf801)
ceres$
ceres$
ceres$ ls /opt/bw/lib
/usr/bin/ls: cannot access '/opt/bw/lib': No such file or directory
ceres$
ceres$ echo $CC
/usr/bin/gcc
ceres$
ceres$ echo $CFLAGS
-std=iso9899:1999 -m64 -g -O0 -pedantic -pedantic-errors -fno-builtin
-fno-fast-math -mno-app-regs -mflat -mhard-float -mhard-quad-float
-mno-unaligned-doubles -mno-faster-structs -mcpu=ultrasparc
-mtune=ultrasparc -mno-vis -mno-cbcond -mno-fmaf -mno-fsmuld -mno-popc
-mno-subxc -mcmodel=medany -mmemory-model=tso -Wl,-rpath=/opt/bw/lib
ceres$
ceres$ echo $CXXFLAGS
-m64 -g -O0 -fno-builtin -fno-fast-math -mno-app-regs
-mno-unaligned-doubles -mcpu=ultrasparc -mtune=ultrasparc
-Wl,-rpath=/opt/bw/lib
ceres$

In any case let me know what I can do to dig into this more.

Oh, last item, I did try to insert -std=c++11 into the CXXFLAGS but the
configure stage blew up every time while looking for std iostream. I
went with what seems to get past configure for CXXFLAGS.




-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional












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

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

[Dennis Clarke]

On a somewhat strange machine I was building with llvm/Clang on FreeBSD
and this :

ijiraq# uname -apKU
FreeBSD ijiraq 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r367349: Wed Nov  4
22:48:25 UTC 2020
r...@freebsd-head-riscv64-build.jail.ci.freebsd.org:/usr/obj/usr/src/riscv.riscv64/sys/QEMU
 riscv riscv64 1300125 1300125
ijiraq#
ijiraq# cc --version
FreeBSD clang version 11.0.0 (g...@github.com:llvm/llvm-project.git
llvmorg-11.0.0-0-g176249bd673)
Target: riscv64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin
ijiraq#

CC=/usr/bin/cc

CFLAGS=-std=iso9899:1999 -m64 -g -O0 -pedantic -pedantic-errors
-march=rv64imafdc -mabi=lp64d -Weverything -Wno-reserved-id-macro
-Wno-unused-macros -Wno-missing-prototypes -Wno-padded -fno-fast-math
-fno-builtin

CPPFLAGS=-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-D_XOPEN_SOURCE=600

CXXFLAGS=-m64 -g -O0 -march=rv64imafdc -mabi=lp64d -fno-fast-math
-fno-builtin

Wherein the config was :

./configure ABI=standard --enable-cxx --prefix=/opt/bw \
--libdir=/opt/bw/lib --disable-assembly


Seems to build fine.

However the tests blow up due to :

convert.c:143:11: error: implicit declaration of function 'strcasecmp'
is invalid in C99

So that is easy to fix.

ijiraq# diff -u ./tests/mpz/convert.c.orig ./tests/mpz/convert.c
--- ./tests/mpz/convert.c.orig  2020-01-17 13:44:49.0 +
+++ ./tests/mpz/convert.c   2020-11-07 22:51:36.823215000 +
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include  /* for strlen */
+#include  /* for strcasecmp */

 #include "gmp-impl.h"
 #include "tests.h"
ijiraq#

Then tests continue swimmingly.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.2 error

[Dennis Clarke]

On 2020-03-30 16:57, Torbjörn Granlund wrote:

rodriguez-murias  writes:

   When i make install :

   /usr/bin/mkdir: cannot create directory ‘/usr/local/share/info’: Permission 
denied

The inability to write into system directories as a non-root user is not
due to a problem with GMP.

You might want to grab a book on Unix and read the first few chapters.




Oh that was brutal and funny. We all need a laugh these days.

Perhaps better to suggest to the guy :

ls -lad /usr/local /usr/local/share

Then that will give him a hint.

Thanks for the laugh :)


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: error on mpz_inits and mpz_clears

[Dennis Clarke]

On 9/24/19 6:01 AM, Rabindra Moirangthem wrote:

Hi Team,

I have installed the gmp library on a centos system


What do you mean? Be specific.



--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: failure to detect format of `double' on MS-Windows

[Dennis Clarke]

On 9/7/19 2:52 PM, Torbjörn Granlund wrote:

Vincent Lefevre  writes:

   $ ./configure '--host=i586-mingw32msvc' '--disable-shared' 
'host_alias=i586-mingw32msvc'
   [...]
   checking format of `double' floating point... od: conftest: No such file or 
directory
   od: conftest: No such file or directory
   unknown
   configure: WARNING: Could not determine float format.
   configure: WARNING: Conversions to and from "double" may be slow.
   [...]

   One needs to change "conftest" to "conftest$EXEEXT".
   Patch attached.

Thanks Vincent, now committed.



Could there be a patch file created for https://gmplib.org/gmp6.1.html
or something similar?  I am thinking that a number of small and
reasonable fixes are being applied to the code base but the release
tarball is locked in time without a patch file to be seen.  The mpfr
folks tend to provide a patch file which addresses some of their
updates and fixes and I am wondering if gmp folks have considered
this ?


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: ISO C forbids an empty translation unit again

[Dennis Clarke]

On 9/3/19 1:08 AM, Marco Bodrato wrote:

Ciao,

Il Lun, 2 Settembre 2019 11:48 pm, Dennis Clarke ha scritto:

This one pops up now and again if I go with LLVM/Clang on FreeBSD and
with really strict CFLAGS.  So in a few files I had to drop in a silly
typedef.


Adding silly lines in the code is not a priority for this project :-D


typedef int __gmp_dummy_typedef;

Looks good to me !



By the way, a patch was added to the main repository:

https://gmplib.org/repo/gmp/rev/04bc88ce93f9


Thing of beauty.   Thank you.
A patch may be needed on the main download site.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: not really a bug but somewhat odd : checking compiler /usr/local/bin/gcc8 ... no, mpn_lshift_com

[Dennis Clarke]

On 7/28/19 8:09 AM, Vincent Lefevre wrote:
> On 2019-07-28 07:40:38 -0400, Dennis Clarke wrote:
>> On 7/28/19 7:32 AM, Vincent Lefevre wrote:
>>> On 2019-07-28 12:44:55 +0200, Vincent Lefevre wrote:
>>>> On 2019-07-28 06:12:06 -0400, Dennis Clarke wrote:
>>>>> configure:6813: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest
>>>>> Abort trap (core dumped)
>>>>
>>>> I don't know in your case, but I fear that this program is buggy.
>>> [...]
>>>
>>> You can try the attached patch in case this would be the issue.
>>> This could also solve invisible failures (as occurring inside
>>> configure) in other cases.
>>>
>>
>> Thank you for that but I suspect the problem lay entirely elsewhere in
>> an unexpected place :
> 
> I don't see how you can deduce that.
> 

It's called being bloody wrong.

Dennis

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

Re: not really a bug but somewhat odd : checking compiler /usr/local/bin/gcc8 ... no, mpn_lshift_com

[Dennis Clarke]

On 7/28/19 7:32 AM, Vincent Lefevre wrote:
> On 2019-07-28 12:44:55 +0200, Vincent Lefevre wrote:
>> On 2019-07-28 06:12:06 -0400, Dennis Clarke wrote:
>>> configure:6813: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest
>>> Abort trap (core dumped)
>>
>> I don't know in your case, but I fear that this program is buggy.
> [...]
> 
> You can try the attached patch in case this would be the issue.
> This could also solve invisible failures (as occurring inside
> configure) in other cases.
> 

Thank you for that but I suspect the problem lay entirely elsewhere in
an unexpected place :

hydra$ cat foo.c

/* The following is mis-compiled by Intel ia-64 icc version 1.8 under
"icc -O3",  After several calls, the function writes partial garbage to
the result vector.  Perhaps relates to the chk.a.nc insn.  This code
needs
to be run to show the problem, but that's fine, the offending cc is a
native-only compiler so we don't have to worry about cross
compiling.  */

#if ! defined (__cplusplus)
#include 

void lshift_com (rp, up, n, cnt)
  unsigned long *rp;
  unsigned long *up;
  long n;
  unsigned cnt;
{
  unsigned long high_limb, low_limb;
  unsigned tnc;
  long i;
  up += n;
  rp += n;
  tnc = 8 * sizeof (unsigned long) - cnt;
  low_limb = *--up;
  high_limb = low_limb << cnt;
  for (i = n - 1; i != 0; i--)
{
  low_limb = *--up;
  *--rp = ~(high_limb | (low_limb >> tnc));
  high_limb = low_limb << cnt;
}
  *--rp = ~high_limb;
}

int main () {
  unsigned long *r, *r2;
  unsigned long a[88 + 1];
  long i;
  for (i = 0; i < 88 + 1; i++)
a[i] = ~0L;
  r = malloc (1 * sizeof (unsigned long));
  r2 = r;
  for (i = 0; i < 528; i += 23)
{
  lshift_com (r2, a,
  i / (8 * sizeof (unsigned long)) + 1,
  i % (8 * sizeof (unsigned long)));
  r2 += 88 + 1;
}
  if (r[2048] != 0 || r[2049] != 0 || r[2050] != 0 || r[2051] != 0 ||
  r[2052] != 0 || r[2053] != 0 || r[2054] != 0)
abort ();
  free (r);
  return 0;
}

#else

int main () {
  return 0;
}

#endif

hydra$


That compiles and runs fine on FreeBSD x86_64 with gcc 8.3.0 however on
 the ppc64 boxen :

hydra$ ls foo
foo
hydra$ gdb ./foo
GNU gdb (GDB) 8.3 [GDB v8.3 for FreeBSD]
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64-portbld-freebsd13.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./foo...
warning: File
"/opt/bw/build/gmp-6.1.2_FreeBSD_13.0-CURRENT_r350103_ppc64.001/.gdbinit" 
auto-loading
has been declined by your `auto-load safe-path' set to
"$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path
/opt/bw/build/gmp-6.1.2_FreeBSD_13.0-CURRENT_r350103_ppc64.001/.gdbinit
line to your configuration file "/home/dclarke/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/dclarke/.gdbinit".
--Type  for more, q to quit, c to continue without paging--c
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the
shell:
info "(gdb)Auto-loading safe path"
(gdb) run
Starting program:
/opt/bw/build/gmp-6.1.2_FreeBSD_13.0-CURRENT_r350103_ppc64.001/foo

Program received signal SIGABRT, Aborted.
0x00081026b898 in .__sys_thr_kill () from /lib/libc.so.7
(gdb) bt
#0  0x00081026b898 in .__sys_thr_kill () from /lib/libc.so.7
#1  0x00081026af3c in .__raise () from /lib/libc.so.7
#2  0x0008101cf41c in abort () from /lib/libc.so.7
#3  0x1cb4 in main () at foo.c:51
(gdb) quit
A debugging session is active.

Inferior 1 [process 3361] will be killed.

Quit anyway? (y or n) y
hydra$

Well looks to be in libc.so.7 here.   :-(

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

Re: not really a bug but somewhat odd : checking compiler /usr/local/bin/gcc8 ... no, mpn_lshift_com

[Dennis Clarke]

On 7/28/19 6:21 AM, paul zimmermann wrote:
>Hi Dennis,
> 
>> Dear gmp/mpfr folks :
> 
> this apparently has nothing to do with mpfr.

No but I know where you all tend to read mailists. :-)

> 
> From the error message in configure ("no, mpn_lshift_com optimization 2,
> program does not run") you can conclude that your compiler is broken.
> Please report to the compiler vendor.

Seems hard to accept given that the FreeBSD provided gcc 8.3.0 compiler
did actually compile and install libgmp from "ports" on this machine.

However when I try this manually I get the config error that I just have
not seen before.




-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Problems with mpfr_set_str() and decimal numbers

[Dennis Clarke]

On 4/16/19 6:15 AM, Torbjörn Granlund wrote:

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



I already heard back from them pretty fast.
I was entirely on the wrong list.
In fact, they suggested I not use MPFR for the application and take a 
long look at GMP in the mpz_t space for doing integer computation.


So .. I shall return .. just not with a bug.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Problems with mpfr_set_str() and decimal numbers

[Dennis Clarke]

Trying to read in a decimal number on the command line and getting a
strange response.  Just ever so slightly wrong result.

Some other code I have was acting strange so I did this bit :

#include 
#include 
#include 
#define __STDC_FORMAT_MACROS
#include 
#include 
#include 
#include 

#define PREC 113 /* lowest reasonable precision */

int main (int argc, char *argv[])
{
uint64_t bit_prec = PREC;
mpfr_t input_m;
int inex; /* mpfr retval */

inex = mpfr_init_set_si(input_m, (long)0, MPFR_RNDN);
/* check if a test integer was on the command line */
if (argc<2){
fprintf(stderr,"FAIL : test number and optional bit precision?\n");
fprintf(stderr," : %s  \n", argv[0]);
fprintf(stderr," : default bit precision is %i\n\n", PREC);
return (EXIT_FAILURE);
}

/* check if a bit precision parameter was on the command line */
if (argc>2){
bit_prec = (int)strtol(argv[2], (char **)NULL, 10);
if (bit_prec>1023){
bit_prec = 1024;
printf("\nWARNING : limit precision to 1024 bits.\n");
}
} else {
bit_prec = PREC;
}
printf("\nWe shall use %i bits of precision.\n", bit_prec);
mpfr_set_default_prec((mpfr_prec_t)bit_prec);

if (argc>1){
/* int mpfr_set_str(mpfr_t rop, const char *s, int base, 
mpfr_rnd_t rnd)

 *
 *   Set rop to the value of the string s in base base, rounded
 *   in the direction rnd. See the documentation of mpfr_strtofr
 *   for a detailed description of the valid string formats.
 *   Contrary to mpfr_strtofr, mpfr_set_str requires the whole
 *   string to represent a valid floating-point number.
 *
 *   The meaning of the return value differs from other MPFR
 *   functions: it is 0 if the entire string up to the final null
 *   character is a valid number in base base;
 *   otherwise it is -1, and rop may have changed (users interested
 *   in the ternary value should use mpfr_strtofr instead).*/
inex = mpfr_set_str(input_m, argv[1], 10, MPFR_RNDN);
if ( inex < 0 ) {
printf("\nFAIL : some mysterious problem happened!\n");
printf(" : we tried to interpret %s\n", argv[1]);
printf(" : however we seemed to get ");
mpfr_printf("%.Rf\n", input_m);
return (EXIT_FAILURE);
}

if (mpfr_number_p(input_m)==0){
printf("\nFAIL : provide a reasonable decimal number.\n");
return (EXIT_FAILURE);
}

} else {
printf("\nFAIL : provide a nice base ten number!\n");
printf(" : %s  \n", argv[0]);
return (EXIT_FAILURE);
}

printf("You seem to have entered %s\n", argv[1]);
printf("Where mpfr_set_str() seems to see ");
mpfr_printf("%.Rf\n", input_m);

return (EXIT_SUCCESS);
}


So seems to work up until the numbers are large :

nix$ ./mpfr_set_str 1844674407370999

We shall use 113 bits of precision.
You seem to have entered 1844674407370999
Where mpfr_set_str() seems to see 1844674407370999.00
nix$

Fine.

However :

nix$ ./mpfr_set_str 18446744073709551601

We shall use 113 bits of precision.
You seem to have entered 18446744073709551601
Where mpfr_set_str() seems to see 18446744073709551616.00
nix$

Not sure where those last two digits went wrong.

nix$ ./mpfr_set_str 1844674407370955160

We shall use 113 bits of precision.
You seem to have entered 1844674407370955160
Where mpfr_set_str() seems to see 1844674407370955264.00
nix$

nix$
nix$ ./mpfr_set_str 999

We shall use 113 bits of precision.
You seem to have entered 999
Where mpfr_set_str() seems to see 999.00
nix$
nix$ ./mpfr_set_str 9990

We shall use 113 bits of precision.
You seem to have entered 9990
Where mpfr_set_str() seems to see 9990.00
nix$ ./mpfr_set_str 9991

We shall use 113 bits of precision.
You seem to have entered 9991
Where mpfr_set_str() seems to see 9992.00
nix$

Weird.

What am I missing ?


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: not really a bug .. is there a way to set the host type in the Makefile.am ?

[Dennis Clarke]

On 2/18/19 10:31 PM, Vincent Lefevre wrote:
> On 2019-02-18 22:24:35 -0500, Dennis Clarke wrote:
>> On 2/18/19 8:25 PM, Vincent Lefevre wrote:
>>> On 2019-02-18 16:44:48 -0500, Dennis Clarke wrote:
>>>>
>>>> This may seem like a strange question but I am running into many
>>>> problems while trying to build gcc 8.2.0 for a RISC-V target. With
>>>> a cross compiler toolset I am easily able to create output ELF files
>>>> for the rv64gc architecture and so that is not a problem. However that
>>>> is only possible ( thus far ) when building gmp separately. The gcc code
>>>> requires that I extract the gmp/mpfr/mpc sources inside the gcc sources
>>>> tree and then build/bootstrap gcc which in turns rebuilds gmp all over
>>>> again.  Regardless if it is pre-installed elsewhere or not.
>>> [...]
>>>
>>> Isn't this a question for the gcc-help mailing-list?
>>>
>>
>> Well yes, it is. However given that the problem occurs within the gmp
>> and mpfr source builds I felt it can not hurt to ask here.  Given that
>> no one seems to know what to do really.
> 
> It seems more likely to be an issue with the gcc build scripts.
> I don't think that GMP and MPFR can or should do anything.
> 

Well said.  I just hope I can figure this out.

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

Re: not really a bug .. is there a way to set the host type in the Makefile.am ?

[Dennis Clarke]

On 2/18/19 8:25 PM, Vincent Lefevre wrote:
> On 2019-02-18 16:44:48 -0500, Dennis Clarke wrote:
>>
>> This may seem like a strange question but I am running into many
>> problems while trying to build gcc 8.2.0 for a RISC-V target. With
>> a cross compiler toolset I am easily able to create output ELF files
>> for the rv64gc architecture and so that is not a problem. However that
>> is only possible ( thus far ) when building gmp separately. The gcc code
>> requires that I extract the gmp/mpfr/mpc sources inside the gcc sources
>> tree and then build/bootstrap gcc which in turns rebuilds gmp all over
>> again.  Regardless if it is pre-installed elsewhere or not.
> [...]
> 
> Isn't this a question for the gcc-help mailing-list?
> 

Well yes, it is. However given that the problem occurs within the gmp
and mpfr source builds I felt it can not hurt to ask here.  Given that
no one seems to know what to do really.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

not really a bug .. is there a way to set the host type in the Makefile.am ?

[Dennis Clarke]

hecking for _mulx_u64... cannot test, assume no
checking for long double... yes
checking format of `long double' floating point... IEEE quad, little endian
checking for TLS support using C11... cannot test, assume no
checking for TLS support... cannot test, assume no
checking if __float128 with hex constants is supported... no
checking for Static Assertion support... yes
checking for library containing clock_gettime... none required
checking for gmp.h... yes
checking whether gcc __attribute__ ((mode (XX))) works... yes
checking for recent GMP... yes
checking usable gmp.h at link time... yes
checking for GMP_NUMB_BITS and sizeof(mp_limb_t) consistency... cannot test
checking for __gmpz_init in -lgmp... no
configure: error: libgmp not found or uses a different ABI (including
static vs shared).
Please read the INSTALL file -- see "In case of problem".
gmake[1]: *** [Makefile:5139: configure-mpfr] Error 1
gmake[1]: Leaving directory
'/usr/home/dclarke/rv64g_local/build/gcc-8.2.0_rv64imafdc.008'
gmake: *** [Makefile:906: all] Error 2
vesta_$

Very annoying given that the gmp library archive was just created
moments ago within the gcc build process. Wrongly.

So the question is ... can I edit the gmp Makefile.in/Makefile.am files
to force the correct "Host type" --host=riscv64-unknown-freebsd12.0 data
in there?

-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional



signature.asc
Description: OpenPGP digital signature
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

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

[Dennis Clarke]

On 12/30/18 11:45 AM, Jeffrey Walton wrote:

On Sun, Dec 30, 2018 at 11:12 AM Torbjörn Granlund  wrote:


Jeffrey Walton  writes:

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

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

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

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

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

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


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

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

What is wrong is obvious. The build is broken.



Maybe I am missing something here. I have an arm7 unit here :

arm7$ uname -a
Linux arm7 4.4.132+ #1 SMP Tue Oct 23 18:03:49 CST 2018 armv7l GNU/Linux
arm7$ head /proc/cpuinfo
processor   : 0
model name  : ARMv7 Processor rev 1 (v7l)
BogoMIPS: 48.00
Features: half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
vfpv4 idiva idivt vfpd32 lpae evtstrm

CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xc0d
CPU revision: 1

arm7$

arm7$ cat ver.c

#define _XOPEN_SOURCE 600

#include 
#include 
#include 
#include 
#include 

void mpfr_version_report();

int main (int argc, char *argv[])
{
mpfr_version_report();
return EXIT_SUCCESS;
}

arm7$

arm7$ cat  mpfr_ver.c

#define _XOPEN_SOURCE 600

#include 
#include 
#include 
#include 
#include 

void mpfr_version_report()
{

printf("GMP  library version : %d.%d.%d\n",
__GNU_MP_VERSION,
__GNU_MP_VERSION_MINOR,
__GNU_MP_VERSION_PATCHLEVEL );

printf("MPFR library: %-12s\n", mpfr_get_version ());
printf("MPFR header : %s (based on %d.%d.%d)\n",
MPFR_VERSION_STRING,
MPFR_VERSION_MAJOR,
MPFR_VERSION_MINOR,
MPFR_VERSION_PATCHLEVEL);

if (mpfr_buildopt_tls_p()!=0)
printf(": compiled as thread safe using TLS\n");

if (mpfr_buildopt_float128_p()!=0)
printf(": __float128 support enabled\n");

if (mpfr_buildopt_decimal_p()!=0)
printf(": decimal float support enabled\n");

if (mpfr_buildopt_gmpinternals_p()!=0)
printf(": compiled with GMP internals\n");

if (mpfr_buildopt_sharedcache_p()!=0)
printf(": threads share cache per MPFR const\n");

printf("MPFR thresholds file used at compile time : %s\n",
  mpfr_buildopt_tune_case ());

}

arm7$ file ver
ver: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 
3.2.0, BuildID[sha1]=606244578692f7d651c024dc7d7c7eed2deb47c5, not stripped

arm7$ ldd ver
linux-vdso.so.1 (0xbef3e000)
libgmp.so.10 => /opt/bw/lib/libgmp.so.10 (0xb6ef)
libmpfr.so.6 => /opt/bw/lib/libmpfr.so.6 (0xb6e48000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d46000)
/lib/ld-linux-armhf.so.3 (0xb6fa2000)
arm7$ ./ver
GMP  library version : 6.1.2
MPFR library: 4.0.1-p13
MPFR header : 4.0.1-p13 (based on 4.0.1)
: compiled as thread safe using TLS
MPFR thresholds file used at compile time : src/arm/mparam.h
arm7$

Both gmp and mpfr compile and test fine on this arm7 unit here.

Download the sources and try a reconfigure with trivial CFLAGS like
 -std=c99 -g -march=armv7-a -O0 and not much else.

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

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

[Dennis Clarke]

On 11/19/18 5:40 AM, Torbjörn Granlund wrote:

Richard Biener  writes:

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

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

   #include 
   #include 

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


using that test I see 100% cpu and slowly growing RSS with a lot of time 
being spent inside mpn_fft_fft and then mpn_fft_mul_2exp_modF :


Program received signal SIGINT, Interrupt.
0x0008002dcd04 in __gmpn_copyi () from 
/home/dclarke/local/lib/libgmp.so.10

(gdb) where
#0  0x0008002dcd04 in __gmpn_copyi ()
   from /home/dclarke/local/lib/libgmp.so.10
#1  0x00080029a021 in mpn_fft_mul_2exp_modF (r=0x800e47610, 
a=0x80150bcb0,

d=1600, n=40) at mul_fft.c:267
#2  0x00080029a3f0 in mpn_fft_fft (Ap=0x800e8e130, K=32, 
ll=0x800e00098,

omega=160, n=40, inc=16, tp=0x800e47610) at mul_fft.c:391
#3  0x00080029a351 in mpn_fft_fft (Ap=0x800e8dc30, K=64, 
ll=0x800e000a0,

omega=80, n=40, inc=8, tp=0x800e47610) at mul_fft.c:383
#4  0x00080029a3b2 in mpn_fft_fft (Ap=0x800e8dc10, K=128, 
ll=0x800e000a8,

omega=40, n=40, inc=4, tp=0x800e47610) at mul_fft.c:384
#5  0x00080029a351 in mpn_fft_fft (Ap=0x800e8dc10, K=256, 
ll=0x800e000b0,

omega=20, n=40, inc=2, tp=0x800e47610) at mul_fft.c:383
#6  0x00080029a351 in mpn_fft_fft (Ap=0x800e8dc10, K=512, 
ll=0x800e000b8,

omega=10, n=40, inc=1, tp=0x800e47610) at mul_fft.c:383
#7  0x0008002995ff in mpn_mul_fft_internal (op=0x8014d4150, pl=9728, 
k=9,
Ap=0x800e8dc10, Bp=0x800e8b410, A=0x8014fd610, B=0x801060950, 
nprime=40,

l=19, Mp=5, fft_l=0x800e00070, T=0x800e47610, sqr=1) at mul_fft.c:738
#8  0x000800298ef8 in __gmpn_mul_fft (op=0x8014d4150, pl=9728,
n=0x801336980, nl=9475, m=0x801336980, ml=9475, k=9) at mul_fft.c:904
#9  0x0008002cc6d6 in __gmpn_sqrmod_bnm1 (rp=0x8014a8500, rn=19456,
ap=0x801336980, an=9475, tp=0x8014d4150) at sqrmod_bnm1.c:194
#10 0x00080029c568 in __gmpn_nussbaumer_mul (pp=0x8014a8500,
ap=0x801336980, an=9475, bp=0x801336980, bn=9475) at 
nussbaumer_mul.c:61

--Type  for more, q to quit, c to continue without paging--
#11 0x00080029b80f in __gmpn_sqr (p=0x8014a8500, a=0x801336980, n=9475)
at sqr.c:97
#12 0x000800371726 in mpfr_sqrhigh_n (rp=0x801483500, np=0x801324180,
n=18947) at mulders.c:180
#13 0x00080031c0ab in mpfr_mul (a=0x7fffde50, b=0x7fffde50,
c=0x7fffde50, rnd_mode=MPFR_RNDD) at mul.c:968
#14 0x00080036b2c0 in mpfr_sqr (a=0x7fffde50, b=0x7fffde50,
rnd_mode=MPFR_RNDD) at sqr.c:561
#15 0x000800312bd0 in mpfr_exp_3 (y=0x7fffe350, x=0x7fffe380,
rnd_mode=MPFR_RNDD) at exp3.c:232
#16 0x00080031487f in mpfr_exp (y=0x7fffe350, x=0x7fffe380,
rnd_mode=MPFR_RNDD) at exp.c:176
#17 0x00080033a525 in mpfr_sinh_cosh (sh=0x7fffe550,
ch=0x7fffe530, xt=0x7fffe880, rnd_mode=MPFR_RNDN)
at sinh_cosh.c:108
#18 0x0008003bf37b in mpc_sin_cos (rop_sin=0x7fffe7e0,
rop_cos=0x7fffe7a0, op=0x7fffe860, rnd_sin=17, rnd_cos=17)
at sin_cos.c:390
#19 0x0008003c3756 in mpc_tan (rop=0x7fffe860, op=0x7fffe860,
rnd=0) at tan.c:196
#20 0x002013c0 in main () at test_case.c:19
(gdb) quit
A debugging session is active.

Inferior 1 [process 58829] will be killed.

Quit anyway? (y or n) y
titan$

This is gmp 6.1.2 and mpfr-4.0.1-p13 and mpc-1.1.0 on FreeBSD 12.0RC1
 and I also see similar behavior on Solaris SPARC.



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



Well the test case provided merely packs up and goes away with no
indication that it will return anytime soon.

I am just going to watch this thread closely.

Dennis

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

Re: Likely GMP bug

[Dennis Clarke]

On 05/25/2018 04:30 PM, Torbjörn Granlund wrote:

Dennis Clarke <dcla...@blastwave.org> writes:

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

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

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

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




OKay .. same result here :

phobos$ gcc --version
gcc (genunix Thu May 17 17:47:37 UTC 2018) 8.1.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

phobos$ ./configure ABI=32 --enable-cxx --prefix=/usr/local 
--libdir=/usr/local/lib --with-gnu-ld --disable-assembly


PASS: t-aors
FAIL: t-cmp
FAIL: t-cmp_ui
PASS: t-cmp_si
PASS: t-equal
PASS: t-get_d
PASS: t-get_str
PASS: t-inp_str
PASS: t-inv
PASS: t-md_2exp
PASS: t-set_f
PASS: t-set_str
PASS: io
PASS: reuse
PASS: t-cmp_z

Testsuite summary for GNU MP 6.1.99

# TOTAL: 15
# PASS:  13
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0



phobos$ gdb tests/mpq/t-cmp_ui
GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from tests/mpq/t-cmp_ui...done.
warning: File 
"/usr/local/build/gmp-6.1.99-20180525_4.16.4-genunix_i686.003/.gdbinit" 
auto-loading has been declined by your `auto-load safe-path' set to 
"$debugdir:$datadir/auto-load".

To enable execution of this file add
add-auto-load-safe-path 
/usr/local/build/gmp-6.1.99-20180525_4.16.4-genunix_i686.003/.gdbinit

line to your configuration file "/home/dclarke/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/dclarke/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the 
shell:

info "(gdb)Auto-loading safe path"
(gdb) dir 
/usr/local/build/gmp-6.1.99-20180525_4.16.4-genunix_i686.003/mpn:/usr/local/build/gmp-6.1.99-20180525_4.16.4-genunix_i686.003/mpn/generic 

Source directories searched: 
/usr/local/build/gmp-6.1.99-20180525_4.16.4-genunix_i686.003/mpn:/usr/local/build/gmp-6.1.99-20180525_4.16.4-genunix_i686.003/mpn/generic:$cdir:$cwd

(gdb) break gcd_1.c:187
No source file named gcd_1.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (gcd_1.c:187) pending.
(gdb) run
Starting program: 
/usr/local/build/gmp-6.1.99-20180525_4.16.4-genunix_i686.003/tests/mpq/t-cmp_ui 


[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
warning: File "/usr/local/gcc8/lib/libstdc++.so.6.0.25-gdb.py" 
auto-loading has been declined by your `auto-load safe-path' set to 
"$debugdir:$datadir/auto-load".

Re-seeding with GMP_CHECK_RANDOMIZE=140064609456624

Breakpoint 1, __gmpn_gcd_1 (up=0xb690, size=1, vlimb=100580449) at 
gcd_1.c:187

187   ulimb >>= (c + 1);
(gdb) print c
$1 = 1
(gdb) print c=30
$2 = 30
(gdb) cont
Continuing.

Breakpoint 1, __gmpn_gcd_1 (up=0xb690, size=1, vlimb=0) at gcd_1.c:187
187   ulimb >>= (c + 1);
(gdb) print c=31
$3 = 31
(gdb) frame
#0  __gmpn_gcd_1 (up=0xb690, size=1, vlimb=0) at gcd_1.c:187
187   ulimb >>= (c + 1);
(gdb) bt
#0  __gmpn_gcd_1 (up=0xb690, size=1, vlimb=0) at gcd_1.c:187
#1  0xb7ec6bef in gcd_2 (gp=0xb690, up=0xb570, vp=0xb6b0) at 
gcd.c:129
#2  0xb7ec81c3 in __gmpn_gcd (gp=0xb690, up=0xb570, usize=4, 
vp=

Re: Likely GMP bug

[Dennis Clarke]

On 05/25/2018 08:10 AM, Niels Möller wrote:

Dennis Clarke <dcla...@blastwave.org> writes:


gcd_1.c:187:13: runtime error: shift exponent 32 is too large for
32-bit type 'long unsigned int'
FAIL t-cmp_ui (exit status: 1)


And code is essentially

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

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

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


I would have thought the deBruijn hash method works for all 32-bit
values to find trailing consecutive zero bits :

http://graphics.stanford.edu/~seander/bithacks.html#ZerosOnRightMultLookup



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

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


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

I'd love to see an isolated code case that creates that runtime error.

Dennis

ps: hours later

phobos$
phobos$ find . -type f -ls | grep "gcd_1" | awk '{ printf("%4i%s\n", 
$7, $11 )}'

7158./mpn/ia64/gcd_1.asm
7192./mpn/gcd_1.o
4465./mpn/generic/gcd_1.c
7516./mpn/.libs/gcd_1.o
4125./mpn/x86/k7/gcd_1.asm
6418./mpn/x86/k6/gcd_1.asm
3820./mpn/x86/p6/gcd_1.asm
1057./mpn/x86/fat/gcd_1.c
3323./mpn/sparc64/gcd_1.asm
2807./mpn/powerpc64/mode64/gcd_1.asm
2520./mpn/powerpc64/mode64/p7/gcd_1.asm
2983./mpn/arm64/gcd_1.asm
2819./mpn/arm/v5/gcd_1.asm
2756./mpn/arm/v6t2/gcd_1.asm
4198./mpn/alpha/ev67/gcd_1.asm
 267./mpn/gcd_1.lo
1255./mpn/x86_64/bd1/gcd_1.asm
1255./mpn/x86_64/k10/gcd_1.asm
4260./mpn/x86_64/gcd_1.asm
4228./mpn/x86_64/core2/gcd_1.asm
1255./mpn/x86_64/zen/gcd_1.asm
1255./mpn/x86_64/nano/gcd_1.asm
phobos$ cat mpn/generic/gcd_1.c
/* mpn_gcd_1 -- mpn and limb greatest common divisor.

Copyright 1994, 1996, 2000, 2001, 2009, 2012 Free Software Foundation, Inc.

This file is part of the GNU MP Library.

The GNU MP Library is free software; you can redistribute it and/or modify
it under the terms of either:

  * the GNU Lesser General Public License as published by the Free
Software Foundation; either version 3 of the License, or (at your
option) any later version.

or

  * the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any
later version.

or both in parallel, as here.

The GNU MP Library is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.

You should have received copies of the GNU General Public License and the
GNU Lesser General Public License along with the GNU MP Library.  If not,
see https://www.gnu.org/licenses/.  */

#include "gmp-impl.h"
#include "longlong.h"

#ifndef GCD_1_METHOD
#define GCD_1_METHOD 2
#endif

#define USE_ZEROTAB 0

#if USE_ZEROTAB
#define MAXSHIFT 4
#define MASK ((1 << MAXSHIFT) - 1)
static const unsigned char zerotab[1 << MAXSHIFT] =
{
#if MAXSHIFT > 4
  5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
#endif
  4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0
};
#endif

/* Does not work for U == 0 or V == 0.  It would be tough to make it 
work for

   V == 0 since gcd(x,0) = x, and U does not generally fit in an mp_limb_t.

   The threshold for doing u%v when size==1 will vary by CPU according to
   the speed of a division and the code generated for the main loop.  Any
   tuning for this is left to a CPU specific implementation.  */

mp_limb_t
mpn_gcd_1 (mp_srcptr up, mp_size_t size, mp_limb_t vlimb)
{
  mp_limb_t  ulimb;
  unsigned long  zero_bits, u_low_zero_bits;

  ASSERT (size >= 1);
  ASSERT (vlimb != 0);
  ASSERT_MPN_NONZERO_P (up, size);

  ulimb = up[0];

  /* Need vlimb odd for modexact, want it odd to get common zeros. */
  count_trailing_zeros (zero_bits, vlimb);
  vlimb >>= zero_bits;

  if (size > 1)
{
  /* Must get common zeros before the mod reduction.  If ulimb==0 then
 vlimb already gives the common zeros.  */
  if (ulimb != 0)
{
  count_trailing_zeros (u_low_zero_bits, ulimb);
  zero_bits = MIN (zero_bits, u_low_zero_bits);
}

  ulimb = MPN_MOD_OR_MODEXACT_1_ODD (up, size, vlimb);
  if (ulimb == 0)
goto done;

  goto strip_u_maybe;
}

  /* size==1, so up[0]!=0 */
  count_trailing_zeros (u_low_zero_bits, ulimb);
  ulimb >>= u_low_zero_bits;
  zero_bits = MIN (zero_bits, u_low_zero_bits);

  /* make u bigger */
  if (vlimb > ulimb)
MP_LIMB_T_SWAP (ulimb, vlimb);

  /* if u is much bigger than v, reduce using a division rather than
 chipping away a

Re: Likely GMP bug

[Dennis Clarke]

On 05/25/2018 04:45 AM, Torbjörn Granlund wrote:

If somebody could take a look at

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

I would appreciate it.  (I  am traveling.)



This seems to require --disable-assembly during configure ..
... starting over   :-\

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

Re: Likely GMP bug

[Dennis Clarke]

On 05/25/2018 04:45 AM, Torbjörn Granlund wrote:

If somebody could take a look at

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

I would appreciate it.  (I  am traveling.)



Not able to reproduce that failure with gmp-6.1.99-20180525 :


configure: summary of build options:

  Version:   GNU MP 6.1.99
  Host type: pentium2-pc-linux-gnu
  ABI:   32
  Install prefix:/usr/local
  Compiler:  gcc
  Static libraries:  yes
  Shared libraries:  yes


Every test passes.

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

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

[Dennis Clarke]

On 11/02/18 08:15 PM, Vincent Lefevre wrote:

On 2018-02-11 10:40:55 +0100, Torbjorn Granlund wrote:

Dennis Clarke <dcla...@blastwave.org> writes:

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

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


Or you can just add a dummy typedef to ensure that the translation unit
is not empty.



As a minor annoyance it does cause gcc ( recent versions 7.x ) to fail.
Oddly enough ye Oracle Studio 12.6 cc running in strict c99 mode is fine
and happy with everything. That is a new experience for me. However the
performance on sparc is miserable.  We all know this and we know why.

Dennis


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

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

[Dennis Clarke]

Most likely something that can be ignored but saw this on my PPC970MP
based Debian system when doing a compile with pedantic CFLAGS :

.
.
.
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. 
-g -m64 -std=iso9899:1999 -Wfatal-errors -pedantic-errors 
-Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec -mfull-toc -mregnames -c 
repl-vsnprintf.c  -fPIC -DPIC -o .libs/repl-vsnprintf.o
repl-vsnprintf.c:396:0: error: ISO C forbids an empty translation unit 
[-Wpedantic]

 #endif /* ! HAVE_VSNPRINTF */

compilation terminated due to -Wfatal-errors.
gmake[2]: *** [Makefile:435: repl-vsnprintf.lo] Error 1
gmake[2]: Leaving directory 
'/usr/local/build/gmp-6.1.2_linux_4.13.0-1-powerpc64.003/printf'

gmake[1]: *** [Makefile:956: all-recursive] Error 1
gmake[1]: Leaving directory 
'/usr/local/build/gmp-6.1.2_linux_4.13.0-1-powerpc64.003'

gmake: *** [Makefile:775: all] Error 2
Command exited with non-zero status 2


I removed the obvious options and config.log says :

using ABI="mode64"
  CC="gcc"
  CFLAGS="-g -m64 -std=iso9899:1999 -Wl,-rpath=/usr/local/lib 
-mcpu=970 -maltivec -mfull-toc -mregnames"

  CPPFLAGS=""
  CXX="g++"
  CXXFLAGS="-g -m64 -std=iso9899:1999 -Wl,-rpath=/usr/local/lib 
-mcpu=970 -maltivec -mfull-toc -mregnames"
  MPN_PATH=" powerpc64/mode64/p4 powerpc64/p4 
powerpc64/mode64/p3-p7 powerpc64/p3-p7 powerpc64/mode64 powerpc64/vmx 
powerpc64 generic"



Which compiles and tests just fine.

Dennis

___
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 ) );
}
}
f

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

[Dennis Clarke]

On 8/28/17 5:36 PM, Torbjörn Granlund wrote:

Dennis Clarke <dcla...@blastwave.org> writes:

   somedays I don't include details and I get railed at .. other days I
   do and I get railed at .. life goes on.
   
Did Niels rail you?  I think that's a quite unfair assessment.  He's


no ... I jsut know that I can be verbose. isn't the first time.


pointing out a central issue here, your snub is the attitude problem
here, if any.


yep



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


I'm just trying to figure out how to squeeze some performance out of a 
few weird processor types.


dc

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

On 8/28/17 5:33 PM, Niels Möller wrote:

Vincent Lefevre  writes:


This only works if the user is root. If a non-root user wants to
install libraries in his home directory, the right solution is to
use LD_LIBRARY_PATH (since GCC doesn't use a run path by default).


I never build things as root. Or run tests. The install phase is done
as root of course and then I check the chmod/attr bits on the output.



You'd either use LD_LIBRARY_PATH, which is going to be a bit brittle



The LD_LIBRARY_PATH env var works as expected on Solaris systems just
as it should ( x86/sparc/POWER7 ? ) but I generally avoid it.



(I should probably not speculate more on exactly how it fails, but I'd
be happy to hear the precise explanation if someone here really knows
the automake magic involved).


I have no clue about automake incantations and spells. :-)

dc

___
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

[Dennis Clarke]

On 8/28/17 5:21 PM, Niels Möller wrote:

Dennis Clarke <dcla...@blastwave.org> writes:


On 8/28/17 4:41 PM, Niels Möller wrote:

Dennis Clarke <dcla...@blastwave.org> writes:




The compiler sees that file gcd_1.asm as something unknown.


That command is bogus.


I think you missed the point.


Then please enlighten me? I'm trying to help, even though I have to
admit that I didn't read carefully all of your 1000+ lines email. My
points are that


somedays I don't include details and I get railed at .. other days I do 
and I get railed at .. life goes on.




1. Invoking any compiler with $(CC) ... -o foo.o foo.asm, like the
failing command you showed, is not expected to work.


yep .. I would think a foo.s is what is needed and as you say m4 had to
 pre-process the input from somewhere else first.



2. GMP's Makefiles are not expected to try to do that; if they do on
your platform, we'd need to figure out why.


sorry .. lost me there.




That libgmpxx depends on libstdc++ is perfectly normal ..


Yes, if gcc is used then you end up with these dependencies.
That doesn't happen with the Oracle Studio 12.5 dev tools compilers.


To clarify, I'd expect libgmpxx to depend on the C++ standard library
supplied with the compiler used to build gmp.


This is all that is left as NEEDED in the output final libs :

v9_7++ $ elfdump -devl  /usr/local/lib/libgmp.so.10.3.2 | grep "NEED"
   [0]  NEEDED0x2c4f  libc.so.1
  [12]  VERNEED   0x8520
  [13]  VERNEEDNUM0x1

v9_7++ $ elfdump -devl /usr/local/lib/libgmpxx.so.4.5.2 | grep "NEED"
   [0]  NEEDED0x229f  libgmp.so.10
   [1]  NEEDED0x2283  libc.so.1
  [13]  VERNEED   0x3d20
  [14]  VERNEEDNUM0x1

Very minimal.  Very very terribly slow.


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

[Dennis Clarke]

On 8/28/17 5:01 PM, Marc Glisse wrote:

On Sun, 27 Aug 2017, Dennis Clarke wrote:


I have been trying to get gmp-6.1.2 to build while avoiding the use of
"disable-assembly" in the configure stage. I think I may have tripped on
something here.  So I isolated everything into my home dir and gave it
a try.  Mostly trying to get some decent performance.


If you care about performance, use gcc to compile GMP. The only good
reason to compile GMP with studio is for gmpxx for ABI reasons.



Yep. I was thinking consistency across a whole toolchain wherein gcc has
not been used and there are no dependencies on libgcc or its brethern.


Configure looks fine thus :

v9_7++ $ ./configure ABI=64 --enable-cxx \

--prefix=/export/home/dclarke/local \
--libdir=/export/home/dclarke/local/lib \


that libdir is redundant.


I figured .. left it in there for years.  gone now.




--build=sparc64-sun-solaris2.10


so you are explicitly trying to disable some optimizations?

checking compiler /opt/developerstudio12.5/bin/c99 -errfmt=error 
-erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s 
-xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs 
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xarch=sparc -I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE... yes




First past .. yes. However I go back and reset those flags to enable
optimizations and remove the debug data. However, I sort of wanted the
debug data and the ability to single step along. It has to be a trade
off with debug libs residing somewhere else I guess.



gmake[2]: *** [Makefile:768: gcd_1.lo] Error 1


this isn't giving any hint as to what the error is :-(


yep .. I was told that m4 needs to pre-process those asm files and we
 should get output foo.s files.


  Should I even care?


No (to the last question).


Let me think on that.




Better than before but a 12 year old PowerMac G5 does the same job in
just about 3.5 secs. An AMD Opteron at 3GHz does it all faster than 
that and I hear from Paul Zimmermann that his laptop is sub-second. 
Not sure

how to get some performance out of libgmp on this platform.  Am really
open to any thoughts.


If you care about GMP performance, don't use sparc... 


I have access to a M7 based 4.1GHz system. It is fairly amazing in terms
of pure speed.  However it can not be had unless the Oracle compilers
are used.

$ fpversion
 A SPARC-based CPU is available.
 Kernel says CPU's clock rate is 4133.2 MHz.

 Sun-4 floating-point controller version 0 found.
 An UltraSPARC chip is available.

 Use "-xtarget=M7 -xcache=16/32/4/8:256/64/8/16:8192/64/8/32" 
code-generation option.


 Hostid = 0x865DA634.
$

$ file pi6_256M
pi6_256M: ELF 64-bit MSB executable SPARCV9 Version 1, UltraSPARC3 
Extensions Required [CBCOND VIS3], dynamically linked, not stripped

$

$ which openssl
/usr/ccs/bin/openssl
$ openssl speed sha512
Doing sha512 for 3s on 16 size blocks: 18525471 sha512's in 2.99s
Doing sha512 for 3s on 64 size blocks: 20462241 sha512's in 3.00s
Doing sha512 for 3s on 256 size blocks: 11174149 sha512's in 3.00s
Doing sha512 for 3s on 1024 size blocks: 4919522 sha512's in 3.00s
Doing sha512 for 3s on 8192 size blocks: 791410 sha512's in 3.00s
OpenSSL 1.0.1p 9 Jul 2015
built on: date not available
options:bn(64,32) md2(int) rc4(ptr,int) des(ptr,risc1,16,int) 
aes(partial) blowfish(ptr)

compiler: information not available
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 
bytes
sha512   99132.96k   436527.81k   953527.38k  1679196.84k 
2161076.91k

$

I don't know what good numbers are but that looks good.  There has
been a ton of money poured into the sparc platform in recent years and
the result is a fairly staggering system.  I think Rainer Orth has done
some work with gcc therein also but the Oracle Studio compilers are the
ones that are built to take advantage of these chips. So the marketing
goes.  :-\

Anyways, whatever it is these assembly files bring to the table may be
rocket science and I was merely trying to get gmp builds, reasonable
builds, across a whole suite of platforms. SPARC is a lot of things but
it isn't dead.

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

[Dennis Clarke]

On 8/28/17 4:41 PM, Niels Möller wrote:

Dennis Clarke <dcla...@blastwave.org> writes:




The compiler sees that file gcd_1.asm as something unknown.


That command is bogus.


I think you missed the point.

That libgmpxx depends on libstdc++ is perfectly normal .. 


Yes, if gcc is used then you end up with these dependencies.
That doesn't happen with the Oracle Studio 12.5 dev tools compilers.
Either way the point is academic as one can not build gmp and use those
assembly tweaks with anything else other than gcc. So perhaps this is
a build process issue wherein m4 is not being called correctly to
output the needed asm source foo.s files.

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

assembly files on Solaris SPARC can only be processed with gcc

[Dennis Clarke]

I have been trying to get gmp-6.1.2 to build while avoiding the use of
"disable-assembly" in the configure stage. I think I may have tripped on
something here.  So I isolated everything into my home dir and gave it
a try.  Mostly trying to get some decent performance.

Configure looks fine thus :

v9_7++ $ ./configure ABI=64 --enable-cxx \
> --prefix=/export/home/dclarke/local \
> --libdir=/export/home/dclarke/local/lib \
> --build=sparc64-sun-solaris2.10
checking build system type... sparc64-sun-solaris2.10
checking host system type... sparc64-sun-solaris2.10
checking for a BSD-compatible install... ./install-sh -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... /usr/local/bin/gawk
checking whether /usr/local/bin/gmake sets $(MAKE)... yes
checking whether /usr/local/bin/gmake supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking ABI=64
checking compiler /opt/developerstudio12.5/bin/c99 -errfmt=error 
-erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s 
-xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs 
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xarch=sparc -I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE... yes
checking compiler /opt/developerstudio12.5/bin/c99 -errfmt=error 
-erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s 
-xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs 
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xarch=sparc has sizeof(long)==8... yes

checking for gcc... /opt/developerstudio12.5/bin/c99
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether /opt/developerstudio12.5/bin/c99 accepts -g... yes
checking for /opt/developerstudio12.5/bin/c99 option to accept ISO 
C89... none needed
checking whether /opt/developerstudio12.5/bin/c99 understands -c and -o 
together... yes
checking for /opt/developerstudio12.5/bin/c99 option to accept ISO 
C99... none needed
checking for /opt/developerstudio12.5/bin/c99 option to accept ISO 
Standard C... (cached) none needed
checking how to run the C preprocessor... 
/opt/developerstudio12.5/bin/c99 -E

checking build system compiler /opt/developerstudio12.5/bin/c99... no
checking build system compiler /opt/developerstudio12.5/bin/c99 
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 
-xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 
-xarch=sparc -I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE... yes
checking for build system preprocessor... 
/opt/developerstudio12.5/bin/c99 -errfmt=error -erroff=%none 
-errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc 
-xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy 
-xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc 
-I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -E

checking for build system executable suffix...
checking whether build system compiler is ANSI... yes
checking for build system compiler math library... -lm
checking whether we are using the GNU C++ compiler... no
checking whether /opt/developerstudio12.5/bin/CC accepts -g... yes
checking C++ compiler /opt/developerstudio12.5/bin/CC 
-I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -dalign -erroff=%none 
-errtags=yes -ftrap=%none -g -xcode=pic32 -m64 -mc -xunroll=1 
-xbuiltin=%none -xarch=sparc -xdepend=no -xnolibmopt -xlinkopt=0 
-xnolibmil -xregs=no%appl -xs -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -D_TS_ERRNO... yes
checking how to run the C++ preprocessor... 
/opt/developerstudio12.5/bin/CC -E

checking for grep that handles long lines and -e... /usr/local/bin/grep
checking for egrep... /usr/local/bin/grep -E
using ABI="64"
  CC="/opt/developerstudio12.5/bin/c99"
  CFLAGS="-errfmt=error -erroff=%none -errshort=full -xstrconst 
-xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 -xregs=no%appl 
-xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none 
-xdebugformat=dwarf -xunroll=1 -xarch=sparc"
  CPPFLAGS="-I/export/home/dclarke/local/include -D_TS_ERRNO 
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE"

  CXX="/opt/developerstudio12.5/bin/CC"
  CXXFLAGS="-dalign -erroff=%none -errtags=yes -ftrap=%none -g 
-xcode=pic32 -m64 -mc -xunroll=1 -xbuiltin=%none -xarch=sparc 
-xdepend=no -xnolibmopt -xlinkopt=0 -xnolibmil -xregs=no%appl -xs 
-D_POSIX_PTHREAD_SEMANTICS 

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

[Dennis Clarke]

This feels like a build test sequence issue as opposed to a bug of any
real sort.  I have pre-existing gmp libs installed in /usr/local from
yesterday and am doing a reconfigure and rebuild today. On a Debian 8.8
system 3.16.0-4-powerpc64 with gcc Debian 4.9.2-10 I see a complete
configure and compile thus :

ppc64$ ./configure ABI=mode64 --enable-cxx --prefix=/usr/local \
> --libdir=/usr/local/lib --build=powerpc970-unknown-linux-gnu
checking build system type... powerpc970-unknown-linux-gnu
checking host system type... powerpc970-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking ABI=mode64
checking compiler gcc -m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 
-maltivec -mfull-toc -mregnames ... yes
checking compiler gcc -m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 
-maltivec -mfull-toc -mregnames has sizeof(long)==8... yes

checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for gcc option to accept ISO C99... -std=gnu99
checking for gcc -std=gnu99 option to accept ISO Standard C... (cached) 
-std=gnu99

checking how to run the C preprocessor... gcc -std=gnu99 -E
checking build system compiler gcc -std=gnu99... yes
checking for build system preprocessor... gcc -std=gnu99 -E
checking for build system executable suffix...
checking whether build system compiler is ANSI... yes
checking for build system compiler math library... -lm
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking C++ compiler g++  -m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 
-maltivec -mfull-toc -mregnames... yes

checking how to run the C++ preprocessor... g++ -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
using ABI="mode64"
  CC="gcc -std=gnu99"
  CFLAGS="-m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec 
-mfull-toc -mregnames"

  CPPFLAGS=""
  CXX="g++"
  CXXFLAGS="-m64 -O2 -Wl,-rpath=/usr/local/lib -mcpu=970 -maltivec 
-mfull-toc -mregnames"
  MPN_PATH=" powerpc64/mode64/p4 powerpc64/p4 
powerpc64/mode64/p3-p7 powerpc64/p3-p7 powerpc64/mode64 powerpc64/vmx 
powerpc64 generic"

checking whether assembler supports --noexecstack option... no
checking for ar... ar
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc -std=gnu99... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert powerpc970-unknown-linux-gnu file names to 
powerpc970-unknown-linux-gnu format... func_convert_file_noop
checking how to convert powerpc970-unknown-linux-gnu file names to 
toolchain format... func_convert_file_noop

checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... dlltool
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc -std=gnu99 
object... ok

checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc -std=gnu99 supports -fno-rtti -fno-exceptions... no
checking for gcc -std=gnu99 option to produce PIC... -fPIC -DPIC
checking if gcc -std=gnu99 PIC flag -fPIC -DPIC works... yes
checking if gcc -std=gnu99 static flag -static works... yes
checking if gcc 

Problem with assembly sources on Solaris 10 SPARC with Oracle Studio 12.4

[Dennis Clarke]

Ran into this just yesterday with a build of libgmp 6.1.0 wherein the 
configure line was simply :


./configure ABI=64 --enable-cxx --prefix=/usr/local \
> --libdir=/usr/local/lib


When I try to compile I very soon run into :

 /opt/solarisstudio12.4/bin/cc -D_STDC_C99= -c -DHAVE_CONFIG_H -I. -I.. 
-D__GMP_WITHIN_GMP -I.. -DOPERATION_gcd_1 -I/usr/local/include 
-I/usr/local/ssl/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -errfmt=error -erroff=%none -errshort=full 
-xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 
-xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none 
-xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 
-xcache=8/16/4:4096/64/16 tmp-gcd_1.s -KPIC -DPIC -o .libs/gcd_1.o
libtool: compile:  ../mpn/m4-ccas --m4=/usr/local/bin/m4 
/opt/solarisstudio12.4/bin/cc -D_STDC_C99= -c -DHAVE_CONFIG_H -I. -I.. 
-D__GMP_WITHIN_GMP -I.. -DOPERATION_gcd_1 -I/usr/local/include 
-I/usr/local/ssl/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -errfmt=error -erroff=%none -errshort=full 
-xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xc -xcode=pic32 
-xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none 
-xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 
-xcache=8/16/4:4096/64/16 gcd_1.asm -o gcd_1.o >/dev/null 2>&1


gmake[2]: *** [gcd_1.lo] Error 1
gmake[2]: Leaving directory `/usr/local/build/gmp-6.1.0/mpn'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/local/build/gmp-6.1.0'
gmake: *** [all] Error 2


When I search for the file gcd_1.asm I see multiple for various 
architectures and I make the guess that mpn/tmp-gcd_1.s is based on the 
source ./sparc64/gcd_1.asm for this system.


Also I see these warnings over and over :


"../gmp-impl.h", line 3699: warning:  attribute "mode" is unknown, ignored
"../gmp-impl.h", line 3700: warning:  attribute "mode" is unknown, ignored
"../gmp-impl.h", line 3701: warning:  attribute "mode" is unknown, ignored
"../gmp-impl.h", line 3702: warning:  attribute "mode" is unknown, ignored
"../gmp-impl.h", line 3703: warning:  attribute "mode" is unknown, ignored


So the simple work around is to build with configure option 
--disable-assembly and then everything works fine.


If more info is required ( I am guessing ) then let me know.

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