21 views

Skip to first unread message

Oct 26, 2011, 1:33:13 PM10/26/11

to linbox...@googlegroups.com

I'm getting errors on Ubuntu with g++ version 4.4.3 and g++ version

4.4.5 (2 different machines) that I did not get on a solaris machine

with g++ version 4.4.1.

4.4.5 (2 different machines) that I did not get on a solaris machine

with g++ version 4.4.1.

It seems that blas-matrix.inl defines a constructor having a signature

not declared in blas-matrix.h. It has to do with the types of the

dimensions (the last two arguments). BlasMatrix declares and/or

defines a smorgasbord of constructors using various signed and

unsigned integer types, not to mention a type template parameter for

some. Version 4.4.1 of g++ apparently ignores an extra definition,

where the more recent versions do not.

Do we really need such verbosity of declarations and definitions? I

would like to think that all relevant signed and unsigned types can

get implicitly cast to a size_t (with compile time warning). I

actually think it is good practice in programs to make explicit casts

to our indexing type, size_t, as the preferred way to avoid type

warnings or errors.

Size_t has been our indexing type since the very first design of

Turner and Kaltofen. I do feel that there could be a review of this

at some point. A case can be made for a signed type (ptrdiff_t, for

instance), because it is sometimes convenient to take differences that

could be negative or even have a negative index. Also a case can be

made for a type permitting larger values than the range of memory

addresses. Not all matrix representations are limited to an index

range that maps directly to memory addresses.

Bottom line: it seems there is a detail to fix in BlasMatrix and a

larger issue to discuss somewhere down the road.

Best,

-dave

make[3]: Entering directory `/home/saunders/sandbox/linbox/linbox/algorithms'

/bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H

-I. -I../.. -O2 -pipe -Wall -g -DNDEBUG -U_LB_DEBUG

-DDISABLE_COMMENTATOR -I/home/saunders/sandbox/include -c -o

diophantine-solver.lo diophantine-solver.C

libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -O2 -pipe -Wall -g

-DNDEBUG -U_LB_DEBUG -DDISABLE_COMMENTATOR

-I/home/saunders/sandbox/include -c diophantine-solver.C -fPIC -DPIC

-o .libs/diophantine-solver.o

In file included from ../../linbox/matrix/blas-matrix.h:1280,

from ../../linbox/blackbox/compose.h:33,

from ../../linbox/algorithms/rational-solver.h:39,

from ../../linbox/algorithms/diophantine-solver.h:28,

from diophantine-solver.C:24:

../../linbox/matrix/blas-matrix.inl:244: error: prototype for

‘LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, long int, T)’

does not match any in class ‘LinBox::BlasMatrix<_Field>’

../../linbox/matrix/blas-matrix.h:294: error: candidates are:

template<class _Field> template<class StreamVector>

LinBox::BlasMatrix::BlasMatrix(const _Field&,

LinBox::VectorStream<StreamVector>&)

../../linbox/matrix/blas-matrix.h:283: error:

LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, const typename

_Field::Element*, size_t, size_t)

../../linbox/matrix/blas-matrix.h:277: error:

LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, const

std::vector<typename Field::Element, std::allocator<typename

Field::Element> >&, size_t, size_t)

../../linbox/matrix/blas-matrix.h:267: error:

LinBox::BlasMatrix<_Field>::BlasMatrix(const

LinBox::BlasMatrix<_Field>&)

../../linbox/matrix/blas-matrix.h:262: error:

template<class _Field> template<class _Matrix>

LinBox::BlasMatrix::BlasMatrix(const _Matrix&, const _Field&)

../../linbox/matrix/blas-matrix.h:255: error:

template<class _Field> template<class Matrix>

LinBox::BlasMatrix::BlasMatrix(const Matrix&, size_t, size_t, size_t,

size_t)

../../linbox/matrix/blas-matrix.h:243: error:

template<class _Field> template<class Matrix>

LinBox::BlasMatrix::BlasMatrix(const Matrix&)

../../linbox/matrix/blas-matrix.h:237: error:

LinBox::BlasMatrix<_Field>::BlasMatrix(LinBox::MatrixStream<Field>&)

../../linbox/matrix/blas-matrix.h:229: error:

template<class _Field> template<class T>

LinBox::BlasMatrix::BlasMatrix(const _Field&, LinBox::Integer&, T)

../../linbox/matrix/blas-matrix.h:226: error:

template<class _Field> template<class T>

LinBox::BlasMatrix::BlasMatrix(const _Field&, int32_t, T)

../../linbox/matrix/blas-matrix.h:223: error:

template<class _Field> template<class T>

LinBox::BlasMatrix::BlasMatrix(const _Field&, unsigned int, T)

../../linbox/matrix/blas-matrix.h:220: error:

template<class _Field> template<class T>

LinBox::BlasMatrix::BlasMatrix(const _Field&, int64_t, T)

../../linbox/matrix/blas-matrix.h:217: error:

template<class _Field> template<class T>

LinBox::BlasMatrix::BlasMatrix(const _Field&, uint64_t, T)

../../linbox/matrix/blas-matrix.inl:227: error:

LinBox::BlasMatrix<_Field>::BlasMatrix()

../../linbox/matrix/blas-matrix.inl:221: error:

LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&)

../../linbox/matrix/blas-matrix.inl:255: error: prototype for

‘LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, long unsigned

int, T)’ does not match any in class ‘LinBox::BlasMatrix<_Field>’

../../linbox/matrix/blas-matrix.h:294: error: candidates are:

template<class _Field> template<class StreamVector>

LinBox::BlasMatrix::BlasMatrix(const _Field&,

LinBox::VectorStream<StreamVector>&)

../../linbox/matrix/blas-matrix.h:283: error:

LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, const typename

_Field::Element*, size_t, size_t)

../../linbox/matrix/blas-matrix.h:277: error:

LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, const

std::vector<typename Field::Element, std::allocator<typename

Field::Element> >&, size_t, size_t)

../../linbox/matrix/blas-matrix.h:267: error:

LinBox::BlasMatrix<_Field>::BlasMatrix(const

LinBox::BlasMatrix<_Field>&)

../../linbox/matrix/blas-matrix.h:262: error:

template<class _Field> template<class _Matrix>

LinBox::BlasMatrix::BlasMatrix(const _Matrix&, const _Field&)

../../linbox/matrix/blas-matrix.h:255: error:

template<class _Field> template<class Matrix>

LinBox::BlasMatrix::BlasMatrix(const Matrix&, size_t, size_t, size_t,

size_t)

../../linbox/matrix/blas-matrix.h:243: error:

template<class _Field> template<class Matrix>

LinBox::BlasMatrix::BlasMatrix(const Matrix&)

../../linbox/matrix/blas-matrix.h:237: error:

LinBox::BlasMatrix<_Field>::BlasMatrix(LinBox::MatrixStream<Field>&)

../../linbox/matrix/blas-matrix.h:229: error:

template<class _Field> template<class T>

LinBox::BlasMatrix::BlasMatrix(const _Field&, LinBox::Integer&, T)

../../linbox/matrix/blas-matrix.h:226: error:

template<class _Field> template<class T>

LinBox::BlasMatrix::BlasMatrix(const _Field&, int32_t, T)

../../linbox/matrix/blas-matrix.h:223: error:

template<class _Field> template<class T>

LinBox::BlasMatrix::BlasMatrix(const _Field&, unsigned int, T)

../../linbox/matrix/blas-matrix.h:220: error:

template<class _Field> template<class T>

LinBox::BlasMatrix::BlasMatrix(const _Field&, int64_t, T)

../../linbox/matrix/blas-matrix.h:217: error:

template<class _Field> template<class T>

LinBox::BlasMatrix::BlasMatrix(const _Field&, uint64_t, T)

../../linbox/matrix/blas-matrix.inl:227: error:

LinBox::BlasMatrix<_Field>::BlasMatrix()

../../linbox/matrix/blas-matrix.inl:221: error:

LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&)

make[3]: *** [diophantine-solver.lo] Error 1

make[3]: Leaving directory `/home/saunders/sandbox/linbox/linbox/algorithms'

make[2]: *** [all-recursive] Error 1

Oct 26, 2011, 1:53:33 PM10/26/11

to linbox...@googlegroups.com

Hello again !

--

Brice Boyer.

____________________________________________________________

brice...@imag.fr Tél. +33(0)4 76 51 45 61

Université Joseph Fourier, Grenoble I.

Laboratoire Jean Kuntzmann, Mathématiques Appliquées et Informatique

LJK - UJF BP53 38041 Grenoble cedex FRANCE

http://ljk.imag.fr/membres/Brice.Boyer

____________________________________________________________

2011/10/26 B Saunders <saun...@udel.edu>

well, I don't like size_t very much. I'd rather we have an index_t that is a typedef to a uint32_t for instance (cf ffspmvgpu). I made these constructors because it was faster than finding/fixing all the compile warnings/errors. I just fixed int -> int32_t etc in the inl but none was missing. I'm not sure what problem there is...

--

You received this message because you are subscribed to the Google Groups "linbox-devel" group.

To post to this group, send email to linbox...@googlegroups.com.

To unsubscribe from this group, send email to linbox-devel...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/linbox-devel?hl=en.

Brice Boyer.

____________________________________________________________

brice...@imag.fr Tél. +33(0)4 76 51 45 61

Université Joseph Fourier, Grenoble I.

Laboratoire Jean Kuntzmann, Mathématiques Appliquées et Informatique

LJK - UJF BP53 38041 Grenoble cedex FRANCE

http://ljk.imag.fr/membres/Brice.Boyer

____________________________________________________________

Oct 26, 2011, 6:42:34 PM10/26/11

to linbox...@googlegroups.com

Brice, thanks for that simple fix. With that these recent g++

versions don't complain during make or make check. However there were

a couple of tests which called that constructor with a long for the

dimension argument. The compiler choked. I have changed the

test-dense and test-matrix-domain so that now they compile with these

compilers.

It means that we have a policy that you must use a size_t or

[u]int<2^{8k}>_t. Fine by me.

versions don't complain during make or make check. However there were

a couple of tests which called that constructor with a long for the

dimension argument. The compiler choked. I have changed the

test-dense and test-matrix-domain so that now they compile with these

compilers.

It means that we have a policy that you must use a size_t or

[u]int<2^{8k}>_t. Fine by me.

I also like the convention of using an index_t, and this is

independent of the question of what it is typedef-ed to. (In other

words, even if typedef-ed to size_t, for example, I would like it.).

I don't yet see a clear benefit of a different unsigned type:

uint32_t, which seems to me to be too constrained. What benefit does

it convey over size_t in ffspmvgpu?

Best,

-dave

Oct 27, 2011, 6:44:05 AM10/27/11

to linbox...@googlegroups.com

2011/10/27 B Saunders <saun...@udel.edu>

Brice, thanks for that simple fix. With that these recent g++

versions don't complain during make or make check. However there were

a couple of tests which called that constructor with a long for the

dimension argument. The compiler choked.

I have changed the

test-dense and test-matrix-domain so that now they compile with these

compilers.

what's their version ? I tested on a 4.4.5/32bits and no problem. Anyway if the compiler fails on this, it's more a compiler problem than a coding one...

The compiler in the latest stable debian is 4.4.5... (maybe a buildbot with a stable debian + telling on the main page we support g++ for a stable debian should be enough ? For instance, we already know many 4.2 releases will produce bogus executables if they compile at all.

It means that we have a policy that you must use a size_t or

[u]int<2^{8k}>_t. Fine by me.

I'd rather loops use using index_t, as well as vector/matrix/... constructors, with the proper casts. I chose to allow any combination of ([u]int[X]_t,T) just because it was a simpler fix for now (not only does it fix warnings but also errors like "there is no rowdim() member in 'int'...". It is also simpler for the user since she doesn't need to make an explicit cast... By the way, there is the same problem when we initialise Fields/Integers... we often support plenty of types while we would be better off supporting only (Integer/unsigned long/long/double) at the price of casting...

We should discuss all this too for the future design and try to stick to this. Some time ago, I had rewritten plenty of loops with size_t...

I also like the convention of using an index_t, and this is

independent of the question of what it is typedef-ed to. (In other

words, even if typedef-ed to size_t, for example, I would like it.).

I don't yet see a clear benefit of a different unsigned type:

uint32_t, which seems to me to be too constrained. What benefit does

it convey over size_t in ffspmvgpu?

I don't know the size of a size_t if I don't check it during configure time... As for an index_t (unsigned) and its signed counterpart, we can typedef them to something (not compiler dependent), the size of which we can choose/we know.

Best,

-dave

cheers

Oct 27, 2011, 2:16:53 PM10/27/11

to linbox...@googlegroups.com

size_t can hold the size of any memory block and any pointer can be

cast to a size_t. This is platform independent. For indices that is

a good, whereas for field and ring element types, I am more

comfortable with types of fixed size such as uint32_t.

cast to a size_t. This is platform independent. For indices that is

a good, whereas for field and ring element types, I am more

comfortable with types of fixed size such as uint32_t.

The only argument I can think of against size_t would be if you are

sure you won't use a matrix of over 2^31 entries and you want matrix

handles to be smaller. I'd need to be shown an example where this

matters before I'd consider it. In any case if index_t is settable at

configure time, then one has both options: use size_t in general and

use uint32_t when there are going to be a gazillion small matrices.

On another thread of this conversation, below I show the compilation

problem exemplified by test-dense when I back off to the use of a long

parameter for handing the matrix size parameter to the test function

(changing this long to size_t is what fixed test-dense for me). It is

with gcc 4.4.5/32bit, which seems to be like your environment, Brice.

So I am surprised if your compiler doesn't also complain.

Best,

-dave

(compiler/arch)

scg39:~/sandbox/linbox/tests> g++ -v

Using built-in specs.

Target: i686-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro

4.4.4-14ubuntu5'

--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs

--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr

--program-suffix=-4.4 --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 --libdir=/usr/lib

--enable-nls --with-sysroot=/ --enable-clocale=gnu

--enable-libstdcxx-debug --enable-objc-gc --enable-targets=all

--disable-werror --with-arch-32=i686 --with-tune=generic

--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu

--target=i686-linux-gnu

Thread model: posix

gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)

----------------------------------------------------------------------------

(change the size_t parameter back to a long)

scg39:~/sandbox/linbox/tests> svn diff test-dense.C

...

-static bool testIdentity (Field &F, size_t n, int iterations)

+static bool testIdentity (Field &F, long n, int iterations)

...

------------------------------------------------------------------------------

(try to compile)

scg39:~/sandbox/linbox/tests> !ma

make test-dense

g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../linbox

-I/home/bdsaunde/sandbox/include -I/home/bdsaunde/sandbox/include

-DLinBoxSrcOnly -O0 -Wall -g -DNDEBUG -U_LB_DEBUG -g -DNDEBUG

-U_LB_DEBUG -c -o test-dense.o test-dense.C

test-dense.C: In function ‘bool testIdentity(Field&, long int, int)

[with Field = main(int, char**)::Field]’:

test-dense.C:331: instantiated from here

test-dense.C:66: error: call of overloaded

‘BlasMatrix(LinBox::Modular<unsigned int>&, long int&, long int&)’ is

ambiguous

../linbox/matrix/blas-matrix.inl:268: note: candidates are:

LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, int32_t, T)

[with T = long int, _Field = LinBox::Modular<unsigned int>]

../linbox/matrix/blas-matrix.inl:235: note:

LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, uint32_t, T)

[with T = long int, _Field = LinBox::Modular<unsigned int>]

../linbox/matrix/blas-matrix.inl:244: note:

LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, int64_t, T)

[with T = long int, _Field = LinBox::Modular<unsigned int>]

../linbox/matrix/blas-matrix.inl:255: note:

LinBox::BlasMatrix<_Field>::BlasMatrix(const _Field&, uint64_t, T)

[with T = long int, _Field = LinBox::Modular<unsigned int>]

test-dense.C:331: instantiated from here

test-dense.C:75: warning: comparison between signed and unsigned

integer expressions

test-dense.C:331: instantiated from here

test-dense.C:88: warning: comparison between signed and unsigned

integer expressions

test-dense.C:331: instantiated from here

test-dense.C:104: warning: comparison between signed and unsigned

integer expressions

make: *** [test-dense.o] Error 1

Oct 28, 2011, 5:32:28 AM10/28/11

to linbox...@googlegroups.com

2011/10/27 B Saunders <saun...@udel.edu>

size_t can hold the size of any memory block and any pointer can be

cast to a size_t. This is platform independent. For indices that is

a good, whereas for field and ring element types, I am more

comfortable with types of fixed size such as uint32_t.

The only argument I can think of against size_t would be if you are

sure you won't use a matrix of over 2^31 entries and you want matrix

handles to be smaller. I'd need to be shown an example where this

matters before I'd consider it. In any case if index_t is settable at

configure time, then one has both options: use size_t in general and

use uint32_t when there are going to be a gazillion small matrices.

On another thread of this conversation, below I show the compilation

problem exemplified by test-dense when I back off to the use of a long

parameter for handing the matrix size parameter to the test function

(changing this long to size_t is what fixed test-dense for me). It is

with gcc 4.4.5/32bit, which seems to be like your environment, Brice.

So I am surprised if your compiler doesn't also complain.

my fault. I had locally modified headers...

Yes gcc 4.4.5/32bit complains. There is a problem with the long int type. I fixed it with adding one more constructor... (but only for gcc-4.4.5 on 32bits...). This does not affect the latest release.

Yes gcc 4.4.5/32bit complains. There is a problem with the long int type. I fixed it with adding one more constructor... (but only for gcc-4.4.5 on 32bits...). This does not affect the latest release.

--

You received this message because you are subscribed to the Google Groups "linbox-devel" group.

To post to this group, send email to linbox...@googlegroups.com.

To unsubscribe from this group, send email to linbox-devel...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/linbox-devel?hl=en.

cheers,

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu