mersenneforum.org And the beat goes on... (compiling the CWI code)
 Register FAQ Search Today's Posts Mark Forums Read

 2015-09-07, 19:25 #1 R.D. Silverman     Nov 2003 22×5×373 Posts 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???? Last fiddled with by R.D. Silverman on 2015-09-07 at 19:35 Reason: addition
2015-09-07, 19:36   #2
R.D. Silverman

Nov 2003

22·5·373 Posts

Quote:
 Originally Posted by R.D. Silverman 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????
The code uses this kind of construct in MANY places.......

2015-09-07, 19:43   #3
R.D. Silverman

Nov 2003

164448 Posts

Quote:
 Originally Posted by R.D. Silverman 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????
The typedef is valid. I don't know why gcc won't compile it.

2015-09-07, 20:18   #4
R.D. Silverman

Nov 2003

22×5×373 Posts

Quote:
 Originally Posted by R.D. Silverman The code uses this kind of construct in MANY places.......
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.

Note that I get hundreds of errors.

Last fiddled with by R.D. Silverman on 2015-09-07 at 20:18

2015-09-07, 20:29   #5
WraithX

Mar 2006

1E616 Posts

Quote:
 Originally Posted by R.D. Silverman 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.
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;
}
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
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"?

2015-09-07, 21:33   #6
R.D. Silverman

Nov 2003

22×5×373 Posts

Quote:
 Originally Posted by WraithX 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; } 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 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"?

x86-64-w64-mingw32-gcc.exe

there is also

x86-64-w64-mingw32-gcc-5.0.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.

2015-09-07, 21:53   #7
R.D. Silverman

Nov 2003

22·5·373 Posts

Quote:
 Originally Posted by R.D. Silverman 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.
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
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.

Last fiddled with by R.D. Silverman on 2015-09-07 at 21:55

 2015-09-08, 06:32 #8 Dubslow Basketry That Evening!     "Bunslow the Bold" Jun 2011 40
2015-09-08, 09:09   #9
ldesnogu

Jan 2008
France

10001001102 Posts

Quote:
 Originally Posted by R.D. Silverman 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.
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.
*/
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????
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.

2015-09-08, 11:02   #10
R.D. Silverman

Nov 2003

164448 Posts

Quote:
 Originally Posted by ldesnogu 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. */ 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.
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................

2015-09-08, 13:49   #11
R.D. Silverman

Nov 2003

22×5×373 Posts

Quote:
 Originally Posted by R.D. Silverman 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................
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

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.

Last fiddled with by R.D. Silverman on 2015-09-08 at 13:52

 Similar Threads Thread Thread Starter Forum Replies Last Post dozba GPU Computing 23 2017-10-03 19:50 ATH GMP-ECM 69 2017-01-04 12:03 schickel Lounge 4 2013-08-28 03:55 sol_kanar Software 3 2009-03-26 09:15 CBoland Software 6 2007-08-01 00:11

All times are UTC. The time now is 00:37.

Sat Oct 23 00:37:30 UTC 2021 up 91 days, 19:06, 0 users, load averages: 1.46, 1.31, 1.42