Tue 14 Jan 2014 09:12:59 PM UTC, comment #9:
I applied Lasse's ambiguity reduction for JIT on the stable branch (http://hg.savannah.gnu.org/hgweb/octave/rev/cc1c19863ae3). I applied jwe's suggested ambiguity reduction for Sparse::diag to the default branch since that is where the problem code lies (http://hg.savannah.gnu.org/hgweb/octave/rev/00539b673cd4). Closing report.
|
Wed 08 Jan 2014 03:22:43 PM UTC, comment #8:
I agree with jwe. Now that I understand why it was working with octave_idx_type = int but not with octave_idx_type = long, I find jwe's solution clearer, and I don't think we need more macros.
|
Wed 08 Jan 2014 03:14:52 PM UTC, comment #7:
I don't see that SECURE_CONST or SECURE_IDX_CONST offers any advantage over just using static_cast<T> directly.
My point of suggesting the other change was to make it clear that the intended constructor is the one that accepts (nr, nc, nz), not (nr, nc, val).
|
Wed 08 Jan 2014 03:04:38 PM UTC, comment #6:
Thinking about a more general and more meaningful method: what about a macro for securing constant values?
When using SECURE_IDX_CONST(0) I think it is pretty obvious that this is a type ensurance.
|
Wed 08 Jan 2014 02:32:14 PM UTC, comment #5:
How about writing that as
to avoid any chance of confusion later about the intent?
|
Wed 08 Jan 2014 01:47:25 PM UTC, comment #4:
Full message:
../../liboctave/array/Sparse.cc: In instantiation of 'Sparse<T> Sparse<T>::diag(octave_idx_type) const [with T = bool; octave_idx_type = long int]':
../../liboctave/array/Sparse-b.cc:33:1: required from here
../../liboctave/array/Sparse.cc:2494:11: error: call of overloaded 'Sparse(int, int, int)' is ambiguous
d = Sparse<T> (0, 1, 0);
^
../../liboctave/array/Sparse.cc:2494:11: note: candidates are:
In file included from ../../liboctave/array/Sparse-b.cc:30:0:
../../liboctave/array/Sparse.h:199:3: note: Sparse<T>::Sparse(octave_idx_type, octave_idx_type, octave_idx_type) [with T = bool; octave_idx_type = long int]
Sparse (octave_idx_type nr, octave_idx_type nc, octave_idx_type nz)
^
In file included from ../../liboctave/array/Sparse-b.cc:31:0:
../../liboctave/array/Sparse.cc:204:1: note: Sparse<T>::Sparse(octave_idx_type, octave_idx_type, T) [with T = bool; octave_idx_type = long int]
Sparse<T>::Sparse (octave_idx_type nr, octave_idx_type nc, T val)
^
I appended the HG changeset patch.
Oh and:
gcc --version
gcc (GCC) 4.8.2 20131219 (prerelease)
(file #30221)
|
Wed 08 Jan 2014 01:23:12 PM UTC, comment #3:
What's the other candidate? I think you truncated the error message.
Typically we require hg changesets. They're just patches with additional metadata:
http://jordi.inversethought.com/blog/how-to-write-a-patch-for-octave/
http://www.gnu.org/software/octave/doc/interpreter/Basics-of-Generating-a-Changeset.html#Basics-of-Generating-a-Changeset
This also requires a commit message:
http://wiki.octave.org/Commit_message_guidelines#Examples
|
Wed 08 Jan 2014 01:07:57 PM UTC, comment #2:
It is bool and long int.
../../liboctave/array/Sparse.cc: In instantiation of 'Sparse<T> Sparse<T>::diag(octave_idx_type) const [with T = bool; octave_idx_type = long int]':
../../liboctave/array/Sparse-b.cc:33:1: required from here
../../liboctave/array/Sparse.cc:2494:11: error: call of overloaded 'Sparse(int, int, int)' is ambiguous
d = Sparse<T> (0, 1, 0);
^
../../liboctave/array/Sparse.cc:2494:11: note: candidates are:
In file included from ../../liboctave/array/Sparse-b.cc:30:0:
../../liboctave/array/Sparse.h:199:3: note: Sparse<T>::Sparse(octave_idx_type, octave_idx_type, octave_idx_type) [with T = bool; octave_idx_type = long int]
I would like to be credited as Lasse Schuirmann <lasse@schuirmann.net>; does the patch have to have another format for that?
|
Wed 08 Jan 2014 12:59:01 PM UTC, comment #1:
Thanks for the patch. The first hunk looks good, but I'm surprised about the second hunk. Can you show me the compiler errors you get when calling Sparse(0, 1, 0) without the cast? I suppose the ambiguity is between Sparse(octave_idx_type, octave_idx_type, T) and Sparse(octave_idx_type, octave_idx_type, octave_idx_type), but T is only ever supposed to be non-integral type (float or double), and the T version is declared explicit. Thus, I don't see the ambiguity here. There could be another bug lying deeper. What compiler are you using?
Would you like to be credited for this patch as Lasse Schuirmann <lasse@schuirmann.net> in the hg log?
|
Wed 08 Jan 2014 09:42:15 AM UTC, original submission:
When compiling with --enable-64 we got a problem with two magic numbers.
One is resulting in two different types of parameters when calling std::max in libinterp/corefcn/jit-typeinfo.cc.
The other one is a constructor ambiguity in liboctave/array/Sparse.cc.
This patch solves these issues and allows to compile with --enable-64 on my system.
|