Cast ambiguity compilation error

[Daniel J Sebald]

I've gotten Mercurial working on my FC3 machine (hoorah!).  Python path problem...

Compiling the latest source on this older system has uncovered one small syntax problem, I believe.  Or I have some outdated compiler, std library headers, or something.

The issue is the abiguity of '!' operator overloaded in oct-inttypes.h.  An example string of errors is below.  There are only a few spots where these errors are occuring.  (Note that the errors are happening when building liboctave, not the src.)  I fixed one instance with a kludge old-style case:


diff -Pur octave/liboctave/intNDArray.cc octave-mod/liboctave/intNDArray.cc
--- octave/liboctave/intNDArray.cc 2009-01-18 13:45:08.000000000 -0600
+++ octave-mod/liboctave/intNDArray.cc 2009-01-18 13:53:19.000000000 -0600
@@ -53,7 +53,7 @@
     {
       T val = this->elem (i);
 
-      if (((double)val) != 0.0 && ((double)val) != 1.0)
+      if (val != 0.0 && val != 1.0)
  return true;
     }
 

Things then compiled along until hitting another instance:

oct-inttypes.h: In function `bool operator!=(const double&, const octave_int<T>&) [with T = int64_t]':
mx-s-i64nda.cc:11:   instantiated from here
oct-inttypes.h:1059: error: call of overloaded `mop(const double&, int64_t)' is ambiguous
oct-inttypes.h:193: note: candidates are: static bool octave_int_cmp_op::mop(T, double) [with xop = octave_int_cmp_op::ne, T = double]
oct-inttypes.h:198: note:                 static bool octave_int_cmp_op::mop(double, T) [with xop = octave_int_cmp_op::ne, T = long long int]
oct-inttypes.h:211: note:                 static bool octave_int_cmp_op::mop(double, uint64_t) [with xop = octave_int_cmp_op::ne]
oct-inttypes.h:212: note:                 static bool octave_int_cmp_op::mop(double, int64_t) [with xop = octave_int_cmp_op::ne]
oct-inttypes.h:213: note:                 static bool octave_int_cmp_op::mop(int64_t, double) [with xop = octave_int_cmp_op::ne]
oct-inttypes.h:214: note:                 static bool octave_int_cmp_op::mop(uint64_t, double) [with xop = octave_int_cmp_op::ne]

which is much more difficult for me to kludge because it is embedded in some definition strings.

The compilation commands are pretty much the same and the one thing different doesn't seem to matter when I remove -fPIC:

OLDER VERSION THAT COMPILES
g++ -c -I/usr/include/pcre -I. -I.. -I../liboctave -I../src -I../libcruft/misc -DHAVE_CONFIG_H -mieee-fp -Wall -W -Wshadow -Wold-style-cast -g -O2 mx-s-i64nda.cc -o mx-s-i64nda.o

NEWER VERSION THAT DOESN'T COMPILE
g++ -c -I/usr/include/pcre -fPIC -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H -mieee-fp -Wall -W -Wshadow -Wold-style-cast -g -O2 mx-s-i64nda.cc -o pic/mx-s-i64nda.o

Anyone with general variable type T experience have a guess as to where to look?  Command line switch?  Newer compiler?  The above files have been unaltered for years, yet last year I was compiling the CVS version with no problems.

Thanks,

Dan

[Jaroslav Hajek-2]

On Sun, Jan 18, 2009 at 9:56 PM, Daniel J Sebald <daniel.sebald@...> wrote:

> I've gotten Mercurial working on my FC3 machine (hoorah!).  Python path
> problem...
>
> Compiling the latest source on this older system has uncovered one small
> syntax problem, I believe.  Or I have some outdated compiler, std library
> headers, or something.
>
> The issue is the abiguity of '!' operator overloaded in oct-inttypes.h.  An
> example string of errors is below.  There are only a few spots where these
> errors are occuring.  (Note that the errors are happening when building
> liboctave, not the src.)  I fixed one instance with a kludge old-style case:
>
>
> diff -Pur octave/liboctave/intNDArray.cc octave-mod/liboctave/intNDArray.cc
> --- octave/liboctave/intNDArray.cc      2009-01-18 13:45:08.000000000 -0600
> +++ octave-mod/liboctave/intNDArray.cc  2009-01-18 13:53:19.000000000 -0600
> @@ -53,7 +53,7 @@
>    {
>      T val = this->elem (i);
>
> -      if (((double)val) != 0.0 && ((double)val) != 1.0)
> +      if (val != 0.0 && val != 1.0)
>        return true;
>    }
>
>
> Things then compiled along until hitting another instance:
>
> oct-inttypes.h: In function `bool operator!=(const double&, const
> octave_int<T>&) [with T = int64_t]':
> mx-s-i64nda.cc:11:   instantiated from here
> oct-inttypes.h:1059: error: call of overloaded `mop(const double&, int64_t)'
> is ambiguous
> oct-inttypes.h:193: note: candidates are: static bool
> octave_int_cmp_op::mop(T, double) [with xop = octave_int_cmp_op::ne, T =
> double]
> oct-inttypes.h:198: note:                 static bool
> octave_int_cmp_op::mop(double, T) [with xop = octave_int_cmp_op::ne, T =
> long long int]
> oct-inttypes.h:211: note:                 static bool
> octave_int_cmp_op::mop(double, uint64_t) [with xop = octave_int_cmp_op::ne]
> oct-inttypes.h:212: note:                 static bool
> octave_int_cmp_op::mop(double, int64_t) [with xop = octave_int_cmp_op::ne]
> oct-inttypes.h:213: note:                 static bool
> octave_int_cmp_op::mop(int64_t, double) [with xop = octave_int_cmp_op::ne]
> oct-inttypes.h:214: note:                 static bool
> octave_int_cmp_op::mop(uint64_t, double) [with xop = octave_int_cmp_op::ne]
>
> which is much more difficult for me to kludge because it is embedded in some
> definition strings.
>

I guess you have gcc 3 series, right? (Judging by the FC3). The answer
is yes, it is a compiler defect.
The mop overloads inside octave_int_cmp_op are unambiguous and
standard conforming.
For more info, see this previous discussion:
http://www.nabble.com/error-when-compiling-Octave-in-Cygwin-td20966037.html#a20966037
and this one on comp.lang.c++:
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/398e6ba0047f902a/c258528a9b0258b9?lnk=gst&q=ambiguous+overload

Your best solution is to upgrade to gcc 4 (and I suggest upgrading the
FC3 anyway). I'm fairly reluctant to alter the conforming code to
please an obsolete compiler due to a particular defect (and so far
nobody even asked for it).
Even if that is an old machine, there should be up-to-dat GNU/Linux
distros fit for it.
But even if you don't want to upgrade the distro, you can build g++ 4
for yourself.
cheers



--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz

[Daniel J Sebald]

Jaroslav Hajek wrote:
> I guess you have gcc 3 series, right? (Judging by the FC3). The answer
> is yes, it is a compiler defect.

Oy.


> I'm fairly reluctant to alter the conforming code to
> please an obsolete compiler due to a particular defect (and so far
> nobody even asked for it).

No, don't do that.


> Even if that is an old machine, there should be up-to-dat GNU/Linux
> distros fit for it.

That's no problem.  It's more figuring out an LVM work-around.  Probably time to do that.

Thanks,

Dan

[John W. Eaton-3]

On 18-Jan-2009, Daniel J Sebald wrote:

| I've gotten Mercurial working on my FC3 machine (hoorah!).  Python path problem...
|
| Compiling the latest source on this older system has uncovered one small syntax problem, I believe.  Or I have some outdated compiler, std library headers, or something.
|
| The issue is the abiguity of '!' operator overloaded in oct-inttypes.h.  An example string of errors is below.  There are only a few spots where these errors are occuring.  (Note that the errors are happening when building liboctave, not the src.)  I fixed one instance with a kludge old-style case:
|
|
| diff -Pur octave/liboctave/intNDArray.cc octave-mod/liboctave/intNDArray.cc
| --- octave/liboctave/intNDArray.cc 2009-01-18 13:45:08.000000000 -0600
| +++ octave-mod/liboctave/intNDArray.cc 2009-01-18 13:53:19.000000000 -0600
| @@ -53,7 +53,7 @@
|      {
|        T val = this->elem (i);
|  
| -      if (((double)val) != 0.0 && ((double)val) != 1.0)
| +      if (val != 0.0 && val != 1.0)
|   return true;
|      }

Your diff seems to be reversed.

Would it work to use

  if (val != 0 && val != 1)

instead?

jwe

 

[Daniel J Sebald]

John W. Eaton wrote:

> | diff -Pur octave/liboctave/intNDArray.cc octave-mod/liboctave/intNDArray.cc
> | --- octave/liboctave/intNDArray.cc 2009-01-18 13:45:08.000000000 -0600
> | +++ octave-mod/liboctave/intNDArray.cc 2009-01-18 13:53:19.000000000 -0600
> | @@ -53,7 +53,7 @@
> |      {
> |        T val = this->elem (i);
> |  
> | -      if (((double)val) != 0.0 && ((double)val) != 1.0)
> | +      if (val != 0.0 && val != 1.0)
> |   return true;
> |      }
>
> Your diff seems to be reversed.

Yes, it should be the other way.


> Would it work to use
>
>   if (val != 0 && val != 1)
>
> instead?

That doesn't fix the problem.  It's the compiler.  It does seem like 0/1 is more general than 0.0 and 1.0, however.  1.0 suggests float.  Apparently it doesn't matter.

Dan