mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > Factoring

Reply
 
Thread Tools
Old 2015-09-07, 19:25   #1
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

22×5×373 Posts
Default 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
R.D. Silverman is offline   Reply With Quote
Old 2015-09-07, 19:36   #2
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

22·5·373 Posts
Default

Quote:
Originally Posted by R.D. Silverman View Post
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.......
R.D. Silverman is offline   Reply With Quote
Old 2015-09-07, 19:43   #3
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

164448 Posts
Default

Quote:
Originally Posted by R.D. Silverman View Post
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.
R.D. Silverman is offline   Reply With Quote
Old 2015-09-07, 20:18   #4
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

22×5×373 Posts
Default

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

Advice?

Note that I get hundreds of errors.

Last fiddled with by R.D. Silverman on 2015-09-07 at 20:18
R.D. Silverman is offline   Reply With Quote
Old 2015-09-07, 20:29   #5
WraithX
 
WraithX's Avatar
 
Mar 2006

1E616 Posts
Default

Quote:
Originally Posted by R.D. Silverman View Post
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"?
WraithX is offline   Reply With Quote
Old 2015-09-07, 21:33   #6
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

22×5×373 Posts
Default

Quote:
Originally Posted by WraithX View Post
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



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.
R.D. Silverman is offline   Reply With Quote
Old 2015-09-07, 21:53   #7
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

22·5·373 Posts
Default

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

Last fiddled with by R.D. Silverman on 2015-09-07 at 21:55
R.D. Silverman is offline   Reply With Quote
Old 2015-09-08, 06:32   #8
Dubslow
Basketry That Evening!
 
Dubslow's Avatar
 
"Bunslow the Bold"
Jun 2011
40<A<43 -89<O<-88

722110 Posts
Default

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) (????).
Dubslow is offline   Reply With Quote
Old 2015-09-08, 09:09   #9
ldesnogu
 
ldesnogu's Avatar
 
Jan 2008
France

10001001102 Posts
Default

Quote:
Originally Posted by R.D. Silverman View Post
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.
ldesnogu is offline   Reply With Quote
Old 2015-09-08, 11:02   #10
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

164448 Posts
Default

Quote:
Originally Posted by ldesnogu View Post
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................
R.D. Silverman is offline   Reply With Quote
Old 2015-09-08, 13:49   #11
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

22×5×373 Posts
Default

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

Last fiddled with by R.D. Silverman on 2015-09-08 at 13:52
R.D. Silverman is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Compiling mfaktc on Mac OS X dozba GPU Computing 23 2017-10-03 19:50
compiling GMP-ECM ATH GMP-ECM 69 2017-01-04 12:03
We beat the odds where I work schickel Lounge 4 2013-08-28 03:55
Compiling mprime source code under Ubuntu sol_kanar Software 3 2009-03-26 09:15
Compiling 24.14 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

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.