On Fri, Mar 13, 2009 at 4:42 PM, Bill Hart wrote:
> In theory, it should work for 32 bit and 64 bit **x86** CPU's only,
> i.e. only two binaries needed for all those CPU's.
Ok so you might lose a little performance but have the flexibility for
it to work fast for most people's architectures.
>
The tests on SkyNet/mark pass. Here is the full matrix:
-eno - 4.3.0 np fp
-cicero 4.3.0 np fp
-menas 4.2.1 np fp / 4.3.3 np fp
-cato 4.1.2 np
-varro A 4.0.1 np fp / 4.3.3 np fp
-cleo 4.1.2 np / 4.3.3 np
-iras 4.1.2 np / 4.3.3 np
-fulvia 4.3.3 np fp *** / S np ** ***
-mark 4.3.3 np / S np
*** 3
That's true to some degree. Fat binaries are not quite as fast as full
builds due to the fact that the assembly functions are accessed via
function pointers instead of directly. There shouldn't be a lot in it,
but there will be quite a bit in it for someone who is say doing a lot
of mpz_set's with
On Fri, Mar 13, 2009 at 2:42 PM, Bill Hart wrote:
> The --enable-fat issue has gone for gcc on fulvia. Of course the yasm
> tests still fail on Sun, but that is harmless.
A question, if I used --enable-fat, I can compile a MPIR library and
link it to one of my programs, and it will automaticall
Mariah has been working on automating it. But I don't know how that is
going, except that occasionally I get bug reports. It doesn't cover
all compiler versions or machines so far.
Thanks for the link. I might use this elsewhere.
Bill.
2009/3/13 Mike Hansen :
>
> On Fri, Mar 13, 2009 at 11:42 A
On Fri, Mar 13, 2009 at 11:42 AM, Bill Hart wrote:
> What do people think? For one thing I am getting really sick of
> running 22 lots of confgure, make, make check every time we need to
> re-test on SkyNet, not to mention tests on other machines as well -
> especially given that some of these te
OK, I've run most of the SkyNet tests through again. Everything is
fine (haven't finished with tests on Mark yet - it is very slow).
The --enable-fat issue has gone for gcc on fulvia. Of course the yasm
tests still fail on Sun, but that is harmless.
But we do have a failure. --enable-fat fails t
On Thursday 12 March 2009 23:26:23 Bill Hart wrote:
> Did you manage to fix the grepping for multifunction files?
>
> I think there are a number of issues that we should look at. We can't
> really use Torbjorn's patches for versions later than 4.2.1 because
> they are designed to patch later versi
Good to see Intel keeping their docs in order.
2009/3/13 :
>
> On Thursday 12 March 2009 23:59:46 Bill Hart wrote:
>> 2009/3/13 :
>> > On Thursday 12 March 2009 23:51:08 Bill Hart wrote:
>> >> 2009/3/12 :
>> >> > On Thursday 12 March 2009 23:26:23 Bill Hart wrote:
>> >> >> Did you manage to fi
On Thursday 12 March 2009 23:59:46 Bill Hart wrote:
> 2009/3/13 :
> > On Thursday 12 March 2009 23:51:08 Bill Hart wrote:
> >> 2009/3/12 :
> >> > On Thursday 12 March 2009 23:26:23 Bill Hart wrote:
> >> >> Did you manage to fix the grepping for multifunction files?
> >> >
> >> > No didn't try ,
2009/3/13 :
>
> On Thursday 12 March 2009 23:51:08 Bill Hart wrote:
>> 2009/3/12 :
>> > On Thursday 12 March 2009 23:26:23 Bill Hart wrote:
>> >> Did you manage to fix the grepping for multifunction files?
>> >
>> > No didn't try , as we dont have any examples at the moment, is this an
>> > open
On Thursday 12 March 2009 23:51:08 Bill Hart wrote:
> 2009/3/12 :
> > On Thursday 12 March 2009 23:26:23 Bill Hart wrote:
> >> Did you manage to fix the grepping for multifunction files?
> >
> > No didn't try , as we dont have any examples at the moment, is this an
> > open ticket #3
>
> There is
2009/3/12 :
>
> On Thursday 12 March 2009 23:26:23 Bill Hart wrote:
>> Did you manage to fix the grepping for multifunction files?
>>
>
> No didn't try , as we dont have any examples at the moment, is this an open
> ticket #3
There is an open ticket. But I am confused. I thought this discussion
On Thursday 12 March 2009 23:26:23 Bill Hart wrote:
> Did you manage to fix the grepping for multifunction files?
>
No didn't try , as we dont have any examples at the moment, is this an open
ticket #3
> I think there are a number of issues that we should look at. We can't
> really use Torbjorn
Did you manage to fix the grepping for multifunction files?
I think there are a number of issues that we should look at. We can't
really use Torbjorn's patches for versions later than 4.2.1 because
they are designed to patch later versions of GMP. After such patches
are applied the license on tho
On Thursday 12 March 2009 23:13:31 Bill Hart wrote:
> The issue is when there are macros, say for mpn_add_n and mpn_sub_n in
> the same file. Configure doesn't handle that situation. It would have
> to expand the yasm macros out. I can't recall what the other issues
> were with using macros for mu
The issue is when there are macros, say for mpn_add_n and mpn_sub_n in
the same file. Configure doesn't handle that situation. It would have
to expand the yasm macros out. I can't recall what the other issues
were with using macros for multiple functions. I know more than I did
back then, both abo
On Mar 12, 10:53 pm, ja...@njkfrudils.plus.com wrote:
> On Thursday 12 March 2009 17:32:48 Bill Hart wrote:
>
> > That does indeed fix the issue. Thanks!
>
> > I'll wait for you to update the greps for multifunction files before
> > finishing testing on SkyNet.
>
> > I guess that will affect the
$tmp_field_name; \\" >>fat.h
> >> > done
> >> > echo " } while (0)" >>fat.h
> >> >
> >> > in configure.in.
> >> >
> >> > Any idea how I work around that gem of free software engineering?
>
OK, thanks.
2009/3/12 Jeff Gilchrist :
>
> On Thu, Mar 12, 2009 at 1:32 PM, Bill Hart
> wrote:
>
>> We still need to sort out Jeff's computer as well.
>
> Sorry, looks like a Windows -> Linux problem. I used TortoiseSVN in
> Windows to get the SVN code and then tried to use the same files in
>
On Thu, Mar 12, 2009 at 1:32 PM, Bill Hart wrote:
> We still need to sort out Jeff's computer as well.
Sorry, looks like a Windows -> Linux problem. I used TortoiseSVN in
Windows to get the SVN code and then tried to use the same files in
Linux to compile. So it might be a linefeed problem, b
_tn | tr '[A-Z]' '[a-z]'`
>> > echo " p->$tmp_field_name = vec.$tmp_field_name; \\" >>fat.h
>> > done
>> > echo " } while (0)" >>fat.h
>> >
>> > in configure.in.
>> >
>
7; '[a-z]'`
> > echo "p->$tmp_field_name = vec.$tmp_field_name; \\" >>fat.h
> > done
> > echo " } while (0)" >>fat.h
> >
> > in configure.in.
> >
> > Any idea how I work around that gem of free software
;>fat.h
>
> in configure.in.
>
> Any idea how I work around that gem of free software engineering?
>
> Bill.
>
> 2009/3/12 :
> > -- Forwarded message --
> > From: ja...@njkfrudils.plus.com
> > To: mpir-de...@googlegroups.com
> > D
gt;>fat.h
done
echo " } while (0)" >>fat.h
in configure.in.
Any idea how I work around that gem of free software engineering?
Bill.
2009/3/12 :
>
>
> >
>
>
> -- Forwarded message ------
> From: ja...@njkfrudils.plus.com
> To: mpir-d
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.
On Thursday 12 March 2009 16:02:50 Bill Hart wrote:
> Arghh!! Where on earth is this coming from:
>
> p->MUL_KaRaTSUBa_THRESHOLD = vec.MUL_KaRaTSUBa_THRESHOLD; \
> p->MUL_TOOM3_THRESHOLD = vec.MUL_TOOM3_THRESHOLD; \
> p->SQR_KaRaTSUBa_THRESHOLD = vec.SQR_KaRaTSUBa_THRESHOLD; \
> p->SQ
Arghh!! Where on earth is this coming from:
p->MUL_KaRaTSUBa_THRESHOLD = vec.MUL_KaRaTSUBa_THRESHOLD; \
p->MUL_TOOM3_THRESHOLD = vec.MUL_TOOM3_THRESHOLD; \
p->SQR_KaRaTSUBa_THRESHOLD = vec.SQR_KaRaTSUBa_THRESHOLD; \
p->SQR_TOOM3_THRESHOLD = vec.SQR_TOOM3_THRESHOLD;
I've changed abou
Great page, but not nearly enough on tr.
2009/3/12 :
>
>
> here a page on portable shell programming
>
> http://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Usual-Tools
>
>
>
>
> On Thursday 12 March 2009 14:53:52 Bill Hart wrote:
>> It looks like BSD systems will break if t
here a page on portable shell programming
http://www.gnu.org/software/autoconf/manual/autoconf.html#Limitations-of-Usual-Tools
On Thursday 12 March 2009 14:53:52 Bill Hart wrote:
> It looks like BSD systems will break if the brackets are inserted.
>
> Bill.
>
> 2009/3/12 :
> > On Thursday
It looks like BSD systems will break if the brackets are inserted.
Bill.
2009/3/12 :
>
> On Thursday 12 March 2009 14:43:00 Bill Hart wrote:
>> This seems to work:
>>
>> echo AHELLO | tr [A-Z] [a-z]
>
> http://www.opengroup.org/onlinepubs/009695399/utilities/tr.html>
>
> recomends also quoting
On Thursday 12 March 2009 14:43:00 Bill Hart wrote:
> This seems to work:
>
> echo AHELLO | tr [A-Z] [a-z]
http://www.opengroup.org/onlinepubs/009695399/utilities/tr.html>
recomends also quoting the expressions
> both on linux and Sun.
>
> Bill.
>
> 2009/3/12 :
> > There was a few other tran
This seems to work:
echo AHELLO | tr [A-Z] [a-z]
both on linux and Sun.
Bill.
2009/3/12 :
>
>
> There was a few other translates in there as well
>
> On Thursday 12 March 2009 14:37:08 Bill Hart wrote:
>> Yes, I do believe this is the issue. It is only replacing capital A
>> with little a an
There was a few other translates in there as well
On Thursday 12 March 2009 14:37:08 Bill Hart wrote:
> Yes, I do believe this is the issue. It is only replacing capital A
> with little a and ignoring the other letters. Here is the result after
> making the change you suggest:
>
> /bin/bash ../l
Yes, I do believe this is the issue. It is only replacing capital A
with little a and ignoring the other letters. Here is the result after
making the change you suggest:
/bin/bash ../libtool --tag=CC --mode=compile gcc -std=gnu99
-DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`e
On Wednesday 11 March 2009 15:26:13 Bill Hart wrote:
> The issue does not occur on sage.math. Thus we can infer:
>
> * It isn't a core2 issue
> * It isn't a gcc issue
> * It isn't a Sun CC issue
>
> The only thing which seems different about that machine is that it is
> a Sun. I'm betting it is so
The issue does not occur on sage.math. Thus we can infer:
* It isn't a core2 issue
* It isn't a gcc issue
* It isn't a Sun CC issue
The only thing which seems different about that machine is that it is
a Sun. I'm betting it is some kind of preprocessing/scripting issue
due to different tools on
The yasm failures look like this:
Test nasm_test: ./out_test.sh: test: argument expected
FAIL: modules/parsers/nasm/tests/nasm_test.sh
Test nasm_test: ./out_test.sh: test: argument expected
FAIL: modules/parsers/nasm/tests/worphan/nasm_worphan_test.sh
Test nasmpp_test: ./out_test.sh: test: argume
The error is the same with Sun cc:
cc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I..
-DOPERATION_fat_redc_basecase -m64 -xO4 -c fat_redc_basecase.c -o
fat_redc_basecase.o >/dev/null 2>&1
/bin/bash ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I.
-I. -I.. -D__GMP_WITHIN_GMP -I..
I managed to tease out what kind of machine it is, and it is
definitely a Core2. No idea why it only has an amd directory for
libraries.
Anyhow, here is the failure with gcc -4.3.3 on fulvia:
/bin/bash ../libtool --tag=CC --mode=compile gcc -std=gnu99
-DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_
Config.guess identifies fulvia as a core2, yet the only gcc library
files that seem to be present for 64 bit are labelled amd64. That is
probably something to do with the failures.
I'm unable to get cat /proc/cpuinfo being a Sun, but here is the
result of uname -a
SunOS fulvia 5.10 Generic_12712
I did make clean. I just tried it again and it definitely passes on varro.
I don't think I'd be too worried about it. The issues on fulvia are
certainly worth worrying about. I'll paste the failures here in a few
hours (I'm tied up with something else right now).
Bill.
2009/3/11 :
>
> On Wedne
On Wednesday 11 March 2009 03:36:15 Bill Hart wrote:
> Here are the results of tests so far on SkyNet:
>
> eno - 4.3.0 n f / 4.3.3 n f
> cicero 4.3.0 n f
> cato 4.1.2 n
> varro A 4.0.1 n f / 4.3.3 n f
> fulvia 4.3.3 n * *** / S n ** *** ;
> menas 4.2.1 n f / 4.3.3 n f
> iras 4.1.2 n / 4.3.3 n
> c
On Wednesday 11 March 2009 03:48:19 ja...@njkfrudils.plus.com wrote:
> On Wednesday 11 March 2009 03:36:15 Bill Hart wrote:
> > Here are the results of tests so far on SkyNet:
> >
> > eno - 4.3.0 n f / 4.3.3 n f
> > cicero 4.3.0 n f
> > cato 4.1.2 n
> > varro A 4.0.1 n f / 4.3.3 n f
> > fulvia 4.3
On Wednesday 11 March 2009 03:36:15 Bill Hart wrote:
> Here are the results of tests so far on SkyNet:
>
> eno - 4.3.0 n f / 4.3.3 n f
> cicero 4.3.0 n f
> cato 4.1.2 n
> varro A 4.0.1 n f / 4.3.3 n f
> fulvia 4.3.3 n * *** / S n ** *** ;
> menas 4.2.1 n f / 4.3.3 n f
> iras 4.1.2 n / 4.3.3 n
> c
45 matches
Mail list logo
