Problems with Windows x86-64 executable
 

I have had two reports of the x86-64 executables crashing on Windows 64, one for sr1sieve and one for sr2sieve.

Has anyone else had problems with the x86-64 Windows version, especially an access violation soon after starting?

Conversely, has anyone successfully run the x86-64 executable on Vista 64?

[QUOTE=geoff;119924]Conversely, has anyone successfully run the x86-64 executable on Vista 64?[/QUOTE]

if nobody is running it, i will try it tomorrow (if vista accept to start)

srsieve 0.6.9, sr1sieve 1.2.4, sr2sieve 1.6.15
 

These versions have a new switch: `sr2sieve -An ...' will set affinity to CPU n.

This feature is probably not useful on Linux where you can just as easily run `taskset -cn sr2sieve ...', It hasn't been tested on Windows yet, please let me know if it doesn't work as expected.

[QUOTE=geoff;119924]I have had two reports of the x86-64 executables crashing on Windows 64, one for sr1sieve and one for sr2sieve.

Has anyone else had problems with the x86-64 Windows version, especially an access violation soon after starting?

Conversely, has anyone successfully run the x86-64 executable on Vista 64?[/QUOTE]
sr1sieve-1.2.4-windows-x86-64 runs great on 64-bit Vista. I have not had problems with any version of sr2sieve on 64-bit Vista.

Thanks Geoff.

It appears that there is a bug in the cross compiler I use to build the Windows x86-64 executables that probably affected all prior sr1sieve versions. sr1sieve version 1.2.4 has a workaround for the bug, and I have also added the workaround to the stable branch in sr1sieve version 1.1.13. Thanks AES for helping track this down.

If anyone builds their own executables, please avoid using GCC version 4.3.0 if possible.

edit: This problem didn't affect the Linux or 32-bit precompiled executables, I use GCC 3.4 to compile them.

Hey Geoff,

You are doing a great job on the sieving side what about the LLRring side?

Carlos

Don't use Windows x86-64 executables for p > 2^51
 

There are more reports of problems with the sr2sieve 64-bit Windows executables, the common thread is that the problems occur in the x87 FPU code path which is used for sieving p > 2^51 or when the --no-sse2 switch is used.

I don't have any solution yet, and without a 64-bit Windows machine it could take a while to locate the problem, so in the meantime please use the 32-bit executable on 64-bit Windows machines for sieving above p=2^51 (about 2250e12 or 2250T).

Hmmm... At first, I thought that maybe [URL="http://en.wikipedia.org/wiki/X86-64#Windows"]this[/URL] was the problem, but then ...
[QUOTE=the article]Early reports claimed that the operating system scheduler would not save and restore the x87 FPU machine state across thread context switches. Observed behavior shows that this is not the case: the x87 state is saved and restored, except for kernel-mode-only threads. The most recent documentation available from Microsoft states that the x87/MMX/3DNow! instructions may be used in long mode.[/QUOTE]

Oh well.

sr1sieve 1.2.5, sr2sieve 1.6.16 (Windows x86-64)
 

I have found a place where the cross-compiler I use to build the x86-64 Windows executables generates incorrect code, causing an array overrun in the x87 FPU code path. This code path is only used when sieving deeper than 2^51 or when the --no-sse2 switch is given. The normal result is that the program crashes with an access violation soon after starting.

As a workaround I have lowered the compiler optimisation level to -O1 when building the sr1sieve version 1.2.5 and sr2sieve version 1.6.16 executables. This changes the part of the code which is obviously incorrect so that it is not obviously incorrect. It still needs to be tested. All earlier versions of the Windows x86-64 executables were affected by this bug and should not be used for sieving p > 2^51.

If compiling your own executable from source, avoid GCC 4.3.0 if possible, or else use the ARCH=x86-64-gcc430 Makefile option instead of ARCH=x86-64. This probably applies to the MacIntel executables too.

Would it be possible to append to [I]sr(x)sieve.log[/I] file version information every time sieve is started? Just to track which versions completed which ranges in case some error occurs.

[QUOTE=Cruelty;120416]Would it be possible to append to [I]sr(x)sieve.log[/I] file version information every time sieve is started? Just to track which versions completed which ranges in case some error occurs.[/QUOTE]

That is a very good idea, I'll do it ASAP. Thanks.