MPIR 2.6.0 alpha1 released

[Bill Hart]

Hi all,

It is with pleasure that we release MPIR 2.6.0 alpha1. The source and
documentation can be downloaded at http://mpir.org/

This release contains a new FFT, support for intmax_t integers, a
Python build generator and various bug fixes.

The alpha version has been tested on only a few architectures at this
point. We appreciate any and all build/bug reports. Once testing is
complete, the status will be upgraded to beta or perhaps final.

Thank you to the all people who made comments on our development list,
who provided bug reports and helped with testing. This includes, but
is probably not limited to Case van Horsen, David Cleaver, Pavel
Holoborodko and Sisyphus.

A full list of code contributions to MPIR can be found in the AUTHORS
file in the source tarball.

Best Wishes,

The MPIR Team.

[leif]

Bill Hart wrote:
> Hi all,
>
> It is with pleasure that we release MPIR 2.6.0 alpha1. The source and
> documentation can be downloaded at http://mpir.org/
>
> This release contains a new FFT, support for intmax_t integers, a
> Python build generator and various bug fixes.
>
> The alpha version has been tested on only a few architectures at this
> point. We appreciate any and all build/bug reports. Once testing is
> complete, the status will be upgraded to beta or perhaps final.

FWIW, I've successfully built MPIR 2.6.0-alpha1 (with '--enable-cxx' and
'--enable-gmpcompat') and run 'make check' on the following platforms:

Linux PPC64 (SLES 11, POWER7), GCC 4.3.4 (without C++ support)

Linux PPC64 (SLES 11, POWER7), GCC 4.6.3

Solaris SPARC (SunOS 5.10, UltraSPARC III), GCC 4.7.0, ABI=32

Solaris SPARC (SunOS 5.10, UltraSPARC III), GCC 4.7.0, ABI=64

I didn't try to (re)build/test anything using GMP/MPIR though.


On Linux IA64 (SLES 10, Itanium) in contrast, I got the following failures:

With the (fairly old) "native" GCC 4.1.2, building the testsuite fails:

make[4]: Entering directory
`/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.1.2/tests/cxx'
g++ -DHAVE_CONFIG_H -I. -I../../../mpir-2.6.0-alpha1/tests/cxx -I../..
-I../../../mpir-2.6.0-alpha1 -I../../../mpir-2.6.0-alpha1/tests -O2
-c -o t-assign.o ../../../mpir-2.6.0-alpha1/tests/cxx/t-assign.cc
../../../mpir-2.6.0-alpha1/mpirxx.h:1587: error:
�__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(intmax_t)�
cannot be overloaded
../../../mpir-2.6.0-alpha1/mpirxx.h:1578: error: with
�__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(long int)�
../../../mpir-2.6.0-alpha1/mpirxx.h:1588: error:
�__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(uintmax_t)�
cannot be overloaded
../../../mpir-2.6.0-alpha1/mpirxx.h:1579: error: with
�__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(long
unsigned int)�
../../../mpir-2.6.0-alpha1/mpirxx.h:1656: error:
�__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct
[1], __mpz_struct [1]>::operator=(intmax_t)� cannot be overloaded
../../../mpir-2.6.0-alpha1/mpirxx.h:1647: error: with
�__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct
[1], __mpz_struct [1]>::operator=(long int)�
../../../mpir-2.6.0-alpha1/mpirxx.h:1657: error:
�__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct
[1], __mpz_struct [1]>::operator=(uintmax_t)� cannot be overloaded
../../../mpir-2.6.0-alpha1/mpirxx.h:1648: error: with
�__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct
[1], __mpz_struct [1]>::operator=(long unsigned int)�
make[4]: *** [t-assign.o] Error 1
make[4]: Leaving directory
`/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.1.2/tests/cxx'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory
`/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.1.2/tests/cxx'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory
`/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.1.2/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
`/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.1.2'
make: *** [check] Error 2

$ gcc -v
Using built-in specs.
Target: ia64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --program-suffix=
--enable-version-specific-runtime-libs --with-system-libunwind
--host=ia64-suse-linux
Thread model: posix
gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)

(No idea whether any recent version of MPIR does build with that version
of GCC.)

Without '--enable-cxx', the testsuite builds and passes.


With GCC 4.7.0 (and CFLAGS="-O0 -finline-functions -fschedule-insns",
since this version is severely broken on Itanium) I get:

libtool: link: ranlib .libs/libtests.a
libtool: link: ( cd ".libs" && rm -f "libtests.la" && ln -s
"../libtests.la" "libtests.la" )
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../mpir-2.6.0-alpha1/tests -I..
-I../../mpir-2.6.0-alpha1 -O0 -finline-functions -fschedule-insns -c
../../mpir-2.6.0-alpha1/tests/t-bswap.c
/bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -O0
-finline-functions -fschedule-insns -o t-bswap t-bswap.o libtests.la
../libmpir.la
libtool: link: gcc -std=gnu99 -O0 -finline-functions -fschedule-insns -o
.libs/t-bswap t-bswap.o ./.libs/libtests.a
/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/.libs/libmpir.so
-lm ../.libs/libmpir.so
/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/.libs/libmpir.so:
undefined reference to `mpn_addmod_2expp1_1'
collect2: error: ld returned 1 exit status
make[4]: *** [t-bswap] Error 1
make[4]: Leaving directory
`/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/tests'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory
`/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/tests'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory
`/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
`/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0'
make: *** [check] Error 2


Btw, invalid options to 'configure' (e.g. '--enable-gmp-compat' or
'--enable-foo') are silently ignored, even with '-v'; probably just some
(newer) autotools "feature"...


-leif

>
> Thank you to the all people who made comments on our development list,
> who provided bug reports and helped with testing. This includes, but
> is probably not limited to Case van Horsen, David Cleaver, Pavel
> Holoborodko and Sisyphus.
>
> A full list of code contributions to MPIR can be found in the AUTHORS
> file in the source tarball.
>
> Best Wishes,
>
> The MPIR Team.

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[Bill Hart]

Hi Leif,

Thanks very much!

The second issue is almost certainly a bug. The first looks like it could be, due to the presence of intmax_t in the output. But the cxx has never built on some machines we have access to due to broken compilers. I'll look into it.

I forgot to mention that we need to run make tune on each arch we have access to and put the resulting output in the correct gmp-mparam.h file in the relevant mpn directory. Of course without svn access (we are switching to git soon I promise), the best way is to just post the output to the list along with the output from config.guess and let one of us commit it.

Bill.

On Sunday, 7 October 2012, leif wrote:

Bill Hart wrote:

Hi all,

It is with pleasure that we release MPIR 2.6.0 alpha1. The source and
documentation can be downloaded at http://mpir.org/

This release contains a new FFT, support for intmax_t integers, a
Python build generator and various bug fixes.

The alpha version has been tested on only a few architectures at this
point. We appreciate any and all build/bug reports. Once testing is
complete, the status will be upgraded to beta or perhaps final.

FWIW, I've successfully built MPIR 2.6.0-alpha1 (with '--enable-cxx' and
'--enable-gmpcompat') and run 'make check' on the following platforms:

  Linux PPC64 (SLES 11, POWER7), GCC 4.3.4 (without C++ support)

  Linux PPC64 (SLES 11, POWER7), GCC 4.6.3

  Solaris SPARC (SunOS 5.10, UltraSPARC III), GCC 4.7.0, ABI=32

  Solaris SPARC (SunOS 5.10, UltraSPARC III), GCC 4.7.0, ABI=64

I didn't try to (re)build/test anything using GMP/MPIR though.


On Linux IA64 (SLES 10, Itanium) in contrast, I got the following failures:

With the (fairly old) "native" GCC 4.1.2, building the testsuite fails:

make[4]: Entering directory `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.1.2/tests/cxx'
g++ -DHAVE_CONFIG_H -I. -I../../../mpir-2.6.0-alpha1/tests/cxx -I../.. -I../../../mpir-2.6.0-alpha1 -I../../../mpir-2.6.0-alpha1/tests    -O2 -c -o t-assign.o ../../../mpir-2.6.0-alpha1/tests/cxx/t-assign.cc

../../../mpir-2.6.0-alpha1/mpirxx.h:1587: error: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(intmax_t)’ cannot be overloaded
../../../mpir-2.6.0-alpha1/mpirxx.h:1578: error: with ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(long int)’
../../../mpir-2.6.0-alpha1/mpirxx.h:1588: error: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(uintmax_t)’ cannot be overloaded
../../../mpir-2.6.0-alpha1/mpirxx.h:1579: error: with ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(long unsigned int)’
../../../mpir-2.6.0-alpha1/mpirxx.h:1656: error: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::operator=(intmax_t)’ cannot be overloaded
../../../mpir-2.6.0-alpha1/mpirxx.h:1647: error: with ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::operator=(long int)’
../../../mpir-2.6.0-alpha1/mpirxx.h:1657: error: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::operator=(uintmax_t)’ cannot be overloaded
../../../mpir-2.6.0-alpha1/mpirxx.h:1648: error: with ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::operator=(long unsigned int)’

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To post to this group, send email to mpir-...@googlegroups.com.
To unsubscribe from this group, send email to mpir-devel+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.

[Case Van Horsen]

>> Bill Hart wrote:
>>>
>>> Hi all,
>>>
>>> It is with pleasure that we release MPIR 2.6.0 alpha1. The source and
>>> documentation can be downloaded at http://mpir.org/
>>>
>>> This release contains a new FFT, support for intmax_t integers, a
>>> Python build generator and various bug fixes.
>>>
>>> The alpha version has been tested on only a few architectures at this
>>> point. We appreciate any and all build/bug reports. Once testing is
>>> complete, the status will be upgraded to beta or perhaps final.

The following tests use VS2010.

When compiling the 32-bit pentium3 library, I get the following warnings:

Generating Code...
preinv_divrem_1.obj : warning LNK4221: This object file does not
define any previously undefined public symbols, so it will not be used
by any link operation that consumes this library
mod_1.obj : warning LNK4006: ___gmpn_preinv_mod_1 already defined in
preinv_mod_1.obj; second definition ignored
lib_mpir_p3.vcxproj -> C:\src\mpir\build.vc10\Win32\Release\mpir.lib
copying outputs from "Win32\Release" to "..\lib\Win32\Release"

A 64-bit K8 library compiles successfully.

Case

[leif]

Bill Hart wrote:
> The second issue is almost certainly a bug. The first looks like it
> could be, due to the presence of intmax_t in the output. But the cxx has
> never built on some machines we have access to due to broken compilers.
> I'll look into it.

While I do get the same results with GCC 4.1.2 and MPIR 2.5.2 [first /
C++ issue], the linker error with GCC 4.7.0 [second issue] is a
regression w.r.t. 2.5.2, i.e., MPIR 2.5.2's testsuite builds and passes
all tests with GCC 4.7.0 (Linux IA64 / SLES 10 Itanium).

Haven't investigated further; someone^TM should install GCC 4.7.2 (or
4.7.1, which fixed the brokenness on Itanium)... ;-)


-leif

> `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.1.2/__tests/cxx'
> g++ -DHAVE_CONFIG_H -I. -I../../../mpir-2.6.0-alpha1/__tests/cxx
> -I../.. -I../../../mpir-2.6.0-alpha1
> -I../../../mpir-2.6.0-alpha1/__tests -O2 -c -o t-assign.o
> ../../../mpir-2.6.0-alpha1/__tests/cxx/t-assign.cc
> ../../../mpir-2.6.0-alpha1/__mpirxx.h:1587: error:
> �__gmp_expr<__mpz_struct [1], __mpz_struct
> [1]>::__gmp_expr(intmax_t)� cannot be overloaded
> ../../../mpir-2.6.0-alpha1/__mpirxx.h:1578: error: with
> �__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(long int)�
> ../../../mpir-2.6.0-alpha1/__mpirxx.h:1588: error:
> �__gmp_expr<__mpz_struct [1], __mpz_struct
> [1]>::__gmp_expr(uintmax_t)� cannot be overloaded
> ../../../mpir-2.6.0-alpha1/__mpirxx.h:1579: error: with
> �__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(long
> unsigned int)�
> ../../../mpir-2.6.0-alpha1/__mpirxx.h:1656: error:
> �__gmp_expr<__mpz_struct [1], __mpz_struct [1]>&
> __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::operator=(intmax_t)�
> cannot be overloaded
> ../../../mpir-2.6.0-alpha1/__mpirxx.h:1647: error: with
> �__gmp_expr<__mpz_struct [1], __mpz_struct [1]>&
> __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::operator=(long int)�
> ../../../mpir-2.6.0-alpha1/__mpirxx.h:1657: error:
> �__gmp_expr<__mpz_struct [1], __mpz_struct [1]>&

> __gmp_expr<__mpz_struct [1], __mpz_struct

> [1]>::operator=(uintmax_t)� cannot be overloaded
> ../../../mpir-2.6.0-alpha1/__mpirxx.h:1648: error: with
> �__gmp_expr<__mpz_struct [1], __mpz_struct [1]>&

> __gmp_expr<__mpz_struct [1], __mpz_struct [1]>::operator=(long

> unsigned int)�

> make[4]: *** [t-assign.o] Error 1
> make[4]: Leaving directory

> `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.1.2/__tests/cxx'

> make[3]: *** [check-am] Error 2
> make[3]: Leaving directory

> `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.1.2/__tests/cxx'

> make[2]: *** [check-recursive] Error 1
> make[2]: Leaving directory

> `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.1.2/__tests'

> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory

> `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.1.2'

> make: *** [check] Error 2
>
> $ gcc -v
> Using built-in specs.
> Target: ia64-suse-linux
> Configured with: ../configure --enable-threads=posix --prefix=/usr
> --with-local-prefix=/usr/local --infodir=/usr/share/info
> --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib

> --enable-languages=c,c++,objc,__fortran,obj-c++,java,ada
> --enable-checking=release
> --with-gxx-include-dir=/usr/__include/c++/4.1.2 --enable-ssp

> --disable-libssp --disable-libgcj --with-slibdir=/lib
> --with-system-zlib --enable-shared --enable-__cxa_atexit

> --enable-libstdcxx-allocator=__new --program-suffix=
> --enable-version-specific-__runtime-libs --with-system-libunwind

> --host=ia64-suse-linux
> Thread model: posix
> gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)
>
> (No idea whether any recent version of MPIR does build with that
> version of GCC.)
>
> Without '--enable-cxx', the testsuite builds and passes.
>
>
> With GCC 4.7.0 (and CFLAGS="-O0 -finline-functions
> -fschedule-insns", since this version is severely broken on Itanium)
> I get:
>
> libtool: link: ranlib .libs/libtests.a
> libtool: link: ( cd ".libs" && rm -f "libtests.la

> <http://libtests.la>" && ln -s "../libtests.la <http://libtests.la>"
> "libtests.la <http://libtests.la>" )
> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../mpir-2.6.0-alpha1/__tests
> -I.. -I../../mpir-2.6.0-alpha1 -O0 -finline-functions
> -fschedule-insns -c ../../mpir-2.6.0-alpha1/tests/__t-bswap.c

> /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -O0
> -finline-functions -fschedule-insns -o t-bswap t-bswap.o

> libtests.la <http://libtests.la> ../libmpir.la <http://libmpir.la>

> libtool: link: gcc -std=gnu99 -O0 -finline-functions
> -fschedule-insns -o .libs/t-bswap t-bswap.o ./.libs/libtests.a

> /home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.7.0/.__libs/libmpir.so
> -lm ../.libs/libmpir.so
> /home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.7.0/.__libs/libmpir.so:

> undefined reference to `mpn_addmod_2expp1_1'
> collect2: error: ld returned 1 exit status
> make[4]: *** [t-bswap] Error 1
> make[4]: Leaving directory

> `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.7.0/__tests'

> make[3]: *** [check-am] Error 2
> make[3]: Leaving directory

> `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.7.0/__tests'

> make[2]: *** [check-recursive] Error 1
> make[2]: Leaving directory

> `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.7.0/__tests'

> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory

> `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.7.0'

> http://groups.google.com/__group/mpir-devel?hl=en
> <http://groups.google.com/group/mpir-devel?hl=en>.

[Brian Gladman]

Thanks for the report Case.

The first warning about an 'empty' object file is OK because the file has to
be included in the build but might be empty because it can be turned off by
the tuning parameters for the build (which happens for p3).

The second is innocuous but I have made a small change to remove this
warning.

Brian

[Bill Hart]

On 7 October 2012 04:10, leif <not.r...@online.de> wrote:

<SNIP>

> On Linux IA64 (SLES 10, Itanium) in contrast, I got the following failures:
>
> With the (fairly old) "native" GCC 4.1.2, building the testsuite fails:
>
> make[4]: Entering directory
> `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.1.2/tests/cxx'
> g++ -DHAVE_CONFIG_H -I. -I../../../mpir-2.6.0-alpha1/tests/cxx -I../..
> -I../../../mpir-2.6.0-alpha1 -I../../../mpir-2.6.0-alpha1/tests -O2 -c -o
> t-assign.o ../../../mpir-2.6.0-alpha1/tests/cxx/t-assign.cc

> ../../../mpir-2.6.0-alpha1/mpirxx.h:1587: error: ‘__gmp_expr<__mpz_struct
> [1], __mpz_struct [1]>::__gmp_expr(intmax_t)’ cannot be overloaded
> ../../../mpir-2.6.0-alpha1/mpirxx.h:1578: error: with
> ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(long int)’
> ../../../mpir-2.6.0-alpha1/mpirxx.h:1588: error: ‘__gmp_expr<__mpz_struct
> [1], __mpz_struct [1]>::__gmp_expr(uintmax_t)’ cannot be overloaded
> ../../../mpir-2.6.0-alpha1/mpirxx.h:1579: error: with
> ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(long unsigned
> int)’
> ../../../mpir-2.6.0-alpha1/mpirxx.h:1656: error: ‘__gmp_expr<__mpz_struct

> [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct

> [1]>::operator=(intmax_t)’ cannot be overloaded
> ../../../mpir-2.6.0-alpha1/mpirxx.h:1647: error: with
> ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct
> [1], __mpz_struct [1]>::operator=(long int)’
> ../../../mpir-2.6.0-alpha1/mpirxx.h:1657: error: ‘__gmp_expr<__mpz_struct

> [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct

> [1]>::operator=(uintmax_t)’ cannot be overloaded
> ../../../mpir-2.6.0-alpha1/mpirxx.h:1648: error: with
> ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>& __gmp_expr<__mpz_struct
> [1], __mpz_struct [1]>::operator=(long unsigned int)’

<SNIP>

OK, I took a look at this and basically an intmax_t and long int are
the same thing on this machine (as are a uintmax_t and unsigned long
int). Thus it is effectively trying to overload the __gmp_exp function
twice with the same type but different implementations (one calls the
si function, the other calls the sx function).

This is a problem for which I don't personally know the solution at
present. Any suggestions would be very helpful.

Bill.

[Bill Hart]

I think I have essentially gotten to the bottom of this bug. And it is
pretty subtle indeed!

The issue is nominative versus structural typing. Consider the
following two structs:

struct mystruct1
{
int d;
double t;
}

struct mystruct2
{
int d;
double t;
}

Structurally, these are the same type as they contain the same fields
(in the same order -- this is important for C). But the names of the
structs are different. Thus nominatively they are different.

Now C/C++ are by and large nominatively typed. Structs with different
names are different for the purpose of type checking.

However, there are some exceptions. The template system in C++ is
structurally typed. You can instantiate templates with differently
named, but structurally identical types without issue, so long as the
implementations don't conflict.

And then there is typedef. This actually doesn't create a new type for
the purposes of type checking. It in fact only creates a type name
alias. The type is still considered to be the same for type checking
purposes.

Now if you look in stdint.h you find that on the system in question,
intmax_t is typedef'd to be a long. Thus intmax_t and long are the
*same* type on that system. Thus it is invalid to define the function
for intmax_t and for long with different implementations. So the
compiler is correct to reject this code.

Unfortunately, I don't know of a way of comparing two types with
preprocessor macros to see if they are the same. But we can compare
their sizes with sizeof. It turns out that sizeof is actually a macro,
not a function, and so can be compared at compile time. If
sizeof(intmax_t) == sizeof(long) then we shouldn't define the second
version of the function. The function will still accept an intmax_t
because that is the same type as a long.

I also found at least one reference which says that intmax_t is
*always* a typedef to an existing integral type. At least in C90 the
type must be an ordinary integer type, but from C99 onwards it can be
an extended integer type (so could conceivably be a uint128_t on a 64
bit machine). I'm not sure if we are still using C90 or whether we are
using gnu99. And I've no idea what the gnu "standard" says anyway. But
at least the fix I suggest should work for quite a few machines. We
might have to make further changes if we start running into problems
with extended types. I know the Apple GCC does all sorts of unusual
things when it comes to standards, so who knows.

I will check in this fix to the repo momentarily.

Bill.

[Bill Hart]

Damn, I am wrong about the last bit. You can't use sizeof in
preprocessor directives!

But now I am looking at this code and wondering if it is even
necessary. When do we expect intmax_t to not be either long or long
long. And we have code for both of the above already.

Bill.

[Bill Hart]

Whoah, we have some major issues here.

mpirxx.h uses HAVE_LONG_LONG. But this is defined in MPIR's internal
config.h, which is no use, as the end user will not have included
this.

Moreover, I can't find where stdint.h is being included in mpirxx.h. I
think it must be designed so that only when it is included do intmax_t
functions get defined.

But I still don't think that these functions should *ever* need
defining. Either an intmax_t is a long or it is a long long on all
platforms we support. So if the long long function actually worked (it
never will for the user), then the intmax_t function is never needed.

Bill.

[Bill Hart]

I think we should test if LLONG_MAX is defined. This actually doesn't
tell us if long long exists, but tells us if long long exists AND the
system long long's are fully c99 compliant.

Then if LLONG_MAX is not defined but MAXINT_MAX is defined and not
equal to LONG_MAX, then we should define maxint_t function.

I'll try this and see if it works. I think this is what is causing the
bug on the ia64 machine with gcc 4.1.2.

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Friday, October 12, 2012 8:18 PM
To: mpir-...@googlegroups.com

Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released

I think we should test if LLONG_MAX is defined. This actually doesn't
tell us if long long exists, but tells us if long long exists AND the
system long long's are fully c99 compliant.

Then if LLONG_MAX is not defined but MAXINT_MAX is defined and not
equal to LONG_MAX, then we should define maxint_t function.

I'll try this and see if it works. I think this is what is causing the
bug on the ia64 machine with gcc 4.1.2.

===================

So all the HAVE_LONG_LONG in mpirxx.h need to be changed to test for
LLONG_MAX?

Brian

[Bill Hart]

Yeah, I've just done it now.

Bill.

[Bill Hart]

Oh no! Our mpirxx.h file also checks HAVE_STDINT_H

This is defined in config.h too!!

Bill.

[Bill Hart]

Oh no it doesn't, I made a mistake. It has #if defined( _STDINT_H ) ||
defined ( _STDINT_H_ ) || defined ( _STDINT )

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Friday, October 12, 2012 8:30 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released

Oh no it doesn't, I made a mistake. It has #if defined( _STDINT_H ) ||
defined ( _STDINT_H_ ) || defined ( _STDINT )

========================
I was about to query this :-)

We will need to include limits.h to pick up LLONG_MAX

Brian

[Bill Hart]

That actually won't work. For C++ we must include stdint.h and not limits.h.

Bill.

[Bill Hart]

Another problem is in the test functions for the ux/sx functions, we
use %lld in the format specifier for an intmax_t. This is only valid
if intmax_t is actually a long long int, which it is not on some *nix
platforms (ia64 for example).

C99 introduced a new format specifier (which I forgot already) for
intmax_t. Of course this is only supported by C99 compilers. I hope
MSVC is C99 compliant enough to have gotten this right, otherwise we
have a lot of fiddling around to do.

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Friday, October 12, 2012 8:34 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released

That actually won't work. For C++ we must include stdint.h and not limits.h.

========================

On Windows LLONG_MAX is defined in limits.h

Brian

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Friday, October 12, 2012 8:39 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released

Another problem is in the test functions for the ux/sx functions, we
use %lld in the format specifier for an intmax_t. This is only valid
if intmax_t is actually a long long int, which it is not on some *nix
platforms (ia64 for example).

C99 introduced a new format specifier (which I forgot already) for
intmax_t. Of course this is only supported by C99 compilers. I hope
MSVC is C99 compliant enough to have gotten this right, otherwise we
have a lot of fiddling around to do.

==================
AFAIK it isn't (and probably won't ever be unless a C99 feature ends up in
C++)

Brian

[Bill Hart]

Yes, but you can't include limits.h in mpirxx.h. If you do, it will
screw up on linux. So we will just have to add something different for
Windows.

As things currently stand, the cxx code passes on ia64, but not
x86_64. So still more screwing around on linux before this is right.

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Friday, October 12, 2012 8:44 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released

Yes, but you can't include limits.h in mpirxx.h. If you do, it will
screw up on linux. So we will just have to add something different for
Windows.

As things currently stand, the cxx code passes on ia64, but not
x86_64. So still more screwing around on linux before this is right.

======================

Then we need:

#ifdef MSC_VER
# include <limits.h>
#endif

where is LLONG_MAX defined on *nix?

Brian

[Bill Hart]

It appears to be defined in limits.h on *nix if you use C, but
stdint.h if you use C++.

Bill.

[Bill Hart]

OK, now I have it working on x86_64. I'll try on ia64.

The only problem on x86_64 is that it doesn't know what to do if you
do a C++ assignment from an long long int, so I just guarded the test
code that tries that by checking if long long is a different type to
long. Otherwise it gets confused (for reasons I don't pretend to
understand fully).

Bill.

[Bill Hart]

I have to say, I am a bit bothered by all these test programs having
#include config.h. This isn't available to the user, and surely all
the test programs should operate just as user programs would and
therefore should not need to include config.h.

Bill.

[Bill Hart]

Nope, now ia64 doesn't work again.

Bill.

[leif]

Bill Hart wrote:
> Another problem is in the test functions for the ux/sx functions, we
> use %lld in the format specifier for an intmax_t. This is only valid
> if intmax_t is actually a long long int, which it is not on some *nix
> platforms (ia64 for example).
>
> C99 introduced a new format specifier (which I forgot already) for
> intmax_t. Of course this is only supported by C99 compilers. I hope
> MSVC is C99 compliant enough to have gotten this right, otherwise we
> have a lot of fiddling around to do.

It doesn't really specify new format letters AFAIK, but inttypes.h,
which defines macros for (portably) printing and scanning the types
defined in stdint.h, e.g. PRIu64 and SCNu64, regardless of whether
uint64_t expands to 'unsigned long' ("%lu") or 'unsigned long long'
("%llu"); one can for example use

printf("%20"PRIu64"\n", (uint64_t)foo); // mind the % and quoting


For printing [u]intmax_t, the macros are PRIdMAX, PRIiMAX, PRIoMAX
(octal), PRIuMAX, PRIxMAX and PRIXMAX (hexadecimal, lower and upper
case, respectively).


-leif

> On 12 October 2012 20:34, Bill Hart <goodwi...@googlemail.com> wrote:
>> That actually won't work. For C++ we must include stdint.h and not limits.h.
>>
>> Bill.
>>
>> On 12 October 2012 20:32, Brian Gladman <b...@gladman.plus.com> wrote:
>>> -----Original Message----- From: Bill Hart Sent: Friday, October 12, 2012
>>> 8:30 PM To: mpir-...@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0
>>> alpha1 released
>>> Oh no it doesn't, I made a mistake. It has #if defined( _STDINT_H ) ||
>>> defined ( _STDINT_H_ ) || defined ( _STDINT )
>>>
>>> ========================
>>> I was about to query this :-)
>>>
>>> We will need to include limits.h to pick up LLONG_MAX
>>>
>>>
>>> Brian
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "mpir-devel" group.
>>> To post to this group, send email to mpir-...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> mpir-devel+...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/mpir-devel?hl=en.
>>>
>

[Bill Hart]

I believe these only get defined if you first define some macro.

[Brian Gladman]

However, inttypes.h is not available on Windows.

Going back to stdint.h, I think the assumption is that this needs to be
included by the user before the mpirxx.h include so we should not include it
in mpirxx.h

On Windows the C++ header for LLONG_MAX is <climits> - I am surprised that
this doesn't exist on *nix.

Brian





inttypes

[leif]

Well, it does (or should).


-leif

[Brian Gladman]

=========================

So including <climits> in mpirxx.h should not cause problems on *nix?

Brian

[Bill Hart]

For some reason, including limits.h on *nix kills the definition of
INTMAX_MAX. I'm trying to figure out what is going wrong.

I think it is because our test code is including some headers and not
others before mpirxx.h even gets a chance.

Bill.

[Bill Hart]

cstdint is only available with a c++0x compiler. So that didn't work.

[Bill Hart]

But we can't do this on systems which don't support stdint.h. This was
not part of the standard before C99. Some systems before C99 partially
implement it, e.g. MSVC.

> On Windows the C++ header for LLONG_MAX is <climits> - I am surprised that
> this doesn't exist on *nix.
>

It exists, but is only partially implemented before c++0x compliant gcc.

Bill.

[Bill Hart]

Nope, I have checked this thoroughly. On linux, either INTMAX_MAX *or*
LONG_MAX is defined. I cannot get both defined.

To get the former, you need to include stdint.h, which we can't do
anyway. To get the latter we need to include limits.h. But in C++ you
cannot include both.

So there is no way to make mpirxx.h work on linux.

We will have to remove c++ support for intmax_t as the C++ standard is
different to the C standard. It is fine in the C library of course.

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Friday, October 12, 2012 9:45 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released

[snip]

> Going back to stdint.h, I think the assumption is that this needs to be
> included by the user before the mpirxx.h include so we should not include
> it
> in mpirxx.h
>

But we can't do this on systems which don't support stdint.h. This was
not part of the standard before C99. Some systems before C99 partially
implement it, e.g. MSVC.

======================================

So we can't 'not include it' - i.e. you believe that we must include it - I
am now completely confused.

> On Windows the C++ header for LLONG_MAX is <climits> - I am surprised that
> this doesn't exist on *nix.

It exists, but is only partially implemented before c++0x compliant gcc.

That is also true of <cstdint> on Windows which was not available before
MSVC 10.

I have a feeling we need to go back to some underlying principles here.

So for a start, intmax_t and uintmax_t on Windows are defined in stdint.h
(C) or cstdint (C++) and they can only be used on MSVC10 and later. They
can be detected by looking for the stdint.h guard _STDINT which can hence be
used to remove code and tests of these types.

I agree with your concern about config.h and HAVE_? defines in user code so
we need an alternative way of guarding code and tests where these are used.

Brian








Bill.

[Bill Hart]

On 12 October 2012 21:57, Brian Gladman <b...@gladman.plus.com> wrote:
> -----Original Message----- From: Bill Hart
> Sent: Friday, October 12, 2012 9:45 PM
>
> To: mpir-...@googlegroups.com
> Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released
>
> [snip]
>
>
>> Going back to stdint.h, I think the assumption is that this needs to be
>> included by the user before the mpirxx.h include so we should not include
>> it
>> in mpirxx.h
>>
>
> But we can't do this on systems which don't support stdint.h. This was
> not part of the standard before C99. Some systems before C99 partially
> implement it, e.g. MSVC.
>
> ======================================
>
> So we can't 'not include it' - i.e. you believe that we must include it - I
> am now completely confused.
>

I mean in the test code. We can't include stdint.h in the test code
before mpirxx.h because on some systems it is not supported or not
fully implemented.

>
>> On Windows the C++ header for LLONG_MAX is <climits> - I am surprised that
>> this doesn't exist on *nix.
>
>
> It exists, but is only partially implemented before c++0x compliant gcc.
>
> That is also true of <cstdint> on Windows which was not available before
> MSVC 10.
>
> I have a feeling we need to go back to some underlying principles here.
>
> So for a start, intmax_t and uintmax_t on Windows are defined in stdint.h
> (C) or cstdint (C++) and they can only be used on MSVC10 and later. They
> can be detected by looking for the stdint.h guard _STDINT which can hence be
> used to remove code and tests of these types.

The _STDINT guard is define in stdint.h. So you need to include it
before you can check if it is available.

On linux configure does a test by trying to compile a program with a
stdint.h feature. If it is found it sets HAVE_STDINT_H to 1 in
config.h. But the user does not have access to this. So the only way
to guard for stdint.h is to either test that the compiler is fully C99
compliant, for which there are defines. Or we can go through compiler
by compiler and work out when it is available.

>
> I agree with your concern about config.h and HAVE_? defines in user code so
> we need an alternative way of guarding code and tests where these are used.

In general these don't exist. Configure creates config.h by compiling
actual programs and seeing what doesn't crash the compiler. You can't
do that with guards.

The only solution is to not supply features which are not available on
all systems, or to only supply them when they are guaranteed to be
supported. For linux, this means what I said. We have to remove c++
support for intmax_t functions. The linux C++ compilers simply don't
make it possible to support this. Fortunately it isn't needed anyway
because intmax_t is always either long or long long on linux.

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Friday, October 12, 2012 10:05 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released

[snip]

>

> I have a feeling we need to go back to some underlying principles here.
>
> So for a start, intmax_t and uintmax_t on Windows are defined in stdint.h
> (C) or cstdint (C++) and they can only be used on MSVC10 and later. They
> can be detected by looking for the stdint.h guard _STDINT which can hence
> be
> used to remove code and tests of these types.

The _STDINT guard is define in stdint.h. So you need to include it
before you can check if it is available.

========================================
In test code yes but not in mpirxx.h, where we can use

#ifdef _STDINT
code using uintmax_t and/or uintmax_t
#endif
========================================

On linux configure does a test by trying to compile a program with a
stdint.h feature. If it is found it sets HAVE_STDINT_H to 1 in
config.h. But the user does not have access to this. So the only way
to guard for stdint.h is to either test that the compiler is fully C99
compliant, for which there are defines. Or we can go through compiler
by compiler and work out when it is available.

>
> I agree with your concern about config.h and HAVE_? defines in user code
> so
> we need an alternative way of guarding code and tests where these are
> used.

In general these don't exist. Configure creates config.h by compiling
actual programs and seeing what doesn't crash the compiler. You can't
do that with guards.

The only solution is to not supply features which are not available on
all systems, or to only supply them when they are guaranteed to be
supported. For linux, this means what I said. We have to remove c++
support for intmax_t functions. The linux C++ compilers simply don't
make it possible to support this. Fortunately it isn't needed anyway
because intmax_t is always either long or long long on linux.

========================================

Then we can use an _MSC_VER guard around this stuff to exclude it on *nix.

Let me know if (and where) you need this and I will do it.

Brian

[Bill Hart]

On 12 October 2012 22:13, Brian Gladman <b...@gladman.plus.com> wrote:
> -----Original Message----- From: Bill Hart
> Sent: Friday, October 12, 2012 10:05 PM
>
> To: mpir-...@googlegroups.com
> Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released
>
> [snip]
>
>>
>> I have a feeling we need to go back to some underlying principles here.
>>
>> So for a start, intmax_t and uintmax_t on Windows are defined in stdint.h
>> (C) or cstdint (C++) and they can only be used on MSVC10 and later. They
>> can be detected by looking for the stdint.h guard _STDINT which can hence
>> be
>> used to remove code and tests of these types.
>
>
> The _STDINT guard is define in stdint.h. So you need to include it
> before you can check if it is available.
>
> ========================================
> In test code yes but not in mpirxx.h, where we can use
>
> #ifdef _STDINT
> code using uintmax_t and/or uintmax_t
> #endif
> ========================================

But this will always exclude that code unless stdint.h is included
somewhere. So where is it going to be included? It would have to be
included in our test code, which we can't do.

It's also a massive burden on the user to test whether stdint.h is
available, and to know to include before mpirxx.h if it is.

Anyhow, I've simply removed c++ support on linux for intmax_t
operators, which now works fine on both x86_64 and ia64.

>
>
> On linux configure does a test by trying to compile a program with a
> stdint.h feature. If it is found it sets HAVE_STDINT_H to 1 in
> config.h. But the user does not have access to this. So the only way
> to guard for stdint.h is to either test that the compiler is fully C99
> compliant, for which there are defines. Or we can go through compiler
> by compiler and work out when it is available.
>
>>
>> I agree with your concern about config.h and HAVE_? defines in user code
>> so
>> we need an alternative way of guarding code and tests where these are
>> used.
>
>
> In general these don't exist. Configure creates config.h by compiling
> actual programs and seeing what doesn't crash the compiler. You can't
> do that with guards.
>
> The only solution is to not supply features which are not available on
> all systems, or to only supply them when they are guaranteed to be
> supported. For linux, this means what I said. We have to remove c++
> support for intmax_t functions. The linux C++ compilers simply don't
> make it possible to support this. Fortunately it isn't needed anyway
> because intmax_t is always either long or long long on linux.
>
> ========================================
>
> Then we can use an _MSC_VER guard around this stuff to exclude it on *nix.
>
> Let me know if (and where) you need this and I will do it.

Ok. I've just done this right now.

So, does it all work on Windows now?

Bill.

>
> Brian

[Brian Gladman]

==============================
When an MPIR user includes stdint.h or cstdint in _their_ code before they
include mpirxx.h, the types in question will then be available to them
==============================

It's also a massive burden on the user to test whether stdint.h is
available, and to know to include before mpirxx.h if it is.

==============================
If they want to use facilities that _require_ either stdint.h or cstdint,
how is this a burden that they can avoid?

Brian

[Bill Hart]

OK, but we can't test that this works.

>
>
> It's also a massive burden on the user to test whether stdint.h is
> available, and to know to include before mpirxx.h if it is.
>
> ==============================
> If they want to use facilities that _require_ either stdint.h or cstdint,
> how is this a burden that they can avoid?
>
>

Yes, you are right about this point.

Bill.

[Brian Gladman]

================================
If we want a test for this we can add one to the test suite and only invoke
it on systems that have stdint.h.

This would be easy on Windows but I accept that this may not be on *nix.

Do we want to get rid of all these uses of config.h in the tests?

cxx\t-assign.cc(22):#include "config.h"
cxx\t-binary.cc(22):#include "config.h"
cxx\t-constr.cc(22):#include "config.h"
cxx\t-misc.cc(29):#include "config.h"
cxx\t-ops.cc(22):#include "config.h"
cxx\t-prec.cc(22):#include "config.h"
cxx\t-ternary.cc(22):#include "config.h"
cxx\t-unary.cc(22):#include "config.h"
misc\t-locale.c(26):#include "config.h"
misc\t-printf.c(30):#include "config.h"
misc\t-scanf.c(34):#include "config.h"
mpf\t-inp_str.c(22):#include "config.h"
mpn\t-get_d.c(28):#include "config.h"
mpq\t-aors.c(22):#include "config.h"
mpq\t-inp_str.c(22):#include "config.h"
mpz\t-inp_str.c(22):#include "config.h"
mpz\io.c(22):#include "config.h"
mpz\t-io_raw.c(22):#include "config.h"
4\Release\gmp-impl.h(112):#include "config.h"
vc10\getopt.c(34):# include <config.h>
misc.c(22):#include "config.h"
mpn\t-invert.c(30):#include "config.h"
mpz\t-get_sx.c(26):#include "config.h"
mpz\t-set_sx.c(25):#include "config.h"
mpz\t-get_ux.c(25):#include "config.h"
mpz\t-set_ux.c(25):#include "config.h"

Brian

[Bill Hart]

This is *not* possible on linux. The presence or otherwise of stdint.h
is not a feature of the compiler (before c99) but a feature of the
libc. There simply isn't a way to do compile time testing for its
existence. You absolutely have to use the HAVE_STDINT_H flag provided
by configure in config.h.

For that reason, we can't get around using config.h in our tests.

It won't work on linux if we do, for the above reason. The danger of
course is that the tests could rely on things that are not available
to the user.

But this seems unavoidable.

By the way, I just made <climits> included unconditionally. We need
this to test for LLONG_MAX on some linux systems. Fortunately this is
a standard header. It doesn't cause a problem any more because we do
not need INTMAX_MAX on linux.

This change shouldn't affect the Windows builds, and I just tested
that it works on ia64 and x86_64.

Two machines down, only a couple of dozen to go.

The biggest problems on x86_64 and ia64 now are the format specifiers
for intmax_t and size_t. But both of these are another can of worms.
To get them correct on linux we need to use the macros leif specified.
But these aren't available on some linux systems and on MSVC because
they only partly implements stdint.h as they are not fully C99
compliant.

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Friday, October 12, 2012 10:46 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released

[snip]

> ================================
> If we want a test for this we can add one to the test suite and only
> invoke
> it on systems that have stdint.h.
>
> This would be easy on Windows but I accept that this may not be on *nix.

This is *not* possible on linux. The presence or otherwise of stdint.h
is not a feature of the compiler (before c99) but a feature of the
libc. There simply isn't a way to do compile time testing for its
existence. You absolutely have to use the HAVE_STDINT_H flag provided
by configure in config.h.

For that reason, we can't get around using config.h in our tests.

========================
Ok, that work we don't need to do :-)

I have made a change to the _MSC_VER guard in mpirxx.h to exclude things
before MSVC 10.

Brian

[Bill Hart]

There are a couple more instances of _MSC_VER guards in mpirxx.h. Did
you only mean to change two of them?

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Friday, October 12, 2012 10:58 PM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released

[snip]

There are a couple more instances of _MSC_VER guards in mpirxx.h. Did
you only mean to change two of them?

========================
No, I meant to do all of them - I'll go through this again.

By the way, I have been going through the tests that use config.h and I have
done about ten of them so far and I haven't found even one that actually
needs config.h on Windows (i.e the test compiles and runs when this include
is omitted).

Brian

[Bill Hart]

On 12 October 2012 23:06, Brian Gladman <b...@gladman.plus.com> wrote:
> -----Original Message----- From: Bill Hart
> Sent: Friday, October 12, 2012 10:58 PM
>
> To: mpir-...@googlegroups.com
> Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released
>
> [snip]
>
> There are a couple more instances of _MSC_VER guards in mpirxx.h. Did
> you only mean to change two of them?
>
> ========================
> No, I meant to do all of them - I'll go through this again.
>

OK, I believe there are two more instances.

> By the way, I have been going through the tests that use config.h and I have
> done about ten of them so far and I haven't found even one that actually
> needs config.h on Windows (i.e the test compiles and runs when this include
> is omitted).
>

Well, we can try removing them and adding them back in if they are
actually needed. Probably they were only added for this specific
problem, which we've now resolved by simply excluding the relevant
code on Linux.

Bill.

[Brian Gladman]

=============================
Ok, I'll go through them and take them out if they are not needed on
Windows. You can then test is this breaks the tests on *nix.

On the print format issue for mp_limb_t, mp_limb_unsigned_t, intmax_t and
uintmax_t, mp_bitcnt_t, ... should we add format specifiers (or macros) in
gmp_h.in where these types are defined?

Brian

[Bill Hart]

Yeah, but I think the people who came up with this new "feature" of C
compilers sat around a table late one night drinking vodka and decided
to implement the most useless and most difficult to rectify "feature"
their evil brains could concoct. So I am not convinced there are
portable macros which actually work everywhere. So we are probably
wasting our time trying.

Bill.

[Brian Gladman]

========================

On Windows we could at least set up "%ld" or "%lld" depending on whether
limbs (and other types) are 32 or 64 bits.

Brian

[Bill Hart]

On 7 October 2012 04:10, leif <not.r...@online.de> wrote:
> With GCC 4.7.0 (and CFLAGS="-O0 -finline-functions -fschedule-insns", since
> this version is severely broken on Itanium) I get:
>
> libtool: link: ranlib .libs/libtests.a
> libtool: link: ( cd ".libs" && rm -f "libtests.la" && ln -s "../libtests.la"
> "libtests.la" )
> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../mpir-2.6.0-alpha1/tests -I..
> -I../../mpir-2.6.0-alpha1 -O0 -finline-functions -fschedule-insns -c
> ../../mpir-2.6.0-alpha1/tests/t-bswap.c
> /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -O0
> -finline-functions -fschedule-insns -o t-bswap t-bswap.o libtests.la
> ../libmpir.la
> libtool: link: gcc -std=gnu99 -O0 -finline-functions -fschedule-insns -o
> .libs/t-bswap t-bswap.o ./.libs/libtests.a
> /home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/.libs/libmpir.so -lm
> ../.libs/libmpir.so
> /home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/.libs/libmpir.so:
> undefined reference to `mpn_addmod_2expp1_1'
> collect2: error: ld returned 1 exit status
> make[4]: *** [t-bswap] Error 1
> make[4]: Leaving directory
> `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/tests'
> make[3]: *** [check-am] Error 2
> make[3]: Leaving directory
> `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/tests'
> make[2]: *** [check-recursive] Error 1
> make[2]: Leaving directory
> `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/tests'
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory
> `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0'
> make: *** [check] Error 2
>

It's pointless trying to build anything with gcc 4.7.0. It's a totally
useless version of the compiler.

Having said that, the function in question is a GMP_EXTERN_INLINE
function defined in gmp-impl.h. Unfortunately, GMP_EXTERN_INLINE is
not defined in gmp-impl.h.

I'll move the definition into gmp-h.in where it is actually defined.

I've no idea why this worked everywhere else but not on this system.
It could still be a compiler bug of course.

>
> Btw, invalid options to 'configure' (e.g. '--enable-gmp-compat' or
> '--enable-foo') are silently ignored, even with '-v'; probably just some
> (newer) autotools "feature"...

I think we possibly do this deliberately as some options need to be
passed to yasm's configure.

If you can give me a list of all possible invalid options users will
type, I'll make sure they are excluded. (Just joking.)

Bill.

>
>
> -leif
>
>
>
>>
>> Thank you to the all people who made comments on our development list,
>> who provided bug reports and helped with testing. This includes, but
>> is probably not limited to Case van Horsen, David Cleaver, Pavel
>> Holoborodko and Sisyphus.
>>
>> A full list of code contributions to MPIR can be found in the AUTHORS
>> file in the source tarball.
>>
>> Best Wishes,
>>
>> The MPIR Team.

>
>
> --
> () The ASCII Ribbon Campaign
> /\ Help Cure HTML E-Mail
>

[Bill Hart]

Yes. Though this is not the issue I was talking about.

We compile on *nix with -std=gnu99, and the newer compilers complain
that we aren't using the new C99 format specifiers for intmax_t and
size_t. Of course these are not defined on older compilers, even if
they do support the -std=gnu99 option. So what we are supposed to do
about it is anyone's guess.

Eventually these compiler warnings, which are numerous, will become
compiler errors. At that point I suggest we write our own compiler.

Bill.

[Bill Hart]

I decided to just leave it where it was and define it __inline__ on
*nix and __inline on MSVC. Apparently this is not completely portable,
but we can deal with any issues if and when they arise. I suspect
there will only be issues on machines whose vendors went out of
business years ago.

Bill.

[leif]

Well, the crude macros (or what they expand to) are not a feature of the
compiler, but the implementation of the printf() and scanf() family of
functions, i.e., again the C library. (Although e.g. GCC actually
interprets format strings to eventually generate warnings.)


And while you cannot use sizeof() in preprocessor conditionals, you
could of course do things like

printf(sizeof(foo)==sizeof(long)?"%ld\n":"%lld\n", foo);

(or dynamically create/modify some format string variable in the code
and pass that).


-leif


P.S.: For the stdint.h / inttypes.h issue, you could at least include /
use them if __STDC_VERSION__ >= 199901L (and __STDC_HOSTED__ is defined
;-) ). IIRC MPIR compiles its tests with '-std=c99' or '-std=gnu99' and
the like if possible anyway.

[Bill Hart]

Yeah but I bet that breaks it on Apple's GCC.

Bill.

[Bill Hart]

Ah nice. This fix of course causes all sorts of multiple symbol clashes on ia64.

Back to the drawing board.

Bill.

[leif]

:-) Birthday edition...

> Having said that, the function in question is a GMP_EXTERN_INLINE
> function defined in gmp-impl.h. Unfortunately, GMP_EXTERN_INLINE is
> not defined in gmp-impl.h.
>
> I'll move the definition into gmp-h.in where it is actually defined.
>
> I've no idea why this worked everywhere else but not on this system.
> It could still be a compiler bug of course.

I haven't looked at this at all, but I'd guess it's related to the
optimization level, i.e., there usually don't remain any references to
that function.

>> Btw, invalid options to 'configure' (e.g. '--enable-gmp-compat' or
>> '--enable-foo') are silently ignored, even with '-v'; probably just some
>> (newer) autotools "feature"...
>
> I think we possibly do this deliberately as some options need to be
> passed to yasm's configure.

The recursive 'configure' is already called with
'--disable-option-checking' (or what it is called).

> If you can give me a list of all possible invalid options users will
> type, I'll make sure they are excluded. (Just joking.)

No space left on device... :-/

But you should certainly test for '--enable-gmpcombat'.


-leif

[Bill Hart]

I've replaced it with a macro. The poor man's portable inline.

This seems to work (after correcting a bug in my first attempt). So
hopefully that bug is knocked on the head.

Once Brian is happy that Windows is doing what it is supposed to, and
I've removed the internal symbol conflicts with flint, I'll issue
another alpha.

Bill.

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Saturday, October 13, 2012 12:48 AM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released

I've replaced it with a macro. The poor man's portable inline.

This seems to work (after correcting a bug in my first attempt). So
hopefully that bug is knocked on the head.

Once Brian is happy that Windows is doing what it is supposed to, and
I've removed the internal symbol conflicts with flint, I'll issue
another alpha.

===============================
I have removed config.h from all test files that do not appear to require
its inclusion.

All tests with such inclusions that remain fail on Windows when config.h is
not included.

These are:

misc\t-locale.c(26):#include <config.h>
misc\t-printf.c(30):#include "config.h"
misc\t-scanf.c(34):#include "config.h"

mpz\t-get_sx.c(26):#include "config.h"
mpz\t-set_sx.c(25):#include "config.h"
mpz\t-get_ux.c(25):#include "config.h"
mpz\t-set_ux.c(25):#include "config.h"

Bill, could you run the tests on *nix to check if I have removed any that
need config.h?

I intend to look at the remaining files that need config.h later today to
see if this is really needed.

Brian

[Brian Gladman]

-----Original Message-----
From: Bill Hart
Sent: Saturday, October 13, 2012 12:48 AM
To: mpir-...@googlegroups.com
Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released

I've replaced it with a macro. The poor man's portable inline.

This seems to work (after correcting a bug in my first attempt). So
hopefully that bug is knocked on the head.

Once Brian is happy that Windows is doing what it is supposed to, and
I've removed the internal symbol conflicts with flint, I'll issue
another alpha.

============================
In addition to removing config.h from tests where it appears not to be
needed, I have changed the four (u)intmax_t tests (mpz.get_sx, mpz.get_ux,
mpz.set_sx, mpz.set_ux) to skip them if stdint.h is not available.

Bill, in addition to checking that all the tests are still working on *nix,
can you please also check the logic for skipping tests in the (u)intmax_t
tests to ensure that this is correct on *nix.

I don't think any more needs to be done on Windows.

Brian

[Bill Hart]

Hi Brian,

I have to go out, but ran a quick test. I get the following:

libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -m64
-O3 -march=k8 -mtune=k8 -c misc.c -fPIC -DPIC -o .libs/misc.o
misc.c: In function 'tests_rand_start':
misc.c:115: warning: implicit declaration of function 'gettimeofday'
misc.c: In function 'tests_hardware_setround':
misc.c:487: error: 'FE_TONEAREST' undeclared (first use in this function)
misc.c:487: error: (Each undeclared identifier is reported only once
misc.c:487: error: for each function it appears in.)
misc.c:488: error: 'FE_TOWARDZERO' undeclared (first use in this function)
misc.c:489: error: 'FE_UPWARD' undeclared (first use in this function)
misc.c:490: error: 'FE_DOWNWARD' undeclared (first use in this function)
misc.c:494: warning: implicit declaration of function 'fegetround'
misc.c:496: warning: implicit declaration of function 'fesetround'
misc.c: In function 'tests_hardware_getround':
misc.c:521: error: 'FE_TOWARDZERO' undeclared (first use in this function)
misc.c:521: error: 'FE_DOWNWARD' undeclared (first use in this function)
misc.c:521: error: 'FE_UPWARD' undeclared (first use in this function)
misc.c:521: error: 'FE_TONEAREST' undeclared (first use in this function)
make[4]: *** [misc.lo] Error 1
make[4]: Leaving directory `/home/wbhart/mpir-trunk/tests'

So I guess misc.c needs config.h.

Bill.

[Brian Gladman]

===============================

I have put it back.

Brian