Gpc May 2010

gpc@gnu.de

6 participants
5 discussions

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

25 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

Fwd: findfiles syntax
by Luis Rivera 26 May '10

26 May '10

for the record, and for all those interested, ---------- Forwarded message ---------- From: Luis Rivera <jlrn77(a)gmail.com> Date: 22 May 2010 14:56 Subject: Re: findfiles syntax To: Maurice Lombardi On 22 May 2010 03:19, Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> wrote: > Luis Rivera a écrit : >> >> program FindFilesTest; >> >> uses GPC, FileUtils; >> >> type >> alphafile=text; >> var >> nameoffile: string; >> filename: alphafile; >> const >> mydir='/usr/local/'; >> >> function aopenin(var a:alphafile):boolean; >> begin if ioresult=0 then >> assign(a,trim(nameoffile)); >> findfiles(mydir,a,false,reset,nil); >> aopenin:=ioresult=0; >> end; >> >> begin >> WriteLn ('Enter file name to type: '); >> ReadLn (nameoffile); >> if aopenin(alphafile) then > [...] > Declaring the text file as filename is very confusing: this is certainly the > source of your errors: you confuse a file and its name. > > 1) a is a file, not a string (Mask) > mydir is a string (the name of the directory to search in) > 2) reset has for parameter a file, not a string. > So it expects the string containing the filename... Changing the naming conventions, trying to avoid confusing the FileName (string) with the FileContents (text), I may do the following: program AtBat; uses GPC, FileUtils; type alphafile=text; var filename: string; filecontents: alphafile; const mydir='/usr/local/'; function aopenin(var a:alphafile):boolean; var f:string; begin if ioresult=0 then f:=trim(filename); assign(a,f); findfiles(mydir,f,false,reset,nil); aopenin:=ioresult=0; end; begin WriteLn ('Enter file name to type: '); ReadLn (filename); if aopenin(filecontents) then WriteLn(filename, ' found!') else Writeln('Sorry: search failed!'); end. However, I still get the same error message... BTW: a simple, sensible way to state "DoNothing" as DirAction? > You might want to declare a FileAction procedure with a string parameter > (nameoffile): probably you would include in it the assign which is before > findfiles in your program and the reset > That's what I just tried to do! :-) > Notice that if there are multiple files found, you will have an error > because you then try to reopen a file (a) which has not been closed: > findfiles apply FileAction on all files which match Mask. Maybe I can get around that problem defining the FileAction procedure in such a way that wildcards are forbidden... > You can close the > file inside FileAction, but beware not to confuse nameoffile as a parameter > of FileAction and as a global variable: if you give two different names and > assign the global name to the parameter inside FileAction you can recover at > the end the last nameoffile found. > > PS: > > A := B = C; > is correct in Pascal, weird but correct. > Cool. Thanks for pointing that out. Cheers! -- Luis Rivera O< http://www.asciiribbon.org/ campaign

2 3

findfiles syntax
by Luis Rivera 24 May '10

24 May '10

Hello! I'm trying to implement a procedure and a function involving findfiles, which, afaik, can do path search. One thing at a time. First is the function. A sample would be --snip-- program FindFilesTest; uses GPC, FileUtils; type alphafile=text; var nameoffile: string; filename: alphafile; const mydir='/usr/local/'; function aopenin(var a:alphafile):boolean; begin if ioresult=0 then assign(a,trim(nameoffile)); findfiles(mydir,a,false,reset,nil); aopenin:=ioresult=0; end; begin WriteLn ('Enter file name to type: '); ReadLn (nameoffile); if aopenin(alphafile) then WriteLn(nameoffile) else Writeln('sorry, search failed'); end. --snip-- The compiler bites me back saying: syntax error before reset extra comma Beats my why. Thanks in advance, -- Luis Rivera O< http://www.asciiribbon.org/ campaign

5 6

Fwd: findfiles syntax
by Luis Rivera 24 May '10

24 May '10

for the record, ---------- Forwarded message ---------- From: Luis Rivera <jlrn77(a)gmail.com> Date: 22 May 2010 11:53 Subject: Re: findfiles syntax To: leledumbo On 22 May 2010 03:00, leledumbo <leledumbo_cool(a)yahoo.co.id> wrote: > > From the reference: > type > TStringProc = procedure (const s: String); > > procedure FindFiles (const Directory, Mask: String; MainDirFirst: Boolean; > FileAction, DirAction: TStringProc); attribute (iocritical); > > How you call it: > findfiles(mydir,a,false,reset,nil); > > mydir is of type string => matches Directory type > a is of type text => doesn't match Mask type > false is of type boolean => matches MainDirFirst type > reset is a procedure to open file for reading, it's of type procedure (f: > text) for text files => doesn't match FileAction type TStringProc (see > above) > nil is a pointer pointing to address 0, which is a reserved location for > unallocated vars => doesn't match DirAction type TStringProc (see above) > > Can you see where the mistakes are now? I do. However, one thing that bothers me is that the sample code at findfilesdemo.pas mentioned earlier in this thread includes the line FindFiles (DirSelf, '*.{pas,p,pp,dpr}', False, DoOutput, nil); as an example. Now I wonder why it compiles and runs if nil shouldn't match. Thanks, -- Luis Rivera O< http://www.asciiribbon.org/ campaign -- Luis Rivera O< http://www.asciiribbon.org/ campaign

1 0

Help! I crashed the compiler.
by John L. Ries 04 May '10

04 May '10

The attached example, produces the following highly informative error message when compiled: gpcbug20100502.p:13: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. I'm running GPC 20070904, based on gcc-4.1.2 under 64-bit Linux (Slamd64 12.2 to be exact). The error is also triggered on my 32-bit Linux (Debian 5.0.4) system running the same compiler, based on gcc-4.1.3. The code (attached) is as follows: unit example; interface type CandName(MaxCandName:integer) = string(MaxCandName); CandStatus = (Elected, Eliminated, Neither); CandRecord = record Name : CandName; RawVote : integer; Allocation : integer; Status : CandStatus; end; CandArray(N:integer) = array[1..N] of CandRecord; end. If I change the declaration on the array to "^CandRecord", the example compiles normally. The types also compile normally inside of a program (instead of a unit). If there's a more recent version of the GPC codebase that I should be using instead, then please let me know. --------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc May 2010