It looks like it does work if I increase the stack. With binary splitting I determined that it fails with 24,183,000 bytes but succeeds with 24,184,000 bytes. That's a lot of memory for this calculation, but admittedly a pretty small amount in total.

I turned on \gm4 and gp entered an infinite out of memory loop (Ctrl+C killed the process).

I was not able to reproduce the results with -f, even at the minimum stack size of 500,032. Maybe this means this is a non-issue?

Charles Greathouse
Analyst/Programmer
Case Western Reserve University

On Mon, Oct 14, 2013 at 6:18 PM, Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> wrote:

On Mon, Oct 14, 2013 at 04:24:39PM -0400, Charles Greathouse wrote:
> Package: pari
> Version: 2.6.1
>
> > version() \\ Windows Vista, 32-bit
> %1 = [2, 6, 1, "git-821079b"]
> > issquarefree(4294967298)
> *** at top-level: issquarefree(4294967
> *** ^--------------------
> *** issquarefree: the PARI stack overflows !
> current stack size: 20000000 (19.073 Mbytes)
> [hint] you can increase GP stack with allocatemem()
>
> *** Break loop: type 'break' to go back to GP prompt
>
> I do not encounter the same problem on [2, 5, 4, "git-52bd53b"] running on
> 64-bit Linux. I don't yet know if this is a regression, a Windows-specific
> bug, or an architecture issue. I suspect it's the last since 4294967298 =
> 2^32 + 2. Possibly of note is its form, 6p with p = 715827883 prime.

I cannot reproduce this problem even running the same version under wine.
You have gprc.txt file. Could you retry with gp -f ?

Does it work if you increase the stack ?

Cheers,
Bill.