[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot
From: |
Tatsuro MATSUOKA |
Subject: |
Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot be overloaded octave_int (char c)" |
Date: |
Mon, 22 Jun 2015 17:55:40 +0900 (JST) |
----- Original Message -----
> From: Daniel J Sebald
> To: Michele31415
> Cc: octave-maintainers
> Date: 2015/6/22, Mon 17:27
> Subject: Re: Compile error at compiling liboctave/array/Array-b.cc due to
> "cannot be overloaded octave_int (char c)"
>
> On 06/21/2015 11:59 PM, Michele31415 wrote:
>> This question was originally posted under a different title. It has been
>> suggested that I post again under a new title that is (presumably) more
>> descriptive. In any case, I still don't have the solution. It seems
> like
>> I'm getting close to getting a Sparc version of Octave running as I
> finally
>> managed to get ./configure to complete. Now if I could only get it to
> make.
>>
>> ---------------------------------------------------------
>>
>> On a Sparc Solaris box building Octave 3.8.2 (update - v. 4.0.0 throws the
>> same error), gmake fails with:
>>
>> In file included from array/idx-vector.h:35:0,
>> from array/Array.h:36,
>> from array/Array-b.cc:29:
>> ./util/oct-inttypes.h: In instantiation of 'class
> octave_int<char>':
>> ./util/oct-inttypes.h:1041:31: required from here
>> ./util/oct-inttypes.h:834:3: error:
> 'octave_int<T>::octave_int(char) [with T
>> = char]' cannot be overloaded
>> octave_int (char c)
>> ^
>> ./util/oct-inttypes.h:831:3: error: with
> 'octave_int<T>::octave_int(T) [with
>> T = char]'
>> octave_int (T i) : ival (i) { }
>> ^
>> In file included from array/idx-vector.h:37:0,
>> from array/Array.h:36,
>> from array/Array-b.cc:29:
>> ./util/oct-mem.h: In function 'T* no_ctor_new(std::size_t) [with T =
>> std::complex<double>; std::size_t = unsigned int]':
>> ./util/oct-mem.h:143:74: warning: cast from 'char*' to
> 'Complex* {aka
>> std::complex<double>*}' increases required alignment of target
> type
>> [-Wcast-align]
>> { return reinterpret_cast<T *> (new char [safe_size_comp (n,
> sizeof (T))]);
>> } \
>> ^
>> ./util/oct-mem.h:148:1: note: in expansion of macro
> 'DEFINE_POD_NEW_DELETE'
>> DEFINE_POD_NEW_DELETE (Complex)
>> ^
>> ./util/oct-mem.h: In function 'T* no_ctor_new(std::size_t) [with T =
>> std::complex<float>; std::size_t = unsigned int]':
>> ./util/oct-mem.h:143:74: warning: cast from 'char*' to
> 'FloatComplex* {aka
>> std::complex<float>*}' increases required alignment of target
> type
>> [-Wcast-align]
>> { return reinterpret_cast<T *> (new char [safe_size_comp (n,
> sizeof (T))]);
>> } \
>> ^
>> ./util/oct-mem.h:149:1: note: in expansion of macro
> 'DEFINE_POD_NEW_DELETE'
>> DEFINE_POD_NEW_DELETE (FloatComplex)
>> ^
>> ./util/oct-mem.h: In function 'T* no_ctor_new(std::size_t) [with T =
>> octave_int<short int>; std::size_t = unsigned int]':
>> ./util/oct-mem.h:143:74: warning: cast from 'char*' to
> 'octave_int16* {aka
>> octave_int<short int>*}' increases required alignment of target
> type
>> [-Wcast-align]
>> { return reinterpret_cast<T *> (new char [safe_size_comp (n,
> sizeof (T))]);
>> } \
>> ^
>> ./util/oct-mem.h:152:1: note: in expansion of macro
> 'DEFINE_POD_NEW_DELETE'
>> DEFINE_POD_NEW_DELETE (octave_int16)
>> ^
>> ./util/oct-mem.h: In function 'T* no_ctor_new(std::size_t) [with T =
>> octave_int<int>; std::size_t = unsigned int]':
>> ./util/oct-mem.h:143:74: warning: cast from 'char*' to
> 'octave_int32* {aka
>> octave_int<int>*}' increases required alignment of target type
>> [-Wcast-align]
>> { return reinterpret_cast<T *> (new char [safe_size_comp (n,
> sizeof (T))]);
>> } \
>> ^
>> ./util/oct-mem.h:153:1: note: in expansion of macro
> 'DEFINE_POD_NEW_DELETE'
>> DEFINE_POD_NEW_DELETE (octave_int32)
>> ^
>> ./util/oct-mem.h: In function 'T* no_ctor_new(std::size_t) [with T =
>> octave_int<long long int>; std::size_t = unsigned int]':
>> ./util/oct-mem.h:143:74: warning: cast from 'char*' to
> 'octave_int64* {aka
>> octave_int<long long int>*}' increases required alignment of
> target type
>> [-Wcast-align]
>> { return reinterpret_cast<T *> (new char [safe_size_comp (n,
> sizeof (T))]);
>> } \
>> ^
>> ./util/oct-mem.h:154:1: note: in expansion of macro
> 'DEFINE_POD_NEW_DELETE'
>> DEFINE_POD_NEW_DELETE (octave_int64)
>> ^
>> ./util/oct-mem.h: In function 'T* no_ctor_new(std::size_t) [with T =
>> octave_int<short unsigned int>; std::size_t = unsigned int]':
>> ./util/oct-mem.h:143:74: warning: cast from 'char*' to
> 'octave_uint16* {aka
>> octave_int<short unsigned int>*}' increases required alignment of
> target
>> type [-Wcast-align]
>> { return reinterpret_cast<T *> (new char [safe_size_comp (n,
> sizeof (T))]);
>> } \
>> ^
>> ./util/oct-mem.h:156:1: note: in expansion of macro
> 'DEFINE_POD_NEW_DELETE'
>> DEFINE_POD_NEW_DELETE (octave_uint16)
>> ^
>> ./util/oct-mem.h: In function 'T* no_ctor_new(std::size_t) [with T =
>> octave_int<unsigned int>; std::size_t = unsigned int]':
>> ./util/oct-mem.h:143:74: warning: cast from 'char*' to
> 'octave_uint32* {aka
>> octave_int<unsigned int>*}' increases required alignment of
> target type
>> [-Wcast-align]
>> { return reinterpret_cast<T *> (new char [safe_size_comp (n,
> sizeof (T))]);
>> } \
>> ^
>> ./util/oct-mem.h:157:1: note: in expansion of macro
> 'DEFINE_POD_NEW_DELETE'
>> DEFINE_POD_NEW_DELETE (octave_uint32)
>> ^
>> ./util/oct-mem.h: In function 'T* no_ctor_new(std::size_t) [with T =
>> octave_int<long long unsigned int>; std::size_t = unsigned int]':
>> ./util/oct-mem.h:143:74: warning: cast from 'char*' to
> 'octave_uint64* {aka
>> octave_int<long long unsigned int>*}' increases required
> alignment of target
>> type [-Wcast-align]
>> { return reinterpret_cast<T *> (new char [safe_size_comp (n,
> sizeof (T))]);
>> } \
>> ^
>> ./util/oct-mem.h:158:1: note: in expansion of macro
> 'DEFINE_POD_NEW_DELETE'
>> DEFINE_POD_NEW_DELETE (octave_uint64)
>> ^
>> In file included from array/Array.cc:42:0,
>> from array/Array-b.cc:30:
>> ./util/oct-locbuf.h: In member function 'octave_local_buffer<short
> unsigned
>> int>::operator short unsigned int*() const':
>> ./util/oct-locbuf.h:120:51: warning: cast from 'char*' to
> 'short unsigned
>> int*' increases required alignment of target type [-Wcast-align]
>> return reinterpret_cast<TYPE *> (this->data ()); \
>> ^
>> ./util/oct-locbuf.h:126:1: note: in expansion of macro
>> 'SPECIALIZE_POD_BUFFER'
>> SPECIALIZE_POD_BUFFER (unsigned short);
>> ^
>> ./util/oct-locbuf.h: In member function 'octave_local_buffer<short
>> int>::operator short int*() const':
>> ./util/oct-locbuf.h:120:51: warning: cast from 'char*' to
> 'short int*'
>> increases required alignment of target type [-Wcast-align]
>> return reinterpret_cast<TYPE *> (this->data ()); \
>> ^
>> ./util/oct-locbuf.h:127:1: note: in expansion of macro
>> 'SPECIALIZE_POD_BUFFER'
>> SPECIALIZE_POD_BUFFER (short);
>> ^
>> ./util/oct-locbuf.h: In member function
> 'octave_local_buffer<int>::operator
>> int*() const':
>> ./util/oct-locbuf.h:120:51: warning: cast from 'char*' to
> 'int*' increases
>> required alignment of target type [-Wcast-align]
>> return reinterpret_cast<TYPE *> (this->data ()); \
>> ^
>> ./util/oct-locbuf.h:128:1: note: in expansion of macro
>> 'SPECIALIZE_POD_BUFFER'
>> SPECIALIZE_POD_BUFFER (int);
>> ^
>> ./util/oct-locbuf.h: In member function
> 'octave_local_buffer<unsigned
>> int>::operator unsigned int*() const':
>> ./util/oct-locbuf.h:120:51: warning: cast from 'char*' to
> 'unsigned int*'
>> increases required alignment of target type [-Wcast-align]
>> return reinterpret_cast<TYPE *> (this->data ()); \
>> ^
>> ./util/oct-locbuf.h:129:1: note: in expansion of macro
>> 'SPECIALIZE_POD_BUFFER'
>> SPECIALIZE_POD_BUFFER (unsigned int);
>> ^
>> ./util/oct-locbuf.h: In member function 'octave_local_buffer<long
>> int>::operator long int*() const':
>> ./util/oct-locbuf.h:120:51: warning: cast from 'char*' to 'long
> int*'
>> increases required alignment of target type [-Wcast-align]
>> return reinterpret_cast<TYPE *> (this->data ()); \
>> ^
>> ./util/oct-locbuf.h:130:1: note: in expansion of macro
>> 'SPECIALIZE_POD_BUFFER'
>> SPECIALIZE_POD_BUFFER (long);
>> ^
>> ./util/oct-locbuf.h: In member function 'octave_local_buffer<long
> unsigned
>> int>::operator long unsigned int*() const':
>> ./util/oct-locbuf.h:120:51: warning: cast from 'char*' to 'long
> unsigned
>> int*' increases required alignment of target type [-Wcast-align]
>> return reinterpret_cast<TYPE *> (this->data ()); \
>> ^
>> ./util/oct-locbuf.h:131:1: note: in expansion of macro
>> 'SPECIALIZE_POD_BUFFER'
>> SPECIALIZE_POD_BUFFER (unsigned long);
>> ^
>> ./util/oct-locbuf.h: In member function
>> 'octave_local_buffer<float>::operator float*() const':
>> ./util/oct-locbuf.h:120:51: warning: cast from 'char*' to
> 'float*' increases
>> required alignment of target type [-Wcast-align]
>> return reinterpret_cast<TYPE *> (this->data ()); \
>> ^
>> ./util/oct-locbuf.h:132:1: note: in expansion of macro
>> 'SPECIALIZE_POD_BUFFER'
>> SPECIALIZE_POD_BUFFER (float);
>> ^
>> ./util/oct-locbuf.h: In member function
>> 'octave_local_buffer<double>::operator double*() const':
>> ./util/oct-locbuf.h:120:51: warning: cast from 'char*' to
> 'double*'
>> increases required alignment of target type [-Wcast-align]
>> return reinterpret_cast<TYPE *> (this->data ()); \
>> ^
>> ./util/oct-locbuf.h:133:1: note: in expansion of macro
>> 'SPECIALIZE_POD_BUFFER'
>> SPECIALIZE_POD_BUFFER (double);
>> ^
>> ./util/oct-locbuf.h: In member function
>> 'octave_local_buffer<std::complex<double> >::operator
> Complex*() const':
>> ./util/oct-locbuf.h:120:51: warning: cast from 'char*' to
> 'Complex* {aka
>> std::complex<double>*}' increases required alignment of target
> type
>> [-Wcast-align]
>> return reinterpret_cast<TYPE *> (this->data ()); \
>> ^
>> ./util/oct-locbuf.h:135:1: note: in expansion of macro
>> 'SPECIALIZE_POD_BUFFER'
>> SPECIALIZE_POD_BUFFER (Complex);
>> ^
>> ./util/oct-locbuf.h: In member function
>> 'octave_local_buffer<std::complex<float> >::operator
> FloatComplex*()
>> const':
>> ./util/oct-locbuf.h:120:51: warning: cast from 'char*' to
> 'FloatComplex*
>> {aka std::complex<float>*}' increases required alignment of
> target type
>> [-Wcast-align]
>> return reinterpret_cast<TYPE *> (this->data ()); \
>> ^
>> ./util/oct-locbuf.h:136:1: note: in expansion of macro
>> 'SPECIALIZE_POD_BUFFER'
>> SPECIALIZE_POD_BUFFER (FloatComplex);
>> ^
>> Makefile:5264: recipe for target
> 'array/array_libarray_la-Array-b.lo' failed
>> gmake[4]: *** [array/array_libarray_la-Array-b.lo] Error 1
>>
>>
>> I looked around for something like this but was unable to find anything
>> similar. I don't even understand what it's complaining about
> here. Any
>> help would be greatly appreciated. Thanks.
>
> POD means "plain old data" which is a term for fundamental data types
> common to C, but not including C++ constructs (e.g., virtual functions).
> I'm guessing that Sparc architecture might be more restrictive in alignment
> rules compare to x86.
>
> To "increase required alignment" means that the compiler would have to
> go from 2 byte alignment (address divisible by 2) to 4 byte alignment
> (address
> divisible by 4).
>
> The answer to the question here has a good explanation of why Intel x86
> doesn't complain about alignment:
>
> http://stackoverflow.com/questions/25762173/why-does-wcast-align-not-warn-about-cast-from-char-to-int-on-x86
>
> Basically, from what that answer suggests when x86 architecture is configured
> in
> the usual way, all data types can be 1-byte aligned. So, if a char * points
> to,
> say, memory address 3, so can the cast int *, float *, so on. On Sparc
> architecture that probably isn't the case.
>
> I don't know why the compilation fails. One would think that the
> compilation would continue, but the executable would not run properly,
> throwing
> exception. Unless perhaps there is an issue when the linker tries to piece
> together object code.
>
> I think the solution will entail making all data arrays 4 or 8 byte aligned.
> Or
> maybe even possibly 16-byte aligned if Complex comes into play. The
> "aligned" attribute of the compiler might be a way of doing that.
>
> http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Type-Attributes.html
>
> I'm attaching a diff file that adds __attribute__ ((aligned (8))) after the
> octave_chunk_buffer allocation. This compiles and doesn't seem to change
> behavior on my x86 system. Maybe it will help on Sparc, either to get rid of
> the warnings or reduce the number of them. If so, perhaps one of the
> developers
> can put a preprocessor condition around that statement--one default for
> typically x86, and another case for SPARC.
>
> If the patch file didn't help, maybe someone else will have an idea.
>
> Dan
Daniel
The explanation for POD is very comprehensive.
POD parts gave warnings but not errors.
But errors occurred at
In file included from array/idx-vector.h:35:0,
from array/Array.h:36,
from array/Array-b.cc:29:
./util/oct-inttypes.h: In instantiation of 'class octave_int<char>':
./util/oct-inttypes.h:1041:31: required from here
./util/oct-inttypes.h:834:3: error: 'octave_int<T>::octave_int(char) [with T =
char]' cannot be overloaded
octave_int (char c)
^
./util/oct-inttypes.h:831:3: error: with 'octave_int<T>::octave_int(T) [with T
= char]'
octave_int (T i) : ival (i) { }
^
array/Array-b.cc:29
#include "Array.h"
array/Array.h:36
#include "idx-vector.h"
array/idx-vector.h:35
#include "oct-inttypes.h"
./util/oct-inttypes.h: In instantiation of 'class octave_int<char>':
./util/oct-inttypes.h:1041:31: required from here
./util/oct-inttypes.h:834:3: error: 'octave_int<T>::octave_int(char) [with T =
char]' cannot be overloaded octave_int (char c)
^
./util/oct-inttypes.h:1041
1037: template <>
1038: inline std::ostream&
1039: operator << (std::ostream& os, const octave_int<int8_t>& ival)
1040: {
1041: os << static_cast<int> (ival.value ());
1042: return os;
1043: }
./util/oct-inttypes.h:834
833: // Always treat characters as unsigned.
834: octave_int (char c)
835: : ival (octave_int_base<T>::truncate_int (static_cast<unsigned char>
(c)))
836: { }
./util/oct-inttypes.h:831:3: error: with 'octave_int<T>::octave_int(T) [with T
= char]'
octave_int (T i) : ival (i) { }
^
./util/oct-inttypes.h:831
831: octave_int (T i) : ival (i) { }
The file of oct-inttypes.h of octave 3.8.2 is attached.
Tatsuro
oct-inttypes.h
Description: Text document
- Compile error at compiling liboctave/array/Array-b.cc due to "cannot be overloaded octave_int (char c)", Michele31415, 2015/06/22
- Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot be overloaded octave_int (char c)", Daniel J Sebald, 2015/06/22
- Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot be overloaded octave_int (char c)",
Tatsuro MATSUOKA <=
- Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot be overloaded octave_int (char c)", tmacchant, 2015/06/22
- Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot be overloaded octave_int (char c)", Daniel J Sebald, 2015/06/22
- Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot be overloaded octave_int (char c)", Tatsuro MATSUOKA, 2015/06/24
- Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot be overloaded octave_int (char c)", Mike Miller, 2015/06/25
- Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot be overloaded octave_int (char c)", tmacchant, 2015/06/25
- Re: Compile error at compiling liboctave/array/Array-b.cc due to "cannot be overloaded octave_int (char c)", Tatsuro MATSUOKA, 2015/06/26