bugGNU Octave - Bugs: bug #29794, --enable-64 keeps...

 
 

bug #29794: --enable-64 keeps OCTAVE_IDX_TYPE=int

Submitter:  Alois Schlögl <schloegl>
Submitted:  Wed 05 May 2010 04:29:43 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Works For Me Assigned to:  None
Originator Name:  Alois Schlögl Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 07 Jul 2010 07:08:15 PM UTC, comment #5: 


Can not reproduced the problem myself. Therefore this thread could be closed. 


Alois Schlögl <schloegl>
Tue 11 May 2010 05:40:25 PM UTC, comment #4: 

I can't confirm this bug.  I also happen to be running Ubuntu 9.10 on an x86_64 machine.  I have the exact same gcc and autoconf versions as Alois. 

When I run with --enable-64 OCTAVE_IDX_TYPE is correctly set to long in config.h.  This change is also propagated down to mxarray.h.  Dropping the --enable-64 correctly switches the index type back to int.  I would try verifying that config.h contains the correct value since it is not a derived file like mxarray.h.  If this is successful you might try deleting mxarray.h which will force it to be regenerated using the new config.h
 
This still leaves the question of whether or not to use OCTAVE_IDX_TYPE rather than size_t in 64-bit builds.

Rik <rik5>
Group administrator
Fri 07 May 2010 09:18:20 AM UTC, comment #3: 

I read the thread on the issues of QR when --enable-64, but do not know how this is related.

I'm working on an 64bit ubuntu 9.10 system, and use
   autoconf (GNU Autoconf) 2.64
   gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)

Here are the full details:
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9)

schloegl@bcipc038:~/src/octave$ autoconf --version
autoconf (GNU Autoconf) 2.64
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later
<http://gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.



Running
   ./autogen.sh
   ./configure
   make
or
   ./autogen.sh
   ./configure --enable-64
   make

with the original configure.ac file will always result in
   typedef int mwSize
   typedef int mwIndex
(in src/mxarray.h line 88-98)

Can you explain, why this happens ?

When I modify configure.ac file with the suggested patch and run
   ./autogen.sh
   ./configure --enable-64
   make
results in   
   typedef long mwSize
   typedef long mwIndex
(in src/mxarray.h line 88-98) and properly working mex-files.


Alois Schlögl <schloegl>
Thu 06 May 2010 08:24:10 PM UTC, comment #2: 

I don't see how configure would get a different result for the size of an integer since it uses the C compiler to perform the check.

If the source of the error is a configure problem, then what version of autoconf are you using?

Also, for full compatibility I think we should have the following definitions on 32-bit systems:

  mwSize         int
  mwIndex        int
  mwSignedIndex  ptrdiff_t

and the following definitions on 64-bit systems:

  mwSize         size_t
  mwIndex        size_t
  mwSignedIndex  ptrdiff_t

(these values are from the Matlab docs on the web).

But since these definitions have to work with our definition for octave_idx_type, I think we should revive the following discussion on the maintainers list before deciding exactly how to fix it:

  https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2010-February/015234.html

John W. Eaton <jwe>
Group administrator
Thu 06 May 2010 10:29:36 AM UTC, comment #1: 

I should add that sizeof(mwSize) and sizeof(mwIndex) were 4 (not 8 as expected.

It seems that
 test $ac_cv_sizeof_int -eq 8;
is true, causing
 OCTAVE_IDX_TYPE=int

But later (e.g. when compiling mex-files), the definition on mxarray.h
  typedef int mwSize
  typedef int mwIndex
use a 4-byte integer. 

It seems there is discrepancy between
  autoconf's AC_CHECK_SIZEOF(int) and
  gcc's sizeof(int)



Alois

Alois Schlögl <schloegl>
Wed 05 May 2010 04:29:43 PM UTC, original submission:  

I tried to use a mex-file on 64-bit Octave and got memory allocation problem. The problem was casued by the fact
that mwSize and mwIndex were defined as int in src/mxarray.h, although configure has been ran with --enable-64
 
The following patch defines mwSize and mwIndex as long, and solves this problem.  

diff -r 580c8d3baf11 configure.ac
--- a/configure.ac Wed May 05 16:08:43 2010 +0200
+++ b/configure.ac Wed May 05 18:18:33 2010 +0200
@@ -194,9 +194,7 @@
   AC_CHECK_SIZEOF(int)
   AC_CHECK_SIZEOF(long)
   if test $ac_cv_sizeof_void_p -eq 8; then
-    if test $ac_cv_sizeof_int -eq 8; then
-      OCTAVE_IDX_TYPE=int
-    elif test $ac_cv_sizeof_long -eq 8; then
+    if test $ac_cv_sizeof_long -eq 8; then
       OCTAVE_IDX_TYPE=long
       AC_DEFINE(IDX_TYPE_LONG, 1, [Define to 1 if octave index type is long])
     else

Alois

Alois Schlögl <schloegl>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

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 schloegl (Submitted the item)
  •  

    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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-07 rik5 StatusNone Works For Me
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code