OK, then we do need a trace of the function calls and the parameters
that are passed for the failing test. Brian is probably right. It's
probably an n=0 or trunc=2*n or trunc=0 passed somewhere, or
something like that. I'm glad I left the code so that it doesn't deal
with these cases, as it may sh
On Saturday 21 January 2012 17:37:27 Jason wrote:
> On Saturday 21 January 2012 15:33:12 Cactus wrote:
> > The FFT tuning appears to work in Windows but if I turn on asserts I see
> > the same problem that Jason reported earlier.
> >
> > But I don't see the out of memory problem.
> >
> > Br
On Saturday 21 January 2012 15:33:12 Cactus wrote:
> The FFT tuning appears to work in Windows but if I turn on asserts I see
> the same problem that Jason reported earlier.
>
> But I don't see the out of memory problem.
>
> Brian
>
>
with asserts on it fails make check anyway , so it's
The FFT tuning appears to work in Windows but if I turn on asserts I see
the same problem that Jason reported earlier.
But I don't see the out of memory problem.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussion
The code was working ok in situ in flint so presumably the most recent bug
fixes also need to be propagated to the tuning code as well.
If that doesn't lead to the source of the problem then check that the
memory allocation, especially of tt is being done correctly.
Unfortunately I am not with my
On Friday 20 January 2012 02:43:11 jason wrote:
>
> On Jan 20, 1:07 am, Jason wrote:
> > On Thursday 19 January 2012 09:42:35 Jason wrote:
> >
> > > On Thursday 19 January 2012 09:32:02 Cactus wrote:
> > > > Thanks for the testing. You are right - the t-locale.c test failure is
> > > > not
> >
