On Mon, Dec 17, 2007 at 09:18:06PM +0100, Richard B. Kreckel wrote:
Hi Paul,
Paul Irofti wrote:
On Thu, Nov 29, 2007 at 11:02:17PM +0100, Richard B. Kreckel wrote:
Index: src/polynomial/elem/cl_UP_GF2.h =================================================================== RCS file: /home/cvs/cln/src/polynomial/elem/cl_UP_GF2.h,v retrieving revision 1.8 diff -u -r1.8 cl_UP_GF2.h --- src/polynomial/elem/cl_UP_GF2.h 1 Aug 2007 22:07:37 -0000 1.8 +++ src/polynomial/elem/cl_UP_GF2.h 29 Nov 2007 22:01:03 -0000 @@ -95,7 +95,7 @@ return x; }
-#if !(defined(__sparc__) || defined(__sparc64__)) +#if !defined(__sparc__) || defined(__sparc64__) // Multiplication of polynomials over GF(2) can unfortunately not profit // from hardware multiply instructions. Use a table instead. // This is a 2^8 x 2^4 table. Maybe a 2^6 x 2^6 table would be better?
Does this help?
Indeed it does: the library compiles, but some of the tests fail. Maybe you can shed some light into this.
Okay, I've applied that patch to the main branch. We've made it compile. That was the easier part. Indeed.
It appears like test loops in src/base/digitseq/cl_asm_sparc64_.cc are broken.
You can try debugging the problem. As a blind shot, you could try redefining LOOP_TYPE in that file. But trying patches and submitting them into some build queue does not make sense any more. Now, somebody must debug things on a machine. Paul, can you do that? It shouldn't be too difficult. If not, can you arrange a login for me? Please do contact me in private if there is a chance.
I'll see if I can get a sparc64 shell on my hands, but the one I was testing with is out of the question (that's what the guy said and I understand). I'll get back to you. Let me know if you find something too.