Some GP functions are not available for C programs, so the compiler cannot handle them. If you use them you will get the infamous "unhandled letter in prototype" error. Sorry fo the inconvenience. These are direuler, forsubgroup, forvec, intnum, prodeuler, prodinf, solve, sumalt, suminf, sumpos and addhelp, kill, trap, plot, ploth, plotrecth.
Some functions are built-in in GP, and so are not available to libpari programs. So if you use them GP2C generate a program that need to run under GP, or with gp2c-run. Since the C prototype for those functions are not available, the C compiler will output a warning. This serves as a reminder of the problem. They are all the plotting functions and allocatemem, extern, input, quit, read, system, whatnow.
For the same reason the following functions are implemented via eval, so are slow and ugly: write, write1, writetex, printp, printp1, printtex.
Also some functions may compile fine but have a surprising behaviour in some
case. default, read, eval. This is because they may modify the state of
the GP interpretor, not of the compiled program. Please see
Section 3.4 for detail. For example
f(n)=eval("intnum(x=-1,1,sin(x)^n")
will not do
what you expect. Rewrite it as f(n)=eval(concat(["intnum(x=-1,1,sin(x)^",n,")"]))
.
The forstep function is supported when the step is a number. If it is a vector, you must add a tag :vec to make GP know about it like in
f(x)= { local(v); v=[2,4,6,6,6,6,6,2,4,6,6] forstep(y=7,x,v:vec,print(y)) }
This is not needed if the step is a vector or a variable of type vec, but is needed if the step is only an expression which evaluates to a vector.
There is little that can be done about these problems without changing PARI/GP itself.