Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Saturday, October 13, 2012 12:48 AM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Saturday, October 13, 2012 12:48 AM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
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. On 13 October 2012 11:28, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Saturday, October 13, 2012 12:48 AM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Saturday, October 13, 2012 12:37 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released 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. === I have put it back. 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-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
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.
On 12 October 2012 18:53, Bill Hart goodwillh...@googlemail.com wrote:
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.
On 11 October 2012 16:01, Bill Hart goodwillh...@googlemail.com wrote:
On 7 October 2012 04:10, leif not.rea...@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
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
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.
On 12 October 2012 19:24, Bill Hart goodwillh...@googlemail.com wrote:
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.
On 12 October 2012 18:53, Bill Hart goodwillh...@googlemail.com wrote:
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.
On 11 October 2012 16:01, Bill Hart goodwillh...@googlemail.com wrote:
On 7 October 2012 04:10, leif not.rea...@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
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.
Bill.
On 12 October 2012 20:10, Bill Hart goodwillh...@googlemail.com wrote:
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.
On 12 October 2012 19:24, Bill Hart goodwillh...@googlemail.com wrote:
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.
On 12 October 2012 18:53, Bill Hart goodwillh...@googlemail.com wrote:
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.
On 11 October 2012 16:01, Bill Hart goodwillh...@googlemail.com wrote:
On 7 October 2012 04:10, leif not.rea...@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
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Friday, October 12, 2012 8:18 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
Yeah, I've just done it now. Bill. On 12 October 2012 20:23, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 8:18 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
Oh no! Our mpirxx.h file also checks HAVE_STDINT_H This is defined in config.h too!! Bill. On 12 October 2012 20:24, Bill Hart goodwillh...@googlemail.com wrote: Yeah, I've just done it now. Bill. On 12 October 2012 20:23, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 8:18 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
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 ) Bill. On 12 October 2012 20:28, Bill Hart goodwillh...@googlemail.com wrote: Oh no! Our mpirxx.h file also checks HAVE_STDINT_H This is defined in config.h too!! Bill. On 12 October 2012 20:24, Bill Hart goodwillh...@googlemail.com wrote: Yeah, I've just done it now. Bill. On 12 October 2012 20:23, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 8:18 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
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. 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-devel@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-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
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. Bill. On 12 October 2012 20:34, Bill Hart goodwillh...@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-devel@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-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Friday, October 12, 2012 8:34 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Friday, October 12, 2012 8:39 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
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. Bill. On 12 October 2012 20:39, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 8:34 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Friday, October 12, 2012 8:44 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
It appears to be defined in limits.h on *nix if you use C, but stdint.h if you use C++. Bill. On 12 October 2012 20:55, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 8:44 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
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. On 12 October 2012 20:56, Bill Hart goodwillh...@googlemail.com wrote: It appears to be defined in limits.h on *nix if you use C, but stdint.h if you use C++. Bill. On 12 October 2012 20:55, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 8:44 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
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. On 12 October 2012 21:03, Bill Hart goodwillh...@googlemail.com wrote: 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. On 12 October 2012 20:56, Bill Hart goodwillh...@googlemail.com wrote: It appears to be defined in limits.h on *nix if you use C, but stdint.h if you use C++. Bill. On 12 October 2012 20:55, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 8:44 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
Nope, now ia64 doesn't work again. Bill. On 12 October 2012 21:05, Bill Hart goodwillh...@googlemail.com wrote: 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. On 12 October 2012 21:03, Bill Hart goodwillh...@googlemail.com wrote: 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. On 12 October 2012 20:56, Bill Hart goodwillh...@googlemail.com wrote: It appears to be defined in limits.h on *nix if you use C, but stdint.h if you use C++. Bill. On 12 October 2012 20:55, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 8:44 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
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(%20PRIu64\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 goodwillh...@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-devel@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-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
I believe these only get defined if you first define some macro. On 12 October 2012 21:13, leif not.rea...@online.de wrote: 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(%20PRIu64\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 goodwillh...@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-devel@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-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Friday, October 12, 2012 9:15 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released I believe these only get defined if you first define some macro. On 12 October 2012 21:13, leif not.rea...@online.de wrote: 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(%20PRIu64\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 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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
Brian Gladman wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 9:15 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released I believe these only get defined if you first define some macro. On 12 October 2012 21:13, leif not.rea...@online.de wrote: 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(%20PRIu64\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 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. Well, it does (or should). -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: leif Sent: Friday, October 12, 2012 9:32 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released Brian Gladman wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 9:15 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released I believe these only get defined if you first define some macro. On 12 October 2012 21:13, leif not.rea...@online.de wrote: 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(%20PRIu64\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 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. Well, it does (or should). = So including climits in mpirxx.h should not cause problems on *nix? 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-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
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. On 12 October 2012 21:35, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: leif Sent: Friday, October 12, 2012 9:32 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released Brian Gladman wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 9:15 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released I believe these only get defined if you first define some macro. On 12 October 2012 21:13, leif not.rea...@online.de wrote: 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(%20PRIu64\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 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. Well, it does (or should). = So including climits in mpirxx.h should not cause problems on *nix? 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-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
cstdint is only available with a c++0x compiler. So that didn't work. On 12 October 2012 21:36, Bill Hart goodwillh...@googlemail.com wrote: 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. On 12 October 2012 21:35, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: leif Sent: Friday, October 12, 2012 9:32 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released Brian Gladman wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 9:15 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released I believe these only get defined if you first define some macro. On 12 October 2012 21:13, leif not.rea...@online.de wrote: 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(%20PRIu64\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 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. Well, it does (or should). = So including climits in mpirxx.h should not cause problems on *nix? 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-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
On 12 October 2012 21:22, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 9:15 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released I believe these only get defined if you first define some macro. On 12 October 2012 21:13, leif not.rea...@online.de wrote: 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(%20PRIu64\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 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 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. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
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. On 12 October 2012 21:45, Bill Hart goodwillh...@googlemail.com wrote: On 12 October 2012 21:22, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 9:15 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released I believe these only get defined if you first define some macro. On 12 October 2012 21:13, leif not.rea...@online.de wrote: 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(%20PRIu64\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 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 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. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Friday, October 12, 2012 9:45 PM To: mpir-devel@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. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
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-devel@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 Bill. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Friday, October 12, 2012 10:05 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
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-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Friday, October 12, 2012 10:20 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released 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-devel@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. == 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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
On 12 October 2012 22:27, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 10:20 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released 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-devel@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. == 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 == 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. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Friday, October 12, 2012 10:29 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released On 12 October 2012 22:27, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 10:20 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released 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-devel@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. == 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 == OK, but we can't test that this works. 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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
On 12 October 2012 22:37, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 10:29 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released On 12 October 2012 22:27, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 10:20 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released 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-devel@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. == 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 == OK, but we can't test that this works. 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. 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 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. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Friday, October 12, 2012 10:46 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
On 12 October 2012 22:52, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 10:46 PM To: mpir-devel@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. There are a couple more instances of _MSC_VER guards in mpirxx.h. Did you only mean to change two of them? Bill. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Friday, October 12, 2012 10:58 PM To: mpir-devel@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
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-devel@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. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
-Original Message- From: Bill Hart Sent: Friday, October 12, 2012 11:11 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released 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-devel@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. = 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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
On 7 October 2012 04:10, leif not.rea...@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
On 12 October 2012 23:27, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 11:23 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released On 12 October 2012 23:19, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 11:11 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released 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-devel@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. = 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? 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. On Windows we could at least set up %ld or %lld depending on whether limbs (and other types) are 32 or 64 bits. 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. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
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. On 12 October 2012 23:48, Bill Hart goodwillh...@googlemail.com wrote: On 7 October 2012 04:10, leif not.rea...@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
Bill Hart wrote: On 12 October 2012 23:19, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 11:11 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released 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-devel@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. = 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? 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. 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. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
On 13 October 2012 00:12, leif not.rea...@online.de wrote: Bill Hart wrote: On 12 October 2012 23:19, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 11:11 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released 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-devel@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. = 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? 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. 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. Yeah but I bet that breaks it on Apple's GCC. Bill. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
Ah nice. This fix of course causes all sorts of multiple symbol clashes on ia64. Back to the drawing board. Bill. On 13 October 2012 00:10, Bill Hart goodwillh...@googlemail.com wrote: 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. On 12 October 2012 23:48, Bill Hart goodwillh...@googlemail.com wrote: On 7 October 2012 04:10, leif not.rea...@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
Bill Hart wrote: On 7 October 2012 04:10, leif not.rea...@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. :-) 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 -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
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. Bill. On 13 October 2012 00:16, Bill Hart goodwillh...@googlemail.com wrote: Ah nice. This fix of course causes all sorts of multiple symbol clashes on ia64. Back to the drawing board. Bill. On 13 October 2012 00:10, Bill Hart goodwillh...@googlemail.com wrote: 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. On 12 October 2012 23:48, Bill Hart goodwillh...@googlemail.com wrote: On 7 October 2012 04:10, leif not.rea...@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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
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]:
