And the beat goes on... (compiling the CWI code)
 

I got a version of the build matrix code compiled and linked.

I am now working on the Lanczos code.

The make file has a reference to a variable defined as an input the to compiler:
BLOCKING_FACTOR. It is used in macros inside .h files and there is an
#ifndef BLOCKING_FACTOR

but its value is not defined anywhere. It is seemingly provided as an input to make
when make is invoked.

There does not seem to be any guidance. I can only guess at its value.

The code also seems to use some syntax/constructs that are not liked by the compiler. e.g.



typedef char hexstr_t[1 + BITS_PER_ELEMENT/4];

The code is clearly trying to define a type as a character array of fixed size. But the compiler fails to
recognize the syntax. Later

hexstr_t hvalue;
hvalue[i] = ......

barfs as well with two errors:

"type defaults to int" for the typedef declaration, then later
"hvalue is neither an array or pointer" for the assignment.

This is easy to fix, but why write code this way????

[QUOTE=R.D. Silverman;409811]I got a version of the build matrix code compiled and linked.

I am now working on the Lanczos code.

The make file has a reference to a variable defined as an input the to compiler:
BLOCKING_FACTOR. It is used in macros inside .h files and there is an
#ifndef BLOCKING_FACTOR

but its value is not defined anywhere. It is seemingly provided as an input to make
when make is invoked.

There does not seem to be any guidance. I can only guess at its value.

The code also seems to use some syntax/constructs that are not liked by the compiler. e.g.



typedef char hexstr_t[1 + BITS_PER_ELEMENT/4];

The code is clearly trying to define a type as a character array of fixed size. But the compiler fails to
recognize the syntax. Later

hexstr_t hvalue;
hvalue[i] = ......

barfs as well with two errors:

"type defaults to int" for the typedef declaration, then later
"hvalue is neither an array or pointer" for the assignment.

This is easy to fix, but why write code this way????[/QUOTE]

The code uses this kind of construct in MANY places.......

[QUOTE=R.D. Silverman;409811]I got a version of the build matrix code compiled and linked.

I am now working on the Lanczos code.

The make file has a reference to a variable defined as an input the to compiler:
BLOCKING_FACTOR. It is used in macros inside .h files and there is an
#ifndef BLOCKING_FACTOR

but its value is not defined anywhere. It is seemingly provided as an input to make
when make is invoked.

There does not seem to be any guidance. I can only guess at its value.

The code also seems to use some syntax/constructs that are not liked by the compiler. e.g.



typedef char hexstr_t[1 + BITS_PER_ELEMENT/4];

The code is clearly trying to define a type as a character array of fixed size. But the compiler fails to
recognize the syntax. Later

hexstr_t hvalue;
hvalue[i] = ......

barfs as well with two errors:

"type defaults to int" for the typedef declaration, then later
"hvalue is neither an array or pointer" for the assignment.

This is easy to fix, but why write code this way????[/QUOTE]

The typedef is valid. I don't know why gcc won't compile it.

[QUOTE=R.D. Silverman;409813]The code uses this kind of construct in MANY places.......[/QUOTE]

This is valid C code; I have tried a variety of compiler flags, including -std=gnu99
to no avail. The compiler refuses to compile this construct.

Advice?

Note that I get hundreds of errors.

[QUOTE=R.D. Silverman;409819]This is valid C code; I have tried a variety of compiler flags, including -std=gnu99
to no avail. The compiler refuses to compile this construct.

Advice?

Note that I get hundreds of errors.[/QUOTE]

I haven't tried to compile the CWI code, but I tried a quick program locally with what information you've given so far:
[CODE]#define BITS_PER_ELEMENT 32
int main(void) {
typedef char hexstr_t[1 + BITS_PER_ELEMENT/4];
hexstr_t hvalue;
hvalue[0] = 1;
if (hvalue[0] == 2) hvalue[0] = 1;
return 0;
}[/CODE]
And I tried every flag I could think of to get it to give me a warning or error:
[CODE]gcc -o typedef.exe -Wall -ansi -pedantic -Wextra -std=gnu99 test.c[/CODE]
And I don't get an error from the above code. Can you try the above to see if that gives you an error?

I guess the best way to proceed here is to ask, what version of gcc are you using? (gcc --version)
I'm using: gcc.exe (x86_64-posix-seh-rev1, Built by MinGW-W64 project) 4.9.2

What are the first couple of errors that you see?

Does the CWI code need a "configure" step? Sometimes big code projects need a "./configure [options]" in the main directory once before trying to do make. Does the CWI code need this, and if so, what options did you pass to configure?

Also, what options, if any, are you passing to "make"?

[QUOTE=WraithX;409820]I haven't tried to compile the CWI code, but I tried a quick program locally with what information you've given so far:
[CODE]#define BITS_PER_ELEMENT 32
int main(void) {
typedef char hexstr_t[1 + BITS_PER_ELEMENT/4];
hexstr_t hvalue;
hvalue[0] = 1;
if (hvalue[0] == 2) hvalue[0] = 1;
return 0;
}[/CODE]
And I tried every flag I could think of to get it to give me a warning or error:
[CODE]gcc -o typedef.exe -Wall -ansi -pedantic -Wextra -std=gnu99 test.c[/CODE]
And I don't get an error from the above code. Can you try the above to see if that gives you an error?

I guess the best way to proceed here is to ask, what version of gcc are you using? (gcc --version)
I'm using: gcc.exe (x86_64-posix-seh-rev1, Built by MinGW-W64 project) 4.9.2

What are the first couple of errors that you see?

Does the CWI code need a "configure" step? Sometimes big code projects need a "./configure [options]" in the main directory once before trying to do make. Does the CWI code need this, and if so, what options did you pass to configure?




Also, what options, if any, are you passing to "make"?[/QUOTE]


x86-64-w64-mingw32-gcc.exe

there is also

x86-64-w64-mingw32-gcc-5.0.1



c:\TDM-GCC-64\bin\gcc -c -Wall -std=gnu99 -D_MSC_VER -DUSE_PTHREAD -D_GNU_SOURCE -pthread %1

These are defines turned on in the CWI makefile.

There is no config step. AFAIK

BTW, I am also running into some data types and defines that are not defined anywhere within the
.c or .h files: DISTR, DBLINT

I suspect the latter may come from GMP somewhere.

[QUOTE=R.D. Silverman;409824]x86-64-w64-mingw32-gcc.exe

there is also

x86-64-w64-mingw32-gcc-5.0.1



c:\TDM-GCC-64\bin\gcc -c -Wall -std=gnu99 -D_MSC_VER -DUSE_PTHREAD -D_GNU_SOURCE -pthread %1

These are defines turned on in the CWI makefile.

There is no config step. AFAIK

BTW, I am also running into some data types and defines that are not defined anywhere within the
.c or .h files: DISTR, DBLINT

I suspect the latter may come from GMP somewhere.[/QUOTE]

here is the version output:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/TDM-GCC-64/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-5.1.0/configure --build=x86_64-w64-mingw32 --enable-targets=all --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite --enable-cxx-flags=-DWINPTHREAD_STATIC --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-threads --enable-libstdcxx-time --with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --prefix=/mingw64tdm --with-local-prefix=/mingw64tdm --with-pkgversion=tdm64-1 --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 5.1.0 (tdm64-1)


I've been at this all day. My brain is mush. I am quitting for now.
I do not know why this typedef is not compiling.

Do you get the same error when you compile WraithX's test code?

If it compiles fine for you, then there is probably a syntax error on the previous line of your code (dropped ; or what have you). If that fails, then you may have a compiler bug in gcc 5 (or mingw or something) (????).

[QUOTE=R.D. Silverman;409811]I got a version of the build matrix code compiled and linked.

I am now working on the Lanczos code.

The make file has a reference to a variable defined as an input the to compiler:
BLOCKING_FACTOR. It is used in macros inside .h files and there is an
#ifndef BLOCKING_FACTOR

but its value is not defined anywhere. It is seemingly provided as an input to make
when make is invoked.

There does not seem to be any guidance. I can only guess at its value.[/QUOTE]
There's a comment in matunion.h about that define:
[code]/*
A November, 2003 timing run showed 128-bit vectors
performed best on IA-64 even with its many registers.
[This may be partially due to the 3 Megabyte L3 cache --
it can hold two vectors each of length 65536
if elements are 16 bytes each but not if they are 32 bytes.]
64-bit vectors ranked second, 256-bit third.
These tests used NMAT_BYTE_WIDTH = INNER_NYTE_WIDTH = 8.
The tests did not consider that more matrix rows (for small primes)
can be omitted if we use wider vectors
-- rather the same matrix was used three times.

A test on an AMD Phenom II with a 3746144 x 3754318 w259102075
matrix suggested that a blocking factor of 256 is better even
for this relatively small matrix size.
*/[/code][quote]The code also seems to use some syntax/constructs that are not liked by the compiler. e.g.



typedef char hexstr_t[1 + BITS_PER_ELEMENT/4];

The code is clearly trying to define a type as a character array of fixed size. But the compiler fails to
recognize the syntax. Later

hexstr_t hvalue;
hvalue[i] = ......

barfs as well with two errors:

"type defaults to int" for the typedef declaration, then later
"hvalue is neither an array or pointer" for the assignment.

This is easy to fix, but why write code this way????[/quote]If you define BLOCKING_FACTOR to say 256 (either add -DBLOCKING_FACTOR 256 when calling gcc, or add #define BLOCKING_FACTOR 256 in matunion.h after the comment quoted above and before the #ifndef BLOCKING_FACTOR check), the code should compile.

[QUOTE=ldesnogu;409862]There's a comment in matunion.h about that define:
[code]/*
A November, 2003 timing run showed 128-bit vectors
performed best on IA-64 even with its many registers.
[This may be partially due to the 3 Megabyte L3 cache --
it can hold two vectors each of length 65536
if elements are 16 bytes each but not if they are 32 bytes.]
64-bit vectors ranked second, 256-bit third.
These tests used NMAT_BYTE_WIDTH = INNER_NYTE_WIDTH = 8.
The tests did not consider that more matrix rows (for small primes)
can be omitted if we use wider vectors
-- rather the same matrix was used three times.

A test on an AMD Phenom II with a 3746144 x 3754318 w259102075
matrix suggested that a blocking factor of 256 is better even
for this relatively small matrix size.
*/[/code]If you define BLOCKING_FACTOR to say 256 (either add -DBLOCKING_FACTOR 256 when calling gcc, or add #define BLOCKING_FACTOR 256 in matunion.h after the comment quoted above and before the #ifndef BLOCKING_FACTOR check), the code should compile.[/QUOTE]

Thanks for the feedback.

It seems that the compile failed because BITS_PER_ELEMENT was not defined. It was not defined because
BLOCKING_FACTOR was not defined................

[QUOTE=R.D. Silverman;409869]Thanks for the feedback.

It seems that the compile failed because BITS_PER_ELEMENT was not defined. It was not defined because
BLOCKING_FACTOR was not defined................[/QUOTE]

I have a working version of the matrix build code, compiled from the new code. It seems
to work correctly and produces a matrix identical with the old code.

The new CWI code has two versions for LA: gauss.c and lanczos.c

I managed to get a 64-bit version of the former built. But when I run it
it gives the same matrix weight mismatch error that I got before.

I assume that CWI is no longer supporting this, but I'd like to ask someone
there (who is still there?) about this problem.

I could work around the problem, telling the code not to exit, but I don't want to
waste a week running LA code only to find out that I get the wrong answer....

Compiling lanczos.c is still ongoing.