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

 
 

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

Submitter:  Lasse Schuirmann <sils1297>
Submitted:  Wed 08 Jan 2014 09:42:15 AM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  None
Originator Name:  Lasse Schuirmann Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group Member
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>
Group 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?


/**
 * Makes sure that no ambiguities occur when using constants.
 *
 * @param type The type to ensure.
 * @param value The value.
 */
#define  SECURE_CONST(type, value)  static_cast<type>(value)

/**
 * Simplification for SECURE_CONST.
 */
#define  SECURE_IDX_CONST(value)  SECURE_CONST(octave_idx_type, (value))


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


else
  {
    // Matlab returns [] 0x1 for out-of-range diagonal

    octave_idx_type nr = 0;
    octave_idx_type nc = 1;
    octave_idx_type nz = 0;

    d = Sparse<T> (nr, nc, nz);
  }


to avoid any chance of confusion later about the intent?

John W. Eaton <jwe>
Group 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>
Group Member
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>
Group Member
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 Files:
   
   
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
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by sils1297 (Submitted the item)
  • -email is unavailable- added by sils1297
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-14 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2014-01-08 sils1297 Attached File- Added ambiguity.patch, #30221
    2014-01-08 jordigh StatusNone Patch Submitted
    2014-01-08 sils1297 Attached File- Added abiguity_64bit.patch, #30220
        Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code