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, intnum, prodinf, solve, sumalt, suminf, sumpos and kill, trap, plot, ploth, plotrecth. Also forvec is only supported with GP 2.2.8 and later.
Some functions are passed to GP by gp2c-run at start-up (using the GP; syntax) instead of being translated in C: install and addhelp. In practice, they can be considered as supported.
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, default, extern, input, quit, read, system, whatnow.
When using PARI 2.1, the following functions are implemented via eval, so are slow and ugly: write, write1, writetex, printp, printp1, printtex. They are properly supported by PARI 2.2.7 and above.
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 4.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.