October 2008 - Gpc

Inefficiency of `mod'
by Emil Jerabek 26 Oct '10

26 Oct '10

Hi, during some debugging I noticed that GPC generates very hairy code for the `mod' operator with signed arguments. A closer look revealed that the code contains a lot of branching on conditions which can be determined on compile time, and most surprisingly, the value of X mod Y is recomputed _twice_, if X is negative. (I've attached a commented assembler dump.) This may be partially a back-end problem (CSE?), but I feel there's something wrong in the relevant code in gpc-common.c (build_pascal_binary_op) as well. `exp1 mod exp2' gets translated into something like exp2 <= 0 ? error : exp1 >= 0 ? exp1 mod exp2 : ((-exp1) mod exp2) == 0 ? 0 : exp2 - (-exp1) mod exp2 This arranges that both arguments supplied to the "internal mod" are non-negative, but this information is not passed on -- the arguments are still declared as signed types, which apparently makes the back-end to produce the mess it does. I've done a little test: the following replacement for `mod', which differs from the built-in one essentially just by the type-casts to `Cardinal', inline operator xmod (X, Y: Integer) = Z: Integer; begin if Y <= 0 then RuntimeError (714); if X >= 0 then Z := Cardinal (X) mod Y else begin Z := Cardinal (-X) mod Y; if Z <> 0 then Z := Y - Z end end; indeed generates a better code, it measures about 15% faster for positive X and more than twice faster for negative X. YMMV. If this is possible in user code, it should work in the compiler internals as well :) The result type of the whole `mod' expression looks dubious too. IIUIC, `exp1 mod exp2' inherits the type of exp1. Now, the result of `mod' is guaranteed to be nonnegative and to fit in the type of exp2 (or more precisely, it is in 0 .. High (type of (exp2)) - 1), whereas it needn't have anything to do with the type of exp1: consider var X, Z: Integer; Y: LongInt; begin X := -8; Y := High (LongInt); Z := X mod Y { -> overflow } end Or am I missing something? Emil (BTW, where is fjf434c.pas?)

10 16

GPC support for AIX 6?
by Gert Doering 16 Feb '10

16 Feb '10

Hi Gnu Pascal list, we're currently using IBM's xpc pascal compiler on IBM AIX 5.3. New machines are being shipped with AIX 6, and IBM's xpc is no longer supported there - for the time being, it actuall works (the xpc frontend generated intermediate code, and the second stage compiler still groks it). Management is not happy about this, as it might break any day, and I have been asked to "provide GPC" on AIX 6. Googling seems to suggest that the earliest release of GCC to work on AIX 6 is gcc 4.2.4 This mailing list's archive suggests that GPC and GCC 4.2 do not yet work together, due to larger efforts required due to backend changes (Waldek's mail from March 12, 2008). I reported this to management ("there is no GPC on AIX 6"), and they came back with the question "if we pay one of the GPC developers to do a GPC port to a recent GCC, to support AIX 6, how much would that cost?". Here we go - I'm posing this question to you. Is one of you capable and willing to make GPC work on AIX 6? And if yes, what would your conditions be (estimated time to do this, estimated costs)? (I can't promise anything, but will report back to management and they will decide...) thanks, gert -- Gert Doering gd(a)medat.de MEDAT Muenchen Tel: 089/126808-0 Fax: -50

7 13

New (gpc-20060325)
by Waldek Hebisch 08 Dec '09

08 Dec '09

I have put a new gpc snapshot at: http://www.math.uni.wroc.pl/~hebisch/gpc-20060325.tar.bz2 Main change is preliminary gcc-4.0.x support. The other changes are rather small. Note that for "production use" 3.4.x and 3.3.x backend are prefered. Also, using 2.8.1, 2.95.3 and 3.2.3 backend should work, but is depreciated. For more detail see: http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20060325 and http://www.math.uni.wroc.pl/~hebisch/gpc/Fixed-20060325 -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

7 44

Re: [Core] [RFA/DWARF2] Handle nested subprograms in CU pc bound calculation
by Pierre Muller 02 Oct '08

02 Oct '08

Hi Daniel, > -----Message d'origine----- > De : gdb-patches-owner(a)sourceware.org [mailto:gdb-patches- > owner(a)sourceware.org] De la part de Daniël Mantione > Envoyé : Thursday, October 02, 2008 8:43 AM > À : FPC Core Developer List > Cc : Pierre Muller; gpc(a)gnu.de; gdb-patches(a)sourceware.org > Objet : Re: [Core] [RFA/DWARF2] Handle nested subprograms in CU pc > bound calculation > > > > Op Wed, 1 Oct 2008, schreef Joel Brobecker: > > > The answer to the question above lies in the Pascal parser. But when > > there are homonyms, how do you specify in your program exactly which > > one you mean? And does GDB provide the same method for distinguishing > > these homonyms? > > > > (need to relearn Pascal one of these days...) > > Pascal has a stack based symbol resolving (we call it the symtablestack > in > the compiler). For example take for example the following program: > > program my_program; > > uses unit_a,unit_b,unit_c; > > var a:integer; > > procedure main_procedure; > > var a:integer; > > procedure sub_procedure; > > var a:integer; > > begin > a:=1; > main_procedure.a:=1; > my_program.a:=1; > unit_a.a:=1; > unit_b.a:=1; > unit_c.a:=1; > end; > > begin > end; Daniel, did you really try to compile this? Both Free Pascal 1.0.10 and 2.2.0 fail to compile on the 'main_procedure.a:=1;' line. > So each procedure context can redefine identifiers. > > Inside sub_procedure, the symtablestack will look like: > > unit_a > unit_b > unit_c > my_program > main_procedure > sub_procedure The stack is correct, but the problem is that if main_procedure would be a function, then main_function would be usable inside sub_procedure either as a nested call by adding an explicit main_function() even if the function has no parameters, or to set the return value of main_function function. Thus main_function. is not allowed at least not for versions <= 2.2.0. Did that change in 2.2.2? > When searching for a symbol, the compiler will search the symbol tables > bottom to top, starting at sub_procedure, ending at unit_a, the first > symbol found is used. GDB would need to implement the same behaviour in > it's Pascal mode. The main current problem is that GDB knows nothing about the used or loaded units ... In stabs, I believe that there is no information on that... Does dwarf have something about this? Of course, we could try to demangle the assembler labels used to extract unit name, but I seem to remember that, at least for Free Pascal, that mangling scheme is version dependent, which will not simplify things :( I also vaguely remember that GPC did not, at least for a while, add anything to the procedure/function names declared in the interface part of units, as in C language. This had the big drawback of preventing to have the same global function/procedure in two different units that is normally allowed according to pascal syntax. Could someone from the GPC development team tell us if this limitation is still in place or if it has been lifted? Thanks for the answers, Pierre Muller Pascal language support maintainer for GDB

2 1

Re: [Core] [RFA/DWARF2] Handle nested subprograms in CU pc bound calculation
by Jonas Maebe 01 Oct '08

01 Oct '08

On 01 Oct 2008, at 18:39, Joel Brobecker wrote: > The answer to the question above lies in the Pascal parser. But when > there are homonyms, how do you specify in your program exactly which > one you mean? unitname.functionname > And does GDB provide the same method for distinguishing > these homonyms? I don't think so. The main problem is that there is no common way of mangling procedure/function names in Pascal. FPC and GPC mangle them in different ways, and as far as I know gdb has no support to demangle either (it definitely does not support demangling FPC names). For this reason, I always use either symbol names or sourcefile:linenr to place breakpoints. Jonas

1 0

Re: [RFA/DWARF2] Handle nested subprograms in CU pc bound calculation
by Pierre Muller 01 Oct '08

01 Oct '08

> -----Message d'origine----- > De : Joel Brobecker [mailto:brobecker@adacore.com] > Envoyé : Wednesday, October 01, 2008 3:16 AM > À : Pierre Muller; gdb-patches(a)sourceware.org > Objet : Re: [RFA/DWARF2] Handle nested subprograms in CU pc bound > calculation > > > > Actually, now that I think of it, a slightly cleaner approach would > > > probably be to extend the language vector to add a flag set to > > > non-zero for the languages that want nested-subprogram handling. > > > The only slight issue is that the CU references the language enum, > > > which means we need to go from that enum to the language_defn to > get access to the flag. > > > > I think you should stick with a language test in the DWARF reader. > > OK. Would the following kind of patch be what you have in mind? > Or would you prefer that the function simply take a language, rather > than a CU. Or actually no function at all? > > 2008-09-30 Joel Brobecker <brobecker(a)adacore.com> > > * dwarf2read.c (dwarf2_handle_nested_subprograms_p): New > function. > (add_partial_subprogram): Replace check of Ada language by call > to dwarf2_handle_nested_subprograms_p. > (dwarf2_get_subprogram_pc_bounds, load_partial_dies): Likewise. This looks fine for me! > This is only just for comments, as there is still one question open: > For Ada, we store the symbols for nested subprograms in the global > context. This allows us to break on these functions even when these > functions are not defined in the current context. Do we want to do the > same with Pascal? Right now, I left this functionality out... > In Ada, we have found it to be extremely convenient to not have to be > inside the enclosing function before we can insert the breakpoint. > When there are ambiguities (say two functions have a nested subprogram > with the same name), the ambiguity can be resolved using the fully > qualified name. I believe that, at least with the Free Pascal compiler and stabs debugging format (which is the format I worked on), all nested subprograms where also in the global context and thus I would not mind to do the same for pascal language. I must confess that I stopped working for the Free Pascal compiler more or less when the dwarf debugging format was added, and I almost don't know anything about that format... The only thing that I can tell, is that last time I checked Free Pascal (version 2.2.0 windows 32bit target) with -gw (dwarf debugging format) I still got lots of errors while trying to load the compiler inside gdb :( I know even less about GNU pascal compiler, but as this compiler is base on the GNU multi-language compiler, I would except it to behave closer to GNU C++ or GNU Ada. I must confess that I don't even know if the full specification would work for pascal in case the same name is used globally and as a nested procedure (I do know that you are allowed to reuse a name defined globally as a local procedure, function or variable inside a function, but I don't know if the (gdb) break GlobalFuntion.LocalFunction would work) Feedback from both Free Pascal and GNU pascal developers would be useful here and more generally on pascal dwarf support. > Tested on x86-linux, no regression (but I don't have a Pascal > compiler). The pascal testsuite is ridiculously tiny (I only wrote a few very basic tests) and there is nothing about nested functions/procedures in it. So there is nothing to expect on this side. By the way, it would probably be useful to repeat the tests with different debugging formats. How can this be done in your testsuite directory? Pierre Muller Pascal language support maintainer for GDB

2 1