I have tried to compile boinc and seti for NetBSD (x86).
But I if I run my binary against the reference WU, I get a result overflow after 35 % :

SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected exceeds the storage space allocated.

Any hints ?

---

Might be related to copiler flags like -ffast-math etc.

---

Join BOINC United now!

Might be related to copiler flags like -ffast-math etc.

Thanks, will try to recompile it.
Was compiled "only" with -O3 -funroll-loops.

---

Might be related to copiler flags like -ffast-math etc.

Thanks, will try to recompile it.
Was compiled "only" with -O3 -funroll-loops.

No success with reduced optimisation.

---

Might be related to copiler flags like -ffast-math etc.

Thanks, will try to recompile it.
Was compiled "only" with -O3 -funroll-loops.

No success with reduced optimisation.

Wich compiler version did you use ? If its a gcc 3.x.x try using "-ffloat-store" as cflag.

---

Join BOINC United now!

No success with reduced optimisation.

Wich compiler version did you use ? If its a gcc 3.x.x try using "-ffloat-store" as cflag.
[/quote]
Used gcc version 3.3.3 (NetBSD nb3 20040520)
Have resolved such a simliar problem with -ffloat-store ?

---

No success with reduced optimisation.

Wich compiler version did you use ? If its a gcc 3.x.x try using "-ffloat-store" as cflag.

Used gcc version 3.3.3 (NetBSD nb3 20040520)
Have resolved such a simliar problem with -ffloat-store ? [/quote]

Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Give it a try.

---

Join BOINC United now!

Used gcc version 3.3.3 (NetBSD nb3 20040520)
Have resolved such a simliar problem with -ffloat-store ?

Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".
[/quote]
Hm, will try it, but I don't get any SIGSEGV or SIGFP.
But the results from the reference WU differs stongly.

---

Used gcc version 3.3.3 (NetBSD nb3 20040520)
Have resolved such a simliar problem with -ffloat-store ?

Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Hm, will try it, but I don't get any SIGSEGV or SIGFP.
But the results from the reference WU differs stongly.
[/quote]

Thanks, the first run against the reference WU produces now valid results. I had compiled it with "-O -ffloat-store".
The next, more optimized binary is now running against the reference WU.

Is it posible, that -ffloat-store slow down the seti app by ~10 % ?

---

Used gcc version 3.3.3 (NetBSD nb3 20040520)
Have resolved such a simliar problem with -ffloat-store ?

Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Hm, will try it, but I don't get any SIGSEGV or SIGFP.
But the results from the reference WU differs stongly.

Thanks, the first run against the reference WU produces now valid results. I had compiled it with "-O -ffloat-store".
The next, more optimized binary is now running against the reference WU.

Is it posible, that -ffloat-store slow down the seti app by ~10 % ?
[/quote]

No i dont think so (should be less than 1-3%).
By way i remember that tetsuji maverick rai said that in his tests with FreeBSD it showed a 10% slowdown compared to linux that's why he droped the client for it and went back to linux.

---

Join BOINC United now!

Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Do you have some more details about this bug ? - A link ?

---

Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Do you have some more details about this bug ? - A link ?

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138791
http://bugs.mysql.com/bug.php?id=2338
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13719

---

Join BOINC United now!

[quote]Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Was not resolved by use this flags. It works only temporarly.
The first run with the reference WU was successfull. After a test with live WUs I get the error again.
Btw. -mieee is only supported on alpha.

---

[quote]Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Was not resolved by use this flags. It works only temporarly.
The first run with the reference WU was successfull. After a test with live WUs I get the error again.
Btw. -mieee is only supported on alpha.

Thats strange :-( especially because the reference wu works now.
Did all you "live WUs" fail or just some of them ? It might be possible that you've got a bunch full noisy Wus.

---

Join BOINC United now!

[quote]Yes.There's a bug in gcc up to gcc 3.4.4 causing a SIGFP/SIGSEGV.
It is suggested to use the "-ffloat-store" cflag.
Also JUST use "-O2".
If all of that wont work try adding a "-mieee".

Was not resolved by use this flags. It works only temporarly.
The first run with the reference WU was successfull. After a test with live WUs I get the error again.
Btw. -mieee is only supported on alpha.

Thats strange :-( especially because the reference wu works now.
Did all you "live WUs" fail or just some of them ? It might be possible that you've got a bunch full noisy Wus.

It was one regular WU, and one with noise. The regular WU was not validated, and has a result overflow, too.

But, in the moment I am testing again, with a different setup :

The reference WU with the app, compiled with gcc 3.3 and "-O -ffloat-store", was successfull on the first system. With "-O2 -ffloat-store" was no pulses detected, but with "-O -ffloat-store" everything is OK.
The second system runs the reference WU against this new binary in the moment.
Next step, if the second system computes right too, is to let some live WUs run.

But, I had readen in a other post, that anyone had the same probelms with the pules on NetBSD Sparc.

---

But, in the moment I am testing again, with a different setup :

The reference WU with the app, compiled with gcc 3.3 and "-O -ffloat-store", was successfull on the first system. With "-O2 -ffloat-store" was no pulses detected, but with "-O -ffloat-store" everything is OK.
The second system runs the reference WU against this new binary in the moment.
Next step, if the second system computes right too, is to let some live WUs run.

The changes in the CFLAGS don't change anything. Problem still extists.

---

But, in the moment I am testing again, with a different setup :

The reference WU with the app, compiled with gcc 3.3 and "-O -ffloat-store", was successfull on the first system. With "-O2 -ffloat-store" was no pulses detected, but with "-O -ffloat-store" everything is OK.
The second system runs the reference WU against this new binary in the moment.
Next step, if the second system computes right too, is to let some live WUs run.

The changes in the CFLAGS don't change anything. Problem still extists.

Maybe it has something to do with that:

-mno-fancy-math-387

Some 387 emulators do not support the sin, cos and sqrt instructions for the 387. Specify this option to avoid generating those instructions. This option is the default on FreeBSD, OpenBSD and NetBSD. This option is overridden when -march indicates that the target cpu will always have an FPU and so the instruction will not need emulation. As of revision 2.6.1, these instructions are not generated unless you also use the -funsafe-math-optimizations switch.


http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/i386-and-x86_002d64-Options.html

---

Join BOINC United now!

[quote]
Some 387 emulators do not support the sin, cos and sqrt instructions for the 387. Specify this option to avoid generating those instructions. This option is the default on FreeBSD, OpenBSD and NetBSD. This option is overridden when -march indicates that the target cpu will always have an FPU and so the instruction will not need emulation. As of revision 2.6.1, these instructions are not generated unless you also use the -funsafe-math-optimizations switch. [quote]
Thanks with -funsafe-math-optimizations and -ffloat-store I get now the first validated result.

But I am not shure, if this is a problem on my system. I tested the binaries, with different FLAGS on two different systems, mostly on both systems, the reference WU was OK.
If I run it against a live WU on my system, I get only with the CFLAGS above a valid result. So I am not shure, if this is a hardware problem (memory, cpu or cache) or OS problem on my system. - But under windows this system produce only valid WUs.

I will start a new thread for requesting jelp from the netbsd people, in the hope that anyone can let run the different apps, and reverify the work of the different apps.

---

Thanks with -funsafe-math-optimizations and -ffloat-store I get now the first validated result.

Now I have the same problem on NetBSD on sparc. But it will now not been fixable by use this flags.
Have anyone a idea ?

---

Thanks with -funsafe-math-optimizations and -ffloat-store I get now the first validated result.

Now I have the same problem on NetBSD on sparc. But it will now not been fixable by use this flags.
Have anyone a idea ?

Actually i don't have access to a sparc and have no clue. This whole xxxBSD stuff seems to be real strange when it comes to compile standard source.

For instance my optimized setiathome for freeBSD was kind of weired.
On freeBSD the use 16-byte aligned malloc and thereby it was a real pain to get fftw3 compile.

Anyway you could try "-msoft-float or -mno-fpu" for software assistance in floatingpoint operations but it'll slow down. But it also depends how the whole system libs (libc etc.) is compiled.

That's the only thing i can think off otherwise you're on your own. Sorry

---

Join BOINC United now!