RE: cross-building with --enable-64: Assembly error

[Philip Nienhuis]

John Donoghue-2 wrote
> -----Original Message-----
> From: John W. Eaton [mailto:

> jwe@

> ] 
> Sent: Saturday, August 16, 2014 8:40 AM
> To: John D; 

> octave-maintainers@

> ; 'Philip Nienhuis'
> Cc: 

> jwe@

> Subject: Re: cross-building with --enable-64: Assembly error
> 
> On 08/15/2014 10:45 PM, John D wrote:
> 
>>> Not that it helps any, but it compiles fine on my Fedora 20 box .
>>>
>>> According to the log, the -O2 optimization is used on mine.
>>>
>>> A quick look on the internet shows a few other people have had 
>>> similar issues when building gcrrypt.
>>
>> I see now that the libcgrypt build completes if I use CFLAGS="".
>>
>> So maybe it is a compiler bug?
>>
>> I see that GCC 4.9.1 has been released.  I suppose we should try it 
>> and see if the problem is fixed in that version.
>>
>> gcc 4.9.1 changes pushed to mxe-octave
> 
> OK, I updated and still see the same problem, so whatever the bug is, GCC
> 4.9.1 doesn't fix it.
> 
> I modified libgcrypt.mk (diff attached) to add -v and -save-temps to the
> compiler flags and I see
> 
>  
> /scratch/jwe/src/mxe-octave-64/usr/libexec/gcc/x86_64-w64-mingw32/4.9.1/cc1
> -fpreprocessed rndhw.i -quiet -dumpbase rndhw.c -mtune=generic
> -march=x86-64 -auxbase-strip .libs/rndhw.o -g -O2 -version -o rndhw.s
>    GNU C (GCC) version 4.9.1 (x86_64-w64-mingw32)
>            compiled by GNU C version 4.9.0, GMP version 6.0.0, MPFR
> version
> 3.1.2, MPC version 1.0.2
>    GGC heuristics: --param ggc-min-expand=100 --param
> ggc-min-heapsize=131072
>    GNU C (GCC) version 4.9.1 (x86_64-w64-mingw32)
>            compiled by GNU C version 4.9.0, GMP version 6.0.0, MPFR
> version
> 3.1.2, MPC version 1.0.2
>    GGC heuristics: --param ggc-min-expand=100 --param
> ggc-min-heapsize=131072
>    Compiler executable checksum: d45bd0cea5f24051d77f101f77aec004
>    COLLECT_GCC_OPTIONS='-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '..' '-I' 
> '../src' '-I' '../src' '-I' 
> '/scratch/jwe/src/mxe-octave-64/usr/x86_64-w64-mingw32/include' '-I' 
> '/scratch/jwe/src/mxe-octave-64/usr/x86_64-w64-mingw32/include' '-O2' 
> '-g' '-save-temps' '-v' '-MT' 'rndhw.lo' '-MD' '-MP' '-MF' 
> '.deps/rndhw.Tpo' '-c' '-D' 'DLL_EXPORT' '-D' 'PIC' '-o' '.libs/rndhw.o' 
> '-mtune=generic' '-march=x86-64'
>     /scratch/jwe/src/mxe-octave-64/usr/bin/x86_64-w64-mingw32-as -v -I . 
> -I .. -I ../src -I ../src -I
> /scratch/jwe/src/mxe-octave-64/usr/x86_64-w64-mingw32/include -I
> /scratch/jwe/src/mxe-octave-64/usr/x86_64-w64-mingw32/include -o
> .libs/rndhw.o rndhw.s
>    GNU assembler version 2.24 (x86_64-w64-mingw32) using BFD version (GNU
> Binutils) 2.24
>    rndhw.s: Assembler messages:
>    rndhw.s:53: Error: unsupported instruction `mov'
>    Makefile:401: recipe for target 'rndhw.lo' failed
>    make[4]: *** [rndhw.lo] Error 1
> 
> 
> So the copy of as that was built as part of the mxe-octave build process
> is
> being used.  But line 53 of the file rndhw.s is a movl instruction, not
> mov.
> So it seems odd to me that the assembler is complaining about mov instead
> of
> movl, but maybe I don't understand what that error message really means.
> 
> Ah, looking more closely, this line is inside an /APP ... /NO_APP block,
> so
> I guess the movl is being expanded incorrectly there?  In any case, I
> don't
> understand why we are seeing different results, especially if we are both
> using the -mtune=generic option.
> 
> Both of the generated rndhw.i and rndhw.s files are also attached.
> 
> Could you try adding -v and -save-temps to your libgcrypt.mk file and send
> me the resulting rndhw.i and rndhw.s files so I can compare them with
> mine?
> Also can you show the exact command line that is used to invoke the
> assembler on your system?
> 
> Thanks,
> 
> Jwe
> 
> 
> Try this match to mxe, based upon this patch.
> http://lists.freedesktop.org/archives/gstreamer-commits/2014-February/077094.html
> 
> fix-libgcrypt.patch (1K)
> <http://octave.1599824.n4.nabble.com/attachment/4666090/0/fix-libgcrypt.patch>

Thanks, with that patch libgcrypt (and stable-octave) could be cross-built w
64-bit indexing.
Trying it out it turns out to be a real 64-bit program - WinXP 32bit
complains octave*.exe "is not a valid win32 executable".

On my win7 64-bit box octave-3.8.2 runs fine, but....
running __run_test_suite__.m errors out in eig.cc:

=================================================

GNU Octave, version 3.8.2
Copyright (C) 2014 John W. Eaton and others.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-w64-mingw32".

Additional information about Octave is available at http://www.octave.org.

Please contribute if you find this software useful.
For more information, visit http://www.octave.org/get-involved.html

Read http://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

octave:1> more off
octave:2> __run_test_suite__

Integrated test scripts:

  liboctave\array\Array.cc-tst ........................... PASS   18/18
  liboctave\array\CMatrix.cc-tst ......................... PASS   11/11
  liboctave\array\CSparse.cc-tst ......................... PASS   10/10
  liboctave\array\Sparse.cc-tst .......................... PASS  103/103
  liboctave\array\dMatrix.cc-tst ......................... PASS   10/10
  liboctave\array\dSparse.cc-tst ......................... PASS   12/12
  liboctave\array\fCMatrix.cc-tst ........................ PASS   11/11
  liboctave\array\fMatrix.cc-tst ......................... PASS    8/8
  liboctave\array\idx-vector.cc-tst ...................... PASS    2/2
  liboctave\util\oct-inttypes.cc-tst ..................... PASS   28/28
  libinterp\corefcn\__contourc__.cc-tst .................. PASS    1/1
  libinterp\corefcn\__dispatch__.cc-tst .................. PASS    1/1
  libinterp\corefcn\__lin_interpn__.cc-tst ............... PASS    1/1
  libinterp\corefcn\__pchip_deriv__.cc-tst ............... PASS    1/1
  libinterp\corefcn\__qp__.cc-tst ........................ PASS    1/1
  libinterp\corefcn\besselj.cc-tst ....................... PASS  191/191
  libinterp\corefcn\betainc.cc-tst ....................... PASS   23/23
  libinterp\corefcn\bsxfun.cc-tst ........................ PASS   73/73
  libinterp\corefcn\cellfun.cc-tst ....................... PASS  129/129
  libinterp\corefcn\conv2.cc-tst ......................... PASS   51/51
  libinterp\corefcn\dassl.cc-tst ......................... PASS    4/4
  libinterp\corefcn\data.cc-tst .......................... PASS  874/874
  libinterp\corefcn\defaults.cc-tst ...................... PASS   10/10
  libinterp\corefcn\det.cc-tst ........................... PASS    5/5
  libinterp\corefcn\dirfns.cc-tst ........................ PASS    1/1
  libinterp\corefcn\dlmread.cc-tst ....................... PASS   20/20
  libinterp\corefcn\dot.cc-tst ........................... PASS   15/15
  libinterp\corefcn\eig.cc-tst ...........................subscript indices
must be either positive integers less than 2^63 or logicals
octave:3>

=================================================

Should I file a bug report for it?
I tried at random a few other fixed test scripts in
/share/octave/etc/tests/fixed, but they did run fine. So maybe it is just
eig.cc that has issues. Is there a way to skip specific tests in
__run_test_suite__.m?


Installing packages (using build_packages.m) goes fine until the image pkg:

=================================================

pkg ('install', 'image-2.2.1.tar.gz')
__spatial_filtering__.cc: In instantiation of 'ET_OUT entropy_filt(MT&,
octave_idx_type, int) [with ET = octave_int<signed char>; MT =
intNDArray<octave_int&lt;signed char> >; ET_OUT = double; octave_idx_type =
long long int]':
__spatial_filtering__.cc:593:9:   required from here
__spatial_filtering__.cc:191:25: error: conversion from 'octave_int<signed
char>' to 'octave_idx_type {aka long long int}' is ambiguous
     hist (vals (i) + add) ++;
                         ^
__spatial_filtering__.cc:191:25: note: candidates are:
In file included from
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/idx-vector.h:35:0,
                 from
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/Array.h:36,
                 from
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/boolMatrix.h:27,
                 from
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/mx-base.h:32,
                 from
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/Matrix.h:30,
                 from
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/oct.h:33,
                 from __spatial_filtering__.cc:21:
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/oct-inttypes.h:884:3:
note: octave_int<T>::operator float() const [with T = signed char]
   operator float (void) const { return float_value (); }
   ^
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/oct-inttypes.h:882:3:
note: octave_int<T>::operator double() const [with T = signed char]
   operator double (void) const { return double_value (); }
   ^
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/oct-inttypes.h:878:3:
note: octave_int<T>::operator T() const [with T = signed char]
   operator T (void) const { return value (); }
   ^
In file included from
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/boolMatrix.h:27:0,
                 from
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/mx-base.h:32,
                 from
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/Matrix.h:30,
                 from
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/oct.h:33,
                 from __spatial_filtering__.cc:21:
C:\Octave\octave-3.8.2\include\octave-3.8.2\octave\../octave/Array.h:389:6:
note: initializing argument 1 of 'T& Array<T>::operator()(octave_idx_type)
[with T = double; octave_idx_type = long long int]'
   T& operator () (octave_idx_type n) { return elem (n); }
      ^
__spatial_filtering__.cc:193:25: error: conversion from 'octave_int<signed
char>' to 'octave_idx_type {aka long long int}' is ambiguous
     hist (vals (i) + add) /= (double)len;
                         ^
=================================================

...but maybe that's due to issues in the image package itself? Has anyone
tried installing and running the image package on 64-bit Linux?


Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/Re-cross-building-with-enable-64-Assembly-error-tp4666071p4666092.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.