MPIR v2.3

[Jason]

Hi

Now that v2.2 is almost ready for release (just waiting to test on a few more
machines ie gcc-farm , should be done by mid next week) , we should think
about what should go in to v2.3 , here are some of the things I hope to do.

1) Quicker release , say no more than 3 months until release (2.1 to 2.2 took
5.5 months.

2) Try the latest autotools to see if they fix a Jeff's gcc-3.4.6 problem and
the MinGW64 c++ shared make check fail

3) General clean-up , an endless task...

4) New assembler code(and some related C code) for x86_64 (*)

5) Try to get a complete list of cpu types for cpuid.c

6) Command line MSVC build

7) Python code for cpu path selection , to share between autotools and MSVC ,
MSVC builds would then only need one project.

8) Some of the changes we have made , have not been finished , finish them. (*)

9) Split configure into two , ie standard and MPIR specific , should make the
maintenance easier , this is fairly ambitious :) Actually I can't see this
happening at all (*)

10) When we update stuff , there are many places where you have to fill in the
same info , make it automatic (autotools can do this , it's just not been set
up that way) (*)

11) Update the test scripts to try make install(local install) so we can build
mpfr,mpc,pari,flint,(sage is too big) against the library

12) try autoupdate: which updates configure.in to the latest spec , there
appear to be some windows dll updates.

13) Clean up the ABI selection code

(*) is from the list of things to do in v2.2 that did not get done.

Any other suggestions? , or volunteers?

Jason

[Bill Hart]

It is very likely that my new FFT will be done within 3 months. It
will be BSD licensed for obvious reasons. But this would be
compatible, so you could use it. That would allow a lot of
improvements to the asymptotically fast division code. But I won't get
to doing those as well in the next 3 months.

The new FFT would hopefully provide a speedup for all asymptotically
fast operations anyway even without rewriting any of them to make use
of the new interface that will be provided.

Bill.

> --
> You received this message because you are subscribed to the Google Groups "mpir-devel" group.
> To post to this group, send email to mpir-...@googlegroups.com.
> To unsubscribe from this group, send email to mpir-devel+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
>
>

[Jason]

On Friday 19 November 2010 13:23:28 Bill Hart wrote:
> It is very likely that my new FFT will be done within 3 months. It
> will be BSD licensed for obvious reasons. But this would be
> compatible, so you could use it. That would allow a lot of
> improvements to the asymptotically fast division code. But I won't get
> to doing those as well in the next 3 months.
>
> The new FFT would hopefully provide a speedup for all asymptotically
> fast operations anyway even without rewriting any of them to make use
> of the new interface that will be provided.
>

Nice , point out any needed mpn_linear ops that could benefit from asm

[Bill Hart]

There are many. I'll post a list when I find some time.

[Jason]

Whoops , posted this in reply to someone else....

One other thing to consider is that we could take advantage of more unrolling
for functions that are only used for FFT , and even better if the lengths are
always a multiple of the unroll factor , then we dont have to bother with
feedin/wind-down or jump-in code.

Jason

[Jason]

Some more idea's

14) There is some asm code out (for non-x86*) there which we can use as it is
under a compatible license

15) Compilers are far more "intelligent" , the macro mul_ppmm is almost
certainly faster in C (since gcc-3.4), perhaps the same for divide , although
for add_ssaaaa I not at all sure , use intrinsic's and ignore crap code from
old compilers.

Jason

[Jason]

Some more

16) Whoops, Bill's new FFT , of which I had completely forgotten about :( ,
Dam'it I going to have to deliver on my small size improvements of perhaps 10%

17) Use emulators for different cpu's (although whether they can trap on
unknown opcode's ? (but not a large problem in my experience)) and OS'es ,
this I think will mainly expose autotools problems (by us or FSF)

Trying to think of future problems (ie the ones that will never bite)(and it's
Friday night....)

Good Night...

Jason

[jason]

Hi

Just an update on where I think we will be heading for this release..

On Nov 19, 10:54 am, Jason <ja...@njkfrudils.plus.com> wrote:
> Hi
>
> Now that v2.2 is almost ready for release (just waiting to test on a few more
> machines ie gcc-farm , should be done by mid next week) , we should think
> about what should go in to v2.3 , here are some of the things I hope to do.
>
> 1) Quicker release , say no more than 3 months until release (2.1 to 2.2 took
> 5.5 months.
>

I'm thinking March 1st , with whatever has been done and tested

> 2) Try the latest autotools to see if they fix a Jeff's gcc-3.4.6 problem and
> the MinGW64 c++ shared make check fail
>

The latest autotools requires some changes to our makefiles etc ,
so....

> 3) General clean-up , an endless task...
>

On-going , just whatever gets done in the time

> 4) New assembler code(and some related C code) for x86_64 (*)
>

On-going , just whatever gets done in the time

> 5) Try to get a complete list of cpu types for cpuid.c
>

Can we get the information from here?

http://www.cpu-world.com/cgi-bin/CPUID.pl

> 6) Command line MSVC build
>

I cant see this happening in the time , although the building part in
fairly straight forward , we still have to get through the configure
part with MSVC. I think in the meantime we should fix the existing
batch scripts , mainly make check for dll's doesn't work( I expect
this is some trivial thing) , and make clean doesn't choose the right
sub-dirs(my knowledge of DOS batch language is not good enough)

> 7) Python code for cpu path selection , to share between autotools and MSVC ,
> MSVC builds would then only need one project.
>
> 8) Some of the changes we have made , have not been finished , finish them. (*)
>
> 9) Split configure into two , ie standard and MPIR specific , should make the
> maintenance easier , this is fairly ambitious :) Actually I can't see this
> happening at all (*)
>
> 10) When we update stuff , there are many places where you have to fill in the
> same info , make it automatic (autotools can do this , it's just not been set
> up that way) (*)
>

I just tried this and it didn't work , don't know why , however it
wouldn't work anyway for the mpn layer. At present when we add a mpn
function we have to remember to fill in the details in many places and
then run autotools , what I want to do is , we just write the function
and run our "mpirnew" script , this fills in all the correct details
in all the right places and runs autotools for us.I'm also thinking to
use this for new cpu types , fat fields , basically anything where the
details have to be entered in multiple places(or where we have
forgotten to enter it before)

[jason]

make check for build.vc9 is basically this

vcbuild mpir-tests.sln "Release|x64"

now this work for a static/lib build OK , but when I build a dll/
shared and run the above command I get this error

Build started: Project: mpn.mullow_basecase, Configuration: Release|
x64
Linking...
LINK : fatal error LNK1181: cannot open input file 'C:\cygwin\home\root
\mpir\tr
nk\build.vc9\lib\x64\Release\mpir.lib'
Build log was saved at "file://c:\cygwin\home\root\mpir\trunk
\build.vc9\mpir-te
ts\mpn.mullow_basecase\x64\Release\BuildLog.htm"
mpn.mullow_basecase - 1 error(s), 0 warning(s)

It's looks like it's still trying to use the static build , are you
ment to pass a parameter saying which build you want to test?

Thanks
Jason

> > Jason- Hide quoted text -
>
> - Show quoted text -

[jason]

On Dec 22, 11:32 am, jason <ja...@njkfrudils.plus.com> wrote:
> On Dec 20, 6:43 pm, jason <ja...@njkfrudils.plus.com> wrote:
>
>
>
>
>
> > Hi
>
> > Just an update on where I think we will be heading for this release..
>
> > On Nov 19, 10:54 am, Jason <ja...@njkfrudils.plus.com> wrote:
>
> > > Hi
>
> > > Now that v2.2 is almost ready for release (just waiting to test on a few more
> > > machines ie gcc-farm , should be done by mid next week) , we should think
> > > about what should go in to v2.3 , here are some of the things I hope to do.
>
> > > 1) Quicker release , say no more than 3 months until release (2.1 to 2.2 took
> > > 5.5 months.
>
> > I'm thinking March 1st , with whatever has been done and tested
>
> > > 2) Try the latest autotools to see if they fix a Jeff's gcc-3.4.6 problem and
> > > the MinGW64 c++ shared make check fail
>

I think so far no-one else but me has got the MinGW64 build to work
properly , I know Jeff said he could compile it but not run make
check. Brian , didn't you have MinGW64 installed and working on one of
your machines?

> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -

[Cactus]

On Dec 22, 11:32 am, jason <ja...@njkfrudils.plus.com> wrote:

Hi Jason

The post build step in postbuild.bat copies a file into the mpir-tests
called test-config.props that sets up the configuration that is to be
tested.

The line is:

copy mpir-tests\%extn%-%cnf%-config.props mpir-tests\test-
config.props

So for the DLL release build the file 'dll-release-config.props should
get copied into test-config.props

So you could delete the test-config.props file, run an MPIR DLL
release build and check that this file is being written and check
which file has been copied to it.

Brian

[Cactus]

Hi Jason,

I do have mingw64 installed and it works fine via the CodeBlocks IDE.

But it won't build mpir, possibly because I have mingw64 installed in
the correct Windows installation directory (Program Files) that has a
space in its name.

Brian

[Cactus]

I have just realised that you are talking about the vc9 build, not the
vc10 one.

I am not sure but I don't think I ever got the tests to work with the
DLL builds in vc9.

Brian

[Jason]

Ah , OK , I thought it was just a missing DLL__EXPORT in gmp-h that was
stopping make check on dll's

Thanks
Jason

[Jason]

As far as I know the space issue only matters if it is in the mpir build path
, I dont think it matters where mingw64 is installed , and then only for make
check , the build worked OK for me with as space in the path. This was also
with the old autotools , perhaps with the new one they have fixed it ? I'll try
it now

Thanks
Jason

[Jason]

Yeah , the build works fine with a space in the path , it's just make check
that fails. There is a later autotools which I can try once we have fixed our
makefiles to comply with the latest spec

Jason

> Thanks
> Jason

[Cactus]

Thanks Jason - I can certainly give it another try.

What directory do I need to be in and what are the 'magic words'?

Does the shell matter?

Brian

[Jason]

Yep , use the MSYS shell and cd to mpir/trunk say and just to be on the safe
side
mkdir briantest
cd briantest

../configure
make
make check

for a native static build , make distclean to clean up

../configure --disable-static --enable-shared
and/or
../configure --build=netburst-w64-mingw32
to pretend we are a netburst (use "none" for a C build)
or
../configure --enable-fat
--enable-assert is another good option

Jason

[Cactus]

Hi Jason

The configure step ended with:

cat: mpn/x86_64_divrem_euclidean_qr_1.as: No such file or directory

which looks like a bad concatenation of a directory and file name.

Brian

[Cactus]

It didn't find Python either - I have Python 2.7 (win32) and Python
3.2 (x64) installed.

Brian

[Jason]

Just ignore the error and continue building , this is meant for a fat build
but it does it unconditionally , I'll change it , mine builds so fast I never
saw it :)

>
> It didn't find Python either - I have Python 2.7 (win32) and Python
> 3.2 (x64) installed.
>
> Brian

Yeah , I forgot about that , linux doesn't find it either but we dont use it ,
so we can ignore that warning.

[Cactus]

make ends with:

make[2]: *** [clears.lo] Error 1
make[2]: Leaving directory `/c/users/brian gladman/my documents/visual
studio 20
10/projects/mpir/brgtest/mpz'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/c/users/brian gladman/my documents/visual
studio 20
10/projects/mpir/brgtest'
make: *** [all] Error 2

Brian

[Jason]

Could you send a bit more context , ie some lines that preceded this

cheers
Jason

[Cactus]

Brian Gladman@BIGSLAVE /c/users/brian gladman/my documents/visual
studio 2010/pr
ojects/mpir/brgtest
$ make >make.log
make[2]: Circular ../../yasm/x86insn_nasm.gperf <- ../../yasm/
x86insn_nasm.gperf
dependency dropped.
make[2]: Circular ../../yasm/x86insn_gas.gperf <- ../../yasm/
x86insn_gas.gperf d
ependency dropped.
make[4]: Circular ../../yasm/x86insn_nasm.gperf <- ../../yasm/
x86insn_nasm.gperf
dependency dropped.
make[4]: Circular ../../yasm/x86insn_gas.gperf <- ../../yasm/
x86insn_gas.gperf d
ependency dropped.
../../yasm/modules/objfmts/elf/elf.c: In function 'elf_set_arch':
../../yasm/modules/objfmts/elf/elf.c:102: warning: passing argument 3
of 'yasm_s
ymrec_add_data' discards qualifiers from pointer target type
../../yasm/libyasm/symrec.h:425: note: expected 'void *' but argument
is of type
'const struct elf_machine_ssym * const'
../../yasm/libyasm/file.c: In function 'yasm__createpath_common':
../../yasm/libyasm/file.c:496: warning: implicit declaration of
function '_mkdir
'
In file included from ../../mpz/clears.c:25:
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.5/include/varargs.h:
4:2: error:
#error "GCC no longer implements <varargs.h>."
c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.5/include/varargs.h:
5:2: error:
#error "Revise your code to use <stdarg.h>."
../../mpz/clears.c: In function '__gmpz_clears':
../../mpz/clears.c:43: warning: implicit declaration of function
'va_start'
../../mpz/clears.c:53: warning: implicit declaration of function
'va_arg'
../../mpz/clears.c:53: error: expected expression before 'mpz_ptr'
../../mpz/clears.c:55: warning: implicit declaration of function
'va_end'

make[2]: *** [clears.lo] Error 1

make[1]: *** [all-recursive] Error 1

make: *** [all] Error 2

I have the make.log file as well but it doesn't contain any error
messages.

The mpn and mpz directories in brgtest end up with *.obj files in them
but the others are empty.

Brian

[Cactus]

> ...
>
> read more »

I've uploaded the make log file to the files area in case it might
give you a clue about whta is wrong.

Brian

[jason]

On linux and on my MinGW64 in config.h I have

/* Define to 1 if <stdarg.h> exists and works */
#define HAVE_STDARG 1

you must not have this , either you dont have it or the autotools test
for it fails for some reason on your system.
The varargs.h is an old fallback which is no longer supported by GCC

[Cactus]

> ...
>
> read more »

Thanks for the help.

It seems that there are two variants of mingw64 - a prefixed or a non-
prefixed version.

My mingw64 directory structure is:

bin <<< compilers here
include <<< only external headers here
lib
x86_64-w64-mingw32
bin
include <<< standard header files here
lib

This is 'out of the box' and I have no idea why the compilers are in
one place and the headers in another.

But this might be why the MPIR build is missing the headers.

Brian

[Jason]

> > 10) When we update stuff , there are many places where you have to fill
> > in the same info , make it automatic (autotools can do this , it's just
> > not been set up that way) (*)
>
> I just tried this and it didn't work , don't know why , however it
> wouldn't work anyway for the mpn layer. At present when we add a mpn
> function we have to remember to fill in the details in many places and
> then run autotools , what I want to do is , we just write the function
> and run our "mpirnew" script , this fills in all the correct details
> in all the right places and runs autotools for us.I'm also thinking to
> use this for new cpu types , fat fields , basically anything where the
> details have to be entered in multiple places(or where we have
> forgotten to enter it before)
>

The script devel/regen fills in some of this information for you , at the
moment it works for mpz mpz mpq printf scanf and it fills in the Makefile.am's
When doing this I noticed we were missing an entry for mpf/clears in the
Makefile.am , this is the kind of thing we dont have to worry about any more :)

Jason

[Cactus]

I tried a mingw64 build of MPIR on another machine but it bowed out
even earlier:

$ ../configure
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of
Makefiles... no
checking ABI=32
checking compiler gcc -m32 -O2 -fomit-frame-pointer ... no
checking compiler gcc -O2 -fomit-frame-pointer ... no
checking compiler icc -no-gcc ... no
checking compiler cc -O ... no
configure: error: could not find a working compiler, see config.log
for details

It didn't even find the mingw64 installation :-(

Brian

[Jason]

Yeah , it didn't recognize it's 64 bit , the part of config.guess is a compile
time test of this

main(){
#ifdef _WIN64
printf("-w64-mingw32\n");
#endif
return 0;}

It looks like there is no compiler in path , you could try
CC=pathandexefor64gcc

There seems to be many different ways that mingw64 can be/has been installed ,
I was thinking of supplying a zip file with a known working config of Mingw64 or
at least until it settles down into a known standard configuration. I had to
rename my gcc executibles , but I didn't adjust the environment to fit mpir.

Jason

[Jason]

Before we can do the same for the mpn functions , we need to split up the C
files so that we only have one function per file.I'll get started on that along
with re-doing the nehalem timings now we have accurate measurements. Brian as
we split the files we will need to adjust the MSVC build to follow.I'll post
each change.

Jason

[Jason]

Hi

I've split the multifunction file popham.* into popcount.* and hamdist.* as
part of the process of one function=one file , I havent done the build.vc*
directory's or the three files below(as I'm not familiar with the YASM syntax)

./mpn/x86w/pentium4/mmx/popham.asm
./mpn/x86w/p6/mmx/popham.asm
./mpn/x86w/p6/p3mmx/popham.asm

Jason

[Jason]

These multifunction files have also now been removed and replaced with separate
files

lorrshift
aorslsh1_n
rsh1aors_n
aors_err?_n

There is nothing to do for windows for the above functions

Jason

[Jason]

aors_n.* has been done except for the file

./mpn/x86w/aors_n.asm

and the directorys build.vc*

aorsmul_1.* has been done except for the files

./mpn/x86w/aorsmul_1.asm
./mpn/x86w/p6/aorsmul_1.asm

and the directorys build.vc*

Jason

[Jason]

The last lot in the mpn directory have now been done ie logops.* except for
the build.vc* directorys

I'll clear up the mulfunction prologue code and after that we will have none
and will not be able to use multifunction files in then "build". NOTE: We can
still use them , but we have to do it manually ie
Someone writes a multifunction files as before , say aors_n.asm , then all we
have to do is
cp aors_n.asm add_n.asm
mv aors_n.asm sub_n.asm

and prepend
define(OPERATION_add_n,1) to add_n.asm
and
define(OPERATION_sub_n,1) to sub_n.asm

Thats it.
We could automate this in the devel/regen script , but its probably not worth
it as so few files can take advantage.

Jason

[Cactus]

Hi All,

Sadly we have not had any volunteers for maintaining the Visual Studio
win32 builds so, either I will have to make these changes or we will
have to give up win32 builds using Visual Studio.

The changes Jason is making are valuable steps towards easier future
builds so they would provide a basis for easier maintenance of the
win32 Visual Studio builds in future. If future Visual Studio support
for win32 is needed it would hence make sense to add these changes.

But the lack of any volunteers for maintaining the Visual Studio win32
builds leads me to wonder whether adding these changes to Visual
Studio build is worth the quite considerable effort involved.

I am willing to put these changes into the Visual Studio 2010 builds
if enough people want them.

But they definitely will NOT go into the Visual Studio 2008 builds
(unless someone else does this).

Brian

[degski]

Hi Cactus,

> Visual Studio win32 builds

What do you mean with win32 builds? 32-bit or just any windows builds?

BR


degski

[Cactus]

The win32 builds are those that work on 32-bit versions of Windows.

The x64 versions are those that work with 64-bit versions of Windows -
these are fully supported in Visual Studio 2010.

Brian

[Cactus]

I have just added all the 'single file' changes to the MPIR SVN for
all Visual Studio 2010 build configurations (both win32 and x64).

The Visual Studio 2008 builds will now fail and I suggest that, unless
someone volunteers to maintain them, we now remove these from SVN and
subsequent MPIR releases.

Brian

[degski]

Hi Cactus,

Thanks for clarifying...

BR


degski

   Brian

--
You received this message because you are subscribed to the Google Groups "mpir-devel" group.
To post to this group, send email to mpir-...@googlegroups.com.
To unsubscribe from this group, send email to mpir-devel+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.

[Jason]

Hi

Yeah , I agree , if they dont work get rid of them , and if someone volunteers
we can easily put them back. Remember cygwin or Mingw32 can do 32bit builds if
you dont have Visual Studio 2010 , and except for gmp_printf(I think?) it is
easy to use with any MSVC . The adaptation of our autotools to use use MSVC is
fairly straight forward but it looks like I wont have the time to do it this
release (2.3) , the other quick way is to write a simple batch file to use
CL.EXE and LINK.EXE on a predetermined directory that has all the asm and C
files , it should be possible to knock one up in a few hours. And perhaps more
term , is to use a python? script to select cpu path that can be fed into a
single MSVC 2010 project , the maintaince of the MSVC builds would be greatly
reduced.

Jason

[Jason]

Hi

Approx March 1st was my plan for the release of the next MPIR 2.3 , that's in
about 2.5 weeks. I haven't done most of what I planed or wanted but I think a
regular(although not rigid) release schedule is important. What does everyone
else think ?

Bill , how's the new fft going?

Thanks
Jason

[Bill Hart]

I'm afraid I haven't gotten it done yet. I'm way behind. :-(

[Jason]

OK , as there isn't any code that we could get in with a slight delay on the
release date , we will stick with ~1st March, the next release is penned in
for 1st June.

There's a few little bits I can do between now and 1st March and I'd like to
get a few confirmations that MPIR does build on MINGW64 properly as detailed in
the other thread , also the Windows batch build , although as I only have
VS2008 I can't help with that one either.

Thanks
Jason

[jason]

On Feb 13, 8:06 am, Jason <ja...@njkfrudils.plus.com> wrote:
> OK , as there isn't any code that we could get in with a slight delay on the
> release date , we will stick with ~1st March, the next release is penned in
> for 1st June.
>
> There's a few little bits I can do between now and 1st March and I'd like to
> get a few confirmations that MPIR does build on MINGW64 properly as detailed in
> the other thread , also the Windows batch build , although as I only have
> VS2008 I can't help with that one either.
>
> Thanks
> Jason
>
> On Saturday 12 February 2011 23:04:49 Bill Hart wrote:
>
> > I'm afraid I haven't gotten it done yet. I'm way behind. :-(
>
> > On 12 February 2011 20:13, Jason <ja...@njkfrudils.plus.com> wrote:
> > > Hi
>
> > > Approx March 1st was my plan for the release of the next MPIR 2.3 ,
> > > that's in about 2.5 weeks. I haven't done most of what I planed or
> > > wanted but I think a regular(although not rigid) release schedule is
> > > important. What does everyone else think ?
>
> > > Bill , how's the new fft going?
>
> > > Thanks
> > > Jason
>

Hi

If we are going to release on March 1st which is tuesday next week
then we should really issue an RC1 by this wednesday , I can test on
all of skynet and gcc-farm in a day or two and this gives other people
just under a week to run tests.I have a few more bits of assembler I
can get in by this mon/tue , just some tweeks to existing code so
windows conversion should be fast and easy :) , although they can be
quite sensitive to the exact feedin code , so a straightforward
windows conversion may not show any benefit , or could even be slower.

Jason

[Jason]

Better make the cutoff tomorrow/monday for new code as all the x86_64 will need
re-tuning.

Jason

[Jason]

I've retuned all the x86_64 arch's , the only other one that has changed is
mips , which hopefully I can tune on the gcc-farm. Brian , I suppose you just
copy the linux params to windows?
We can then release an RC1 later today

Jason

[Jason]

I cant tune on gcc42 mips just like skynet's cato , so that's it , I believe I
can cook up an RC1 when the windows tuning params go in.

jason

[Cactus]

I have just benchmarked the new Linux tuning values for nehalem on
Windows against the one I am using and I get a 2% drop in performance.

So I don't propose to change what we now use for this processor.

As I have retired all my non nehalem machines, I can't directly test
the tuning on other processors. But unless we have evidence that the
current Windows tuning values need to be changed, I would be inclined
to leave them alone.

I have tested the new Windows assembler code for k8, core2 and nehalem
and all tests pass. The command line WIndows build is close to
working but MSBUILD doesn't run the final file copying phase
correctly.

Brian

[Jason]

OK

> As I have retired all my non nehalem machines, I can't directly test
> the tuning on other processors. But unless we have evidence that the
> current Windows tuning values need to be changed, I would be inclined
> to leave them alone.
>

OK

> I have tested the new Windows assembler code for k8, core2 and nehalem
> and all tests pass.

I can test netburst/penryn etc under a fake mingw64

> The command line WIndows build is close to
> working but MSBUILD doesn't run the final file copying phase
> correctly.
>

Shame , I'll spin a RC1 anyway , and if you manage to fix it we may have to run
a few tests again. I'm going to run our standard test suite on skynet/gcc-
farm/washington-cluster/mine and also try tests on available x64 machines

> Brian

[jason]

Just doing a few quick tests before RC1 , and we have broken the
cygwin build , it built OK about a week ago ,so it something recent ,
mpir-2.2 builds alright so it's not cygwin that broken.

/bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 -
DHAVE_CONFIG_H -I.
-I../../mpn -I.. -D__GMP_WITHIN_GMP -I../.. -DOPERATION_`echo fib2_ui
| sed 's/_
$//'` -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -c -o
fib2_ui.l
o fib2_ui.c
libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../mpn -I..
-D__GMP_W
ITHIN_GMP -I../.. -DOPERATION_fib2_ui -m32 -O2 -fomit-frame-pointer -
mtune=core2
-march=core2 -c fib2_ui.c -o fib2_ui.o
In file included from fib2_ui.c:26:
/usr/include/stdio.h:53: error: expected '=', ',', ';', 'asm' or
'__attribute__'
before 'fpos_t'
In file included from fib2_ui.c:26:
/usr/include/stdio.h:210: error: expected declaration specifiers or
'...' before
'fpos_t'
/usr/include/stdio.h:216: error: expected ';', ',' or ')' before '*'
token
/usr/include/stdio.h:379: error: expected declaration specifiers or
'...' before
'fpos_t'
/usr/include/stdio.h:380: error: expected ';', ',' or ')' before '*'
token
/usr/include/stdio.h:535: error: expected declaration specifiers or
'...' before
'fpos_t'
/usr/include/stdio.h:540: error: expected declaration specifiers or
'...' before
'fpos_t'
make[2]: *** [fib2_ui.lo] Error 1
make[2]: Leaving directory `/home/root/mpir/trunk/cygwin/mpn'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/home/root/mpir/trunk/cygwin'

[jason]

It doesn't affect mingw32/64 , so my guess is that some MSVC change just
happens to bite cygwin as well

Jason

[Cactus]

There are several configuration changes that I have introduced for the
first time as a result of the recent MSVC inclusion of stdint.h.

The keyword 'volatile' used to be undefined but is now left alone.
And the following defines have been added:

#define HAVE_INTMAX_T 1
#define HAVE_PTRDIFF_T 1
#define HAVE_UINT_LEAST32_T 1
#define NPRINTF_J 1
#define NPRINTF_T 1

The last two are to control the interface between MPIR and MPFR and
should not cause any issues unless there is a name conflict.

Does cygwin support all of the types mentioned?

Brian

[Cactus]

Ignore this - I assume that the Cygwin build makes no use of the MSVC
build components apart from the assembler files. If this is correct,
it is hard to see what has caused the build to fail.

Brian

[jason]

I did a binary search from rev 3260 to rev 3370 and all the rev's pass ,
WHAT! , it's fine now , I suspect it's a problem with the cygwin svn not
updating things properly. If I can reproduce it I'll save a copy so I can
see what is going on. Anyway I do a RC1 in the next hour or two.

Thanks
Jason

Brian

--

[Jason]

eno on skynet has had it's autotools upgraded and our Makefiles are not yet
compatible, I dont know how much work this will involve , but I doubt it's
difficult , although I would like to take a few weeks testing it , too see if it
throws up any wobbles. I suggest we release 2.3.0 with the current autotools ,
which we know is stable , and after a month or so (or 2.4.0) we can upgrade to
the latest autotools. Current autotools is available on my machine and I
suppose another on skynet (sage cluster is too old).

Comments ?

Thanks
Jason

[Jason]

skynet machines are either the old version or the newer version for autotools
, so my machine has the only "current" version.

> Thanks
> Jason

[jason]

That is strange , cygwin on vista 32 bit is OK on trunk , but cygwin
on vista 64 bit on trunk gives the error and cygwin on vista 64 bit on
mpir-2.2 is OK

On Feb 22, 3:53 pm, "jason" <ja...@njkfrudils.plus.com> wrote:

> Jason- Hide quoted text -
>
> - Show quoted text -