bugGNU Octave - Bugs: bug #41145, Building with 64 bit indexing...

 
 

bug #41145: Building with 64 bit indexing fails on ArchLinux and Ubuntu

Submitted by:  Lasse Schuirmann <sils1297>
Submitted on:  Wed 08 Jan 2014 09:42:15 AM UTC  
 
Category: Configuration and Build SystemSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Build Failure
Status: FixedAssigned to: None
Originator Name: Lasse SchuirmannOpen/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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.

Rik <rik5>
Project Administrator
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.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
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).

John W. Eaton <jwe>
Project Administrator
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.

Lasse Schuirmann <sils1297>
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?

John W. Eaton <jwe>
Project Administrator
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)

Lasse Schuirmann <sils1297>
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

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
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?

Lasse Schuirmann <sils1297>
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?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
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.

Lasse Schuirmann <sils1297>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #30221:  ambiguity.patch added by sils1297 (1KiB - text/x-patch)
file #30220:  abiguity_64bit.patch added by sils1297 (992B - text/x-patch - Solves two ambiguities.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by sils1297 (Submitted the item)
  • -unavailable- added by sils1297
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 14 Jan 2014 09:12:59 PM UTCrik5StatusPatch Submitted=>Fixed
      Open/ClosedOpen=>Closed
    Wed 08 Jan 2014 01:47:25 PM UTCsils1297Attached File-=>Added ambiguity.patch, #30221
    Wed 08 Jan 2014 12:59:01 PM UTCjordighStatusNone=>Patch Submitted
    Wed 08 Jan 2014 09:42:15 AM UTCsils1297Attached File-=>Added abiguity_64bit.patch, #30220
      Carbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup1