Error building PPL on Cygwin64

[Jean-Pierre Flori]

Dear all,

I get the following error when building PPL on top of MPIR 2.7.0.alpha4 on Cygwin64:
/home/jp/sage.git/local/include/gmpxx.h:1548:3: error: '__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(intmax_t)' cannot be overloaded
   __gmp_expr(intmax_t l) { mpz_init_set_sx(mp, l); }
   ^

Loos like https://groups.google.com/d/msg/mpir-devel/DA-ywrNv80w/te-P10I3vVQJ

[Bill Hart]

Argh, I hate C++. What a useless language.

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+...@googlegroups.com.
To post to this group, send email to mpir-...@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[Brian Gladman]

On 07/04/2014 23:02, Bill Hart wrote:
> Argh, I hate C++. What a useless language.

When we attempt to overload (u)intmax_t types, won't we inevitably be
duplicating overloads of either long or long long types?

I am no expert on C++ overloading but aren't overloads on type aliases
illegal?

Brian

[Bill Hart]

Sounds about right to me. C/C++ never did decide whether the language had a nominative type system or not.

Last night I wrote some C++. It complained that I didn't have an overload for int, so I added one. Later in an almost identical situation, I added one for int and it complained that there was then an ambiguity with the overload for long, const char * and some other type that wasn't even related in my opinion. There's seemingly no way to know when it will complain because you didn't overload for both int and long, and when it it will complain that you did.

I then had a function f which I overloaded for mp_limb_t, which I made explicit so it wouldn't convert from other types automatically. It completely ignored that and told me that it didn't know if f((unsigned long) a) was meant to be a call to f(long) or f(int). I mean, WTF. This language is just idiotic. I fixed the problem by removing the overload for int, which was obviously easily confused with an unsigned long!

I think GMP recently did away with their old C++ header and replaced it with something easier to maintain (no idea about the details, I'm guessing based on the little I've seen).

I guess ridding the earth of C++ is not one of the possible solutions open to us?

Bill.

[Brian Gladman]

We attempt to protect against overloading type aliases with:

#if defined(MPIR_HAVE_STDINT)
# if INTMAX_MAX != LONG_MAX && (INTMAX_MAX != LLONG_MAX ||
!defined(MPIRXX_HAVE_LLONG))
# define MPIRXX_INTMAX_T 1
# endif
# if UINTMAX_MAX != ULONG_MAX && (UINTMAX_MAX != ULLONG_MAX ||
!defined(MPIRXX_HAVE_LLONG))
# define MPIRXX_UINTMAX_T 1
# endif
#endif

at around line 60 in mpirxx.h. Unless I am misreading this, the above
guards on Windows should evaluate to:

if TRUE && (FALSE || FALSE)

so the overloads should not be seen (they aren't on Visual Studio).

It seems that something is going wrong in these guards on CygWin64.

Brian

[Bill Hart]

On Cygwin64 intmax_t should be long long. Anyway, we can compile those guards and see which is evaluating incorrectly. Possibly some header defining LLONG_MAX is missing, or something like that.

Bill.

   Brian

[Brian Gladman]

On 08/04/2014 00:03, Bill Hart wrote:
> Sounds about right to me. C/C++ never did decide whether the language
> had a nominative type system or not.

> Last night I wrote some C++. It complained that I didn't have an
> overload for int, so I added one. Later in an almost identical
> situation, I added one for int and it complained that there was then an
> ambiguity with the overload for long, const char * and some other type
> that wasn't even related in my opinion. There's seemingly no way to know
> when it will complain because you didn't overload for both int and long,
> and when it it will complain that you did.
>
> I then had a function f which I overloaded for mp_limb_t, which I made
> explicit so it wouldn't convert from other types automatically. It
> completely ignored that and told me that it didn't know if f((unsigned
> long) a) was meant to be a call to f(long) or f(int). I mean, WTF. This
> language is just idiotic. I fixed the problem by removing the overload
> for int, which was obviously easily confused with an unsigned long!
>
> I think GMP recently did away with their old C++ header and replaced it
> with something easier to maintain (no idea about the details, I'm
> guessing based on the little I've seen).
>
> I guess ridding the earth of C++ is not one of the possible solutions
> open to us?

Can we keep a part of it please :-)

I like a lot of C++, especially the ability to define operator
overloading with classes. I do a lot of multiple precision work and the
ability to have the compiler parse the arithmetic while operating on a
class type for large integers and large reals is a big plus for me.

Brian

[Brian Gladman]

On 08/04/2014 00:14, Bill Hart wrote:
> On Cygwin64 intmax_t should be long long. Anyway, we can compile those
> guards and see which is evaluating incorrectly. Possibly some header
> defining LLONG_MAX is missing, or something like that.

On Cygwin64 it seems that longs are 8 bytes. So we have an supposed
Windows ABI that has not adopted the Windows ABI!

Maybe our code doesn't expect this sort of behaviour?

Brian

[leif]

Brian Gladman wrote:
> On 08/04/2014 00:14, Bill Hart wrote:
>> On Cygwin64 intmax_t should be long long. Anyway, we can compile those
>> guards and see which is evaluating incorrectly. Possibly some header
>> defining LLONG_MAX is missing, or something like that.
>
> On Cygwin64 it seems that longs are 8 bytes. So we have an supposed
> Windows ABI that has not adopted the Windows ABI!

I guess ridding the earth of Windows is not one of the possible
solutions open to us?


-leif

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

[Bill Hart]

So assuming limits.h has been included, we have:

MPIR_HAVE_STDINT 1

INTMAX_MAX != LONG_MAX

UINTMAX_MAX != ULONG_MAX

This is because on Cygwin64 INTMAX_MAX is not defined. Who knows where they put the definition. It's not in stdint.h or limits.h.

Bill.

On 8 April 2014 02:06, Brian Gladman <b...@gladman.plus.com> wrote:

   Brian

[Bill Hart]

Apparently they are defined if you do:

#define __STDC_LIMIT_MACROS 1

Bill.

[Jean-Pierre Flori]

On Wednesday, April 9, 2014 4:08:21 PM UTC+2, Bill Hart wrote:

So assuming limits.h has been included, we have:

MPIR_HAVE_STDINT 1

INTMAX_MAX != LONG_MAX

UINTMAX_MAX != ULONG_MAX

This is because on Cygwin64 INTMAX_MAX is not defined. Who knows where they put the definition. It's not in stdint.h or limits.h.

Strange.
I do have:
 jp@napoleon-7 /usr/include
$ grep -r INTMAX .
./stdint.h:#define INTMAX_MIN (-__I64(9223372036854775807) - 1)
./stdint.h:#define INTMAX_MAX (__I64(9223372036854775807))
./stdint.h:#define UINTMAX_MAX (__U64(18446744073709551615))
./stdint.h:#define INTMAX_C(x) x ## L
./stdint.h:#define UINTMAX_C(x) x ## UL
./stdint.h:#define INTMAX_C(x) x ## LL
./stdint.h:#define UINTMAX_C(x) x ## ULL

and indeed there:
/* Limits of greatest-width integer types */

#define INTMAX_MIN (-__I64(9223372036854775807) - 1)
#define INTMAX_MAX (__I64(9223372036854775807))
#define UINTMAX_MAX (__U64(18446744073709551615))

And I have LONG_MAX in limits.h.

[Bill Hart]

Yeah, as I said, they get defined only if you first do:

#define __STDC_LIMIT_MACROS 1

Bill.

[Bill Hart]

So probably the problem will go away for them if they upgrade to the latest autotools. It has a test for this and presumably is automatically adding the flag when it is building our own test code.

Bill.

[Jean-Pierre Flori]

2014-04-09 16:24 GMT+02:00 Bill Hart <goodwi...@googlemail.com>:
> Yeah, as I said, they get defined only if you first do:
>
> #define __STDC_LIMIT_MACROS 1

It seems I don't need this define on my setup (unless I misunderstood you):

$ cat bla.c
#include <stdint.h>
#include <limits.h>

#pragma message LONG_MAX
#pragma message INTMAX_MAX
#pragma message __STDC_LIMIT_MACROS
#if LONG_MAX == INTMAX_MAX
#pragma message eq
#endif

$cpp bla.c
...
# 4 "bla.c"
#pragma message 9223372036854775807L
# 4 "bla.c"


# 5 "bla.c"
#pragma message (9223372036854775807L)
# 5 "bla.c"


# 6 "bla.c"
#pragma message __STDC_LIMIT_MACROS
# 6 "bla.c"



# 8 "bla.c"
#pragma message eq
# 8 "bla.c"

[Bill Hart]

g++ bla.c

prag.c:5:17: warning: expected a string after ‘#pragma message’ [-Wpragmas]

 #pragma message INTMAX_MAX

                 ^

prag.c:6:17: warning: expected a string after ‘#pragma message’ [-Wpragmas]

 #pragma message __STDC_LIMIT_MACROS

[Bill Hart]

$ cpp bla.c

# 1 "bla.c"

# 1 "<command-line>"

# 1 "bla.c"

# 1 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/stdint.h" 1 3 4

# 9 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/stdint.h" 3 4

# 1 "/usr/include/stdint.h" 1 3 4

# 14 "/usr/include/stdint.h" 3 4

# 1 "/usr/include/bits/wordsize.h" 1 3 4

# 15 "/usr/include/stdint.h" 2 3 4

typedef signed char int8_t;

typedef short int16_t;

typedef int int32_t;

typedef long int64_t;

typedef unsigned char uint8_t;

typedef unsigned short uint16_t;

typedef unsigned int uint32_t;

typedef unsigned long uint64_t;

typedef signed char int_least8_t;

typedef short int_least16_t;

typedef int int_least32_t;

typedef long int_least64_t;

typedef unsigned char uint_least8_t;

typedef unsigned short uint_least16_t;

typedef unsigned int uint_least32_t;

typedef unsigned long uint_least64_t;

typedef signed char int_fast8_t;

typedef long int_fast16_t;

typedef long int_fast32_t;

typedef long int_fast64_t;

typedef unsigned char uint_fast8_t;

typedef unsigned long uint_fast16_t;

typedef unsigned long uint_fast32_t;

typedef unsigned long uint_fast64_t;

# 91 "/usr/include/stdint.h" 3 4

typedef long intptr_t;

typedef unsigned long uintptr_t;

typedef long intmax_t;

typedef unsigned long uintmax_t;

# 10 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/stdint.h" 2 3 4

# 2 "bla.c" 2

# 1 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include-fixed/limits.h" 1 3 4

# 34 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include-fixed/limits.h" 3 4

# 1 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include-fixed/syslimits.h" 1 3 4

# 1 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include-fixed/limits.h" 1 3 4

# 168 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include-fixed/limits.h" 3 4

# 1 "/usr/include/limits.h" 1 3 4

# 14 "/usr/include/limits.h" 3 4

# 1 "/usr/include/features.h" 1 3 4

# 14 "/usr/include/features.h" 3 4

# 1 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include-fixed/sys/cdefs.h" 1 3 4

# 52 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include-fixed/sys/cdefs.h" 3 4

# 1 "/usr/include/sys/features.h" 1 3 4

# 53 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include-fixed/sys/cdefs.h" 2 3 4

# 1 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/stddef.h" 1 3 4

# 147 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/stddef.h" 3 4

typedef long int ptrdiff_t;

# 212 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/stddef.h" 3 4

typedef long unsigned int size_t;

# 324 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/stddef.h" 3 4

typedef short unsigned int wchar_t;

# 54 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include-fixed/sys/cdefs.h" 2 3 4

# 15 "/usr/include/features.h" 2 3 4

# 15 "/usr/include/limits.h" 2 3 4

# 169 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include-fixed/limits.h" 2 3 4

# 8 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include-fixed/syslimits.h" 2 3 4

# 35 "/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include-fixed/limits.h" 2 3 4

# 3 "bla.c" 2

# 4 "bla.c"

#pragma message 9223372036854775807L

# 4 "bla.c"

# 5 "bla.c"

#pragma message (9223372036854775807L)

# 5 "bla.c"

# 6 "bla.c"

#pragma message __STDC_LIMIT_MACROS

# 6 "bla.c"

# 8 "bla.c"

#pragma message eq

# 8 "bla.c"

int main(void)

{

   return 0;

}

[Jean-Pierre Flori]

Oh sure, one has to use g++... and the the !__cpluplus becomes false.

--
Jean-Pierre Flori

[Bill Hart]

So same here, but they still aren't defined.

Bill.

[Bill Hart]

Try the following program with g++ with and without the first line:

#define __STDC_LIMIT_MACROS 1

#include <limits.h>

#include <stdint.h>

#include <iostream>

using namespace std;

#if INTMAX_MAX != LONG_MAX

#error error2

#endif

#if INTMAX_MAX != LLONG_MAX

#error error3

#endif

#if UINTMAX_MAX != ULONG_MAX

#error error5

#endif

#if UINTMAX_MAX != ULLONG_MAX

#error error6

#endif

int main(void)

{

   intmax_t a = 0;

    cout << INTMAX_MAX << " " << LLONG_MAX << endl;

   return 0;

}

[Jean-Pierre Flori]

2014-04-09 16:44 GMT+02:00 Bill Hart <goodwi...@googlemail.com>:
> Try the following program with g++ with and without the first line:
>

Sure, the first line is needed.

[Bill Hart]

So we could always add the following to mpirxx.h:

#ifdef __CYGWIN64__

#define __STDC_LIMIT_MACROS 1

#endif

It's a bit hacky, but it surely fixes the problem.

Bill.

[Jean-Pierre Flori]

That whould be
#if defined(__CYGWIN__) && defined(__x86_64__)

I'd like to check the issue does not arise on other systems first though.

--
Jean-Pierre Flori

[Bill Hart]

I don't really understand why our CXX tests compile on Cygwin64. I don't see this define anywhere. In fact, grepping the whole of mpir, it doesn't appear.

Bill.

[Bill Hart]

Oh, I saw quite some discussion of this on the web. They seemed to think __CYGWIN64__ was fine.

Bill.

On 9 April 2014 17:14, Jean-Pierre Flori <jpf...@gmail.com> wrote:

[Jean-Pierre Flori]

See http://cygwin.com/faq/faq.html#faq.programming.64bitporting-cygwin64

--
Jean-Pierre Flori

[Jean-Pierre Flori]

As far as PPL is concered, this looks bad:
http://www.cs.unipr.it/pipermail/ppl-devel/2009-January/013953.html

Note that the undef is still in the latest  PPL version (1.1).

[Bill Hart]

Great, I think I will add the following to mpirxx.h and head home for the day:

#ifdef __CYGWIN64__

#define else ; 

#define true ((rand()%10000) == 0 ? 0 : 1)

#warning Error: mpirxx.h line 30, Error: mpirxx.h line 30, Error: mpirxx.h line 30, Error: mpirxx.h line 30, Error: mpirxx.h line 30, ... internal segfault, please report.

#endif

[Jean-Pierre Flori]

On Wednesday, April 9, 2014 5:37:54 PM UTC+2, Bill Hart wrote:

Great, I think I will add the following to mpirxx.h and head home for the day:

Yeah.
To conclude, I'd say this is a PPL issue, so no action to be taken on the MPIR side.
Also note this is surely not Cygwin specific.

[Bill Hart]

I think that the flag should be passed in by the build system, which means flint will probably have to fix this.

However, perhaps there's another workaround worth considering, namely to check if INTMAX_MAX is defined. If not, then exclude the intmax code in that instance too, since we cannot be sure it will work.

Now recent autotools may even have a config.h flag to tell whether INTMAX_MAX is defined. We could check that.

Bill.

[Jean-Pierre Flori]

I've done some more testing and it seems the issue may not be stdc_limit_macros and stdint.h.
Indeed it seems that when PPL include stdint.h, the macro is well defined and I can retrieve the value of INTMAX_MAX.

The issue seems to be that for whatever reason the preprocessor treats gmpxx.h template stuff before actually including limits.h and so getting LONG_MAX...
Note that limits is one of the first thing included in gmpxx.h.

[Jean-Pierre Flori]

Ok, I think I got it.
LONG_MAX is defined in the "C" limits.h
What gmpxx.h includes is the "C++" limits.h.

[Bill Hart]

Also INTMAX_MAX?

I wonder if it is safe for us to include the C limits.h instead.

Bill.

[Jean-Pierre Flori]

On Sunday, April 13, 2014 11:40:15 PM UTC+2, Bill Hart wrote:

Also INTMAX_MAX?

Nope, this is defined in stdint.h and that header is included by PPL itself before including gmpxx.h.
 

I wonder if it is safe for us to include the C limits.h instead.

No idea.
But without it LONG_MAX is not defined on my system.

(And note that the C++ limits.h is needed, that was not a amistake I gues when seeing the comment next to the line inclduing it.)

[Jean-Pierre Flori]

On Sunday, April 13, 2014 11:42:48 PM UTC+2, Jean-Pierre Flori wrote:

On Sunday, April 13, 2014 11:40:15 PM UTC+2, Bill Hart wrote:

Also INTMAX_MAX?

Nope, this is defined in stdint.h and that header is included by PPL itself before including gmpxx.h.
 

I wonder if it is safe for us to include the C limits.h instead.

No idea.
But without it LONG_MAX is not defined on my system.

(In fact it gets included in the end, but after gmpxx.h is treated...)

[Jean-Pierre Flori]

I see:
"""
#if defined _WIN64
#include <limits.h>
#endif
"""
in gmp-impl.h
I'll have a look at that tomorrow.

[Jean-Pierre Flori]

FYI, same failure on gcc110 (linux/POWER7).

[Jean-Pierre Flori]

On Monday, April 14, 2014 12:09:58 PM UTC+2, Jean-Pierre Flori wrote:

FYI, same failure on gcc110 (linux/POWER7).

And PPL fails to configure when gmpxx includes climits.

[leif]

Jean-Pierre Flori wrote:
> FYI, same failure on gcc110 (linux/POWER7).

g++ -v?

The current "logic" in mpirxx.h is IMHO really pretty fragile. Note
btw. that C99 long longs aren't part of C++98, hence a preprocessor for
the latter (including '-std=c++98') doesn't even have to support them
(i.e., LL/ULL literals).

Besides giving some macros more intuitive names, I'd first make sure
every used macro is indeed defined (and error out or give a warning
otherwise). (MPIR_HAVE_STDINT for example doesn't imply that it has
been included, nor that the relevant macros are defined [in C++].)


-leif

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

[Jean-Pierre Flori]

On Monday, April 14, 2014 12:26:15 PM UTC+2, leif wrote:

Jean-Pierre Flori wrote:
> FYI, same failure on gcc110 (linux/POWER7).

g++ -v?

 $ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.7.2/lto-wrapper
Target: ppc64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux
Thread model: posix
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC)

The current "logic" in mpirxx.h is IMHO really pretty fragile.  Note
btw. that C99 long longs aren't part of C++98, hence a preprocessor for
the latter (including '-std=c++98') doesn't even have to support them
(i.e., LL/ULL literals).

Besides giving some macros more intuitive names, I'd first make sure
every used macro is indeed defined (and error out or give a warning
otherwise).  (MPIR_HAVE_STDINT for example doesn't imply that it has
been included, nor that the relevant macros are defined [in C++].)

I agree that prepending the tests for intmax_t != (long) long could be prepended with defined(...) &&

At least it would solve the PPL issue.

[Jeroen Demeyer]

When compiling Sage-6.4.beta1 with MPIR-2.7.0-alpha10 on Linux x86_64
with GCC 4.6.4, I get

gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I/usr/local/src/sage-config/local/include
-I/usr/local/src/sage-config/local/include/csage
-I/usr/local/src/sage-config/src
-I/usr/local/src/sage-config/src/sage/ext
-I/usr/local/src/sage-config/local/include/python2.7 -c
build/cythonized/sage/libs/ppl.cpp -o
build/temp.linux-x86_64-2.7/build/cythonized/sage/libs/ppl.o
-fno-strict-aliasing -w
In file included from build/cythonized/sage/libs/ppl.cpp:352:0:
../local/include/gmpxx.h:1548:3: error: ‘__gmp_expr<__mpz_struct [1],
__mpz_struct [1]>::__gmp_expr(intmax_t)’ cannot be overloaded
../local/include/gmpxx.h:1539:3: error: with ‘__gmp_expr<__mpz_struct
[1], __mpz_struct [1]>::__gmp_expr(long int)’
../local/include/gmpxx.h:1552:3: error: ‘__gmp_expr<__mpz_struct [1],
__mpz_struct [1]>::__gmp_expr(uintmax_t)’ cannot be overloaded
../local/include/gmpxx.h:1540:3: error: with ‘__gmp_expr<__mpz_struct
[1], __mpz_struct [1]>::__gmp_expr(long unsigned int)’
../local/include/gmpxx.h:1615:16: error: ‘__gmp_expr<__mpz_struct [1],
__mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct
[1]>::operator=(intmax_t)’ cannot be overloaded
../local/include/gmpxx.h:1604:16: error: with ‘__gmp_expr<__mpz_struct
[1], __mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct
[1]>::operator=(long int)’
../local/include/gmpxx.h:1619:16: error: ‘__gmp_expr<__mpz_struct [1],
__mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct
[1]>::operator=(uintmax_t)’ cannot be overloaded
../local/include/gmpxx.h:1606:16: error: with ‘__gmp_expr<__mpz_struct
[1], __mpz_struct [1]>& __gmp_expr<__mpz_struct [1], __mpz_struct
[1]>::operator=(long unsigned int)’
error: command 'gcc' failed with exit status 1

The reason is that you are overloading with "intmax_t" and "long int"
which is the same type.

I don't know if I should blame MPIR, PPL or Sage, but I just let you
know because this worked fine with MPIR-2.6.0.

Jeroen.

[Bill Hart]

There was a very long thread discussing this issue (specifically relating to PPL). It was my understanding we'd fixed it. It has to do with the inclusion of C instead of C++ headers which provide INTMAX_MAX or some such thing (I forget precisely now).

intmax_t and long int shouldn't both be overloaded if the right headers are included since we have defines to prevent it, based on the existence of INTMAX_MAX, I think.

Bill.

Jeroen.

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscribe@googlegroups.com.
To post to this group, send email to mpir-...@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

[Bill Hart]

Indeed I looked up the thread and we concluded that we needed check that LONG_MAX is defined before checking whether INTMAX_MAX != LONG_MAX in gmpxx.h. For some reasons LONG_MAX is not defined on some systems if C++ instead of C headers are included.

If INTMAX_MAX == LONG_MAX then there shouldn't be double overloading.

Bill.

[Jean-Pierre Flori]

In fact the fix you merged does not look sufficient.
I can also produce errors.

You should also check for defined(INTMAX_MAX) (and defined(UINTMAX_MAX)).
Just as in the following patch:
http://trac.sagemath.org/attachment/ticket/15015/mpirxx.2.patch

Feel free to merge it, I won't have time to do a proper pull request, sorry.

Best,
JP

[Bill Hart]

Thanks for looking into that again JP.

I will try to merge that soon.

Bill.

--

You received this message because you are subscribed to the Google Groups "mpir-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+...@googlegroups.com.

[Jeroen Demeyer]

On 2014-09-05 16:57, Bill Hart wrote:
> Thanks for looking into that again JP.
>
> I will try to merge that soon.

Is it by chance in 2.7.0-alpha11?

[Bill Hart]

No, sorry. There are numerous patches still to be merged for MPIR. I'll try to do them soon. I haven't had a weekend for months, and it's getting tiresome.

Bill.

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscribe@googlegroups.com.

[Bill Hart]

I have now merged this and the remaining patches from Brian Gladman for Windows.

I will shortly issue what will hopefully be the final alpha.

Bill.