v1.42 and SVN <= 40 have the same filtering code that sets the amount of excess needed during the filtering. As Serge noted in post #97, you are in the 'just enough for filtering but not enough for a good matrix' zone, and should sieve a bit more.

[QUOTE=jasonp;185337]v1.42 and SVN <= 40 have the same filtering code that sets the amount of excess needed during the filtering. As Serge noted in post #97, you are in the 'just enough for filtering but not enough for a good matrix' zone, and should sieve a bit more.[/QUOTE]

Thanks, I already thought that it could be something like this.

[quote=jasonp;185337]v1.42 and SVN <= 40 have the same filtering code that sets the amount of excess needed during the filtering. As Serge noted in post #97, you are in the 'just enough for filtering but not enough for a good matrix' zone, and should sieve a bit more.[/quote]
I am pretty certain problems like this currently mean a restart of factmsieve.pl. Would it be posible to change factmsieve.pl to cope?

I am not sure we can catch the msieve's return code (if it is a specific one), but we can re-parse the ggnfs.log and insert the logic to return to sieving (a bit ugly because at this time we will have left the sieving loop).

But a better solution would be for -nc1 to abort without trying to make overdense .cyc. The abort trigger would be around the line which prints
"found 19082 cycles, need 447614" (i.e. need many more than found), and exit. (Normal flow is when found more than needed.)

Would it be possible to get rid of the "common/filter/clique.c:1: error: CPU you selected does not support x86-64 instruction set" bug? This occurs even when I run the command "make x86_64" which will never work without moving the # on the OPT_FLAGS= lines in the makefile.
Typing x86 or x86_64 for most programs will make that change for you.

I've never liked this method of compiling on 64-bit either. Most programs figure this out for you because most development teams have a sucker willing to learn how autoconf and automake work.

Otherwise, does anyone know how a makefile can figure out for itself whether it's running on 64-bit x86? Then change the list of files to be compiled based on the answer?

[quote=jasonp;186850]Otherwise, does anyone know how a makefile can figure out for itself whether it's running on 64-bit x86? Then change the list of files to be compiled based on the answer?[/quote]

Something like this perhaps:
[code]PROC = $(shell uname -p)

ifeq ($(PROC), x86_64)
FILES_PROC = file64.c
else
FILES_PROC = file32.c
endif

all:
@echo $(FILES_PROC)
[/code]To override the detection, you could then use make PROC=whatever.

You just need to put the correct -march= in the x86: and x86_64: sections rather that putting it in OPT_FLAGS and then CFLAGS.
I personally am not bothered about having to type x86_64.
It is fiddling with the makefile that is a pain.
If what ldesnogu said works then use that.

It works for sure on my machine: Fedora 11 x86_64.

I might have used some GNU make specific features; I think the last time I used a standard make was 8 years ago, so I'm definitely not able to tell.

ldesnogu: 'uname -p' on my windows system gives 'unknown', although 'uname -m' gives 'i686'. The trouble with using the output of uname is that there are so many variations in the output across different systems. (For laughs, look inside a random configure script to see how complex parsing uname output is)

henry: putting -march in the make target will work correctly when linking the library and building the demo app, but it does not carry through to compiling the individual source files. These have their own build lines.

Segmentation fault with v. 1.41 fixed in v. 1.42
 

Not a bug report: more a fix report.

[CODE]N 310890304013484373562887127745452331540345397505219234961440691761619412607848591598982342820937073960794129304412792830537498
A6 11
A5
A4
A3
A2
A1
A0 10
R1 -100000000000000000000000000000000
R0 2111377674535255285545615254209921
FAMAX 26000000
FRMAX 26000000
SALPMAX 536870912
SRLPMAX 536870912
[/CODE]

This segfaulted on v. 1.41. Compiled v. 1.42 (x86_64, k8), and it worked fine.

Thumbs up!