Re: GMP 6.3.0: Failure building on MinGW (defaulting to ABI=64)
Am 10.12.2023 um 22:51 schrieb Marc Glisse: On Sun, 10 Dec 2023, Simon Sobisch wrote: $ ./config.guess && gcc --version && as --version gcc -v file.c gives more information about the assembler that is really used. Thank you for the note, I'll use this next time. On this specific machine there is only the old GNU assembler available, so it is quite sure that this was used. gcc.exe (MinGW.org GCC Build-2) 9.2.0 gcc-9 is old. Yes. I also run some GCC 4 on an old Linux kernel (also 32 bit) from time to time (but haven't checked GMP 6.3 there). I did not found a note about the minimal GCC version to build GMP - is there a documentation about that? (I see no reason why GCC 9 should not work) Isn't mingw.org abandoned? I thought everyone had moved to mingw-w64.org. "partial"; osdn.net is down so the downloading does not work any more so you can only install from a mirror or a backup, but of course existing installations still work. I _guess_ binaries from mingw-w64.org will need a "relative recent" version of the Windows operating system; "good old MinGW" still works fine with Windows XP (last time I've checked also with older versions); therefore using it to keep "legacy" environments up-to-date is still reasonable. ... and most other mingw binaries I've seen are much bigger than the ones originally distributed by mingw.org. using ABI="64" CC="gcc" CFLAGS="-Wno-attribute" Specifying CFLAGS yourself is not a great idea, it prevents GMP from adding nice optimization flags. If you really want to pass -Wno-attribute, either put it in CPPFLAGS, or run configure once without CFLAGS to see what GMP wants to use, and add -Wno-attribute to that. Good point. I've moved it to CPFFLAGS: configure ABI=64 CPPFLAGS="-Wno-attributes -Wno-ignored-attributes" The question is still why the ABI 64 is chosen on this system. Any idea? This error seems to be related to changing the ABI after the initial configure. Using "make distclean" fixes this. I therefore think that something like `AC_ARG_VAR([ABI], [Application Binary Interface to use])` (maybe also reference https://gmplib.org/manual/ABI-and-ISA in its description) should be added to configure.ac to make that error on an ABI change and also adding this missing piece to configure's help output. You mean this? https://gmplib.org/repo/gmp-6.3/file/tip/configure.ac#l455 I think it has been there for a while. Yes, exactly this. And executing ../configure --help | grep ABI I also see the help output. But somehow the documented result [1] of being precious > The value of variable when configure was launched is saved in the > cache, including if it was not specified on the command line but via > the environment. > variable is checked for consistency between two configure runs did not trigger: first not specifying [and leading to ABI=64], then specifying as ABI=32, did neither resulting in a configure error nor did it reused the old value. Simon [1]: https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Setting-Output-Variables.html ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
GMP 6.3.0: Failure building on MinGW (defaulting to ABI=64)
Problem when building from 6.3.0 release tarball: libtool: compile: ../mpn/m4-ccas --m4=m4 gcc -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_x86_64_add_n -Wno-attribute x86_64_add_n.asm -DDLL_EXPORT -DPIC -o .libs/x86_64_add_n.o m4 -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_x86_64_add_n -DDLL_EXPORT -DPIC x86_64_add_n.asm >tmp-x86_64_add_n.s gcc -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_x86_64_add_n -Wno-attribute tmp-x86_64_add_n.s -DDLL_EXPORT -DPIC -o .libs/x86_64_add_n.o tmp-x86_64_add_n.s: Assembler messages: tmp-x86_64_add_n.s:112: Error: bad register name `%rdi' tmp-x86_64_add_n.s:113: Error: bad register name `%rsi' tmp-x86_64_add_n.s:114: Error: bad register name `%rcx' tmp-x86_64_add_n.s:115: Error: bad register name `%rdx' tmp-x86_64_add_n.s:116: Error: bad register name `%r8' tmp-x86_64_add_n.s:117: Error: bad register name `%r9' tmp-x86_64_add_n.s:119: Error: bad register name `%rsp)' tmp-x86_64_add_n.s:121: Error: bad register name `%rcx' tmp-x86_64_add_n.s:123: Error: bad register name `%r8' tmp-x86_64_add_n.s:124: Error: `jrcxz' is only supported in 64-bit mode [...] make[2]: *** [x86_64_add_n.lo] Error 1 Environment: $ ./config.guess && gcc --version && as --version haswell-pc-mingw32 gcc.exe (MinGW.org GCC Build-2) 9.2.0 GNU assembler (GNU Binutils) 2.32 This assembler was configured for a target of `mingw32'. configure options: ./configure --prefix=/mingw --enable-fat \ --enable-shared --disable-static configure outputs: using ABI="64" CC="gcc" CFLAGS="-Wno-attribute" CPPFLAGS="" MPN_PATH=" x86_64/coreihwl x86_64/coreisbr x86_64/coreinhm x86_64/core2 x86_64 generic" checking if the assembler knows about the mulx instruction... no configure: WARNING: +-- configure: WARNING: | WARNING WARNING WARNING configure: WARNING: | Host CPU has the mulx instruction, but it can't be configure: WARNING: | assembled by configure: WARNING: | gcc -c configure: WARNING: | Older x86 instructions will be used. configure: WARNING: | This will be an inferior build. configure: WARNING: +-- configure: summary of build options: Version: GNU MP 6.3.0 Host type: haswell-pc-mingw32 ABI: 64 Install prefix:/mingw Compiler: gcc Static libraries: no Shared libraries: yes As the issue "obviously" is the ABI that doesn't match I've tried with ABI=32, which works a bit better, to then error with: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_fat_com -c fat_com.c -DDLL_EXPORT -DPIC -o .libs/fat_com.o In file included from ../gmp-impl.h:147, from ../mpn/generic/com.c:31, from .././mpn/x86/fat/com.c:32, from fat_com.c:10: ../fib_table.h:4:1: warning: data definition has no type or storage class 4 | Error, error, this data is for 64 bits | ^ ../fib_table.h:4:1: warning: type defaults to 'int' in declaration of 'Error' [-Wimplicit-int] ../fib_table.h:4:8: warning: type defaults to 'int' in declaration of 'error' [-Wimplicit-int] 4 | Error, error, this data is for 64 bits |^ ../fib_table.h:4:20: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'data' 4 | Error, error, this data is for 64 bits |^~~~ make[2]: *** [fat_com.lo] Error 1 This error seems to be related to changing the ABI after the initial configure. Using "make distclean" fixes this. I therefore think that something like `AC_ARG_VAR([ABI], [Application Binary Interface to use])` (maybe also reference https://gmplib.org/manual/ABI-and-ISA in its description) should be added to configure.ac to make that error on an ABI change and also adding this missing piece to configure's help output. Using the right ABI all tests pass. Rechecked with GMP 6.2.1 - the ABI needs to be specified there manually, too, the same warning is seen in the output. Just to let you know: make check resulted in multiple occurrences of libtool: warning: '-no-install' is ignored for haswell-pc-mingw32 libtool: warning: assuming '-no-fast-install' instead Side note, just FYI: to build without warnings on MinGW (also with recent MSYS2) the following additional option needs to be specified CFLAGS="-Wno-attributes -Wno-ignored-attributes" Simon ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: GMP 6.2.1 core2 x86_64 assembler error "operands invalid for `movq'"
Am 02.11.2022 um 13:59 schrieb Torbjörn Granlund: I seem to have misread the report. I thought the movq mem,xmm instructions were the problem. Good that this got clearer. I pushed a fix to the repo. Please try it. https://gmplib.org/repo/gmp/rev/3ac5afa36be5 works fine for me on core2. Thank you. Simon ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: GMP 6.2.1 core2 x86_64 assembler error "operands invalid for `movq'"
Am 02.11.2022 um 08:58 schrieb Niels Möller: Torbjörn Granlund writes: This is not the same bug as we worked around for register-to-register copying on x86-32 some years ago. It is not cleer what syntax this assembler might accept, and which also gives the right instruction (here and on non-prolematic hosts). For reference, in nettle x86_64 code, there are a few places where I write "movd" instead of "movq" for 64-bit moves between general 64-bit registers and xmm registers, to work around build problems on macos. E.g., umac-nh.s: movd%xmm4, %rax sha3-permute.s: movd%xmm15, %r9 Seems to work fine everywhere I've tested it, but I've not really understood why "movd" could ever be used as mnemonic for that operation (I also use it in other places for 32-bit moves). I guess there are some historic reasons. So would be useful to try if replacement movq --> movd Rechecked. I've changed the two occurrences of movq%xmm0, %rax https://gmplib.org/repo/gmp/file/tip/mpn/x86_64/core2/popcount.asm#l169 https://gmplib.org/repo/gmp/file/tip/mpn/x86_64/core2/hamdist.asm#l194 - movq%xmm0, %rax + movd%xmm0, %rax (i) solves the problem on (older) macos, and Works like a charm, now both assembling works on x86_64 and all internal tests (and all tests in gnucobol's "make checkall" which uses GMP for arithmetic) pass! (ii) produces identical object code on systems with more up-to-date assemblers. As I've understood you did exactly that before in other places. I can't test that myself because I don't have a core2 anywhere else currently. Regards, /Niels Again: big thanks for pointing this out. Open question: can this change be applied to the repo and if yes by whom? Simon ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: GMP 6.2.1 core2 x86_64 assembler error "operands invalid for `movq'"
Am 01.11.2022 um 22:55 schrieb Torbjörn Granlund: Simon Sobisch writes: config.status: linking ../mpn/x86_64/core2/popcount.asm to mpn/popcount.asm config.status: linking ../mpn/x86_64/core2/hamdist.asm to mpn/hamdist.asm tmp-popcount.s:181:suffix or operands invalid for `movq' tmp-hamdist.s:206:suffix or operands invalid for `movq' Is this on a recent version of macos with current versions gcc+binutils installed? Or is either old variants? That is an old MacBook with the most current "developer command line tools" that were available (from 2013/2014 if I remember correctly). This is not the same bug as we worked around for register-to-register copying on x86-32 some years ago. It is not cleer what syntax this assembler might accept, and which also gives the right instruction (here and on non-prolematic hosts). Sigh. Sadly I don't know enough about assembly to patch it myself :-( But I can test because that machine is now available to me (it was passed to me instead of being thrown away; I did a reset, installed the most current software that was supported there and now try to get some programs running via terminal). Note: running configure with ABI=32 (which leads to use of x86 instead of x86_64) leads to all files compiling and also all tests passing. Therefore we at least know that the syntax used there including that old register to register workaround _does_ work correct with that assembler. Thank you for getting back to me on this topic. Simon ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
GMP 6.2.1 core2 x86_64 assembler error "operands invalid for `movq'"
Environment: Version: GNU MP 6.2.1 Host type: core2-apple-darwin11.4.2 ABI: 64 linked files: config.status: linking ../mpn/x86_64/core2/popcount.asm to mpn/popcount.asm config.status: linking ../mpn/x86_64/core2/hamdist.asm to mpn/hamdist.asm make -k builds everything without an error but those two above fail (I think in gas), details see below. When doing a research on this issue I recognized in mpn/x86/pentium4/sse/popcount.asm a comment "movq avoided due to gas bug" (which is in since GMP 4.3). Maybe it is possible do do something similar for popcount.asm and hamdist.asm in mpn/x86_64/core2 ? Making all in mpn /bin/sh ../libtool --mode=compile --tag=CC ../../mpn/m4-ccas --m4="m4" gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I../../mpn -I.. -D__GMP_WITHIN_GMP -I../.. -DOPERATION_`echo popcount | sed 's/_$//'` -O2 -pedantic -fomit-frame-pointer -m64 -mtune=core2 -march=core2 `test -f 'popcount.asm' || echo '../../mpn/'`popcount.asm libtool: compile: ../../mpn/m4-ccas --m4=m4 gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I../../mpn -I.. -D__GMP_WITHIN_GMP -I../.. -DOPERATION_popcount -O2 -pedantic -fomit-frame-pointer -m64 -mtune=core2 -march=core2 popcount.asm -fno-common -DPIC -o .libs/popcount.o m4 -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_popcount -DPIC popcount.asm >tmp-popcount.s gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I../../mpn -I.. -D__GMP_WITHIN_GMP -I../.. -DOPERATION_popcount -O2 -pedantic -fomit-frame-pointer -m64 -mtune=core2 -march=core2 tmp-popcount.s -fno-common -DPIC -o .libs/popcount.o tmp-popcount.s:181:suffix or operands invalid for `movq' make[2]: *** [popcount.lo] Error 1 /bin/sh ../libtool --mode=compile --tag=CC ../../mpn/m4-ccas --m4="m4" gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I../../mpn -I.. -D__GMP_WITHIN_GMP -I../.. -DOPERATION_`echo hamdist | sed 's/_$//'` -O2 -pedantic -fomit-frame-pointer -m64 -mtune=core2 -march=core2 `test -f 'hamdist.asm' || echo '../../mpn/'`hamdist.asm libtool: compile: ../../mpn/m4-ccas --m4=m4 gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I../../mpn -I.. -D__GMP_WITHIN_GMP -I../.. -DOPERATION_hamdist -O2 -pedantic -fomit-frame-pointer -m64 -mtune=core2 -march=core2 hamdist.asm -fno-common -DPIC -o .libs/hamdist.o m4 -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_hamdist -DPIC hamdist.asm >tmp-hamdist.s gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I../../mpn -I.. -D__GMP_WITHIN_GMP -I../.. -DOPERATION_hamdist -O2 -pedantic -fomit-frame-pointer -m64 -mtune=core2 -march=core2 tmp-hamdist.s -fno-common -DPIC -o .libs/hamdist.o tmp-hamdist.s:206:suffix or operands invalid for `movq' make[2]: *** [hamdist.lo] Error 1 Thanks for any pointers, Simon ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: GMP 6.2.1 Aborting when running tuneup program in one.cold()
Thanks for the prompt answer! Am 20.10.2021 um 16:19 schrieb Torbjörn Granlund: When tuneup cannot measure things accurately, it bails out. That's interesting. Is there any thing I can do to help tuneup measure things accurately? Can you please add that important information (abort of the program is no bug, just use the non-optimized version) to the documentation https://gmplib.org/manual/Performance-optimization ideally together with the answer to the related questions "What should -f NNN" relate to?" and "Should I manually build the average" (if this isn't an effect of "not accurately measured")? > No bug. Maybe the tuneup program could also hint this at start (additional to the doc change)? Something like ./tuneup Try finding optimal parameters for ./mpn/x86_64/skylake/gmp-mparam.h If this is not possible this program will abort, which is no bug, and you should use the untuned version. Using: CPU cycle counter, supplemented by microsecond getrusage() speed_precision 1, speed_unittime 3.34e-10 secs, CPU freq 2992.97 MHz DEFAULT_MAX_SIZE 1000, fft_max_size 5 Simon ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
GMP 6.2.1 Aborting when running tuneup program in one.cold()
make check passed
Testsuite summary for GNU MP 6.2.1
# TOTAL: 0
# PASS: 0
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
and the installed library also seems to work fine from a quick test, but
the tuneup program crashes.
System specs below.
Questions:
* Did I missed a known issue?
* Can I do anything about this?
* Should I care running tuneup at all?
The application does some heavy computations with it in the range
+-9 (mostly multiply and divide [often by 10] and
addition/subtraction and string representation all via GnuCOBOL)
* As the output of the tuneup utility is different each time and the
docs at https://gmplib.org/manual/Performance-optimization are more
spare than for other parts: Should I run it multiple times and then
use the average? It lists -NNN but doesn't give a clue how to set
it - should I set that? Does a high value make an average on its own?
I'm available to provide more info as needed (please CC me in answers as
I'm not subscribed to this list).
Thanks,
Simon
* uname -a
Linux cent01test 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
* ../config.guess && ./configfsf.guess
sandybridge-pc-linux-gnu
x86_64-pc-linux-gnu
* gcc -v (build directly before on that machine)
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/gcc-11.2.mit.gcc.flags/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/opt/gcc-11.2 --disable-multilib
--enable-languages=c,c++,lto --with-gmp=/opt/gmp-6.2.1/lib
CFLAGS='-march=native -mtune=native' CXXFLAGS='-march=native -mtune=native'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC)
* m4 --version
m4 (GNU M4) 1.4.16
* backtrace:
$ gdb tuneup --quiet -ex run -ex bt -ex quit
Reading symbols from /opt/install/gmp-6.2.1/tune/tuneup...(no debugging
symbols found)...done.
Starting program: /opt/install/gmp-6.2.1/tune/tuneup
Parameters for ./mpn/x86_64/skylake/gmp-mparam.h
[Detaching after fork from child process 31364]
Using: CPU cycle counter, supplemented by microsecond getrusage()
speed_precision 1, speed_unittime 3.34e-10 secs, CPU freq 2992.97 MHz
DEFAULT_MAX_SIZE 1000, fft_max_size 5
/* Generated by tuneup.c, 2021-10-20, gcc 11.2 */
#define MOD_1_NORM_THRESHOLD 0 /* always */
#define MOD_1_UNNORM_THRESHOLD 0 /* always */
#define MOD_1N_TO_MOD_1_1_THRESHOLD 4
#define MOD_1U_TO_MOD_1_1_THRESHOLD 3
#define MOD_1_1_TO_MOD_1_2_THRESHOLD13
#define MOD_1_2_TO_MOD_1_4_THRESHOLD38
#define PREINV_MOD_1_TO_MOD_1_THRESHOLD 9
#define USE_PREINV_DIVREM_1 1 /* native */
#define DIV_QR_1_NORM_THRESHOLD 1
#define DIV_QR_1_UNNORM_THRESHOLDMP_SIZE_T_MAX /* never */
#define DIV_QR_2_PI2_THRESHOLD 33
#define DIVEXACT_1_THRESHOLD 0 /* always (native) */
#define BMOD_1_TO_MOD_1_THRESHOLD 20
#define DIV_1_VS_MUL_1_PERCENT 468
#define MUL_TOOM22_THRESHOLD26
#define MUL_TOOM33_THRESHOLD73
#define MUL_TOOM44_THRESHOLD 208
#define MUL_TOOM6H_THRESHOLD 300
#define MUL_TOOM8H_THRESHOLD 406
#define MUL_TOOM32_TO_TOOM43_THRESHOLD 73
#define MUL_TOOM32_TO_TOOM53_THRESHOLD 159
#define MUL_TOOM42_TO_TOOM53_THRESHOLD 137
#define MUL_TOOM42_TO_TOOM63_THRESHOLD 151
#define MUL_TOOM43_TO_TOOM54_THRESHOLD 106
#define SQR_BASECASE_THRESHOLD 0 /* always (native) */
#define SQR_TOOM2_THRESHOLD 32
#define SQR_TOOM3_THRESHOLD114
#define SQR_TOOM4_THRESHOLD176
#define SQR_TOOM6_THRESHOLD446
#define SQR_TOOM8_THRESHOLD547
#define MULMID_TOOM42_THRESHOLD 48
#define MULMOD_BNM1_THRESHOLD 15
#define SQRMOD_BNM1_THRESHOLD 18
#define MUL_FFT_MODF_THRESHOLD 460 /* k = 5 */
#define MUL_FFT_TABLE3 \
{ {460, 5}, { 23, 6}, { 27, 7}, { 15, 6}, \
{ 31, 7}, { 25, 8}, { 13, 7}, { 29, 8}, \
{ 15, 7}, { 33, 8}, { 17, 7}, { 35, 8}, \
{ 19, 7}, { 40, 8}, { 21, 9}, { 11, 8}, \
{ 35, 9}, { 19, 8}, { 41, 9}, { 23, 8}, \
{ 49, 9}, { 27,10}, { 15, 9}, { 39, 8}, \
{ 81, 9}, { 43,10}, { 23, 9}, { 55,11}, \
{ 15,10}, { 31, 9}, { 71,10}, { 39, 9}, \
{ 87,10}, { 47, 9}, {512,10}, { 1024,11}, \
{ 2048,12}, { 4096,13}, { 8192,14}, { 16384,15}, \
{ 32768,16}, { 65536,17}, { 131072,18}, { 262144,19}, \
{ 524288,20}, {1048576,21}, {2097152,22}, {4194304,23}, \
{8388608,24}
gmp.h uses undefined preprocessor symbol
The following bug exists since at least GMP 4.3 and still persists: gmp-h.in defines _GMP_DECLSPEC_EXPORT / _GMP_DECLSPEC_IMPORT for different systems and use it later. The problem: it does not define it to something for unknown environments. The attached patch defines them empty when the compiler is not known and adds the working definition for the OrangeC compiler. [Note: the patch used the old format, ORANGEC understands both ´__dllexport__´ and ´dllexport´ so it may be added to the GCC-define] Simon Index: gmp-h.in === --- gmp-h.old.in +++ gmp-h.in @@ -168,18 +168,18 @@ #if defined (__GNUC__) #define __GMP_DECLSPEC_EXPORT __declspec(__dllexport__) #define __GMP_DECLSPEC_IMPORT __declspec(__dllimport__) -#endif -#if defined (_MSC_VER) || defined (__BORLANDC__) +#elif defined (_MSC_VER) || defined (__BORLANDC__) || defined (__ORANGEC__) #define __GMP_DECLSPEC_EXPORT __declspec(dllexport) #define __GMP_DECLSPEC_IMPORT __declspec(dllimport) -#endif -#ifdef __WATCOMC__ +#elif defined (__WATCOMC__) #define __GMP_DECLSPEC_EXPORT __export #define __GMP_DECLSPEC_IMPORT __import -#endif -#ifdef __IBMC__ +#elif defined (__IBMC__) #define __GMP_DECLSPEC_EXPORT _Export #define __GMP_DECLSPEC_IMPORT _Import +#else +#define __GMP_DECLSPEC_EXPORT +#define __GMP_DECLSPEC_IMPORT #endif #if defined( _MSC_VER ) ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
