The apptests all pass in the technical sense on the gcc farm except for a mpfr
error on loulou.esiee.fr which is nothing to do with mpir , it's a missing
symbol probably fixed in a later release of mpfr . The apptest script need to
be updated so that we have proper passes and not technical ones(
mingw32 and mingw64 both pass mpir tests , the apptest scripts wont
even run yet so I'll have to do that later , only MSVC to do
MINGW32_NT-6.0 NEHALEM 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys
nehalem-pc-mingw32
gcc version 4.5.2 (GCC)
NEHALEM
PASSED configure CC=gcc.exe CXX=g++.exe
PASSED
exe!fft_truncate1_twiddle(ii=649f90, is=8, n=0, w=000100, t1=2ef878,
t2=2ef898, ws=1, r=0, c=0, rs=20, trunc=0) Line 113
exe!fft_truncate1_twiddle(ii=649f90, is=8, n=1, w=80, t1=2ef878,
t2=2ef898, ws=1, r=0, c=0, rs=10, trunc=0) Line 123
exe!fft_truncate1_twiddle(ii=649f90, is=8, n=
mul_mfa_truncate_sqrt2(r1=648810, i1=648090, n1=78, i2=648450, n2=78,
depth=7, w=1)
fft_mfa_truncate_sqrt2_outer(ii=649f90, n=80, w=1, t1=2ef878, t2=2ef898,
temp=2ef8b8, n1=8, trunc=100)
fft_truncate1_twiddle(ii=649f90, is=8, n=10, w= 8, t1=2ef878, t2=2ef898,
ws=1, r=0, c=0, rs=1, trunc=0)
fft_t
Oh sorry, I'm confused. Obviously trunc <= n is valid.
What we need though is the entire call trace that leads to that set of
params so we can see where the bug is. I am sure the bug is in my code, I'm
just not sure where.
Bill.
On Tuesday, 3 January 2012, Bill Hart wrote:
> Hi Brian,
>
> yes n
Hi Brian,
yes n=1, trunc=0 is an invalid set of params.
We must have trunc > n. So we need to track down where it is called from
to see how it's happening.
Bill.
On Tuesday, 3 January 2012, Cactus wrote:
> The twiddle code is entered with n = 0 from the above sequence both when
n = 1 and also
The twiddle code is entered with n = 0 from the above sequence both when n
= 1 and also when trunk = 0 and n = 0.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussion on the web visit
https://groups.google.com/d
This is one sequence IN fft_mfa_truncate_sqrt2.c that ends with entry to
the failing code with n = 0.
void fft_truncate1_twiddle(mp_limb_t ** ii, mp_size_t is,
mp_size_t n, mp_bitcnt_t w, mp_limb_t ** t1, mp_limb_t ** t2,
mp_size_t ws, mp_size_t r, mp_size_t c, mp_size_t rs, mp_size_t
One possibility is that in t-mul_mfa_truncate_sqrt2 the top limbs of
the integers being multiplied are zero, so that ultimately trunc <=
2*n which would cause the problem.
Bill.
On 3 January 2012 15:39, Bill Hart wrote:
> Hi Brian,
>
> I am not sure how n ever gets to be zero. It should start as
Hi Brian,
I am not sure how n ever gets to be zero. It should start as a power
of 2 and always remain thus. Probably the bug is elsewhere.
Bill.
On 3 January 2012 13:42, Cactus wrote:
> I think I have found the problem.
>
> Both ifft_radix2_twiddle and ifft_radix2_twiddle don't guard against e
I think I have found the problem.
Both fft_radix2_twiddle and ifft_radix2_twiddle don't guard against entry
with n = 0. I changed the first part of both routines according to the
template:
if (n < 2)
{
mp_size_t tw1, tw2;
tw1 = r*c;
tw2 = tw1 + rs*c;
if(n)
I think I have found the problem.
Both ifft_radix2_twiddle and ifft_radix2_twiddle don't guard against entry
with n = 0. I changed the first part of both routines according to the
template:
if (n < 2)
{
mp_size_t tw1, tw2;
tw1 = r*c;
tw2 = tw1 + rs*c;
if(n)
Cygwin passes mpir tests
CYGWIN_NT-6.0-WOW64 nehalem 1.7.9(0.237/5/3) 2011-03-29 10:10 i686
Cygwin
nehalem-pc-cygwin
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
gcc version 4.5.3 (GCC)
nehalem
PASSED configure CC=cc-3.exe CXX=c++-3.exe
PASSED configure CC=cc-3.exe CXX=c++-
All mpir tests pass on the gcc farm , I'l try the apptests on the farm now
Linux gcc17 2.6.26-2-amd64 #1 SMP Thu Nov 25 04:30:55 UTC 2010 x86_64 GNU/Linux
k10-unknown-linux-gnu
gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)
gcc17
PASSED configure CC=gcc-4.1
PASSED configure CC=gcc
On 3 January 2012 10:00, Cactus wrote:
> Thanks Bill,
>
> So the test failure matters - I was hoping that it didn't :-)
>
> My laptop, which I am using right now, has 4GB of RAM - I am not clear
> whether it is the stack or the heap that overflows but I suspect the former.
This shouldn't be a pro
Thanks Bill,
So the test failure matters - I was hoping that it didn't :-)
My laptop, which I am using right now, has 4GB of RAM - I am not clear
whether it is the stack or the heap that overflows but I suspect the former.
On another issue, how do I actually integrate the new FFT with MPIR?
Hi Brian,
you are absolutely right. I had completely forgotten about the
function. I renamed a whole pile of others that were called twiddle,
but I forgot that these still existed. It's ok though, that is what I
intended.
Bill.
On 3 January 2012 08:16, Cactus wrote:
> I am using the version you
I am using the version you refer to above.
As far as I can see, the test t-mul_mfa_truncate_sqrt2 does end up
calling fft_radix2_twiddle via this call sequence:
mul_mfa_truncate_sqrt2(r1, i1, int_limbs, i2, int_limbs, depth, w);
fft_mfa_truncate_sqrt2_outer(ii, n, w, &t1, &t2, &s1, sqrt,
18 matches
Mail list logo
