Command-line options of gp2c

Here is a brief description of the main options of gp2c, which can be seen with ./gp2c -h.

In Section 2.1 we saw how to use the -g option.

• -g tells gp2c to generate gerepile calls to clean up the PARI stack and reduce memory usage. You will probably need this option, although the C code will be easier to read or hand-edit without it.

• -ofile tells gp2c to write the generated C file to the file file instead of the standard output.

• -iN allows you to change the indentation of the generated C file. So if you want 4 spaces, just use the -i4 option with gp2c. The default is 2.

• -W is useful for debugging the .gp file, in the sense that it detects if some local variable is undeclared. For example, if the file algorithm.gp has a routine like

  radical(x)=F=factor(x)[,1];prod(i=1,length(F),F[i])
  

  The variable 'F' is undeclared in this routine, so when running gp2c with the -W option it prints

  Warning:algorithm.gp:1:variable undeclared F

  At present, an undeclared variable is taken to be a "formal variable" for polynomials by gp2c, so do not declare it if that is what you intend. For example in pol(a,b,c)=a*x^2+b*x+c you must not declare 'x' since it stands for the formal variable 'x.

• -pprefix A problem with C is that it is subject to name clashes, i.e., if a GP variable in your routine has the same name as a C symbol in the pari library, the compiler will report strange errors. So this option changes ALL user variables and user routine names by adding a prefix prefix to them. For example the GP routine add(x,y) with -pmy_ will become the C function my_add(x,y).

  Try this option each time the compiler fails to compile gp2c output to see if there is a name conflict. If this is the case, change the name in your GP script. It may be difficult to find conflicting names if your compiler is not verbose enough and if you are not familiar with the PARI code and C in general.

  Example of conflicting names are top,bot,prec,un, but there are thousands of others and they may be system-dependent.

• -ssuffix: Add suffix to the names of the installed functions under GP. This is to avoid clashes with the original GP script. For example, if you want to compare timings you may want to use the option -s_c This does not affect the C code, only the install commands.

• -S: Assume strict prototypes for functions. This means that you have declared all the local variables with local and not as parameters. Also, when a parameter is not mandatory, a default value must be assigned to it in the declaration, like for 'flag' in

  test(data,flag=0)={CODE}
  

  This does not affect the C code, only the install commands.

• -h gives the help.

• -v gives the gp2c version.

• -l prints a list of all the GP functions known by the compiler. So if a routine contains a GP routine not on this list, gp2c will show an error when trying to translate it. For example the routine forvec is not yet implemented, so you should not use it.

  Reasons why a GP function may not be known by the compiler are:

  • The function is not part of the PARI library. See Section 4.3

  • You use the old PARI 1.39 function names instead of the new ones. gp2c currently does not know about the 'compat' default. Use whatnow under GP to get the current name. For example, mod() is now Mod().

  • You use a GP function that does not exists in the GP version gp2c was compiled against. Please recompile gp2c against the PARI tree of this GP version.

    Normally no functions are added between two stable releases of GP with the same minor version number (say 2.1.1 and 2.1.2) so there is no need to recompile gp2c when you upgrade. But if you use the developement versions, you need to recompile. Also some new developement versions may break old versions of gp2c, so upgrade gp2c at the same time.

    However, if you want to compile scripts which do not use the new functions, you do not need to recompile. Note that you may use the GP environnement variables to tell gp2c-run which GP to use.

  • -t Output the table of types known to the compiler, see Section 3.