- Gpc - gnu.de

Re: Quo vadis, GPC?
by samiam＠moorecad.com 28 Jul '10

28 Jul '10

Frank, Some brief notes on your presentation "Quo vadis, GPC" (Where is GPC going). I'd of sent it direct, but I note your email is not working. First, I also considered, and was strongly suggested, to use GCC as a backend for my compiler. I rejected this idea because, primarily, of the very tight coupling between the front and back ends of GCC. This is in contrast to the well developed intermediate code coupled systems outside of GCC. The other issue is the, frankly, hostile attitude of the GCC folks towards Pascal. Fortran and other compilers are distributed with GCC and get better support from the GCC group. I can't help but think that this comes from the C group perception of Pascal as a rival, which it used to be but is no longer. As for making GPC a front end for another compiler, I can't think of a better way to insure that GPC dies quietly. Virtually all of the "cascade" compilers, including Cfront, had severe difficulties, including becoming unnaturally coupled to one particular backend, and angering users by giving errors from the underlying compiler that the front end didn't catch. C++ became a success because Stroustrup moved quickly away from Cfront and onto a true compiler for C++. GPC started out with a big advantage due to having a high quality back end with wide implementation. However, you detail well the unseen costs of that, including a moving target back end specification, inability to write the compiler in its own language, etc. Pascal scores low as a common implementation language, but as you detail, most of this is because of a movement to interpreters and away from true compilers. Although this is stated to be "because of ease of development", I believe in large part this is a reaction to the difficulties of C/C++ development, which is directly traceable to the complexity of the language and the difficulties with debugging a language totally lacking in basic type security. I think nothing underlines this more than Anders' move to Microsoft and C#: Anders went from taking a language designed around type security (Pascal) and tearing away its type security, to taking a language designed around a lack of type security (and proud of it) C, and adding type security to that. I completely agree with your diatribe on automatic destructors. I choose automatic (and anonymous) constructors and destructors for the language Pascaline (a highly extended version of Pascal) because I believed it was necessary for the compiler to both control when, and in what order, the constructors and destructors are called. I also believe (as shown in Java and C#) that classes should be treated as code structuring constructs and NOT as "extended records", and that both static and dynamic objects have their uses. In Pascaline, classes are expressed as modules which can be instantiated, and fit within modules in program structure (programs are a series of modules which may contain classes). For more on that, I invite you to look over the Pascaline specification: http://www.standardpascal.org/standards.html I looked at templates for Pascaline, and I used your exact example to evaluate it, that is, general handlers for list structures. However, I came to the conclusion that this was also the paramount example for classes, and in fact classes are an example of a highly structured system of typing that reduces the need for the highly unstructured method offered by templates (which by the way, Wirth is on record as saying was not such a hot idea). Although I am not sure I see the sense of your basic argument (interest in GPC is falling off, so lets rewrite it). I would say it makes equal sense to simply start moving parts of GPC into its own language and away from C. If you were to write a code generator to replace the back end, in Pascal, you would both be independent of GCC and much farther along on your goal of a GPC rewritten in its own language. Cheers, Scott Moore

2 1

Re: Quo vadis, GPC
by John Gordon Ollason 28 Jul '10

28 Jul '10

I shall begin by thanking all the people who have contributed to GPC which I have used as my programming language of choice for algorithms since I moved to Linux Red Hat Version 5.2. I am now retired and apart from the occasional recreational programming, a couple of years ago I wrote a Sudoku solver when I was annoyed that I couldn't solve a particular grid, I very seldom need a Pascal compiler. I was an ALGOL 60 programmer before I became a Pascal programmer, and then, when I had to learn C I was horrified by the ad hoc nature of the language. But ad hoc seems to be the favoured strategy of the time, and as far as I know very few people learn Pascal now, and therefore the base of users is ageing. Without a thriving population of young programmers the language will die, and I suspect that the formal virtues of a language in the ALGOL tradition are not being transmitted, and perhaps new programmers are not being equipped to recognize the admirable qualities of Pascal. I suggest, therefore, that no substantial development of GPC would be cost effective unless there were a large base of users of the language, and that the first priority should be to determine the number of current users of the language and to estimate its expected future use. My own pessimistic assessment may be mistaken; I hope it is, but it would make sense to find out before committing a substantial amount of effort in further development of a language that is only used by a small minority of programmers. John O.

1 0

Re: close(file); always necessary??
by samiam＠moorecad.com 19 Jun '10

19 Jun '10

Hence the reference count stuffs. I did a paper analysis once, I decided that: 1. To do true automated storage recycling, you have to track each pointer leaving scope, which means that you have to know where every pointer is. 2. Be ready to reference count each pointer, that is, each copy operation increments the reference count, and each dynamic entry gets a reference counter that is initially one for the pointer that is returned. 3. Decrement the reference counter each time any pointer leaves scope. 4. produce an error if the programmer attempts to free a non-zero referred pointer. 5. The whole thing generates headaches. Seriously, it is quite doable with Pascal, but generates a lot of overhead. Each data structure needs a template for the contained pointers, and every data structure leaving scope or freed must be analysed for contained pointers, and those pointers decrementing reference counts. Wirth also described this scheme, although I don't think he ever tried it. I have thought about implementing it primarily to shut people up, i.e., lack of automated storage collection "is a problem with old languages like Pascal". It isn't, the price paid for reclaimation overhead is the same as Java or other languages, we are primarily burdened by users who expect true compiled performance code. Scott -------- Original Message -------- Subject: Re: close(file); always necessary?? From: Frank Heckenbach <ih8mj(a)fjf.gnu.de> Date: Fri, June 18, 2010 2:56 pm To: gpc(a)gnu.de samiam(a)moorecad.com wrote: > Then that would leave you pretty close to > automatic dynamic storage recycling, no ? Partly. When a pointer variable goes out of scope, we cannot automatically dispose it, since copies may exist. Fully automatic storage recycling still requries full-blown reference counting or garbage collection, AFAICS. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 1

Re: close(file); always necessary??
by samiam＠moorecad.com 18 Jun '10

18 Jun '10

2 1

Re: close(file); always necessary??
by samiam＠moorecad.com 15 Jun '10

15 Jun '10

2 1

close(file); always necessary??
by Rugxulo 15 Jun '10

15 Jun '10

Hey, In non-standard Pascal mode, does it matter if I explicitly close the file or not? E.g., "close(file);", is that done automatically or is it implementation defined? (I'm 99% sure DOS always closes files upon exit.) I'm just wondering if that's a fair assumption for Linux, etc. (though I kinda doubt it).

3 2

3 points
by spir 14 Jun '10

14 Jun '10

Hello, I'm am amateur programmer, new to gpc and rather new to Pascal as well. I wonder whether this list is a proper place to find help in learning the language, and in using it for a few projects of mine. If yes, then below is a first series of diverse questions. I will have some more as I discover the language (including some stupid ones, certainly ;-). [Note: I have a candidate answer to the questions, but ask anyway to be sure, and stop wondering.] -1- writing arrays & records What is the literal notation for arrays & records? Can it apply to (a) const definition (b) var initialisation (c) var assignment? Is there a way to write back arrays & records to output (tostring(x), according to standard notation)? If not, how to write such a tool func? (super useful for learning, prototyping, testing...) Is it at all possible to write the following 'show' tool func: show(x); // 'x : 1' --> stdout show(x+1); // 'x+1 : 2' --> stdout ? (my dream debugging tool) -2- traversing collections Is there a way to traverse arrays with elements directly? (--> foreach, or Eiffel's across) Is it possible to define traversal for custom collections? -3- TP-like object system Is there more information in fpc's documentation about its object system (than chapter 6.8 in manual)? Else, are there good places online to find information about TP's object system? Denis ________________________________ vit esse estrany ☣ spir.wikidot.com

4 5

mixed comments
by Rugxulo 06 Jun '10

06 Jun '10

With apologies if this has already been mentioned. (I don't feel like searching the mailing list archives right now, and I haven't checked the test suite.) I just thought it was funny / interesting. ;-) { using GPC 20070904 / GCC 3.4.4 via DJGPP (gpc.info) : "GPC's default behaviour is (like BP) not to allow mixed comments" ... except that it allows it by ignoring it, not reporting an error (which is what was implied, or so I thought!) } { $ extended-pascal} { says "Hello, mixed!" } { $ standard-pascal} { says "Hello, mixed!" } {GPC default} { says "Hello" } {FPC default} { says "Hello" } program comment(output); begin write('Hello'); { *) write(', mixed!'); (* } writeln; end.

2 1

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

GPC debugging with Snow Leopard/Xcode 3.2
by Francesco Panasiti 29 Apr '10

29 Apr '10

I've moved a large GPC project from Mac OSX 10.4 to Snow Leopard (Xcode 3.2, Intel CPU). Compilation (GNU Pascal 3.4.6u4) is ok, but I can't start debugging from Xcode as I get the following error: ""Exception starting task (/Developer/usr/bin/gdb) ; name: NSInvalidArgumentException, reason: working directory doesn't exist"" With evidence, gdb is looking for the executable in the wrong directory, but I don't know how to workaround that. Thanks in advance for any help. ------------------------------------------------------------- Francesco Panasiti -------------------------------------------------------------

2 2

Fwd: [Fwd: GCC 4.5.0 Released]
by Rugxulo 21 Apr '10

21 Apr '10

Oops, replied to private e-mail instead! ---------- Forwarded message ---------- From: Rugxulo <rugxulo(a)gmail.com> Date: Tue, 20 Apr 2010 19:13:05 -0500 Subject: Re: [Fwd: GCC 4.5.0 Released] To: Adriaan van Os <gpc(a)microbizz.nl> Hi, just a few warnings from me. ;-) On 4/19/10, Adriaan van Os <gpc(a)microbizz.nl> wrote: > > The Free Software Foundation and the GNU Compiler Collection (GCC) > development team have released GCC 4.5.0. Clang is also self-hosting now, and ClangBSD can bootstrap (currently in testing but seems to basically work, from what I hear). > The developers have measured performance improvements of 5% to 10% > on high-performance computing benchmarks. (Of course, results vary > depending on choice of CPU, benchmark, and optimization options.) In my (horribly lame) experience, I saw some bad regressions with 4.4.2 vs. earlier GCCs. Granted, it was just one really weird case, but still, it makes me think even moreso that GCC is only 686-tuned these days. (I was trying to benchmark something on my old old 586.) It worries me a bit since I just assumed 4.x was always way better. (Note that I never bothered to isolate the problem just yet, it wasn't crucial or anything, just really odd. And it was a C program, not Pascal.) > GCC 4.5.0 is now capable of "link-time optimization". Only using an ELF container (although non-ELF targets can somehow possibly use it too, allegedly). Hopefully not as exclusive as Gold linker (x86/x86-64 ELF only). I do really feel like all the world's a Linux these days. :-/ > GCC also generates better debug information for optimized code, > including information about the value of variables that have been optimized > away. In other words, you need GDB 7+ by default (else have to choose an older Dwarf debug format via --dwarf-2 or whatever).

1 0

[Fwd: GCC 4.5.0 Released]
by Adriaan van Os 19 Apr '10

19 Apr '10

-------- Original Message -------- Subject: GCC 4.5.0 Released Date: Sun, 18 Apr 2010 16:01:49 -0700 (PDT) From: mitchell(a)codesourcery.com (Mark Mitchell) Reply-To: mark(a)codesourcery.com To: gcc-announce(a)gcc.gnu.org CC: gcc(a)gcc.gnu.org The Free Software Foundation and the GNU Compiler Collection (GCC) development team have released GCC 4.5.0. This release is a major upgrade to the compilers, with a particular focus on the performance of the generated code. The developers have measured performance improvements of 5% to 10% on high-performance computing benchmarks. (Of course, results vary depending on choice of CPU, benchmark, and optimization options.) GCC 4.5.0 is now capable of "link-time optimization". Traditionally, most C and C++ compilers (including GCC) have only been able to optimize within a single source file or "module". GCC was therefore unable to take advantage of optimization opportunities that required knowledge about multiple modules. This limitation has been removed in GCC 4.5.0. This optimization can provide significant increases in performance and equally significant reductions in code size. In addition, GCC 4.5.0 has improved loop optimization infrastructure. This infrastructure, based on an advanced "polyhedral" model for optimization, allows GCC to perform more advanced loop optimizations. In the future, this infrastructure will be tuned and used more heavily. GCC 4.5.0 also features improvements for a wide variety of specific architectures, including support for recent CPUs using the ARM, AVR, ColdFire, MIPS, Power, SuperH, and x86 architectures. GCC also generates better debug information for optimized code, including information about the value of variables that have been optimized away. And, of course, a wide variety of defects in all parts of the compiler (ranging from language conformance to code-generation) have been corrected. Refer to gcc.gnu.org: http://gcc.gnu.org/gcc-4.5/changes.html for more information about this release. GCC 4.5.1, with corrections for any critical defects reported in GCC 4.5.0, is expected in July, 2010. As always, a vast number of people contributed to this GCC release -- far too many to thank individually! -- Mark Mitchell CodeSourcery mark(a)codesourcery.com (650) 331-3385 x713

2 1

Disposing generic pointers
by John L. Ries 15 Apr '10

15 Apr '10

The other day, I compiled a unit I wrote several years ago under FPC and got the following warning: queues.p(101,37) Warning: use of NEW or DISPOSE for untyped pointers is meaningless The same unit compiles under GPC (20070904) without warnings. My question is: does GPC properly deallocate memory in such a case, or is the DISPOSE request ignored? The offending procedure is: procedure killq(var Queue : QType ); var Item : pointer; begin while(not EmptyQ(Queue)) do begin Dequeue(Queue,Item); if Item<>nil then dispose(Item); end; end; { killq } --------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|

5 14

GPC installation
by kriti panday 19 Mar '10

19 Mar '10

Hello Please tell me how can we install GPC on unix or windows. Or the installtion steps for GPC on windows. the installtion steps for GPC on unix. Thanx

2 1

Moving doubles with overlapped memory
by Adriaan van Os 10 Mar '10

10 Mar '10

Any comments on <http://bugs.freepascal.org/view.php?id=15921> ? Regards, Adriaan van Os

3 2

GPC installation
by kriti panday 06 Mar '10

06 Mar '10

I want to install GPC on windows XP or red hat linux. Plesae guide me on which this installation is easy ,and how can i install it . Thanks

2 1

Re: gpc installation support
by Maurice Lombardi 23 Feb '10

23 Feb '10

kriti panday a écrit : > HELLO > Please tell me how can i get support for gpc installation.To which mail > ID ,i will send my question. > Please support me.Tell me the procedure for GPC installation on Unix. send mail to the gpc list, not to gpc-doc which is specialized and pretty dead download the latest gpc snapshot http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20070904.tar.bz2 and gcc sources for backend (3.4.x and 4.1.x are fine) The instructions are in p/INSTALL in the gpc snapshot: in Unix better compile the compiler than install binaries. There has been posted in this list a script to automate the building, but I never used it. Maybe the author will give the reference. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

Re: gpc installation support
by Adriaan van Os 23 Feb '10

23 Feb '10

kriti panday wrote: > HELLO > Please tell me how can i get support for gpc installation.To which mail > ID ,i will send my question. > Please support me.Tell me the procedure for GPC installation on Unix. More info here <http://alignment.hep.brandeis.edu/Software/Pascal/Index.html> Regards, Adriaan van Os

1 0

Hi everyone - got a question about GPC
by Hodges, Robert CTR USAF AFMC 520 SMXS/MXDEC 18 Feb '10

18 Feb '10

I downloaded GPC from this web site: http://www.gnu-pascal.de/binary/ I downloaded the binary version of GPC and GCC bundled together in RMP format for Linux. I specifically need GPC 2.1 with GCC 2.95, the file called gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz <http://www.gnu-pascal.de/binary/gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz> . I was greatly relieved to find this web site, and that binaries were available in the versions I needed. Problem is, when I install the RPM, it looks like the "binary" GCC compiler is incomplete - no actual binaries, compiler not ready to run. I could be wrong, so if I am, I need someone to help point me in the right direction. I'm a sysadmin who's installing this software for a developer, which I am not. Since I personally think the most ridiculous thing in the world is a compiler that won't work until it's compiled by another compiler, can anybody point me in the right direction to either an installable package of GPC 2.1, GCC 2.95 for Linux or tell me how to get this particular backage to work? Oh, I am attempting to install and run this package on SuSE Linux Enterprise Server 11. Major thanks in advance to anyone that can help out. Not sure what to think, the most recent update I can identify on the above web site was 5 years ago. Anybody out there? Bob

6 16

Re: Zeichensalat
by Adriaan van Os 17 Feb '10

17 Feb '10

egbert(a)seibertz.de wrote: > Moin Pascaller, > > im Rahmen von systemweiten Zeichensatzumstellungen (von > latin1 auf utf8) funktionieren nun erwartungsgemäß einige > Pascalprogramme nicht mehr. Teilweise weil Dateinamen > nicht mehr verstanden werden und teilweise weil Eingaben > nicht mehr verstanden werden. Oder die Nutzer die Ausgaben > nur noch erraten können ... > > Sehr ärgerlich an utf8 ist, daß durch die variable > Zeichenlänge der Programmieraufwand für die Erkennung > überproportional ansteigt. Möglicher Weise wäre utf16 > (USC2) deutlich einfacher im Aufwand ... Nach meiner Meinung ist UTF-16 wohl die slechteste Wahl, weil auch UTF-16 eine Kodierung ist mit variabeler Länge (<http://en.wikipedia.org/wiki/Utf-16>), obwohl Sie oft nicht als Solches behandelt wird, was dann wiederum zu Fehlern führt ! Ich bevorzuge UTF-8. Adriaan van Os

1 0

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

Long String Generation
by Kevan Hashemi 15 Feb '10

15 Feb '10

Dear GPC Users, I use long strings to pass numerical data into and out of a shared library I compile from Pascal. Right now, I generate a long string of numbers like this. program string_demo; var long_string:string(100000); i:integer; begin long_string:=''; for i:=1 to 10000 do writestr(long_string,long_string,i:1,' '); end. Clearly, this is inefficient. It takes 200 ms on my machine. If I use an array of characters instead of a string, and append each new entry to the array, execution time drops to 10 ms. I can't see a way of using GPC's writestr, concat, or trim functions to accelerate my string generation. I can't alter the long_string.length field directly. If I could fill up the string with spaces first, I could use the string as an array, then trim the spaces off the end. But filling up the string with spaces requires multiple calls to writestr, so I'm back where I started. It seems to me that I'm missing an obvious solution to my problem, and I thought you might point it out to me. Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

4 6

compiler directives should be shut off when using --standard-pascal
by Rugxulo 03 Feb '10

03 Feb '10

Hi, I agree. This basically means that cmdline dialect options should take precedence over any listed in the file itself. This should not cause anybody much trouble, if any, except in some rare makefiles, and even that should be an easy fix. ---------- Forwarded message ---------- From: Scott Moore Date: Tue, Feb 2, 2010 at 1:38 PM Subject: Re: New P5 available To: Rugxulo In retrospect, it's probably not a good idea that GPC tries to take compiler directives from the programs. There should be a way to turn off GPC's parse of the compiler directives, since that would make GPC defacto non-standard. It should have been shut off with the --standard-pascal switch.

1 0

CWSDPMI r7 - 4GB support (Beta Test)
by Rugxulo 14 Jan '10

14 Jan '10

Charles Sandmann writes: "I would like to announce the beta for CWSDPMI release 7. The purpose of this release is to allow high performance access to large amounts of physical memory (up to 4GB). Memory above 32-bit address space (common on machines over 3GB physical memory) will be mapped to fill the address hole to provide a full 4GB memory. 4MB pages will be automatically used for large memory requests. Release 7 also includes the bug fixes included in the release 5 2008 refresh, and improved 4MB page support included in the never completed r6. Current DJGPP releases support large memory allocation requests and with CWSDPMI release 7 allow a contiguous memory block over 4091MB. This CWSDPMI release is dedicated to those few dozen people who want to prove their 4GB+ computers can actually run 4GB 32-bit applications. For those who need more than 4GB, I'll provide some code that allows you to map 5GB+ memory (up to 64GB) into the address space on request. The next release will probably be when I get several people bugging me that 64GB isn't enough under DOS :-) Binary Distribution: http://clio.rice.edu/djgpp/beta/csdpmi7b.zip Source Distribution: http://clio.rice.edu/djgpp/beta/csdpmi7s.zip Please send me any comments or bug reports. Have fun, and thanks for testing !"

1 0

Unable to print
by Contestcen＠aol.com 21 Dec '09

21 Dec '09

I tried that statement, but it did not recognize the command "net". Also the Pascal program seems to bomb when I use any value other than 'USB001' in the call to InitPrinter (or when I omit InitPrinter). The printer is connected directly to my computer by a USB cable. There is no local net. Date: Thurs, Dec 17 2009 5:00 am From: "Zaphod Beeblebrox" "SirJohn" <contestcen(a)aol.com> wrote in message news:dff19abd-9e4d-40c0-a4cb-d7aa8b66e7a3@j14g2000yqm.googlegroups.com... >I just moved to Windows 7, which means that I now connect to my > printer via a USB port instead of a serial port. In those FPC > programs which use the printer I changed InitPrinter('LPT1') to > InitPrinter('USB001') however, everything I print is now going to a > disk file named USB001 instead of to the printer. What else do I > need > to get this working? Make sure the printer is shared, and then use the following command to redirect LPT2 to the printer: net use LPT2: \\computername\printername /persistent:yes Replace 'computername' with your computer name, and 'printername' with the share name of your printer. After you've run the command, you should be able to use InitPrinter('LPT2') in your program. BTW, you want to use LPT2 since from what I've read, if the printer port actually exists, Vista and Windows 7 won't let you redirect to it. Hope this helps.

1 0

Unable to print
by Contestcen＠aol.com 21 Dec '09

21 Dec '09

I am using FPC 2.2.4 for i386. From: Marco van de Voort On 2009-12-17, SirJohn <contestcen(a)aol.com> wrote: > I just moved to Windows 7, which means that I now connect to my > printer via a USB port instead of a serial port. In those FPC > programs which use the printer I changed InitPrinter('LPT1') to > InitPrinter('USB001') however, everything I print is now going to a > disk file named USB001 instead of to the printer. What else do I need > to get this working? Which FPC are you using on windows 7? Could be one of the following three editions: go32v2/win32/win64 ? Note that go32v2(dos) is not supported/recommended on NT based windowses (NT4/2k/2k3/xp/vista/w2k8/w7).

1 0

Compiler differences
by John Gordon Ollason 11 Dec '09

11 Dec '09

Greetings, Having installed gpc 20060325, based on gcc-3.4.4 in replacement of gpc 20041218, based on gcc-3.3.3 I discovered that some programs which worked on the earlier version don't work on the later one. I narrowed the problem down to changes in the behaviour of goto. program gototest; label 9999; procedure try; begin goto 9999; end; { try } begin try; 9999: end. The program gototest.p is compiled by both compilers. The following program gototest1; label 9999; procedure try; begin goto 9999; end; { try } begin repeat try; 9999: until 0=0; end. is compiled by gpc 20041218 but the newer compiler gives the following error: gpc --classic-pascal gototest.p gototest.p: In main program: gototest.p:10: error: invalid target for nonlocal `goto' I have had a look at the ISO7185 specification, and though I am not an expert in these matters, it seems to me that the newer compiler is behaving incorrectly. Incidentally FreePascal gives the following error for both programs: Free Pascal Compiler version 2.2.2 [2008/10/26] for x86_64 Copyright (c) 1993-2008 by Florian Klaempfl Target OS: Linux for x86-64 Compiling gototest.p gototest.p(5,13) Error: Goto statements aren't allowed between different procedures gototest.p(14) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Error: /usr/bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled) Are any of the compilers behaving as specified in the ISO7815 standard? Best wishes, John O.

2 2

Compiling and linking Gnu-Pascal under Fedora 11 on x86_64 hardware.
by John Gordon Ollason 09 Dec '09

09 Dec '09

Greetings, I had to upgrade my hardware from i686 to x86_64 and my operating system from Fedora Core 4 to Fedora Core 11. I have tried to install Gnu-Pascal by downloading several versions from the Gnu-Pascal homepage and all attempts fail Every attempt to use make terminated in errors as follows: -- . . . make[2]: *** [32/libgcc_s_32.so] Error 1 make[2]: Leaving directory `/usr/local/src/gpcbuild/gcc' make[1]: *** [libgcc.a] Error 2 make[1]: Leaving directory `/usr/local/src/gpcbuild/gcc' make: *** [all-gcc] Error 2 fail. -- I downloaded the install.gpc script and that didn't work either. The closest I have got to a working system is illustrated by the listing below. -- $ gpc -v hello.p Using built-in specs. Configured with: ../gcc-3.4.4/configure --enable-languages=pascal : (reconfigured) ../gcc-3.4.4/configure --enable-languages=pascal : (reconfigured) ../gcc-3.4.4/configure --enable-languages=pascal : (reconfigured) ../gcc-3.4.4/configure --enable-languages=pascal Thread model: posix gpc version 20070904, based on gcc-3.4.4 gpc1 -quiet -v hello.p -quiet -dumpbase hello.p -mtune=k8 -famtmpfile=/tmp/cceErexo.gpa -version -o /tmp/ccsxBXZC.s GNU Pascal version 20070904, based on gcc-3.4.3 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.1 20090725 (Red Hat 4.4.1-2). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Pascal Compiler PreProcessor version 20070904, based on gcc-3.4.3 as -V -Qy -o /tmp/ccUtT5MU.o /tmp/ccsxBXZC.s GNU assembler version 2.19.51.0.14 (x86_64-redhat-linux) using BFD version version 2.19.51.0.14-1.fc11 20090722 ld --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /usr/lib/../lib64/crtbegin.o -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.4 -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.4/../../../../lib64 -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.4/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/ccUtT5MU.o -lgpc -lm -lgcc -lc -lgcc crtend.o /usr/lib/../lib64/crtn.o ld: cannot find -lgpc -- and there I am stuck. Any constructive suggestions about what to try next would be very welcome. Thanks, John O.

3 2

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

GPC installation on Intel 64 bit CPU, make fails
by Ernst-Ludwig.Bohnen＠t-online.de 28 Nov '09

28 Nov '09

Hallo, I am trying to install GPC (gpc-20060325, based on gcc-core-3.4.4) on a PC with Intel-Xeon 64 bit CPU and openSUSE 11.2. Make ends up with some mystical error lines, see below. Any suggestions? Ernst-Ludwig ..../configure --enable-languages=pascal --prefix=/usr/gnu <RET> ..../make <RET> .......... .......... .......... ./auto-host.h:185:1: warning: "HAVE_DECL_GETOPT" redefined In file included from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcov.c:37: /tmp/root/install.gpc/gcc-3.4.4/gcc/tsystem.h:40:1: warning: this is the location of the previous definition In file included from /tmp/root/install.gpc/gcc-3.4.4/gcc/gcov-io.h:240, from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcov.c:51: ./auto-host.h:185:1: warning: "HAVE_DECL_GETOPT" redefined In file included from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcov.c:37: /tmp/root/install.gpc/gcc-3.4.4/gcc/tsystem.h:40:1: warning: this is the location of the previous definition In file included from /usr/include/features.h:371, from /usr/include/stdio.h:28, from /tmp/root/install.gpc/gcc-3.4.4/gcc/tsystem.h:79, from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcc2.c:41: /usr/include/gnu/stubs.h:7:27: gnu/stubs-32.h: No such file or directory make[2]: *** [libgcc/32/_muldi3.o] Error 1 make[1]: *** [libgcc.a] Error 2 make: *** [all-gcc] Error 2

2 2

Re: GPC installation on Intel 64 bit CPU, make fails
by Ernst-Ludwig.Bohnen＠t-online.de 28 Nov '09

28 Nov '09

Maurice, merci pour votre reponse After installing /usr/include/gnu/stubs-32.h, which was missing on my machine, the 'last words' of make changed when installing gpc-20060325 based on gcc-core-3.4.4, see below. It probably did not help. Then I tried various GPC/GCC combinations and found a nearly working one: gpc-20070904 (the Hebisch edition, as you wrote) based on gcc-4.1.2, which is said to be not a recommended gcc candidate, but it works. Running gpc gives in the beginning this message: 'usr/bin/ld: skipping incompatible /usr/gnu/lib/libgcc_s.so when searching for -lgcc_s'. My final feeling is walking at night through a black forrest when installing GPC. Thank you for giving hints Ernst-Ludwig ----------------- Last words of make --------------------------------------------- /tmp/root/install.gpc/gcc-3.4.4/gcc/tsystem.h:40:1: warning: this is the location of the previous definition In file included from /tmp/root/install.gpc/gcc-3.4.4/gcc/gcov-io.h:240, from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcov.c:51: ./auto-host.h:185:1: warning: "HAVE_DECL_GETOPT" redefined In file included from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcov.c:37: /tmp/root/install.gpc/gcc-3.4.4/gcc/tsystem.h:40:1: warning: this is the location of the previous definition /usr/lib64/gcc/x86_64-suse-linux/4.4/cc1: /tmp/root/install.gpc/gpc-build/gcc/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib64/libstdc++.so.6) make[1]: *** [collect2.o] Error 1 make: *** [all-gcc] Error 2 -----Original Message----- Date: Wed, 25 Nov 2009 10:58:25 +0100 Subject: Re: GPC installation on Intel 64 bit CPU, make fails From: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> To: "Ernst-Ludwig.Bohnen(a)t-online.de" <Ernst-Ludwig.Bohnen(a)t-online.de> Ernst-Ludwig.Bohnen(a)t-online.de a Ã©crit : > I am trying to install GPC (gpc-20060325, based on gcc-core-3.4.4) > on a PC with Intel-Xeon 64 bit CPU and openSUSE 11.2. Make ends up > with some mystical error lines, see below. I have limited experience with that. I have only installed gpc with gcc 3.4.4 and gcc-4.1.2 on redhat fedora core 6 with a Xeon 64 CPU both 32 bits and 64 bits versions. You should rather try the latest gpc snapshot available on the hebisch site http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20070904.tar.bz2 but the problem is probably the same. See below > > ..../configure --enable-languages=pascal --prefix=/usr/gnu <RET> > > ..../make <RET> > .......... > .......... > .......... > ./auto-host.h:185:1: warning: "HAVE_DECL_GETOPT" redefined > In file included from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcov.c:37: > /tmp/root/install.gpc/gcc-3.4.4/gcc/tsystem.h:40:1: warning: this is the > location of the previous definition > In file included from /tmp/root/install.gpc/gcc-3.4.4/gcc/gcov-io.h:240, > Â Â Â Â Â Â Â Â Â from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcov.c:51: > ./auto-host.h:185:1: warning: "HAVE_DECL_GETOPT" redefined > In file included from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcov.c:37: > /tmp/root/install.gpc/gcc-3.4.4/gcc/tsystem.h:40:1: warning: this is the > location of the previous definition > In file included from /usr/include/features.h:371, > Â Â Â Â Â Â Â Â Â from /usr/include/stdio.h:28, > Â Â Â Â Â Â Â Â Â from /tmp/root/install.gpc/gcc-3.4.4/gcc/tsystem.h:79, > Â Â Â Â Â Â Â Â Â from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcc2.c:41: > /usr/include/gnu/stubs.h:7:27: gnu/stubs-32.h: No such file or directory in this directory /usr/include/gnu/ in my system I find stubs.h stubs-32.h stubs-64.h So there is probably some misinstallation in your setup. > make[2]: *** [libgcc/32/_muldi3.o] Error 1 > make[1]: *** [libgcc.a] Error 2 > make: *** [all-gcc] Error 2 > Maurice -- Â Â Â Â Maurice Lombardi Laboratoire de Â Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex Â Â FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 4

/usr/local/gcc-3.4.6/configure: test: argument expected
by DUCARROZ Birgit 25 Nov '09

25 Nov '09

Hello, I try to install gpc on a solaris 10 x86 Done this: bash-3.00# gunzip gcc-3.4.6.tar.gz bash-3.00# tar -xvf gcc-3.4.6.tar bash-3.00# rm gcc-3.4.6.tar bash-3.00# ln -s /usr/local/gpc-20041017/p /usr/local/gcc-3.4.6/gcc/p bash-3.00# cd /usr/local/gpc-build/ bash-3.00# /usr/local/gcc-3.4.6/configure enable-languages=pascal gives me the following error: /usr/local/gcc-3.4.6/configure: test: argument expected Please can anyone help me? Kind regards, Birgit

2 1

Intel 64, GPC-installation, make fails
by Ernst-Ludwig.Bohnen＠t-online.de 24 Nov '09

24 Nov '09

Hallo, I am trying to install GPC (gpc-20060325, based on gcc-core-3.4.4) on a PC with Intel-Xeon 64 bit CPU and openSUSE 11.2. Make ends up with some mystical error lines, see below. Any suggestions? Ernst-Ludwig ..../configure --enable-languages=pascal --prefix=/usr/gnu <RET> ..../make <RET> .......... .......... ./auto-host.h:185:1: warning: "HAVE_DECL_GETOPT" redefined In file included from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcov.c:37: /tmp/root/install.gpc/gcc-3.4.4/gcc/tsystem.h:40:1: warning: this is the location of the previous definition In file included from /tmp/root/install.gpc/gcc-3.4.4/gcc/gcov-io.h:240, from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcov.c:51: ./auto-host.h:185:1: warning: "HAVE_DECL_GETOPT" redefined In file included from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcov.c:37: /tmp/root/install.gpc/gcc-3.4.4/gcc/tsystem.h:40:1: warning: this is the location of the previous definition In file included from /usr/include/features.h:371, from /usr/include/stdio.h:28, from /tmp/root/install.gpc/gcc-3.4.4/gcc/tsystem.h:79, from /tmp/root/install.gpc/gcc-3.4.4/gcc/libgcc2.c:41: /usr/include/gnu/stubs.h:7:27: gnu/stubs-32.h: No such file or directory make[2]: *** [libgcc/32/_muldi3.o] Error 1 make[1]: *** [libgcc.a] Error 2 make: *** [all-gcc] Error 2

1 0

anyfile and blockwrite
by Wolfgang Helbig 18 Nov '09

18 Nov '09

Hi, Using blockwrite with Anyfile surprises me: The type definitions are: byteFile= file of packed record b: eightbits end; eightbits = 0..255; And the variables: dvibuf: array [0..800] of eightbits; dvifile: byteFile; The file is opened by rewrite(dvifile, filename) and then written by procedure writeit(f: anyfile); begin blockwrite(f, dvibuf[0..211], 212) end; I expected to get a file with 212 bytes like this one: osx $ od -tu1 expected 0000000 247 2 1 131 146 192 28 59 0 0 0 0 3 232 27 32 0000020 84 101 88 32 111 117 116 112 117 116 32 50 48 48 57 46 0000040 49 49 46 49 56 58 49 57 49 57 139 0 0 0 1 0 0000060 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 * 0000120 0 0 0 255 255 255 255 141 159 242 0 0 142 160 2 131 0000140 51 218 141 160 253 134 204 38 141 145 20 0 0 243 0 75 0000160 241 96 121 0 10 0 0 0 10 0 0 0 5 99 109 114 0000200 49 48 171 104 97 108 108 111 142 142 159 24 0 0 141 146 0000220 0 232 96 163 49 142 140 248 0 0 0 42 1 131 146 192 0000240 28 59 0 0 0 0 3 232 2 155 51 218 1 213 193 71 0000260 0 2 0 1 243 0 75 241 96 121 0 10 0 0 0 10 0000300 0 0 0 5 99 109 114 49 48 249 0 0 0 151 2 223 0000320 223 223 223 223 0000324 But instead I get this file, the length is correct, but every byte occupies 32 bit, the higher bytes are not written at all. osx $ od -tu1 unexpected 0000000 247 0 0 0 2 0 0 0 1 0 0 0 131 0 0 0 0000020 146 0 0 0 192 0 0 0 28 0 0 0 59 0 0 0 0000040 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0000060 3 0 0 0 232 0 0 0 27 0 0 0 32 0 0 0 0000100 84 0 0 0 101 0 0 0 88 0 0 0 32 0 0 0 0000120 111 0 0 0 117 0 0 0 116 0 0 0 112 0 0 0 0000140 117 0 0 0 116 0 0 0 32 0 0 0 50 0 0 0 0000160 48 0 0 0 48 0 0 0 57 0 0 0 46 0 0 0 0000200 49 0 0 0 49 0 0 0 46 0 0 0 49 0 0 0 0000220 56 0 0 0 58 0 0 0 49 0 0 0 57 0 0 0 0000240 50 0 0 0 51 0 0 0 139 0 0 0 0 0 0 0 0000260 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0000300 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 * 0000320 All this is done with gpc version 20070904 on Mac OS X 10.6.2. I want to make minimal use of GPC extensions, thats why I didn't use the GPC byte for eight_bits or didn't use packed on subranges. I'd prefer to use packed file of eightbits instead, but GPC ignores packed for files. And then I'd like to use buffered output without changing the source file! Greetings, Wolfgang

2 1

howto install gpc on solaris x86?
by DUCARROZ Birgit 05 Nov '09

05 Nov '09

Hello, does anyone have some experience howto install GNU pascal on Solaris 10 x86 platform? I found for SPARC, but not for x86. And how does it work? Any suggestions would be appreciated! Kind regards, Birgit

2 1

how to write inline-assembly in gpc?
by jcyang 03 Nov '09

03 Nov '09

Since there is not offical reference,I got only one tutorial <a href="http://www.gnupascal.de/contrib/misc/gpcasm.zip"> gpcasm.zip </a>.But when I try to follow the tut and try the inline assembly example on my debian.The gpc was not happy with it. <pre> gnu_asm.pas : In procedure 'MyStupidDelay': gnu_asm.pas:3: error : can't find a register in class AREG while reloading asm </pre> Here is the code program gnu_asm; Procedure MyStupidDelay(time : integer); Begin Asm("0 : pushl $0xfffff 1 : decl(%%esp) jnz 1b addl $0x4, %%esp decl %%eax jnz 0b" : : "a" (time) : "eax" ); end; begin write("only for test"); end. Another question,are there any other refernece, tutorials, examples on inline assembly in gnu pascal. thanks.

2 1

Kubuntu AMD-64 Linux: WHAT no graphics?
by twixt＠cstone.net 14 Oct '09

14 Oct '09

I installed gpc and all required or recommended packages using aptitude. The manual apparently contains no mention of graphics output. But that's why I downloaded Pascal in the first place! Looking through the mailing list archives, I find mention of a GRX library. But when I do a search for "grx" within aptitude, I come up empty. All I want to do is create a 432 pixel x 378 pixel image with over 2000 different 24-bit colors, all in a very precise pattern, a fractal shape as a matter of fact. In the time it is taking me to find any programming language that will let me do this, I suppose I could do it manually with a graphics editor, although this would be somewhat tedious. I can create a 432x378 array of strings, where each string is the hexadecimal code for a 24-bit color. How can I turn this array into an image? Does anyone know of a programming language which DOES do graphics? Thanks for your patience. David Bush

5 4

AMD 64 Pascal build error
by twixt＠cstone.net 14 Oct '09

14 Oct '09

3 2

Kubuntu AMD 64: grx build error
by twixt＠cstone.net 11 Oct '09

11 Oct '09

Thanks for your help! Following the installation instructions, I was able to run "make -f makefile.x11" apparently without errors. I used the following choices when editing makedefs.grx: HAVE_LIBTIFF=y HAVE_LIBJPEG=y HAVE_LIBPNG=y NEED_ZLIB=y INCLUDE_PRINTING_CODE=n INCLUDE_BMP_CODE=y INCLUDE_GPC_SUPPORT=y INCLUDE_SHARED_SUPPORT=y INCLUDE_BGI_SUPPORT=y HAVE_UNIX_TOOLS=n BUILD_X86_64=n I left the rest of the makedefs.grx file alone. Then I went into the /test subdirectory and here is the log: david@Achernar:~/software/grx/grx248/grx248/test$ sudo make -f makefile.x11 [sudo] password for david: gcc -c -O2 -fno-strict-aliasing -Wall -m32 -D__XWIN__ -I../include arctest.c -o arctest.o In file included from arctest.c:21: test.h: In function ‘main’: test.h:88: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result gcc -s -m32 -s -o xarctest arctest.o ../lib/unix/libgrx20X.a -ltiff -ljpeg -lpng -lz -L/usr/X11R6/lib -lX11 -lm /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../libz.so when searching for -lz /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../libz.a when searching for -lz /usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz /usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz /usr/bin/ld: cannot find -lz collect2: ld returned 1 exit status make: *** [xarctest] Error 1 david@Achernar:~/software/grx/grx248/grx248/test$ What should I do? Thanks again! David

2 1

Re: More issues with EOLN, EOF, and the Pascal standard.
by samiam＠moorecad.com 24 Sep '09

24 Sep '09

1 0

Re: More issues with EOLN, EOF, and the Pascal standard.
by samiam＠moorecad.com 24 Sep '09

24 Sep '09

1 0

Re: More issues with EOLN, EOF, and the Pascal standard.
by samiam＠moorecad.com 24 Sep '09

24 Sep '09

1 0

Re: More issues with EOLN, EOF, and the Pascal standard.
by samiam＠moorecad.com 24 Sep '09

24 Sep '09

2 1

More issues with EOLN, EOF, and the Pascal standard.
by Chad Simmons 24 Sep '09

24 Sep '09

In a continuation of the thread: http://www.gnu-pascal.de/crystal/gpc/en/raw-mail10017.html Regarding conformance to the ISO 7185. It seems that GPC will correctly report EOLN before EOF even when none exists in the file. However, after successfully reading the end of line character, EOLN will still return true while EOF also simultaneously returns true. This has a tendency to give odd results. EOF and EOLN should be mutually exclusive. If the file doesn't properly have it's end of line marker before the end of the file, GPC can, should, and does currently insert the end of line into the buffer. But once it's been read, EOF should return true, and EOLN should not. I'm unfortunately not familiar enough with how gpc source is organized, so I'm not sure where to make the needed correction, in order to submit the patch. I would be willing to work on it however, if someone could point me in the right direction. Thanks, Chad Simmons The following program demonstrates the unusual behavior: PROGRAM GRADES (INPUT,OUTPUT); VAR SUM, COUNT, GRADE : INTEGER; BEGIN SUM := 0; COUNT := 0; WRITELN('ENTER GRADES AND PRESS CTRL-D WHEN FINISHED'); READ(GRADE); WHILE NOT EOF DO BEGIN SUM := SUM + GRADE; COUNT := COUNT + 1; IF EOLN THEN READ(CH); WRITELN('EOLN? ', EOLN); WRITELN('EOF? ', EOF); IF NOT EOF THEN READ(GRADE); END; WRITELN('TOTAL STUDENTS ', COUNT); WRITELN('CLASS AVERAGE ', SUM DIV COUNT); END. The output: $ ./grades ENTER GRADES AND PRESS CTRL-D WHEN FINISHED 20 30 40EOLN? False EOF? False EOLN? False EOF? False EOLN? True EOF? True TOTAL STUDENTS 3 CLASS AVERAGE 30 gpc -v output: $ gpc -v Using built-in specs. Configured with: ../src/configure -v --enable-languages=c,pascal --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --disable-libmudflap --enable-checking=release x86_64-linux-gnu Thread model: posix gpc version 20070904, based on gcc-4.1.3 20080301 (prerelease) (Ubuntu 2.1-4.1.2-19ubuntu1)

3 5

makefile problems
by Martin Kalbfuß 06 Sep '09

06 Sep '09

Thanks, unit path is the option I was looking for. I have a C background. But I forgot to mention that this is a library. So there's no main file. And the C part is needed to make some C macros and defines visible. It's a wrapper for the brand new allegro library. The keytypes are a long list of key names needed in two places. I decided to separate and include it. .I'm aware of --automake, and It makes the process much easier. But it's far to weak to replace a Makefile. Maybe some of the following things are wrong(hopefully): - no install target - no clean target - no support for building documentation - no dependency checking. (In my case allegro-4.9 for the examples) What's the way to go, when you like to release a library? For C I would use autotools and pkg-config. And I think It would be nice if there are going to be some macros for the use with autotools like an AC_PROG_CC equivalent AC_PROG_GPC which checks for the gpc compiler.

5 4

makefile problems
by Martin Kalbfuß 04 Sep '09

04 Sep '09

Hi, I'm very frustrated. I'm not able to get a working makefile for my project. It has the following directory tree: pallegro |_src | |_pallegro.pas | |_display.pas | |_keyboard.pas | |_altime.pas | |_define.c | |_keytypes.def |_Makefile pallegro.pas depends on everything keyboard.pas depends on display.pas, define.c and keytypes.def display.pas depends on define.c altime.pas depends on define.c define.c depends on nothing keytypes.def depends on nothing I'm not able to create a makefile. Especially the placement in the src directory produces problems. I get dependency problems all the time. Could someone show me a basic makefile? I don't know how to proceed. :-( ________________________________________________________________ Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/

2 1

Re: define loop
by Martin Kalbfuß 03 Sep '09

03 Sep '09

Ups. Sorry. I misunderstood the documentation. Thanks. ______________________________________________________ GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de

1 0

define loop
by Martin Kalbfuß 03 Sep '09

03 Sep '09

Hi again, I wonder what the loop define is good for and how I would use it. It would be nice if someone could show me an example. Thanks, Martin

3 2

exporting imported names with extended pascal style modules
by Martin Kalbfuß 03 Sep '09

03 Sep '09

Hi, I have two modules "keyboard" and "display" exporting some names with export = all; This works fine. I try to create a module importing all names of both at once. I tried: export = all; import aldisplay in 'display'; alkeyboard in 'keyboard'; But the imported names aren't exported. Is there a way to do this without exporting every single imported name? Thanks, Martin

2 1

Least significant byte
by Prof A Olowofoyeku (The African Chief) 02 Sep '09

02 Sep '09

Hi all Does anyone know how to return the lest significant byte of a given number? e.g. function least_significant_byteof (num: integer): byte; An algorithm in Pascal or C would be fine. Thanks, -- Best regards, The Chief

4 4

newbie questions!
by Arsha 14 Aug '09

14 Aug '09

Hi, I just downloaded Dev-Pas IDE 1.9.4.13 bundled with GPC + MinGW, and having tried to compile successfully a few simple programs but I cannot compile the examples provided by package like “WinHello” program. Can someone instruct me how to build those programs? P.S 1: When I open the “Windows Hello” project file and try to compile it I get the following error: Compile : “Error compiling resource file: E:/Dev-Pas/examples/WinHello/rsrc.o” Resource: “gcc: installation problem, cannot exec `cpp0': No such file or directory E:\Dev-Pas\bin\windres: preprocessing failed.” Compile log: “Building resource file... E:\Dev-Pas\bin\windres -i E:/Dev-Pas/examples/WinHello/rsrc.rc -o e:/dev-pas/examples/winhello/rsrc.o” P.S 2: What does mean that .jtp extension in the server page? P.S 3: Any other "optimization" command in GPC not available directly from IDE? -- View this message in context: http://www.nabble.com/newbie-questions%21-tp24936270p24936270.html Sent from the Gpc mailing list archive at Nabble.com.

3 7

Re: Bug report - Schemata bug
by Waldek Hebisch 01 Jun '09

01 Jun '09

Martin Kalbfuss wrote: Fixed quoting > > You tried to use automatic initialization of variable sized > > schema. Unfortunatly, it works only simplest cases (basically > > the schema parameters must be constants). > > > > There is a bug in the compiler: there should be reasonable > > error message instead of the above... > > > > But the same happens if I use > > new( table, map. width , map. height ); > > instead. Isn't it very useless if I can only use constants for dynamic memory? > You can allocate variable sized items unsing new. Simply you can not request automatic initialization of such items. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

Bug report - Schemata bug
by Martin Kalbfuß 31 May '09

31 May '09

I reduced my game code to the needed data types and code. The same happens if I use new. I'm not sure if this is really a compiler bug. I wrote another program doing the same, without this error. But I cannot find the bug. My compiler version is Using built-in specs. Configured with: ../src/configure -v --enable-languages=c,pascal --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --disable-libmudflap --enable-checking=release i486-linux-gnu Thread model: posix gpc version 20070904, based on gcc-4.1.3 20080420 (prerelease) (Debian 2.1-4.1.2-22) The error message is bug.pas:75: internal compiler error: in process_otherwise, at p/typecheck.c:4407 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>.

3 2

problems with schema parameter
by Martin Kalbfuß 30 May '09

30 May '09

I wrote the following code: PROCEDURE play( map : map_type ); VAR player1 : player_type( 'O', 'a', 'd', 'w', 's', red, right, 10, 10, 3 ); player2 : player_type( 'O', Crt.ksLeft, Crt.ksRight, Crt.ksUp, Crt.ksDown, green, left, 15, 15, 3 ); table : table_type_ptr; BEGIN new( table, map.width, map.height ); ... END; END; And here are the important types: x_coordinate_type = 1..table_width; x_dimension_type = 1..table_width; map_type( w, h, p1x, p1y, p2x, p2y : INTEGER ) = RECORD width : x_dimension_type VALUE w; height : y_dimension_type VALUE h; player1_pos : player_pos_type VALUE [ p1x; p1y ]; player2_pos : player_pos_type VALUE [ p2x; p2y ]; collision : BOOLEAN VALUE FALSE; data : ARRAY[ 1..h, 1..w ] OF CHAR; END; table_type( w, h : INTEGER ) = ARRAY[ 1..h, 1..w ] OF field_type; table_type_ptr = ^table_type; When I want to compile the code I get the following error: snake.pas: In procedure `play': snake.pas:203: internal compiler error: in process_otherwise, at p/typecheck.c:4407 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>. The problem is the call to new. Is this my fault?

2 1

ascii or scancodes?
by Martin Kalbfuß 29 May '09

29 May '09

Hi again, I have another problem with my text snake game. It's about the use of the keyboard functions of Crt. The player record has some fields holding the keys for changing the direction of the snake. I want the following key sets as standard. player 1: left -> a right -> d up -> w down -> s player 2: left -> arrow left right -> arrow right up -> arrow up down -> arrow down I found the scancodes for the arrow keys on the net, and they are working. But the scancodes I found for the letters doesn't. I also read that usb keyboards have different scancodes. Is it possible to use scancodes platform independent? Or are there ascii codes for the arrow keys, I could use?

2 1

timing functions?
by Martin Kalbfuß 28 May '09

28 May '09

Hi Community, I'm writing a small snake game with the CRT unit. I wan't to set up a timer for the snake movement. What is the best way to do so with gpc. If possible I would like to use ISO code. I found some functions, but they Thanks

2 1

Adding a global define
by Adriaan van Os 02 May '09

02 May '09

I have created a patch that adds a define to include/ansidecl.h. When I build the compiler with the patch, the build hangs as indicated below. My questions are: 1. What's going on ? 2. Is there a configuration file in gcc/p or gcc/p/rts that needs a manual rebuild after the patch ? 3. Is there a recommended way to add a define to the compilation of all files (including libiberty) ? Regards, Adriaan van Os stage1/xgcc -Bstage1/ -B/Developer/Pascal/gpc346u4/i386-apple-darwin10/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition -DHAVE_CONFIG_H -o xgcc gcc.o gccspec.o intl.o \ prefix.o version.o ../libiberty/libiberty.a -liconv ./xgcc -B./ -B/Developer/Pascal/gpc346u4/i386-apple-darwin10/bin/ -isystem /Developer/Pascal/gpc346u4/i386-apple-darwin10/include -isystem /Developer/Pascal/gpc346u4/i386-apple-darwin10/sys-include -L/Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../ld -dumpspecs > tmp-specs mv tmp-specs specs cd ../../gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" DESTDIR="../.." AR="` if [ -f /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ar ] ; then echo /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ar ; else if [ "i386-apple-darwin10" = "i386-apple-darwin10" ] ; then echo ar; else t='s,y,y,'; echo ar | sed -e $t ; fi; fi`" RANLIB="` if [ -f /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ranlib ] ; then echo /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ranlib ; else if [ "i386-apple-darwin10" = "i386-apple-darwin10" ] ; then echo ranlib; else t='s,y,y,'; echo ranlib | sed -e $t ; fi; fi`" RANLIB_TEST="" generated-files make[3]: Nothing to be done for `generated-files'. cd ../../gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" DESTDIR="../.." AR="` if [ -f /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ar ] ; then echo /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ar ; else if [ "i386-apple-darwin10" = "i386-apple-darwin10" ] ; then echo ar; else t='s,y,y,'; echo ar | sed -e $t ; fi; fi`" RANLIB="` if [ -f /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ranlib ] ; then echo /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ranlib ; else if [ "i386-apple-darwin10" = "i386-apple-darwin10" ] ; then echo ranlib; else t='s,y,y,'; echo ranlib | sed -e $t ; fi; fi`" RANLIB_TEST="" generated-files make[3]: Nothing to be done for `generated-files'. cd ../../gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" DESTDIR="../.." AR="` if [ -f /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ar ] ; then echo /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ar ; else if [ "i386-apple-darwin10" = "i386-apple-darwin10" ] ; then echo ar; else t='s,y,y,'; echo ar | sed -e $t ; fi; fi`" RANLIB="` if [ -f /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ranlib ] ; then echo /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ranlib ; else if [ "i386-apple-darwin10" = "i386-apple-darwin10" ] ; then echo ranlib; else t='s,y,y,'; echo ranlib | sed -e $t ; fi; fi`" RANLIB_TEST="" generated-files make[3]: Nothing to be done for `generated-files'. cd ../../gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" DESTDIR="../.." AR="` if [ -f /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ar ] ; then echo /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ar ; else if [ "i386-apple-darwin10" = "i386-apple-darwin10" ] ; then echo ar; else t='s,y,y,'; echo ar | sed -e $t ; fi; fi`" RANLIB="` if [ -f /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ranlib ] ; then echo /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ranlib ; else if [ "i386-apple-darwin10" = "i386-apple-darwin10" ] ; then echo ranlib; else t='s,y,y,'; echo ranlib | sed -e $t ; fi; fi`" RANLIB_TEST="" generated-files make[3]: Nothing to be done for `generated-files'. cd ../../gcc-3.4.6/gcc/p/rts && make -f Makefile.in srcdir=. GCC_VERSION="3.4.6" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" DESTDIR="../.." AR="` if [ -f /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ar ] ; then echo /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ar ; else if [ "i386-apple-darwin10" = "i386-apple-darwin10" ] ; then echo ar; else t='s,y,y,'; echo ar | sed -e $t ; fi; fi`" RANLIB="` if [ -f /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ranlib ] ; then echo /Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../binutils/ranlib ; else if [ "i386-apple-darwin10" = "i386-apple-darwin10" ] ; then echo ranlib; else t='s,y,y,'; echo ranlib | sed -e $t ; fi; fi`" RANLIB_TEST="" generated-files make[3]: Nothing to be done for `generated-files'. rm -rf p/docdemos ../../gcc-3.4.6/gcc/p/script/mkdir-p p/docdemos ../../gcc-3.4.6/gcc/p/script/extract-doc-demos -o p/docdemos ../../gcc-3.4.6/gcc/p/doc/*.texi ../../gcc-3.4.6/gcc/p/doc/generated/*.texi ../../gcc-3.4.6/gcc/p/doc/en/*.texi echo timestamp > "p/stamp-docdemos" make[2]: Circular libgcc.a <- pascal dependency dropped. if [ -f specs.ready ] ; then \ true; \ else \ echo timestamp > specs.ready; \ fi objext='.o' \ LIB1ASMFUNCS='' \ LIB2FUNCS_ST='_eprintf __gcc_bcmp' \ LIBGCOV='_gcov _gcov_merge_add _gcov_merge_single _gcov_merge_delta' \ LIB2ADD='' \ LIB2ADD_ST='' \ LIB2ADD_SH='' \ LIB2ADDEH='../../gcc-3.4.6/gcc/unwind-dw2.c ../../gcc-3.4.6/gcc/unwind-dw2-fde-darwin.c ../../gcc-3.4.6/gcc/unwind-sjlj.c ../../gcc-3.4.6/gcc/unwind-c.c' \ LIB2ADDEHSTATIC='../../gcc-3.4.6/gcc/unwind-dw2.c ../../gcc-3.4.6/gcc/unwind-dw2-fde-darwin.c ../../gcc-3.4.6/gcc/unwind-sjlj.c ../../gcc-3.4.6/gcc/unwind-c.c' \ LIB2ADDEHSHARED='../../gcc-3.4.6/gcc/unwind-dw2.c ../../gcc-3.4.6/gcc/unwind-dw2-fde-darwin.c ../../gcc-3.4.6/gcc/unwind-sjlj.c ../../gcc-3.4.6/gcc/unwind-c.c' \ LIB2ADDEHDEP='unwind.inc unwind-dw2-fde.h unwind-dw2-fde.c' \ LIBUNWIND='' \ LIBUNWINDDEP='' \ SHLIBUNWIND_LINK='' \ SHLIBUNWIND_INSTALL='' \ FPBIT='' \ FPBIT_FUNCS='_pack_sf _unpack_sf _addsub_sf _mul_sf _div_sf _fpcmp_parts_sf _compare_sf _eq_sf _ne_sf _gt_sf _ge_sf _lt_sf _le_sf _unord_sf _si_to_sf _sf_to_si _negate_sf _make_sf _sf_to_df _sf_to_tf _thenan_sf _sf_to_usi _usi_to_sf' \ LIB2_DIVMOD_FUNCS='_divdi3 _moddi3 _udivdi3 _umoddi3 _udiv_w_sdiv _udivmoddi4' \ DPBIT='' \ DPBIT_FUNCS='_pack_df _unpack_df _addsub_df _mul_df _div_df _fpcmp_parts_df _compare_df _eq_df _ne_df _gt_df _ge_df _lt_df _le_df _unord_df _si_to_df _df_to_si _negate_df _make_df _df_to_sf _df_to_tf _thenan_df _df_to_usi _usi_to_df' \ TPBIT='' \ TPBIT_FUNCS='_pack_tf _unpack_tf _addsub_tf _mul_tf _div_tf _fpcmp_parts_tf _compare_tf _eq_tf _ne_tf _gt_tf _ge_tf _lt_tf _le_tf _unord_tf _si_to_tf _tf_to_si _negate_tf _make_tf _tf_to_df _tf_to_sf _thenan_tf _tf_to_usi _usi_to_tf' \ MULTILIBS=` ./xgcc -B./ -B/Developer/Pascal/gpc346u4/i386-apple-darwin10/bin/ -isystem /Developer/Pascal/gpc346u4/i386-apple-darwin10/include -isystem /Developer/Pascal/gpc346u4/i386-apple-darwin10/sys-include -L/Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../ld --print-multi-lib` \ EXTRA_MULTILIB_PARTS='' \ SHLIB_LINK='' \ SHLIB_INSTALL='' \ SHLIB_EXT='' \ SHLIB_MULTILIB='' \ SHLIB_MKMAP='' \ SHLIB_MKMAP_OPTS='' \ SHLIB_MAPFILES='' \ SHLIB_NM_FLAGS='-pg' \ MULTILIB_OSDIRNAMES='' \ mkinstalldirs='/bin/sh ../../gcc-3.4.6/gcc/mkinstalldirs' \ /bin/sh mklibgcc > tmp-libgcc.mk xgcc: unrecognized option `-isystem' xgcc: unrecognized option `-isystem' mv tmp-libgcc.mk libgcc.mk ./xgcc -B./ -B/Developer/Pascal/gpc346u4/i386-apple-darwin10/bin/ -isystem /Developer/Pascal/gpc346u4/i386-apple-darwin10/include -isystem /Developer/Pascal/gpc346u4/i386-apple-darwin10/sys-include -L/Volumes/P300/Users/adriaan/gnu/gpc/gpc346u4/build/gcc/../ld -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc-3.4.6/gcc -I../../gcc-3.4.6/gcc/. -I../../gcc-3.4.6/gcc/../include \ -c ../../gcc-3.4.6/gcc/config/darwin-crt2.c -o crt2.o xgcc: unrecognized option `-isystem' xgcc: unrecognized option `-isystem' xgcc: unrecognized option `-DIN_GCC' xgcc: unrecognized option `-isystem' xgcc: unrecognized option `-I.' xgcc: unrecognized option `-I.' xgcc: unrecognized option `-I../../gcc-3.4.6/gcc' xgcc: unrecognized option `-I../../gcc-3.4.6/gcc/.' xgcc: unrecognized option `-I../../gcc-3.4.6/gcc/../include'

2 3

Aborting compilation
by Pascal Viandier 30 Apr '09

30 Apr '09

Hi all, Is there a gpc directive that can issue a message and then abort the compilation? I tried {$M ...} but it does not stop the compilation process. My goal is to prohibit the use of FillChar() in our code by stopping the compilation when the compiler finds one. I used a macro that redefines FillChar(a,b,c); as {$M ERROR: Fillchar use is not allowed!} but this does not seem sufficient to prevent its usage and its destructive effect on strings :-( If there is no such compiler directive, any other suggestion is welcome. Regards Pascal Viandier

2 2

[Fwd: GCC 4.4.0 Released]
by Adriaan van Os 23 Apr '09

23 Apr '09

-------- Original Message -------- Subject: GCC 4.4.0 Released Date: Thu, 23 Apr 2009 09:12:30 +0200 From: Jakub Jelinek <jakub(a)redhat.com> Reply-To: Jakub Jelinek <jakub(a)redhat.com> To: gcc-announce(a)gcc.gnu.org, gcc(a)gcc.gnu.org The GNU Compiler Collection version 4.4.0 has been released. GCC 4.4.0 is a major release, containing substantial new functionality not available in GCC 4.3.x or previous GCC releases. See: http://gcc.gnu.org/gcc-4.4/changes.html for more information about changes in GCC 4.4.0. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in gcc/gcc-4.4.0/ subdirectory. If you encounter difficulties using GCC 4.4, please do not contact me directly. Instead, please visit http://gcc.gnu.org for information about getting help. As always, a vast number of people contributed to this GCC releases -- far too many to thank individually!

1 0

Re: Stupid Installation Question
by John L. Ries 19 Apr '09

19 Apr '09

Wasn't aware that someone had GPC working with the GCC 4 back end, but I'm happy to hear it (must not have been paying enough attention to the list). Anyway, I now have a working GPC on my laptop and I have verified that my existing GCC (4.2.3) still works. Thanks to both you and the Chief for your help. --------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------| On Sun, 19 Apr 2009, Yahoo - Christopher Butler wrote: > John L. Ries wrote: >> How does one go about compiling and installing GPC under Linux in such >> a way as to not interfere with the GCC 4 one already has? I've ended >> up installing and ripping out GPC on the Linux side on three different >> occasions (always Slackware) because I was no longer able to use GCC 4 >> (as much as I hate C, it is useful to have a C compiler around for >> compiling free software). Seems that the GCC 3 libraries GPC needs >> end up pre-empting the GCC 4 libraries. If people need exact error >> messages, I can go ahead and redo the install, so I can remember what >> they are (it's been a while). >> >> I did recently install that other free Pascal compiler, only to >> discover that it wouldn't compile my nearly completed project from 5 >> years ago (not even my Borland-style units), so I really would like to >> have GPC back on my Linux boxes without the hassle of changing distros. >> >> BTW: As much as I appreciate Kevan Hashemi's making a pre-compiled >> Linux GPC binary available, my preference would be for a 64-bit build. >> >> --------------------------| >> John L. Ries | >> Salford Systems | >> Phone: (619)543-8880 x107 | >> or (435)867-8885 | >> --------------------------| >> > > John > > In response to your email below is exactly what I do to install GPC on > Fedora 9 32 Linux. > > Download the following files to your home directory:- > > GCC > > http://ftp.gnu.org/gnu/gcc/gcc-4.1.2/gcc-4.1.2.tar.bz2 > > Or > > ftp://ftp.gnu.org/gnu/gcc/gcc-4.1.2/gcc-4.1.2.tar.bz2 > > GPC > > http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20070904.tar.bz2 > > ***** Commands should be typed exactly ***** > > mkdir src > mkdir src/build > > tar -xf gcc-4.1.2.tar.bz2 -C src > > tar -xf gpc-20070904.tar.bz2 -C src > > cd src/gpc-20070904/ > > cp -Rp ../gcc-4.1.2/gcc > > cd ../build > > ../gcc-4.1.2/configure --prefix=/usr/local/gpc --program-suffix=-4.1.2 > --enable-debug --enable-languages=c,pascal > > make DEBUG=1 > > ***** After compiling become Root and install ***** > > make install > > cd /usr/local/bin > ln -sf ../gpc/bin/gpc-4.1.2 gpc > ln -sf ../gpc/bin/gpc-run gpc-run > ln -sf ../gpc/bin/gpidump gpidump > ln -sf ../gpc/bin/binobj binobj > > I hope this has been useful and wish you the best of luck. > > As regards of GPC on Linux 64 bit machine, you will have to rewrite GPC. > > Chris > > > > > >

1 0

Stupid Installation Question
by John L. Ries 19 Apr '09

19 Apr '09

How does one go about compiling and installing GPC under Linux in such a way as to not interfere with the GCC 4 one already has? I've ended up installing and ripping out GPC on the Linux side on three different occasions (always Slackware) because I was no longer able to use GCC 4 (as much as I hate C, it is useful to have a C compiler around for compiling free software). Seems that the GCC 3 libraries GPC needs end up pre-empting the GCC 4 libraries. If people need exact error messages, I can go ahead and redo the install, so I can remember what they are (it's been a while). I did recently install that other free Pascal compiler, only to discover that it wouldn't compile my nearly completed project from 5 years ago (not even my Borland-style units), so I really would like to have GPC back on my Linux boxes without the hassle of changing distros. BTW: As much as I appreciate Kevan Hashemi's making a pre-compiled Linux GPC binary available, my preference would be for a 64-bit build. --------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|

2 2

Stupid Installation Question # 2
by John L. Ries 19 Apr '09

19 Apr '09

Probably related to the first. I notice that Gentoo masks its GPC e-build. Are there any precautions to be observed when unmasking it so it can be installed? --------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|

1 0

Re: Linux Binaries and Makefile
by Kevan Hashemi 30 Mar '09

30 Mar '09

Dear Prof O, > On your "desktop" in Linux? That sounds odd to me. Everything I do is a bit odd. > If you don't know what you're doing, yes. That's precisely my point: I don't know what I'm doing. > An exaggeration. As I said, on a modern PC (e.g., an Athlon XP 3800), it > only takes a few minutes I was not refering to "compile time". I was referring to "Where on earth do I get a non-broken version of sed? What is sed anyway? Why won't patch work on this machine with these diff files? Is it patch that's not working or is it just that I'm a retard? What does it mean that the .tar.bz.tar archive is in an unrecognizable format?" Compiling GPC will be four hours work for me, minimum. > If you find one, it may not work. So far, that 20041218 distribution of binaries has worked on every single one of the two dozen machines we have loaded it onto. Why would the 20070904 distribution fail to work? Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

4 7

Linking
by Hünniger, Dirk 25 Mar '09

25 Mar '09

Hello, I am trying to compile an old pascal code with gpc. There was a problem with the autolinker, symbols collided between ncurses and grx (I think) ,so I removed it and build a command line manually in a makefile. I turned off the graphics and everything worked fine, it compiled linked and produced the desired output. Now I am trying to turn the graphics on again. The problem is that the linker complains that the following symbols could not be found. __gr_setcolor' `setlinestyle' `outtextxy' `setwritemode' `setviewport' `clearviewport' `__gr_getfillsettings' `setfillstyle' `settextstyle' `__gr_closegraph' So I edited the graph unit and replaced the references to these symbols by impleamantations that do nothing. No everything compiles again, a graphics window appears, but nothing is drawn into it. Here is my compile and link command line: c:\dev_gpc\bin\gpc c:\dev_gpc\examples\gbr\brichten.pas -oc:\dev_gpc\examples\gbr\richt.exe -lgrx20 c:\dev_gpc\units/graph.o -lgrx20 -lgdi32 c:\dev_gpc\units/dos.o c:\dev_gpc\units/grx.o c:\dev_gpc\units/gpc.o c:\dev_gpc\units/system.o c:\dev_gpc\units/mathe.o c:\dev_gpc\units/crt.o c:\dev_gpc\units/crtc.o -lpanel -lpdcurses c:\dev_gpc\units/math_nst.o c:\dev_gpc\units/br_var1.o c:\dev_gpc\units/br_var2.o c:\dev_gpc\units/br_proz.o c:\dev_gpc\units/br_plan.o c:\dev_gpc\units/geometri.o c:\dev_gpc\units/br_bili.o c:\dev_gpc\units/br_dio.o c:\dev_gpc\units/br_ko_g.o c:\dev_gpc\units/grafikpl.o -fno-inline -s -fno-io-checking -fno-range-checking -fimplicit-result -O1 -Wno-warnings -fno-assertions -fextended-syntax -fignore-function-results -fcstrings-as-strings -fpointer-arithmetic -march=i486 --no-autolink --no-automake -funit-path=c:\dev_gpc\units;c:\dev_gpc\examples\GBR\UNIT -funit-destination-path=c:\dev_gpc\units -Bc:\dev_gpc\lib\ -Bc:\dev_gpc\lib\gcc\mingw32\3.4.5\ -funit-path=C:\dev_gpc\examples\GBR\INC;C:\dev_gpc\examples\GBR\UNIT --no-autolink -LC:\dev_gpc\lib Note that -lgrx20 is given and that -no-autolink is given. I also analyed libgrx20.a with nm. It told me that a symbol. `_setlinestyle' does existis. But replacing `setlinestyle' with `_setlinestyle' in the graph library caused the linker to complain that the symbol `_setlinestyle' was not resolved. So my basic question is how can I turn on the graphics. Yours Dirk

2 1

Solved: Linking
by Hünniger, Dirk 25 Mar '09

25 Mar '09

I did not know that the order of the command line arguments is important now everything works fine

1 0

Re: instal gnu pascal
by samiam＠moorecad.com 24 Feb '09

24 Feb '09

2 1

Re: instal gnu pascal
by samiam＠moorecad.com 23 Feb '09

23 Feb '09

2 1

instal gnu pascal
by Palmerim Soares 23 Feb '09

23 Feb '09

Help! I use Windows XP. I just want to instal and use GNU pascal but it seens to be very very very difficult!!!!!! What i have to do to simply instal and use GNU Pascal without guesses and a lot of complications????????????? Thanks for your help Palmerim

2 1

With statement behaviour for objects
by Adriaan van Os 21 Feb '09

21 Feb '09

Any comments on <http://bugs.freepascal.org/view.php?id=13210> ? Regards, Adriaan van Os

3 2

GNU Pascal and warnings.
by Lennart Thelander 19 Feb '09

19 Feb '09

Hello. For quite many functions/Procedures, I get two warnings: warning: frame size too large for reliable stack checking warning: try reducing the number of local variables Say what? Reducing the number of local variables? Here's an example: PROCEDURE TTextEditItem.HandleKey(VAR theEvent:EventRecord); VAR i : SInt16; pt : Point; theChr : Char; theKey : SInt16; shift : BOOLEAN; option : BOOLEAN; control : BOOLEAN; command : BOOLEAN; lineHeight, ascent : SInt16; theStyle : TextStyle; I say that's a small amount of (small) local variables, so how can there be too many? And what is a "frame" and how can I reduce its size? Or better: How do I allow for a larger frame size? This is GNU Pascal 3.4.6u2 on Mac OS X and Xcode 2.5. Regards Lennart Thelander System Developer Lennart.Thelander(a)atex.com Phone +46 (0) 42 25 39 05 Fax +46 (0) 42 25 39 29 Atex Media AB Garnisonsgatan 10C S-254 66 Helsingborg SWEDEN Bringing new life to your media business www.atex.com THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

3 3

[Commit] gdb/pascal language 2 or 4 byte char support in strings
by Pierre Muller 10 Feb '09

10 Feb '09

I committed the patch below to add support for fixed width chars greater than 1 for pascal language. This works nicely for Free Pascal, I couldn't test it for GPC because I didn't find out if those kind of char are supported... Pierre Muller Pascal language support maintainer for GDB ChangeLog entry: 2009-02-08 Pierre Muller <muller(a)ics.u-strasbg.fr> * p-lang.c (is_pascal_string_type): Fix comment. Determine exact size of char elements for GPC strings. (pascal_printstr): Handle char width of 2 or 4. * p-valprint.c (pascal_val_print): Handle char of width 2 or 4. Index: gdb/p-lang.c =================================================================== RCS file: /cvs/src/src/gdb/p-lang.c,v retrieving revision 1.45 diff -u -p -r1.45 p-lang.c --- gdb/p-lang.c 5 Feb 2009 12:16:25 -0000 1.45 +++ gdb/p-lang.c 9 Feb 2009 23:54:58 -0000 @@ -86,7 +86,7 @@ pascal_main_name (void) } /* Determines if type TYPE is a pascal string type. - Returns 1 if the type is a known pascal type + Returns a positive value if the type is a known pascal string type. This function is used by p-valprint.c code to allow better string display. If it is a pascal string type, then it also sets info needed to get the length and the data of the string @@ -126,14 +126,20 @@ is_pascal_string_type (struct type *type && strcmp (TYPE_FIELDS (type)[0].name, "Capacity") == 0 && strcmp (TYPE_FIELDS (type)[1].name, "length") == 0) { - if (length_pos) + struct type *char_type; + if (length_pos) *length_pos = TYPE_FIELD_BITPOS (type, 1) / TARGET_CHAR_BIT; - if (length_size) + if (length_size) *length_size = TYPE_LENGTH (TYPE_FIELD_TYPE (type, 1)); - if (string_pos) + if (string_pos) *string_pos = TYPE_FIELD_BITPOS (type, 2) / TARGET_CHAR_BIT; /* FIXME: how can I detect wide chars in GPC ?? */ - if (char_size) + char_type = TYPE_FIELD_TYPE (type,2); + if (char_size && TYPE_CODE (char_type) == TYPE_CODE_ARRAY) + { + *char_size = TYPE_LENGTH (TYPE_TARGET_TYPE (char_type)); + } + else if (char_size) *char_size = 1; if (arrayname) *arrayname = TYPE_FIELDS (type)[2].name; @@ -218,7 +224,8 @@ pascal_printstr (struct ui_file *stream, /* If the string was not truncated due to `set print elements', and the last byte of it is a null, we don't print that, in traditional C style. */ - if ((!force_ellipses) && length > 0 && string[length - 1] == '\0') + if ((!force_ellipses) && length > 0 + && extract_unsigned_integer (string + (length - 1) * width, width) == 0) length--; if (length == 0) @@ -234,6 +241,7 @@ pascal_printstr (struct ui_file *stream, unsigned int rep1; /* Number of repetitions we have detected so far. */ unsigned int reps; + unsigned long int current_char; QUIT; @@ -243,9 +251,13 @@ pascal_printstr (struct ui_file *stream, need_comma = 0; } + current_char = extract_unsigned_integer (string + i * width, width); + rep1 = i + 1; reps = 1; - while (rep1 < length && string[rep1] == string[i]) + while (rep1 < length + && extract_unsigned_integer (string + rep1 * width, width) + == current_char) { ++rep1; ++reps; @@ -261,7 +273,7 @@ pascal_printstr (struct ui_file *stream, fputs_filtered ("', ", stream); in_quotes = 0; } - pascal_printchar (string[i], stream); + pascal_printchar (current_char, stream); fprintf_filtered (stream, " <repeats %u times>", reps); i = rep1 - 1; things_printed += options->repeat_count_threshold; @@ -269,8 +281,7 @@ pascal_printstr (struct ui_file *stream, } else { - int c = string[i]; - if ((!in_quotes) && (PRINT_LITERAL_FORM (c))) + if ((!in_quotes) && (PRINT_LITERAL_FORM (current_char))) { if (options->inspect_it) fputs_filtered ("\\'", stream); @@ -278,7 +289,7 @@ pascal_printstr (struct ui_file *stream, fputs_filtered ("'", stream); in_quotes = 1; } - pascal_one_char (c, stream, &in_quotes); + pascal_one_char (current_char, stream, &in_quotes); ++things_printed; } } Index: gdb/p-valprint.c =================================================================== RCS file: /cvs/src/src/gdb/p-valprint.c,v retrieving revision 1.59 diff -u -p -r1.59 p-valprint.c --- gdb/p-valprint.c 3 Jan 2009 05:57:52 -0000 1.59 +++ gdb/p-valprint.c 9 Feb 2009 23:54:58 -0000 @@ -79,7 +79,7 @@ pascal_val_print (struct type *type, con print_spaces_filtered (2 + 2 * recurse, stream); } /* For an array of chars, print with string syntax. */ - if (eltlen == 1 + if ((eltlen == 1 || eltlen == 2 || eltlen == 4) && ((TYPE_CODE (elttype) == TYPE_CODE_INT) || ((current_language->la_language == language_pascal) && (TYPE_CODE (elttype) == TYPE_CODE_CHAR))) @@ -93,14 +93,15 @@ pascal_val_print (struct type *type, con /* Look for a NULL char. */ for (temp_len = 0; - (valaddr + embedded_offset)[temp_len] + extract_unsigned_integer (valaddr + embedded_offset + + temp_len * eltlen, eltlen) && temp_len < len && temp_len < options->print_max; temp_len++); len = temp_len; } - LA_PRINT_STRING (stream, valaddr + embedded_offset, len, 1, 0, - options); + LA_PRINT_STRING (stream, valaddr + embedded_offset, len, + eltlen, 0, options); i = len; } else @@ -165,14 +166,17 @@ pascal_val_print (struct type *type, con /* For a pointer to char or unsigned char, also print the string pointed to, unless pointer is null. */ - if (TYPE_LENGTH (elttype) == 1 - && (TYPE_CODE (elttype) == TYPE_CODE_INT - || TYPE_CODE(elttype) == TYPE_CODE_CHAR) + if (((TYPE_LENGTH (elttype) == 1 + && (TYPE_CODE (elttype) == TYPE_CODE_INT + || TYPE_CODE (elttype) == TYPE_CODE_CHAR)) + || ((TYPE_LENGTH (elttype) == 2 || TYPE_LENGTH (elttype) == 4) + && TYPE_CODE (elttype) == TYPE_CODE_CHAR)) && (options->format == 0 || options->format == 's') && addr != 0) { /* no wide string yet */ - i = val_print_string (addr, -1, 1, stream, options); + i = val_print_string (addr, -1, TYPE_LENGTH (elttype), stream, + options); } /* also for pointers to pascal strings */ /* Note: this is Free Pascal specific:

2 2

Re: Write doesn't work with CRT
by Alexey Kotlyarov 25 Jan '09

25 Jan '09

> Depending on what you want to do, > either > writeln("sqrt(-1)"); > or > writeln(sqrt(1)); > works. I'm sorry, I haven't made it clear the first time. So: With CRT, all writeln do nothing. For example: uses crt; begin writeln('OK') end. produces nothing. uses crt; begin writeln('OK'); writeln(sqrt(-1)) end. produces just the error message from sqrt(-1), NOT 'OK'. Same programs without "uses crt;" both include 'OK' (the latter before the error message). > > You might try: > > program testcrt; > uses gpc, crt; > begin > writeln('OK'); > sleep(10); > writeln(sqrt(-1)); > end. Now I understand more about the problem. If I put the CRT unit in, each write will actually be to some virtual screen appearing on top of my console and disappearing after program finished. As all test programs above finish quickly, I simply can't see it. Therefore, this sample: program testcrt; uses gpc, crt; begin writeln('OK'); readln end. works as expected, but there is nothing left on the console after it ran. Is this by design? Because I might have programs which use CRT for every kind of things and I still must see their output.

3 2

Write doesn't work with CRT
by Alexey Kotlyarov 25 Jan '09

25 Jan '09

Being compiled version of GPC installed on Ubuntu, the following very simple program fails to produce any output: program testcrt; uses crt; begin writeln('OK'); writeln(sqrt(-1)); { error } end. $ gpc --automake testcrt.pas -o testcrt $ ./testcrt ./testcrt: argument to `SqRt' is < 0 (error #708 at 40b6c6) Notice the absence of OK. Similarly, removing error line makes program produce no output. Removing 'uses crt;' restores normal behavior. Version info and such: $ gpc --version gpc 20070904, based on gcc-4.1.3 20080420 (prerelease) (Ubuntu 2.1-4.1.2-22ubuntu1) Copyright (C) 2006 Free Software Foundation, Inc. $ uname -a Linux flower2 2.6.27-11-generic #1 SMP Fri Jan 23 13:58:13 UTC 2009 x86_64 GNU/Linux Any ideas of how to fix this?

3 5

LLVM
by Adriaan van Os 25 Jan '09

25 Jan '09

I would like to draw your all attention to the LLVM compiler infrastructure <http://llvm.org/>. I hear good things about it from people writing compiler front-ends for it. There is also the clang front-end <http://clang.llvm.org/> project. LLVM may in the future replace GCC in many software projects. It may be a good idea to get somehow involved. Regards, Adriaan van Os

1 0

X CODE 3.1 AND INTEGRATION PROBLEMS
by MICHAEL MCNEESE 21 Jan '09

21 Jan '09

I recently added GNU Pascal to my inventory of languages in X Code 3.1 along with the integration kit. Unfortunately, Pascal does not show up in the X Code enviroment. Its possible that upon installation the it simply is not indexed properly. Does anyone have any suggestions? mike

2 2

New version?
by leledumbo 06 Jan '09

06 Jan '09

Will there be any new version of gpc? Or at least the latest one (20070904) with gcc 4.2.X or 4.3.X integration? -- View this message in context: http://www.nabble.com/New-version--tp21308910p21308910.html Sent from the Gpc mailing list archive at Nabble.com.

1 0

Linux Binaries and Makefile
by Kevan Hashemi 01 Jan '09

01 Jan '09

Dear GPC, The African Chief maintains the Windows version of GPC, now using 20070904 sources. Adriaan maintains the MacOS version, now using 20070904 sources. I think the outstanding question for Prince and me is the Linux version. There is no binary distribution of the 20070904 GPC that I can find. I use the 20041218 version on Linux. I suppose most Linux users are happy to compile GPC from sources. But I'm not a Linux expert: I just port my code to Linux for my Linux users. So I'm stuck with 20041218, and my code has to remain compatible with the older GPC. (I have a bunch of compiler directives to get the module names right.) Suppose I wanted to compile the 20070904 sources on Linux. How would I go about it? Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

8 21

Turning Off Specific Compiler Warnings
by Yang Lao 01 Jan '09

01 Jan '09

Is there a way to turn off specific compiler warnings? The particular warning that gets in the way of the more helpful ones is: warning: missing string capacity - assuming 255

3 4

Linux Binaries and Makefile
by Mario Fetka 24 Dec '08

24 Dec '08

Hallo, i have read trough the mail archive : " From: Prince Riley Subject: Linux Binaries and Makefile Date: 15 Dec 2008, 16:32:20 ..... There's been a suggestion to have a repository set up on Sourceforge which is a very well known open source project repository. If anyone would like to suggest another site, please do so. .... " my suggestion is to setup the version controllsystem on gnu-pascal.de and a bugtracker if needed mailinglist already exists my second suggestion is to create repositories for the different os's on gnu-pascal.de for ex: packages.gnu-pascal.de/deb for debian/ubuntu packages.gnu-pascal.de/mandriva packages.gnu-pascal.de/fedora packages.gnu-pascal.de/suse just my 2 euro Cent Mario

4 4

Re: Linux Binaries and Makefile
by Prof A Olowofoyeku (The African Chief) 24 Dec '08

24 Dec '08

On 16 Dec 2008 at 10:49 Kevan Hashemi wrote: >I downloaded to my Linux machine (home folder, not desktop). >I extracted. I see the pascal folder. I run pascal/bin/gpc. sudo tar -zxvf gpc-20070904.i686-pc-linux-gnu.tar.gz -C / export PATH=$PATH:/pascal/bin Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

4 9

Re: Linux Binaries and Makefile
by Yang Lao 22 Dec '08

22 Dec '08

Per distro setups. On Sun, Dec 21, 2008 at 5:33 PM, Martin Marques <mmarques(a)unl.edu.ar> wrote: > What situation are you talking of? > > Yang Lao escribió: > >> Please do not do this. The Linux Standard Base exists in order to avoid >> this situation. >> >> On Sun, Dec 21, 2008 at 4:08 AM, Mario Fetka <mario.fetka(a)gmail.com<mailto: >> mario.fetka(a)gmail.com>> wrote: >> >> >> my suggestion is to setup the version controllsystem on >> gnu-pascal.de <http://gnu-pascal.de> >> and a bugtracker if needed >> mailinglist already exists >> >> my second suggestion is to create repositories for the different os's >> on gnu-pascal.de <http://gnu-pascal.de> >> >> for ex: >> >> packages.gnu-pascal.de/deb <http://packages.gnu-pascal.de/deb> for >> debian/ubuntu >> packages.gnu-pascal.de/mandriva < >> http://packages.gnu-pascal.de/mandriva> >> packages.gnu-pascal.de/fedora >> packages.gnu-pascal.de/suse >> <http://packages.gnu-pascal.de/fedorapackages.gnu-pascal.de/suse> >> >> just my 2 euro Cent >> >> Mario >> >> >> >> >> >> >

1 0

Re: Turning Off Specific Compiler Warnings
by Adriaan van Os 22 Dec '08

22 Dec '08

(repost) Yang Lao wrote: > Is there a way to turn off specific compiler warnings? In general {$local W-} DoSomethingPotentiallyDangerous; {$endlocal} or on the command-line -Wno-xxx (e.g. -Wno-cast-align) > The particular warning that gets in the way of the more helpful ones is: > > warning: missing string capacity - assuming 255 but I don't know of an xxx for this particular warning. Regards, Adriaan van Os

1 0

Linux Binaries and Makefile
by gmail.com 20 Dec '08

20 Dec '08

Hallo, i have read trough the mail archive : " From: Prince Riley Subject: Linux Binaries and Makefile Date: 15 Dec 2008, 16:32:20 ..... There's been a suggestion to have a repository set up on Sourceforge which is a very well known open source project repository. If anyone would like to suggest another site, please do so. .... " my suggestion is to setup the version controllsystem on gnu-pascal.de and a bugtracker if needed mailinglist already exists my second suggestion is to create repositories for the different os's on gnu-pascal.de for ex: packages.gnu-pascal.de/deb for debian/ubuntu packages.gnu-pascal.de/mandriva packages.gnu-pascal.de/fedora packages.gnu-pascal.de/suse just my 2 euro Cent Mario

1 0

[Fwd: Fwd: GPC Home Page]
by Adriaan van Os 09 Dec '08

09 Dec '08

Forwarding from a private email. -------- Original Message -------- Subject: Fwd: GPC Home Page Date: Mon, 8 Dec 2008 11:46:16 -0600 From: Prince Riley <wmarketing3(a)gmail.com> To: Adriaan van Os <gpc(a)microbizz.nl> References: <48187967.3080904(a)brandeis.edu> <48187E48.8000302(a)microbizz.nl> Hello I was following this thread and I have the same question, where are the Linux and MinGW binaries for this? Thanks Prince ---------- Forwarded message ---------- From: *Adriaan van Os* <gpc(a)microbizz.nl <mailto:gpc@microbizz.nl>> Date: Wed, Apr 30, 2008 at 8:12 AM Subject: Re: GPC Home Page To: gpc(a)gnu.de <mailto:gpc@gnu.de> Kevan Hashemi wrote: Where can I get the latest GPC binaries for MacOS, Linux, and MinGW? If the binaries are not available, where can I download the latest source files? The Mac OS X version has recently been updated to use gpc-20070904. As was announced on this list on April 15, sources, binaries and a build script for Mac OS X are available from my website <http://www.microbizz.nl/gpc.html>. Regards, Adriaan van Os

2 1

[Fwd: Fwd: GPC Home Page]
by Adriaan van Os 09 Dec '08

09 Dec '08

Forwarding from a private email. -------- Original Message -------- Subject: Fwd: GPC Home Page Date: Mon, 8 Dec 2008 11:46:16 -0600 From: Prince Riley <wmarketing3(a)gmail.com> To: Adriaan van Os <gpc(a)microbizz.nl> References: <48187967.3080904(a)brandeis.edu> <48187E48.8000302(a)microbizz.nl> Hello I was following this thread and I have the same question, where are the Linux and MinGW binaries for this? Thanks Prince ---------- Forwarded message ---------- From: *Adriaan van Os* <gpc(a)microbizz.nl <mailto:gpc@microbizz.nl>> Date: Wed, Apr 30, 2008 at 8:12 AM Subject: Re: GPC Home Page To: gpc(a)gnu.de <mailto:gpc@gnu.de> Kevan Hashemi wrote: Where can I get the latest GPC binaries for MacOS, Linux, and MinGW? If the binaries are not available, where can I download the latest source files? The Mac OS X version has recently been updated to use gpc-20070904. As was announced on this list on April 15, sources, binaries and a build script for Mac OS X are available from my website <http://www.microbizz.nl/gpc.html>. Regards, Adriaan van Os

1 0

X86 Solaris 10 Binaries
by Gloria, Jing 26 Nov '08

26 Nov '08

Where can I find a build for GPC on X86 Solaris 10?

2 1

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

OpenBSD build
by G. Ramalho 15 Sep '08

15 Sep '08

Hello, I'm trying to build GPC on my OpenBSD box. xgcc seems to be correctly built but I can't get past the following: CC="`echo /root/gpc-build/gcc/xgcc -B/root/gpc-build/gcc/ -B/usr/local/i386-unknown-openbsd4.3/bin/ -B/usr/local/i386-unknown-openbsd4.3/lib/ -isystem /usr/local/i386-unknown-openbsd4.3/include' ' | sed -e 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[^/][^:]*/$,../../\1,'`" PC="`echo ./xgpc -B./' ' | sed -e 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[^/][^:]*/$,../../\1,'`" CONFIG_SITE=nonexisting-file \ $src/p/rts/configure --silent > /dev/null --srcdir=$src/p/rts \ `if [ x@with_shared@ = xyes ]; then echo '--with-shared'; fi` configure: error: installation or configuration problem: C compiler cannot create executables. gmake[1]: *** [p/rts/Makefile] Error 1 gmake[1]: Leaving directory `/root/gpc-build/gcc' gmake: *** [all-gcc] Error 2 OS: OpenBSD 4.3 / i386 (VMWare). GCC/GPC : 3.3.5 / 20060325 Any help is really appreciated. Ramalho.

1 0

Garbage Collection
by Prof. Harley Flanders 03 Sep '08

03 Sep '08

A question for the GPC list: Suppose I have defined type Vec = array[1..1000] of Extended; // 10,000 bytes var A, B, C, D: Vec; function Sum(const A, B: Vec): Vec; In the assignment D := Sum(Sum(A, B), C); there is an intermediate result Sum(A, B), going to an unnamed temporary vector. Does garbage collection pick up that space? Similar question with operator + (const A, B: Vec) C: Vec; D := (A+B)+C; More complicated: Delphi mode, so I have "Result" available var Zero: Vec; // Zero[J] = 0 for all J function Foo(A: Vec; N: Word): Vec; var B: Vec; begin if N = 0 then Result := Zero else if Odd(N) then Result := A + Foo(A, N - 1) else begin B := (Foo(A, N div 2) Result := B + B; end; end; // Foo Garbage collection handles this correctly? Whatever the answers, how do I PROVE them by measuring stack, heap, or whatever? Thanks, HF -- ============================= Prof. Harley Flanders 3533 Windemere Court Ann Arbor, MI 48105-2867 Home: 734 668 1546 harley(a)umich.edu =============================

2 1

Console apps
by Prof. Harley Flanders 02 Sep '08

02 Sep '08

Would anyone please tell me what to write in a Console App so DOS opens in Full Screen mode, not in a window, and in 80 x 25 mode (80 columns, 25 lines). Thank you, HF -- ============================= Prof. Harley Flanders 3533 Windemere Court Ann Arbor, MI 48105-2867 Home: 734 668 1546 harley(a)umich.edu =============================

4 3

GNU Pascal based TeX
by Wolfgang Helbig 07 Jul '08

07 Jul '08

Hi, at http://www.ba-stuttgart.de/~helbig/tex-gpc/ you'll find a set of change files to build GNU Pascal based TeX, METAFONT, weave, tangle and some other related programs. Especially the file tex.ch contains lots of examples how to use GPC extensions. Enjoy, Wolfgang

1 0

Re: turn off lazyIO on disk files
by Wolfgang Helbig 04 Jul '08

04 Jul '08

Hi, Frank Heckenbach wrote: >> On writing, GPC doesn't buffer yet at all; it's not implemented yet. >> It's not that it couldn't be done, but it's more tricky, because GPC >> supports various ways of seeking, pre-reading, getting the file >> position etc., which all would have to take account of the buffers. >> >> If it's a serious problem you could kludge it by installing a >> user-defined file write routine which can do the buffering. If you >> know that your application only does sequential writes, this would >> work. I've done this once (see RewriteBuffer in cgi.pas in >> http://fjf.gnu.de/misc/cgiprogs.tar.bz2). Let me know if you need >> more details. >> >> Frank >> Thanks for the enlightement about buffering in GPC. And Emil Jerabek wrote: >The bottleneck in TeX's I/O is the output to the dvi file, which is >done byte by byte (there's no other choice in standard Pascal). Knuth >himself notes that this is inefficient, the porter is expected to >optimize it: >In the case of GPC, it is trivial to replace the write_dvi procedure >with a single call to BlockWrite. This makes a huge difference in the >running time. Did that. And the time command shows the difference: 64.45 real 15.16 user 48.45 sys 11.40 real 10.55 user 0.57 sys Compares pretty good to a web2c based distribution of TeX, in this case teTeX-3.0: 7.54 real 7.01 user 0.17 sys Thanks to both of you, Wolfgang Helbig -- "Dijkstra is right, but you don't say such things!" (A less courageous programmer)

1 0

turn off lazyIO on disk files
by Wolfgang Helbig 04 Jul '08

04 Jul '08

Hi, the program, Don Knuth's TeX adapted to GPC version 2.1, does heavy I/O on text files. I noticed a very high percentage of system time. I believe this is due to lazy I/O, which seems to be unbuffered. GPC should apply lazy/IO when the text file comes from the keyboard, but to use buffered I/O when it comes from the disk. Is there a way to turn off lazy/IO on nonterminal text files? Greetings, Wolfgang Helbig

3 2

Indent program for the GPC
by pripoae teodor anton 04 Jul '08

04 Jul '08

Hello. I read in the to-do list than a planned feature is a indent-like source code formatter for Pascal. I have three questions: 1. Is anybody who is doing this job? I saw something like this here: http://www.gnu-pascal.de/crystal/gpc/en/mail4247.html?pos=13294915#13294915 but it seems to be unfinished, and it seems to be very long time ago (in 2000). 2. What are the multi-styles for this (in the c indent program called indent, I know that there are a lot of styles: k&r, gnu, berkeleyetc...) 3. How can i contribute to GPC? I haven't tryed to contribute to GNU software yet. I wrote a pascal indent (with some modes, (unix/dos) and with output file), but it has only one mode (yet). Regards, Pripoae Teodor Anton, pripoae_teodor_anton(a)yahoo.com

4 3

GPC and the Linux Standard Base
by Yang Lao 12 Jun '08

12 Jun '08

I wonder if any version of gpc for linux is compliant or conformant with the Linux Standard Base. When I run your hello program through their lsbappchk it gives messages like this: FAIL Symbol isnanl is used, but is not included in LSB 3.2 (Core & C++ & Desktop)

2 2

[Fwd: GCC 4.3.1 Released]
by Adriaan van Os 09 Jun '08

09 Jun '08

-------- Original Message -------- Subject: GCC 4.3.1 Released Date: Mon, 9 Jun 2008 03:49:31 -0400 From: Jakub Jelinek <jakub(a)redhat.com> Reply-To: Jakub Jelinek <jakub(a)redhat.com> To: gcc-announce(a)gcc.gnu.org, gcc(a)gcc.gnu.org GCC 4.3.1 has been released. GCC 4.3.1 is a bug-fix release, containing fixes for regressions in GCC 4.3.0 relative to previous GCC releases. See: http://gcc.gnu.org/gcc-4.3/changes.html and particularly http://gcc.gnu.org/gcc-4.3/changes.html#4.3.1 for more information about changes in GCC 4.3.1. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in gcc/gcc-4.3.1/ subdirectory. As always, a vast number of people contributed to this GCC release -- far too many to thank individually!

1 0

[Fwd: GCC 4.2.4 Released]
by Adriaan van Os 09 Jun '08

09 Jun '08

-------- Original Message -------- Subject: GCC 4.2.4 Released Date: Wed, 21 May 2008 15:13:16 +0000 (UTC) From: Joseph S. Myers <joseph(a)codesourcery.com> Reply-To: gcc(a)gcc.gnu.org To: gcc-announce(a)gcc.gnu.org, gcc(a)gcc.gnu.org GCC 4.2.4 has been released. GCC 4.2.4 is a bug-fix release, containing fixes for regressions in GCC 4.2.3 relative to previous GCC releases. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank individually!

1 0

Re: Mac OS X Pascal Interfaces version 2.1
by Adriaan van Os 06 May '08

06 May '08

> Updated Mac OS X Pascal Interfaces, version 2.1 (release H), can be downloaded from > <http://www.microbizz.nl/gpc.html>. The direct link is <http://www.microbizz.nl/GPCInterfacesH.dmg> The installer package missed a file (PLibraries/GPCMacOS.a). The file has been added. Regards, Adriaan van Os

1 0

Mac OS X Pascal Interfaces version 2.1
by Adriaan van Os 06 May '08

06 May '08

Updated Mac OS X Pascal Interfaces, version 2.1 (release H), can be downloaded from <http://www.microbizz.nl/gpc.html>. The direct link is <http://www.microbizz.nl/GPCInterfacesH.dmg> The installer package contains Mac OS X Pascal interface units for GNU Pascal, FreePascal and MetroWerks CodeWarrior Pascal. A lot of work went into this new release, units were added or updated and several bugs have been fixed. There are now 330 Pascal interface units. For GPC on Mac OS X, this release requires the recently released gpc346u2 compiler (and a soon-to-be released new GPC Xcode kit). Please report bugs to <gpc(a)microbizz.nl>. The Pascal Interfaces team: Peter N. Lewis <peter(a)stairways.com.au> Jonas Maebe <jonas.maebe(a)elis.ugent.be> Adriaan van Os <http://www.microbizz.nl/gpc.html> Gale Paeper <gpaeper(a)empirenet.com>

1 0

pascal strings in the gnu assembler
by steven.borley 05 May '08

05 May '08

Hope this is not considered too off-topic as it about the gnu assemble (gnu-as). I beg forgiveness on grounds that's its Pascal related. In my assembly code I'm trying to place string constants in memory (length byte followed by ASCII string with no trailing zero byte) The following is failing with "Error: illegal relocation size: 1" FOO: .byte ((BAR - . - 2) & 0x7F) ; calculate length .ascii "foo" BAR: .word 0x1234 ; dummy for this example I could just hard code the length, except I eventually want this as macro as I have several hundred strings. And unfortunately this part of the code has to be in assembler, for various reasons. I assume the error is because ((BAR - . - 2) & 0x7F) resolves to a two byte type even although we can see its value would always fit within a byte. It didn't seem a particularly unusually thing to want to do so I'm hoping someone can point me in the right direction with this. Regards, Steven

3 2

GPC Home Page
by Kevan Hashemi 30 Apr '08

30 Apr '08

Hi, The following page is top of the list when you Google "GNU Pascal Compiler". http://www.gnu-pascal.de/gpc/h-index.html The copyright on the page has not been updated since 2005. The most recent version of GPC available on the site is 20041017. When I look for GPC, I end up finding it in three different places: one for MacOS (I have 20051116), one for Linux (I use 20041017), and one for Windows (I have 20070904 for MinGW). My cross-platform code has to include compiler directives like this: {$ifdef __GPC_RELEASE__} {$if __GPC_RELEASE__ > 20050000} {$define INIT_CALL '_p__M0_init'} {$else} {$define INIT_CALL 'init_pascal_main_program'} {$endif} {$else} {$define INIT_CALL 'init_pascal_main_program'} {$endif} procedure initialize_main; external name INIT_CALL; Where can I get the latest GPC binaries for MacOS, Linux, and MinGW? If the binaries are not available, where can I download the latest source files? Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

2 2

Building latest gpc on Intel OS X 10.5.2
by Peter Schorn 28 Apr '08

28 Apr '08

I'm trying to build the latest gpc (gpc-20070904.tar.bz2) with Adriaan's patches on a Macintosh OS X 10.5.2. with Intel. I configure with ../gcc-4.1.2/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc412 but the "make bootstrap" fails with Undefined symbols: "___sysctl", referenced from: ___enable_execute_stack in _enable_execute_stack_s.o ld: symbol(s) not found /usr/bin/libtool: internal link edit command failed make[3]: *** [libgcc_s.dylib] Error 1 make[2]: *** [libgcc.a] Error 2 make[1]: *** [stage1_build] Error 2 make: *** [bootstrap] Error 2 What am I missing? Peter --- peter.schorn(a)acm.org

4 19

compiling static library + gpc runtime without _statvfs on Mac OS X for Intel
by Glenn Howes 20 Apr '08

20 Apr '08

Hello, After months of being distracted by another portion of my application, I'm back to creating a universal binary version of the Pascal based library we are linking into our C++ based application. The problem is the application will not launch under PPC on Mac OS X 10.3 (Panther). The console registers an undefined symbol: _statvfs expected to be defined in /usr/lib/libSystem.B.dylib After some research, I found this call is being used by the StatFS routine implemented in rts.c (line 1510) /** Get information about a file system. */ GLOBAL (Boolean _p_StatFS (char *Path UNUSED, StatFSBuffer *Buf)) { int Result; #ifdef HAVE_STATVFS struct statvfs b; errno = 0; Result = statvfs (Path, &b); Buf->BlockSize = (long long int) b.f_frsize; Buf->BlocksTotal = (long long int) b.f_blocks; Buf->BlocksFree = (long long int) b.f_bavail; Buf->FilesTotal = (int) b.f_files; Buf->FilesFree = (int) b.f_favail; #elif defined (HAVE_STATFS) struct statfs b; errno = 0; Result = statfs (Path, &b); Buf->BlockSize = (long long int) b.f_bsize; Buf->BlocksTotal = (long long int) b.f_blocks; Buf->BlocksFree = (long long int) b.f_bavail; Buf->FilesTotal = (int) b.f_files; Buf->FilesFree = (int) b.f_ffree; #else Result = -1; errno = ENOSYS; #endif if (Result == 0) return True; Buf->BlockSize = 0; Buf->BlocksTotal = 0; Buf->BlocksFree = 0; Buf->FilesTotal = 0; Buf->FilesFree = 0; return False; } It appears to me that HAVE_STATVFS is defined if my current OS X SDK (10.4) has a statvfs.h header file amongst its include files, which means if I build my Pascal development environment from the build-on- Intel.command that the statvfs version will be hard wired into the runtime and any binary I generate will not work on 10.3 (which does not have statvfs in its libSystem.B.dylib library). Also, if I build my environment/library on a PowerPC using the build-on- powerPC-10.3.command, I end up with a different set of link problems involving the long double version of pow(). Besides which, I'd prefer to do my development on OS X for Intel going forward. I have tried hand editing the above routine and rebuilding my Pascal development environment, and pulling the statvfs.h file from my OS X SDK, and yet when my application links, it still has an unresolved reference to _statvfs. I'm not a build engineer, as my previous missives to this mailing list make clear, and I'm at a loss as to how to proceed. Just to be clear, I link in two static libraries: a universal version of the libgpc.a for the runtime, and a universal version of the library I've created. Neither of them contain the symbol _statvfs (at least I can't find that text in them). I link that with my application. The application now references _statvfs (I can now see the text in it's executable). I can't launch on 10.3. I comment out the calls to the Pascal library and recompile+relink, and the application no longer has the symbol and I can launch under 10.3. So something in either of the gpc associated libraries must be calling something which calls statvfs, making the linker (ld) mark statvfs as an unresolved symbol to be loaded in at runtime. At least that is my impression. So, I'd appreciate some suggestions. --glenn

4 8

Updated GPC compiler for Mac OS X
by Adriaan van Os 15 Apr '08

15 Apr '08

Updated GPC sources, patches and binary installers for Mac OS X can be downloaded from <http://www.microbizz.nl/gpc.html>. The source package includes a double-clickable build script. Special thanks to Gale Paeper and Thorsten Lemke for their help. Regards, Adriaan van Os

1 0

Re: GPC compiler bug: functional parameter invocation
by Régis Cridlig 05 Apr '08

05 Apr '08

Thank you, I succeeded in installing the latest cygwin build: gpc-20070904.i686-pc-cygwin.tar.gz This is the compiler version: $ gpc -v Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: ../configure --enable-languages=pascal --enable-threads=posix - -with-system-zlib --enable-nls --without-included-gettext --enable-interpreter - -disable-sjlj-exceptions --enable-shared --build=i686-pc-cygwin --host=i686-pc-c ygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr : (reconfigured) ../c onfigure --enable-languages=pascal --enable-threads=posix --with-system-zlib --e nable-nls --without-included-gettext --enable-interpreter --disable-sjlj-excepti ons --enable-shared --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-p c-cygwin --enable-haifa --prefix=/usr Thread model: posix gpc version 20070904, based on gcc-3.4.4 This is the compilation and execution: $ gpc crashes.p -Wall -g -o crashes.exe $ gdb crashes.exe GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) run Starting program: /cygdrive/c/Documents and Settings/regis.cridlig/My Documents/Info/Pascal/crashes.exe Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/secur32.dll Program received signal SIGSEGV, Segmentation fault. 0x0022cc20 in ?? () (gdb) bt #0 0x0022cc20 in ?? () #1 0x004010a9 in _p__M0_S1_Q (J=200, A=@0x22cc20) at crashes.p:16 #2 0x004010c6 in _p__M0_S1_Q (J=100, A=@0x401050) at crashes.p:16 #3 0x004010e2 in _p__M0_main_program () at crashes.p:20 #4 0x0040115b in main (argc=1, argv=0x6927a0, envp=0x690090) at <implicit code>:22 (gdb) The program source: $ cat crashes.p program Crashes(input,output); function B(l:integer):boolean; begin B:=true; end; procedure Q(j:integer;function A(l:integer):boolean); function E(l:integer):boolean; begin E := false end; begin if A(j) then Q(200,E); end; begin Q(100,B); end. What is going wrong? -- Regis 2008/4/4, Prof A Olowofoyeku (The African Chief) <chiefsoft(a)bigfoot.com>: > > On 3 Apr 2008 at 14:25, Régis Cridlig wrote: > > > > > What is the latest stable release of gpc? > > > > http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20070904.tar.bz2 > > > You can get Cygwin binaries here: > http://gnu-pascal.de/contrib/chief/win32/cygwin/ > > > Best regards, The Chief > -------- > Prof. Abimbola A. Olowofoyeku (The African Chief) > web: http://www.greatchief.plus.com/ > > >

4 12

FPC compiler bug: functional parameter invocation
by Régis Cridlig 04 Apr '08

04 Apr '08

Hello! This short program compiles without a warning, but crashes at execution. The compiler is FPC 2.2 on the win32 platform. program Crashes(input,output); function B(l:integer):boolean; begin B:=true; end; procedure Q(j:integer;function A(l:integer):boolean); function E(l:integer):boolean; begin E := false end; begin if A(j) then Q(200,E); end; begin Q(100,B); end. This is the compiler command: $ gpc --classic-pascal -g -Wall crashes.p Here are the stack frames from gdb: Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll Loaded symbols for /usr/bin/cygwin1.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll Loaded symbols for /cygdrive/c/WINDOWS/system32/secur32.dll Program received signal SIGSEGV, Segmentation fault. 0x0022cc20 in ?? () (gdb) bt #0 0x0022cc20 in ?? () #1 0x004010a9 in _p__M0_S1_Q (J=200, A=@0x22cc20) at crashes.p:16 #2 0x004010c6 in _p__M0_S1_Q (J=100, A=@0x401050) at crashes.p:16 #3 0x004010e2 in _p__M0_main_program () at crashes.p:20 #4 0x0040115b in main (argc=1, argv=0x6927b0, envp=0x690090) at <implicit code>:22 I am pretty sure that this is a compiler bug, because this program used to run on MacPascal with no error. -- Regis Cridlig cridlig(a)gmail.com

3 6

Re: FPC compiler bug: functional parameter invocation
by Prof A Olowofoyeku (The African Chief) 04 Apr '08

04 Apr '08

> On 3 Apr 2008 at 14:25, Régis Cridlig wrote: > > > What is the latest stable release of gpc? > > http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20070904.tar.bz2 You can get Cygwin binaries here: http://gnu-pascal.de/contrib/chief/win32/cygwin/ Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

1 0

Re: FPC compiler bug: functional parameter invocation
by Prof A Olowofoyeku (The African Chief) 03 Apr '08

03 Apr '08

On 3 Apr 2008 at 12:14, Régis Cridlig wrote: [...] > > Here is the output of gpc -v > > > > $ gpc -v > > Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs > > Configured with: > > /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --ver bose > > --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib > > --libe xecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info > > --enable-langu ages=c,ada,c++,d,f77,pascal,java,objc --enable-nls > > --without-included-gettext -- enable-version-specific-runtime-libs > > --without-x --enable-libgcj --disable-java- awt --with-system-zlib > > --enable-interpreter --disable-libgcj-debug --enable-thre ads=posix > > --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptio ns > > --enable-hash-synchronization --enable-libstdcxx-debug Thread model: > > posix gpc version 20050331, based on gcc-3.4.4 (cygming special, gdc > > 0.12, using dmd 0 .125) That is a very old GPC release. I cannot reproduce the problem on gpc- 20060215 for example. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

1 0

Re: gpc and gcc-4.1.2
by Waldek Hebisch 16 Mar '08

16 Mar '08

Martin Marques wrote: > > Yes. Unpack gpc sources, make sure that p subdirectory from gpc > > source tree appears as gcc-4.1.2/gcc/p is gcc source tree (either > > use move or a symlink), configure and make. > > Didn't work. :-( > > make[2]: se ingresa al directorio > `/usr/src/redhat/BUILD/gcc-4.1.2-20070925/host-x86_64-unknown-linux-gnu/gcc' > gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros > -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. > -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include > -I../.././gcc/../libcpp/include ../.././gcc/dbxout.c -o dbxout.o > ../.././gcc/dbxout.c: In function ?dbxout_type?: > ../.././gcc/dbxout.c:1978: error: ?have_used_extensions? no se declaró > aquí (primer uso en esta función) > ../.././gcc/dbxout.c:1978: error: (Cada identificador no declarado > solamente se reporta una vez > ../.././gcc/dbxout.c:1978: error: ara cada funcion en la que aparece.) > make[2]: *** [dbxout.o] Error 1 > make[2]: se sale del directorio > `/usr/src/redhat/BUILD/gcc-4.1.2-20070925/host-x86_64-unknown-linux-gnu/gcc' > make[1]: *** [all-gcc] Error 2 > make[1]: se sale del directorio `/usr/src/redhat/BUILD/gcc-4.1.2-20070925' > make: *** [all] Error 2 > > Any ideas? > Do you really use use gcc-4.1.2? The name gcc-4.1.2-20070925 indicates that you have different version. IIRC the patch /usr/src/redhat/BUILD/ is was used for Redhat modified sources, which are usually different than official version. I would suggest to try to use unmodified gcc-4.1.2. If for some reason you need to use RedHat/Fedora specific version, please make sure first that you can compile gcc alone -- without gpc. Concerning the error message: it tells you that the identifier 'have_used_extensions' is undefined. AFAICS this identifier does not apper in gcc-4.1.2 (change log claims that it was removed in 2005). Gpc patches some gcc files, but the patch also does not contain it. So I think that you get message about 'have_used_extensions' because your 'gcc-4.1.2-20070925' is a modified version and that the modification contains error. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 4

gpc and gcc-4.1.2
by Martin Marques 13 Mar '08

13 Mar '08

I'm trying to compile gpc on a Fedora 8 system, and I can' find instructions on how to compile it with newer versions of gcc. Should I just get the latest gpc sources and try to compile with newer gcc-4.1.2 sources?

3 4

[Fwd: GCC 4.3.0 Released]
by Adriaan van Os 10 Mar '08

10 Mar '08

-------- Original Message -------- Subject: GCC 4.3.0 Released Date: Mon, 10 Mar 2008 06:21:34 -0400 From: Jakub Jelinek <jakub(a)redhat.com> Reply-To: Jakub Jelinek <jakub(a)redhat.com> To: gcc-announce(a)gcc.gnu.org GCC 4.3.0 has been released. GCC 4.3.0 is a major release, containing substantial new functionality not available in GCC 4.2.x or previous GCC releases. See: http://gcc.gnu.org/gcc-4.3/changes.html for more information about changes in GCC 4.3.0. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html The release is in gcc/gcc-4.3.0/ subdirectory. There is one important caveat. It was discovered after the final release has been made that some OS kernels on i?86 and x86_64 architectures violate the processor specific ABI with regards to the DF flag, if a process is interrupted with a signal while doing overlapping memmove or running some other code with DF flag set, the signal handler might be started with DF flag set on entry to the signal handler. GCC 4.3.0 no longer emits cld instructions unnecessarily, so GCC 4.3.0 compiled async signal handlers or functions the signal handlers call that rely on DF flag being cleared might misbehave. This will be hopefully fixed in the kernels soon and future GCC releases might provide an optional workaround for this bug. Fixes for some systems: Linux http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdi… FreeBSD http://www.freebsd.org/cgi/query-pr.cgi?pr=121422 Hurd http://sources.redhat.com/ml/libc-alpha/2008-03/msg00020.html If you encounter difficulties using GCC 4.3, please do not contact me directly. Instead, please visit http://gcc.gnu.org for information about getting help. As always, a vast number of people contributed to this GCC releases -- far too many to thank individually!

1 0

Cross Compiler GPC
by david.garcia＠servext.dimetronic.es 25 Feb '08

25 Feb '08

Hi! I want a cross compiler GPC for Power PC, but I don´t know that I make to correctly configure my version of GPC in Linux. I use GCC 3.4.3. and GPC 20060325. Thanks Este mensaje y sus ficheros adjuntos se dirigen exclusivamente a su destinatario y pueden contener información privilegiada o confidencial. Si no es usted el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. Los ficheros adjuntos han sido comprobados con un programa anti virus antes de su transmisión, pero les recomendamos que efectúen sus propias comprobaciones antes de abrir cualquiera de ellos. No aceptamos responsabilidad alguna por daños o pérdidas causados por virus informáticos. English translation Tradução portuguesa

1 0

Building shared objects with GP
by Pascal Viandier 13 Feb '08

13 Feb '08

Hi GPC crew, I am trying to build shared objects with gp on SUN Sparc Solaris 10 using gpc 20070904 based on gcc-4.1.2. I tried many options of gp with no success. It looks like gp does not pass the --shared and -fPIC command line options to gpc so it produces only regular objects. So, is there a way to benefit from gp's great features to generate shared objects? Thanks Pascal Viandier

3 8

Is it possible to use dynamic arrays in gpc?
by Ohonin Yuriy 07 Feb '08

07 Feb '08

Hello. I'm trying to use such a code: type TVar = object param1, param2:string; .... end; TVarList = object Items:array of TVar; count:cardinal; ..... end; In Delphi and FPC it works fine, but in GPC i get an error 45: warning: missing string capacity -- assuming 255 49: error: syntax error before `of' Is it possible to use dynamic arrays in gpc? I had searched gpc manual, but it is not clear for me - may be, it is possible to use dynamic array only as function parametr? It seems to be a little strange - dynamic arrays are a very old feature :( -- Best regards, Yuriy Ohonin.

5 6

"internal compiler error" with gpc-20070904 on CString2String use
by J. David Bryan 05 Feb '08

05 Feb '08

The attached program causes an "internal compiler error" when compiled using gpc version 20070904, based on gcc-3.4.5 (mingw special), running on Windows XP. -- Dave

3 3

-V and -b fail with gpc-20070904
by J. David Bryan 05 Feb '08

05 Feb '08

Attempting to use an alternate installed gpc version or gpc compiled for a different machine does not work: $ gpc -V 4.1.2 a.pas gpc: `-V' must come at the start of the command line $ gpc -b m68k a.pas gpc: `-b' must come at the start of the command line Problem appears to be that "init_gpc_options" inserts "-famtmpfile" and perhaps "-fsyntax-only" in front of all user-specified options, but "process_command" requires that "-V" and "-b" appear first. Workaround is to call the desired compiler driver directly, e.g.: $ i686-pc-mingw32-gpc-4.1.2 a.pas ...although that is somewhat awkward. Also, if the above bug is fixed, it appears that "process_command" will invoke "<machine>-gcc-<version>" instead of "<machine>-gpc-<version>". -- Dave

1 0

Re: Is it possible to use dynamic arrays in gpc?
by Waldek Hebisch 05 Feb '08

05 Feb '08

Ohonin Yuriy wrote: > I'm trying to use such a code: > > type > TVarList = object > Items:array of TVar; > count:cardinal; > ..... > end; > > In Delphi and FPC it works fine, but in GPC i get an error > > 45: warning: missing string capacity -- assuming 255 > 49: error: syntax error before `of' > > Is it possible to use dynamic arrays in gpc? gpc does not implement Delphi style dynamic arrays. As Adriaan wrote you can get very similar functionality using Extended Pascal schema and pointers. Of course Extended Pascal schema have quite different syntax. Also memory management is different: with pointers to schema you must manually deallocate arrays. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

[Fwd: GCC 4.2.3 Released]
by Adriaan van Os 04 Feb '08

04 Feb '08

-------- Original Message -------- Subject: GCC 4.2.3 Released Date: Sun, 3 Feb 2008 16:57:35 +0000 (UTC) From: Joseph S. Myers <joseph(a)codesourcery.com> Reply-To: gcc(a)gcc.gnu.org To: gcc-announce(a)gcc.gnu.org, gcc(a)gcc.gnu.org GCC 4.2.3 has been released. GCC 4.2.3 is a bug-fix release, containing fixes for regressions in GCC 4.2.2 relative to previous GCC releases. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank individually!

1 0

[Patch] testsuite/gdb.pascal new testcase integer.exp
by Pierre Muller 31 Jan '08

31 Jan '08

I committed this as pascal language maintainer. For gpc mailing list mainly: I had to add to XFAIL for gpc because of the buggy line information. I used an old gpc gpc 20050331, based on gcc-3.4.4 (cygming special, gdc 0.12, using dmd 0.125) but this is the official cygwin distro of gpc. Do newer gpc binaries give better results? Pierre Muller testsuite/ChangeLog entry: 2008-01-31 Pierre Muller <muller(a)ics.u-strasbg.fr> * gdb.pascal/integers.pas: New test program. * gdb.pascal/integers.exp: New testcase. Index: gdb.pascal/integers.pas =================================================================== RCS file: gdb.pascal/integers.pas diff -N gdb.pascal/integers.pas --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/integers.pas 31 Jan 2008 14:49:23 -0000 1.1 @@ -0,0 +1,51 @@ +{ + Copyright 2008 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see <http://www.gnu.org/licenses/>. +} + +program integers; + + +function add(a,b : integer) : integer; +begin + add:=a+b; +end; + +function sub(a,b : integer) : integer; +begin + sub:=a-b; +end; + +var + i, j, k, l : integer; + +begin + i := 0; + j := 0; + k := 0; + l := 0; { set breakpoint 1 here } + i := 1; + j := 2; + k := 3; + l := k; + + i := j + k; + + j := 0; { set breakpoint 2 here } + k := 0; + l := add(i,j); + l := sub(i,j); + +end. Index: gdb.pascal/integers.exp =================================================================== RCS file: gdb.pascal/integers.exp diff -N gdb.pascal/integers.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/integers.exp 31 Jan 2008 14:49:23 -0000 1.1 @@ -0,0 +1,129 @@ +# Copyright 2008 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +if $tracelevel then { + strace $tracelevel +} + +load_lib "pascal.exp" + +set testfile "integers" +set srcfile ${testfile}.pas +set binfile ${objdir}/${subdir}/${testfile}$EXEEXT + +if {[gdb_compile_pascal "${srcdir}/${subdir}/${srcfile}" "${binfile}" executabl e [list debug ]] != "" } { + return -1 +} + +gdb_exit +gdb_start +gdb_reinitialize_dir $srcdir/$subdir +gdb_load ${binfile} +set bp_location1 [gdb_get_line_number "set breakpoint 1 here"] +set bp_location2 [gdb_get_line_number "set breakpoint 2 here"] + +if { [gdb_breakpoint ${srcfile}:${bp_location1}] } { + pass "setting breakpoint 1" +} +if { [gdb_breakpoint ${srcfile}:${bp_location2}] } { + pass "setting breakpoint 2" +} + +# Verify that "start" lands inside the right procedure. +if { [gdb_start_cmd] < 0 } { + untested start + return -1 +} + +gdb_test "" ".* at .*${srcfile}.*" "start" + +gdb_test "cont" "Breakpoint .*:${bp_location1}.*" "Going to first breakpoint" + +gdb_test "print i" ".* = 0" "Print i before assigned to 1" + +gdb_test "next" "i := 1;" "Next to 'i := 1' line" +gdb_test "next" "j := 2;" "Next to 'j := 2' line" +# At that point, +# i should be equal to 1 +gdb_test "print i" " = 1" +# but j should still be equal to zero +if { $pascal_compiler_is_gpc } { + setup_xfail *-*-* +} +gdb_test "print j" " = 0" "Test j value before assignment" + +gdb_test "next" "k := 3;" "Next to 'k := 3' line" +gdb_test "next" "l := k;" "Next to 'l := k' line" + +#j should be equal to 2 +gdb_test "print j" " = 2" +# k should be equal to 3 +gdb_test "print k" " = 3" +# But l shoud still be zero +if { $pascal_compiler_is_gpc } { + setup_xfail *-*-* +} +gdb_test "print l" " = 0" + +# Test addition +gdb_test "print i + j" " = 3" +gdb_test "print i + k" " = 4" +gdb_test "print j + k" " = 5" +gdb_test "print i + j + k" " = 6" + +# Test substraction +gdb_test "print j - i" " = 1" +gdb_test "print i - j" "= -1" +gdb_test "print k -i -j" " = 0" +gdb_test "print k -(i + j)" " = 0" + +# Test unany minus +gdb_test "print -i" " = -1" +gdb_test "print (-i)" " = -1" +gdb_test "print -(i)" " = -1" +gdb_test "print -(i+j)" " = -3" + +# Test boolean operators =, <>, <, <=, > and >= +gdb_test "print i + 1 = j" " = true" +gdb_test "print i + 1 <> j" " = false" +gdb_test "print i + 1 < j" " = false" +gdb_test "print i + 1 <= j" " = true" +gdb_test "print i + 1 > j" " = false" +gdb_test "print i + 1 >= j" " = true" + +# Test multiplication +gdb_test "print 2 * i" " = 2" +gdb_test "print j * k" " = 6" +gdb_test "print 3000*i" " = 3000" + +#Test div and mod operators +gdb_test "print 35 div 2" " = 17" +gdb_test "print 35 mod 2" " = 1" + +# Test several operators together +gdb_test "print i+10*j+100*k" " = 321" +gdb_test " print (i + 5) * (j + 7)" " = 54" + +# 'set i' does not work, as there are set sub-commands starting with 'i' +# Thus we need to use 'set var i' +gdb_test "set var i := 2" " := 2" +gdb_test "print i" " = 2" "Testing new i value" + +gdb_test "cont" \ + "Breakpoint .*:${bp_location2}.*" \ + "Going to second breakpoint" +gdb_test "print i" \ + ".* = 5.*" \ + "Value of i after assignment"

1 0

Help installing on Mac OSX 10.5
by Tom Schneider 30 Jan '08

30 Jan '08

Could someone point me to simple step-by-step instructions for complete installation of GPC on Mac OSX 10.5? I got: http://www.microbizz.nl/gpc.html GNU Pascal 3.4.5u2 installer for Mach-O Intel (Intel native and PowerPC cross compiler) (16.6 MB) and was able to get it installed at: /Developer/Pascal/gpc345u2/bin/gpc so: [toot:~/now/delila] tds% which gpc /usr/bin/gpc [toot:~/now/delila] tds% dir /usr/bin/gpc lrwxr-xr-x 1 root wheel 34 Jan 29 23:19 /usr/bin/gpc@ -> /Developer/Pascal/gpc3 45u2/bin/gpc but when I try to compile I get: /usr/bin/ld: can't locate file for: -lcrt1.o (along with various warnings about my program that are ok.) I get no compiled result. (I also installed the Mac OS X Pascal Interfaces but that did not help.) Adding: --unit-path=/Developer/Pascal/GPCPInterfaces -I/Developer/Pascal/GPCPInterfaces to my control script did not help. I have no clue as how to fix this. Thanks, Tom Dr. Thomas D. Schneider National Institutes of Health National Cancer Institute Center for Cancer Research Nanobiology Program Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.ccrnp.ncifcrf.gov/~toms/

2 1

Problem porting to Mac OS-X
by Martin Liddle 16 Jan '08

16 Jan '08

Apologies because this is probably a silly question. I have a small application that I have written in Gnu Pascal that works nicely under Fedora Core 7 on an Intel PC using gpc 20020502 (yes I know it is old but there are reasons not connected with this task). I now want to port the application to Apple Macs running OS-X. I have downloaded and installed gpc 20051116 from <http://www.microbizz.nl/gpc.html> and that appears to be working. My application compiles OK but fails at the linking stage with the message: /usr/bin/ld: can't locate file for : -lcrt1.o The only unit my application includes is gpc.pas and the only screen input and output is simple reads and writes. A search doesn't find a crt1.o anywhere on the system. What do I do next? -- Martin Liddle, Tynemouth Computer Services, 3 Kentmere Way, Staveley, Chesterfield, Derbyshire, S43 3TW. Web site: <http://www.tynecomp.co.uk>.

3 9

bug report
by Russell Whitaker 04 Jan '08

04 Jan '08

hi given: program bug; procedure foo; begin end; begin foo( 1 ); writeln("OK"); end. gives these compile errors: bug.pas: In main program: bug.pas:8: error: too many (>1) arguments to routine `foo' bug.pas:3: error: routine declaration bug.pas:8: error: too few (1) arguments to function `foo' russ

1 0

Assignment of cstrings passed to C routine
by Harmonious Botch 25 Dec '07

25 Dec '07

I'm trying to call a C routine from a pascal program, and pass string data back and forth. I can call it, I can pass integers back and forth ( thanks to Frank H ), but I can't pass strings. Attempts to assign data to a cstring either result in segmentation errors or garbage in the string. The following is the C routine: #include <stdio.h> char c_str[13]; void c_print_str() { printf ("Now in C routine called from Pascal code.\n"); printf ("string is %s.\n", c_str); fflush (stdout); /* So the text really appears now. */ } The following is the pascal program: program str_trans(input); (* This is an attempt to pass a string from a pascal program to a c function. The corresponding c code is in str_trans.c It is compiled with gpc --automake --unit-path=/home/x/pas str_trans.pas -o str_trans *) {$L str_trans.c} {$X+} procedure c_print_str; asmname 'c_print_str'; var char_ptr: ^char; c_str: cstring; asmname 'c_str'; external; begin new( char_ptr ); char_ptr^ := 'x'; writeln( char_ptr^ ); flush( output ); c_str := char_ptr; writeln( 'calling c function' ); c_print_str; end. As shown, it ends up with garbage in c_str. If I change the value of char_ptr^, the garbage changes. If I try simple assignment in the pascal program, such as c_str := 'x'; or c_str[3] := 'x'; or c_str^ := char_ptr^ it compiles ok, but generates run-time segmentation errors. So, the ideal help would be if someone could explain to me how to assign to c_str. If not, does anyone know how to pass string data between C and Pascal programs in some other manner? Thanks, and happy solstace to all! HB -- View this message in context: http://www.nabble.com/Assignment-of-cstrings-passed-to-C-routine-tp14472794… Sent from the Gpc mailing list archive at Nabble.com.

4 6

Memory layout of array of variable size.
by Bastiaan Veelo 24 Dec '07

24 Dec '07

Hi, In an attempt to hook up to GTK+, I am trying to pass a Pascal array of varible size to C. Static arrays are fine, but these arrays carry some additional information like capacity and size, and I gues they could be received as a struct on the C-side. However, I cannot figure out the structure that the struc should have. I do like this in Pascal: procedure YGTK_init(var argc : CInteger; argv : array of CString); external name 'YGTK_init'; procedure Y_init; var argc : CInteger; argv : array[0..ParamCount] of CString; Counter : integer; begin argc := ParamCount+1; for Counter := 0 to ParamCount do begin argv[Counter] := NewCString(ParamStr(Counter)); end; YGTK_init(argc, argv); end; And like this in C: struct t_argv { int end; void *argv; }; void YGTK_init( int *argc, struct t_argv argv ) { printf("In ygtk.c:YGTK_init.\n"); printf("argv.end: %d\n", argv2.argc); printf("argv.argv address: %p\n", argv2.argv); printf("argv.argv int: %d\n", argv2.argv); printf("argv.argv string: %s\n", argv2.argv); printf("number of arguments: %d\n", *argc); } So I figured out that the first element in the struct is an integer containing the length-1 of the array, but what it should look like for the rest I do not know yet. Do you have an idea? Thanks, Bastiaan.

5 9

Re: dispose: bug or feature?
by Scott Moore 13 Dec '07

13 Dec '07

Scott Moore wrote: >> From: Russell Whitaker <russ(a)ashlandhome.net> >>> >>> On Mon, 10 Dec 2007, Scott Moore wrote: >>> >>> [..] >>>> What did you expect to happen? >>>> >>> I expected "dispose" to undo what "new" does. >>> Could not find a comment in gpc's source that states otherwise. >>> >>> At present, >>> >>> new(p) >>> 1. allocates a block of memory from the heap, the size is the size >>> that p wants to point to. >>> 2. returns the address of that memory block. >>> >>> dispose(p) >>> 1. marks the block of memory that p points to as free. >>> (I say "marks" because the block doesn't disapear) >>> >>> Thus, this works, but shouldn't: >>> >>> writeln( p^ ); >>> dispose( p ); >>> writeln( p^ ); >> >> ============================================= >> 6.5.4 Identified-variables >> An identified-variable shall denote the variable, if any, identified >> by the value of the pointer-variable >> of the identified-variable (see 6 .4 .4 and 6 .6 .5 .3) shall be >> accessible until the termination of the >> activation of the program-block or until the variable is made >> inaccessible (see the required procedure >> 28 >> ISO/IEC 7185 :1990(E) >> dispose, 6.6 .5 .3). >> NOTE | The accessibility of the variable also depends on the existence >> of a pointer-variable that has >> attributed to it the corresponding identifying-value. >> A pointer-variable shall be a variable-access that denotes a variable >> possessing a pointer-type . It shall >> be an error if the pointer-variable of an identified-variable either >> denotes a nil-value or is undefined. >> It shall be an error to remove from the set of values of the >> pointer-type the identifying-value of an >> identified-variable (see 6 .6 .5 .3) when a reference to the >> identified-variable exists. >> Examples: >> p1fi >> p1f .fatherf >> p1's .sibling's .father's >> 6.5 >> =========================================================== >> The statement "writeln( p^ );" after dispose is an "error", dispose >> left p undefined. >> >>> If you dig into gpc's heap.pas you will find code that is the >>> equivalent of: >>> >>> if p <> nil then >>> dispose(p); >>> >>> What I'd like to see is the equivalent of: >>> >>> if p <> nil then >>> begin >>> dispose(p); >>> p := nil; >>> end >>> else >>> writeln( stderr,"WARN: illegal use of dispose"); >>> >>> In places the specs are hard to follow, but I think the specs would >>> allow this. >>> >>> Russ >>> >> >> ====================================================== >> 6.6 .5.3 Dynamic allocation procedures >> >> ... >> >> dispose(q) >> >> shall remove the identifying-value denoted by the expression q from >> the pointer-type of q . It >> shall be an error if the identifying-value had been created using the >> form new(p,c l , . . .,cn). >> >> dispose(q,kl , . . .,km) >> >> shall remove the identifying-value denoted by the expression q from >> the pointer-type of q . The >> case-constants k 1, . . .,km shall be listed in order of increasing >> nesting of the variant-parts . It >> shall be an error unless the variable had been created using the form >> new(p,c 1 , . . .,cn ) and m is >> equal to n . It shall be an error if the variants in the variable >> identified by the pointer value of >> q are different from those specified by the values denoted by the >> case-constants k 1, . . .,km. >> >> NOTE | The removal of an identifying-value from the pointer-type to >> which it belongs renders the identifiedvariable >> inaccessible (see 6 .5.4) and makes undefined all variables and >> functions that have that value >> attributed (see 6 .6 .3 .2 and 6 .8 .2 .2). >> >> It shall be an error if q has a nil-value or is undefined. >> =================================================== >> >> So, again, it is an error (to pass nil to dispose). However, the >> standard leaves it up to the >> implementation when and if such errors are detected, so this is a >> "quality" issue: >> >> ================================================= >> 3.1 Error >> A violation by a program of the requirements of this International >> Standard that a processor is >> permitted to leave undetected. >> ================================================== >> >> I'll bet a nickel that the dispose nil behavior you saw was designed >> to compensate >> for disposals of zero length data. I had to solve that problem, but >> did it using a key address, >> i.e., new() returns a specific, predefined location that is the >> universal zero length pointer. >> >> Scott Moore >> > >

3 2

dispose: bug or feature?
by Russell Whitaker 11 Dec '07

11 Dec '07

Hi Given a pointer p, dispose(p) does not set p to nil. This program, program tst; type ptr = ^string; var p : ptr; begin p := new( ptr, 20 ); p^ := "abc"; writeln( p^ ); dispose( p ); p := nil; if p = nil then writeln("OK"); dispose( p ); writeln( p^ ); end. as is gives you abc OK segmentation fault The seg fault is from the last writeln. If you comment out the line "p := nil", the second "dispose" causes a core dump. If you comment out both "p := nil" and the second "dispose" you get abc abc and that's also an error. I do not know what side effects you might get if you caused "dispose" to set the pointer to nil. Russ

6 8

Re: dispose: bug or feature?
by Scott Moore 11 Dec '07

11 Dec '07

Peter N Lewis wrote: > It's not worth nit picking on the list further, but I wonder if...: > >> dispose(q) >> shall remove the identifying-value denoted by the expression q from the >> pointer-type of q . It shall be an error if the identifying-value had >> been created using the form new(p,c l , . . .,cn). >> >> ... >> >> NOTE -- The removal of an identifying-value from the pointer-type to >> which it belongs renders the identified-variable inaccessible (see >> 6.5.4) and makes undefined all variables and functions that have that >> value attributed (see 6.6.3.2 and 6.8.2.2). > > > "identified-variable" refers to the content, not p per se? > > Note how it makes the distinction of "identifying-value" (ie the > pointer?) and "identified-variable" (ie p^). > > Thus p^ is inaccessible. > > There is a reason I don't attempt to read standards! It says "makes undefined all variables and functions that have that value attributed", and the "value" the speaketh of is the "identifying-value". This is why I included the definition of: new(p) shall create a new variable that is totally-undefined, shall create a new identifying-value of the pointer-type associated with p, that identifies the new variable, and shall attribute this identifying-value to the variable denoted by the variable-access p Note "shall attribute this identifying-value to the variable denoted by the variable-access p" The double speak has a purpose, and the meaning covers several storage management schemes, including references and recycling. For reference systems, where the pointer contains not an address but a logical key to the actual variable, the "identifying-value" becomes undefined because its table entry becomes invalid. For recycling systems, the actual pointer may be set invalid. Its an important point, because it lets the implementor implement advanced storage handling. Scott Moore

1 0

German Book about GNU-Pascal needs contributors
by Eike 06 Dec '07

06 Dec '07

Hi Folks! There is a book in German language about GNU-Pascal available at Wikibooks. See http://de.wikibooks.org/wiki/GNU-Pascal_in_Beispielen There is a publishing company, who is going to sell this and some other books from wikibooks. The money will be donated to the wikimedia foundation. I do not have the time, to step through this book again and fix all those things, which might have changed or should be rewritten. If someone would like to take this job, feel free. Translators are also welcome. Without your help, this book becomes more and more outdated and not worth publishing. Yours Eike

3 4

Updated review of GPC
by Scott Moore 27 Nov '07

27 Nov '07

I have completed a periodic update of a review for the GPC compiler with respect to its' ability to compile and run ISO 7185 level 0 standard programs. I present it here in advance of posting it on the web site: http://www.moorecad.com/standardpascal/compiler.html In order to give the members of the GPC group a chance to correct any errors or raise any complaints. You will please note that there is a section for GPC originator comments. I would be happy to accept any reasonable section the GPC group would wish to include in that section, limited only by size and taste concerns. I note that the web page for GPC does not specify who speaks for GPC, so I would only ask that if multiple people wish to post such a comment, the GPC group would work between its members to prepare a coordinated submittal. Thank you, Scott Moore <below contains the review> ======================================================================== GPC Last verified: November 25, 2007 ISO 7185 full standard test: One failure (see explanation) Version: gpc version 20051116, based on gcc-3.4.4 Pascal-s compile/run: Pass Implementation first order details: Processor run on: AMD Athlon 3200+ Bits: 32 Value of maxint: 2147483647 Default integer field width: 11 characters Default real format field width: 29 characters Default boolean field width: 6 Default character field width: 1 character. Implementation character set: ASCII My comments: 1. Test failure on ISO 7185 section 6.4.3.5, specifically the requirement that each line consist of a sequence of characters terminated by the eoln sequence. When a temporary (unnamed) file was output with an incomplete last line, and subsequently read back, the last eoln was found to be missing. The responsible parties for GPC have informed me that this problem has been fixed in the current version of GPC. When I am able to obtain and test that version, I will update this information. 2. The date of the version tested is fairly old (2005, above). The test was done using a "prebuilt" version of GPC (their terminology) from the GPC web site. The maintainers have recommended using a newer build of the source, which I didn't do for the following reasons. First, there is considerable effort involved with building GPC from source, and GPC is highly cross coupled to building GCC, itself a significant undertaking. Second, I don't believe most users would build their own new version, for similar reasons. Finally, the "current version" involves building from the current source with patches. It would be next to impossible for me to accurately specify such a "version" of the software. 3. The GPC documentation inaccurately states that the flag "--standard-pascal" is all that is needed to insure ISO 7185 level 0 compliance. In fact, this switch was found broken at the time of testing, and caused several normal ISO 7185 features to be incorrectly flagged as errors/warnings. In addition, the flag --field-widths was found to be needed. Finally, the version tested output several warnings with no relationship to Pascal (in fact, they were C language warnings). The net command syntax required to accurately compile ISO 7185 Pascal using GPC is: gpc --field-widths -Wno-warnings -o <program> <program>.pas Where <program> is the name of the Pascal program to be compiled. GPC originator comments: <Not supplied> =========================================================================

2 3

unsubscribe
by jamiekg＠wizardling.geek.nz 27 Nov '07

27 Nov '07

1 0

Most represented string in a TStringlist
by Contestcen＠aol.com 25 Nov '07

25 Nov '07

It looks like AOL may have converted my last message from plain text to HTML once again. Resending... Hi Is there an elegant way to determine which string is mostly represented in a TStringList? For instance if I've got the following the function should return 'Delphi': StringList[0] := 'Pascal'; StringList[1] := 'Pascal'; StringList[2] := 'Delphi'; StringList[3] := 'Delphi'; StringList[4] := 'Delphi'; - Wed, Nov 21 2007 1:04 pm 1 message, 1 author Probably the fastest way to do this is to hash each item to an integer and then count the occurrences of each hash value. Frank Rubin **************************************Check out AOL's list of 2007's hottest products. (http://money.aol.com/special/hot-products-2007?NCID=aoltop00030000000001)

1 0

Most represented string in a TStringlist
by Contestcen＠aol.com 25 Nov '07

25 Nov '07

Hi Is there an elegant way to determine which string is mostly represented in a TStringList? For instance if I've got the following the function should return 'Delphi': StringList[0] := 'Pascal'; StringList[1] := 'Pascal'; StringList[2] := 'Delphi'; StringList[3] := 'Delphi'; StringList[4] := 'Delphi'; - Wed, Nov 21 2007 1:04 pm 1 message, 1 author Probably the fastest way to do this is to hash each item to an integer and then count the occurrences of each hash value. Frank Rubin **************************************Check out AOL's list of 2007's hottest products. (http://money.aol.com/special/hot-products-2007?NCID=aoltop00030000000001)

1 0

ISO 7185 Failures [updated]
by Scott Moore 23 Nov '07

23 Nov '07

{****************************************************************************** GPC standard ISO 7185 test failures The following failures were found: =============================================================================== C:\GPC\usr\test>gpc --standard-pascal -Wno-warnings -o fails fails.pas fails.pas:115: error: ISO 7185 Pascal allows only simple constants fails.pas: In main program: fails.pas:136: error: this use of packed array components is an extension of fails.pas:136: error: Borland Pascal, traditional Macintosh Pascal fails.pas:137: error: this use of packed record fields is an extension of Borland fails.pas:137: error: Pascal, traditional Macintosh Pascal =============================================================================== None of these are valid failures, or indeed even have a reasonable explaination in the standard. Also, all of these used to work fine in GPC: GNU Pascal version 2.1 (20020510), based on gcc-2.95.3-6 (mingw special) See the testing details for that compiler: http://www.moorecad.com/standardpascal/compiler.html Now, with "--standard-pascal" off: =============================================================================== C:\GPC\usr\test>gpc -Wno-warnings -o fails fails.pas C:\GPC\usr\test>fails 1 10 100 2147483647 True False 'too much<eoln> too soon' s/b 'too much<eoln> too soon<eoln> ' =============================================================================== Items: 1. Integer field default appears to be "1". This appears to indicate the default fields for integer is set to 1. This is technically valid, but clearly preverts the intent of the language. The "Pascal users manual and report" shows several examples of the field for integer being clearly set to the maximum size of integer. Ie., for a maximum integer of 11 digits including the sign (for +/-2147483647) the default should be 11 digits for integer. The output of numbers in collumns under the assumption that they would correctly spaced for all integers would fail under the current GPC (see again the several examples in the "report"). I have had the discussion with another implementor, and this treatment of defaults falls under "techically valid (by the ISO 7185 standard), but would break examples of the original Pascal as formulated by Wirth", which I consider a quality issue. I tried this also with the "--standard-pascal" flag on (by commenting out the error causing statements), and got the same result. Again, this used to pass. 2. Boolean outputs nonstandard. There is no explaination for the values of boolean. Since they are treated as the strings "true" or "false", there is no possible default field that would deliver the results shown. If the default were 5 (size of 'false') the result would be: True False For 4 (size of 'true') it would be: True Fals I tried this also with the "--standard-pascal" flag on (by commenting out the error causing statements), and got the same result. Again, this used to pass. 3. Last line in file without "eoln" not corrected as required by standard. In ISO 7185 "6.4.3.5 File types" lines without proper eoln are referred to as "partial lines", and are stated not to occur. In effect, the implementation must either make sure that an eoln is always generated at the end of the file, or that on read, an eoln is essentially inserted if missing at the end of the file. In effect, a text file must be completely empty or be structured as a series of whole lines, including an eoln at the end of each line. I don't believe this ever passed in GPC, but I was told it would be fixed in later revisions. Here is a -v dump on the GPC used: =============================================================================== C:\GPC\usr\test>gpc -v Reading specs from /ecos-c/gpc/usr/bin/../lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: ../configure --verbose --prefix=/usr --exec-prefix=/usr --sysco nfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --inf odir=/usr/share/info --enable-languages=c,pascal --enable-nls --without-included -gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --di sable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug -- enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sj lj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gpc version 20051116, based on gcc-3.4.4 =============================================================================== ******************************************************************************} program fails(output); const scst = 'this is a string'; type cset = set of char; prec = packed record i: integer; b: boolean; c: char; r: real; stc: cset; end; var i: integer; pavs: packed array [1..10] of cset; parec: prec; ft: text; ca: char; begin for i := 1 to 10 do pavs[i] := [chr(i+ord('a'))]; parec.stc := ['b'..'e', 'i']; writeln(1); writeln(10); writeln(100); writeln(maxint); writeln(true); writeln(false); rewrite(ft); writeln(ft, 'too much'); write(ft, 'too soon'); reset(ft); write(''''); while not eof(ft) do begin if eoln(ft) then write('<eoln>'); read(ft, ca); write(ca) end; write(''''); writeln(' s/b ''too much<eoln> too soon<eoln> '''); end.

3 3

ISO 7185 test failures
by Scott Moore 23 Nov '07

23 Nov '07

{****************************************************************************** GPC standard ISO 7185 test failures The following failures were found: =============================================================================== C:\GPC\usr\test>gpc --standard-pascal -Wno-warnings -o fails fails.pas fails.pas:93: error: ISO 7185 Pascal allows only simple constants fails.pas: In main program: fails.pas:112: error: this use of packed array components is an extension of fails.pas:112: error: Borland Pascal, traditional Macintosh Pascal fails.pas:113: error: this use of packed record fields is an extension of Borland fails.pas:113: error: Pascal, traditional Macintosh Pascal =============================================================================== None of these are valid failures, or indeed even have a reasonable explaination in the standard. Also, all of these used to work fine in GPC: GNU Pascal version 2.1 (20020510), based on gcc-2.95.3-6 (mingw special) See the testing details for that compiler: http://www.moorecad.com/standardpascal/compiler.html Now, with "--standard-pascal" off: =============================================================================== C:\GPC\usr\test>gpc -Wno-warnings -o fails fails.pas C:\GPC\usr\test>fails 1 10 100 2147483647 True False =============================================================================== This appears to indicate the default fields for integer is set to 1. This is technically valid, but clearly preverts the intent of the language. The "Pascal users manual and report" shows several examples of the field for integer being clearly set to the maximum size of integer. Ie., for a maximum integer of 11 digits including the sign (for +/-2147483647) the default should be 11 digits for integer. The output of numbers in collumns under the assumption that they would correctly spaced for all integers would fail under the current GPC (see again the several examples in the "report"). I have had the discussion with another implementor, and this treatment of defaults falls under "techically valid (by the ISO 7185 standard), but would break examples of the original Pascal as formulated by Wirth", which I consider a quality issue. There is no explaination for the values of boolean. Since they are treated as the strings "true" or "false", there is no possible default field that would deliver the results shown. If the default were 5 (size of 'false') the result would be: True False For 4 (size of 'true') it would be: True Fals I tried this also with the "--standard-pascal" flag on (by commenting out the error causing statements), and got the same result. Again, this used to pass: GNU Pascal version 2.1 (20020510), based on gcc-2.95.3-6 (mingw special) Here is a -v dump on the GPC used: =============================================================================== C:\GPC\usr\test>gpc -v Reading specs from /ecos-c/gpc/usr/bin/../lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: ../configure --verbose --prefix=/usr --exec-prefix=/usr --sysco nfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --inf odir=/usr/share/info --enable-languages=c,pascal --enable-nls --without-included -gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --di sable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug -- enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sj lj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gpc version 20051116, based on gcc-3.4.4 =============================================================================== ******************************************************************************} program fails(output); const scst = 'this is a string'; type cset = set of char; prec = packed record i: integer; b: boolean; c: char; r: real; stc: cset; end; var i: integer; pavs: packed array [1..10] of cset; parec: prec; begin for i := 1 to 10 do pavs[i] := [chr(i+ord('a'))]; parec.stc := ['b'..'e', 'i']; writeln(1); writeln(10); writeln(100); writeln(maxint); writeln(true); writeln(false) end.

2 4

About Timing Functions and Inline Assembly
by pascaltomath＠yahoo.fr 16 Nov '07

16 Nov '07

Dear Kevan; Of course I do not know what scientific projects you are working on, but I guess that you also, you can probably use for your goals the "Inline Assembly" for Timing. As you know very well, with the Assembly opcode, or, with the Hex code, you can easily get the the timing in nanosecond unit. I use it for profiling my codings [for testing my: -vectorization, -pipelining, -unrolling, -overlapping, -recurrence processes], and, it proves itself very useful. And please, as you are a physicist, would you like not to forget to tell us if; according to the quantum physics laws, we in fact are living truly in a bi-dimensional holographic universe. Sincerely, Kadir T. --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail

1 0

Re: About The - GetMicroSecondTime on Windows
by Prof A Olowofoyeku (The African Chief) 15 Nov '07

15 Nov '07

Hi I found this code for getttimeofday: http://www.koders.com/c/fid456B26D94CDBADE2A642C5F13B41A31102D20C5E.aspx But the result is the same. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

1 0

About The - GetMicroSecondTime on Windows - Post
by pascaltomath＠yahoo.fr 15 Nov '07

15 Nov '07

Dear All; I have tested the Kevan Hashemi's program, on SuSE Linux 10.2 running with AMD Athlon X2 CPU. GNU Pascal 20070904; compiled with GCC 4.1.2 [the latest snapshot], and, compiled with GCC 3.4.6, with the same option << enable languages C, C++, Pascal>> yield the correct results. On Win XP platform, with MinGW using GCC 3.4.5, it does not. I must add that, the testing part of NTL which belongs to the "Timings" does not give correct results on MinGW. But, on Cygwin with GCC 3.4.4, the testing part runs in a perfect manner. When you build and use NTL on MinGW without paying attention to the errors of its test program, there is not also any conflict at all thereafter. With kind regards. Kadir Yuce --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail

4 4

[Fwd: Re: About The Timing Codes and MinGW Tools]
by Kevan Hashemi 14 Nov '07

14 Nov '07

Dear Kadir, > I am going to write and compile some others, see the facts, and after > putting them in a strict formal manner, I will send them to the MinGW > developers and here. Thank you for doing that. I find that the same Pascal code will compile under Cigwin and run with microseconds displayed correctly. I tried the older Pascal compiler (20060215) in MinGW and obtained the same problem: microseconds is always zero. So I think you're probably right: the problem is with MinGW. Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

1 0

About The Timing Codes and MinGW Tools
by pascaltomath＠yahoo.fr 14 Nov '07

14 Nov '07

Dear Professor Olowofoyeku; I have compiled some C++ codes quite similar to the timing test program of the NTL Library, and they have given too some erroneous results. I am going to write and compile some others, see the facts, and after putting them in a strict formal manner, I will send them to the MinGW developers and here. Perhaps, perhaps, there may be a missed "link command option" which must be added during the compile time. Whatever, MinGW is a true wonderful collection provided very generously to us. Really thanks a lot to its smart and laborious developers. I use it along with the GNU Tools Suite; being able to get those wonders on Windows platform, open sourced and free, what gift... Sincerely Yours, With my best regards. Kadir T. Yuce --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail

1 0

GetMicroSecondTime on Windows
by Kevan Hashemi 05 Nov '07

05 Nov '07

Dear GPC Creators, I'm using GPC 20070904 to compile the following on Windows within MinGW: program p; function GetMicroSecondTime:longint; external name '_p_GetMicroSecondTime'; var i,j:integer; x:real; begin for i:=0 to 10 do begin for j:=0 to 100000 do x:=j/2; writeln(GetMicroSecondTime); end; end. On Linux with GPC 20041218, and on MacOS with GPC 20051116, the program produced output like this: 1194023823927008 1194023823934003 1194023823940745 1194023823947257 1194023823955457 1194023823977409 1194023823984707 1194023823990997 1194023823997348 1194023824003602 1194023824023001 But with the GPC 20070904 and MinGW, I get this: 1194023823000000 1194023823000000 1194023823000000 1194023823000000 1194023823000000 1194023823000000 1194023823000000 1194023823000000 1194023823000000 1194023824000000 1194023824000000 It appears that the microsecond part of the time is not working. Yours, Kevan -- Kevan Hashemi, Electrical Engineer Physics Department, Brandeis University http://alignment.hep.brandeis.edu/

2 2

Implementation of UnixTimeToTime
by Wieland, Patrick 19 Oct '07

19 Oct '07

Hello everyone! I found the function "UnixTimeToTime" in gpc.pas declared as "external" and was wondering where I could find the implementation. May someone please help me? best regards Patrick Wieland

2 1

Generating shared objects with gpc
by Pascal Viandier 17 Oct '07

17 Oct '07

Hi gpc crew, Is there a way to generate a shared object (.so) under unix with gpc? I found nothing about this in GPC documentation. I tried "gpc --automake -o foo.so foo.pas" on the command line (foo.pas being a module) This does not work: I get an error about an undefined reference to 'main' Is it possible at all to generate a shared object with gpc? Does someone have any clue? Regards Pascal Viandier

3 5

[Fwd: GCC 4.2.2 Released]
by Adriaan van Os 10 Oct '07

10 Oct '07

-------- Original Message -------- Subject: GCC 4.2.2 Released Date: Tue, 9 Oct 2007 13:22:19 -0700 From: Mark Mitchell <mark(a)codesourcery.com> Reply-To: mark(a)codesourcery.com To: gcc-announce(a)gcc.gnu.org GCC 4.2.2 has been released. GCC 4.2.2 is a bug-fix release, containing fixes for regressions in GCC 4.2.1 relative to previous GCC releases. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html The compilers in this release are covered by GNU General Public License version 3. See: http://gplv3.fsf.org for more information about GPLv3. Please do not contact me directly regarding questions or comments about this release or about GPLv3. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank individually! -- Mark Mitchell CodeSourcery mark(a)codesourcery.com (650) 331-3385 x713

1 0

[RFA-2] Handle GPC specific name for main function
by Pierre Muller 08 Oct '07

08 Oct '07

Thanks to Joel for all his contribution, I resubmit a modified version, which is the same as Joel proposed, to the exception that I used "const char *" instead of "const char const *" that I did not find anywhere else in the GDB sources and seems really strange to me... I also modified the final comment inside pascal_main_name. ChangeLog entry: 2007-10-08 Pierre Muller <muller(a)ics.u-strasbg.fr> * p-lang.h (pascal_main_name): Add declaration. * p-lang.c (GPC_P_INITIALIZE, GPC_MAIN_PROGRAM_NAME_1) (GPC_MAIN_PROGRAM_NAME_2): New constants. (pascal_main_name): New function. * symtab.c: Include p-lang.h. (find_main_name): Add call to pascal_main_name. * Makefile.in (symtab.o): Add dependency on p-lang.h. Index: p-lang.h =================================================================== RCS file: /cvs/src/src/gdb/p-lang.h,v retrieving revision 1.12 diff -u -p -r1.12 p-lang.h --- p-lang.h 23 Aug 2007 18:08:36 -0000 1.12 +++ p-lang.h 8 Oct 2007 15:41:43 -0000 @@ -21,6 +21,9 @@ struct value; +/* Defined in p-lang.c */ +extern const char *pascal_main_name (void); + extern int pascal_parse (void); /* Defined in p-exp.y */ extern void pascal_error (char *); /* Defined in p-exp.y */ Index: p-lang.c =================================================================== RCS file: /cvs/src/src/gdb/p-lang.c,v retrieving revision 1.33 diff -u -p -r1.33 p-lang.c --- p-lang.c 23 Sep 2007 16:25:05 -0000 1.33 +++ p-lang.c 8 Oct 2007 15:41:43 -0000 @@ -35,6 +35,56 @@ extern void _initialize_pascal_language (void); +/* All GPC versions until now (2007-09-27) also define a symbol called + '_p_initialize'. Check for the presence of this symbol first. */ +static const char GPC_P_INITIALIZE[] = "_p_initialize"; + +/* The name of the symbol that GPC uses as the name of the main + procedure (since version 20050212). */ +static const char GPC_MAIN_PROGRAM_NAME_1[] = "_p__M0_main_program"; + +/* Older versions of GPC (versions older than 20050212) were using + a different name for the main procedure. */ +static const char GPC_MAIN_PROGRAM_NAME_2[] = "pascal_main_program"; + +/* Function returning the special symbol name used + by GPC for the main procedure in the main program + if it is found in minimal symbol list. + This function tries to find minimal symbols generated by GPC + so that it finds the even if the program was compiled + without debugging information. + According to information supplied by Waldeck Hebisch, + this should work for all versions posterior to June 2000. */ + +const char * +pascal_main_name (void) +{ + struct minimal_symbol *msym; + + msym = lookup_minimal_symbol (GPC_P_INITIALIZE, NULL, NULL); + + /* If '_p_initialize' was not found, the main program is likely not + written in Pascal. */ + if (msym == NULL) + return NULL; + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_1, NULL, NULL); + if (msym != NULL) + { + return GPC_MAIN_PROGRAM_NAME_1; + } + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_2, NULL, NULL); + if (msym != NULL) + { + return GPC_MAIN_PROGRAM_NAME_2; + } + + /* No known entry procedure found, the main program is probably + not compiled with GPC. */ + return NULL; +} + /* Determines if type TYPE is a pascal string type. Returns 1 if the type is a known pascal type This function is used by p-valprint.c code to allow better string display. Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.165 diff -u -p -r1.165 symtab.c --- symtab.c 24 Sep 2007 07:40:32 -0000 1.165 +++ symtab.c 8 Oct 2007 15:41:44 -0000 @@ -40,6 +40,7 @@ #include "filenames.h" /* for FILENAME_CMP */ #include "objc-lang.h" #include "ada-lang.h" +#include "p-lang.h" #include "hashtab.h" @@ -4126,7 +4127,7 @@ set_main_name (const char *name) static void find_main_name (void) { - char *new_main_name; + const char *new_main_name; /* Try to see if the main procedure is in Ada. */ /* FIXME: brobecker/2005-03-07: Another way of doing this would @@ -4151,6 +4152,13 @@ find_main_name (void) return; } + new_main_name = pascal_main_name (); + if (new_main_name != NULL) + { + set_main_name (new_main_name); + return; + } + /* The languages above didn't identify the name of the main procedure. Fallback to "main". */ set_main_name ("main"); Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.941 diff -u -p -r1.941 Makefile.in --- Makefile.in 8 Oct 2007 15:09:04 -0000 1.941 +++ Makefile.in 8 Oct 2007 15:41:45 -0000 @@ -2751,7 +2751,7 @@ symtab.o: symtab.c $(defs_h) $(symtab_h) $(filenames_h) $(objc_lang_h) $(ada_lang_h) $(hashtab_h) \ $(gdb_obstack_h) $(block_h) $(dictionary_h) $(gdb_string_h) \ $(gdb_stat_h) $(cp_abi_h) $(observer_h) $(gdb_assert_h) \ - $(solist_h) $(ada_lang_h) + $(solist_h) $(p_lang_h) target.o: target.c $(defs_h) $(gdb_string_h) $(target_h) $(gdbcmd_h) \ $(symtab_h) $(inferior_h) $(bfd_h) $(symfile_h) $(objfiles_h) \ $(gdb_wait_h) $(dcache_h) $(regcache_h) $(gdb_assert_h) $(gdbcore_h) \

1 1

Re: [RFC] adding gdb.pascal subdir: updated version
by Pierre Muller 08 Oct '07

08 Oct '07

Thanks for checking this in... Running "make RUNTESTFLAGS=--dir=gdb.pascal" I got the following result with GPC: === gdb Summary === # of expected passes 15 # of unexpected failures 1 # of expected failures 1 # of known failures 1 /usr/local/src/cvs/build/gdb/testsuite/../../gdb/gdb version 6.7.50-20071008-cvs -nx The problem with fpc is that it does not work with cygwin, because cygwin type directories are used, that fpc does not handle. And I have no access to a linux machine here... The gpc specific failure should disappear as soon as I get the pascal_main_name patch in. The known failure is about the string problem, for which I have a fix (only partial) pending. The expected failure is gpc specific too, and comes from the wrong debug information generated. By the way, is this dependent on the type of debug info generated? Does stabs and dwarf both generate the wrong line number information? Pierre Muller GDB pascal language maintainer > -----Original Message----- > From: gdb-patches-owner(a)sourceware.org [mailto:gdb-patches- > owner(a)sourceware.org] On Behalf Of 'Daniel Jacobowitz' > Sent: Monday, October 08, 2007 2:42 PM > To: Pierre Muller > Cc: gdb-patches(a)sourceware.org > Subject: Re: [RFC] adding gdb.pascal subdir: updated version > > On Mon, Oct 08, 2007 at 02:17:54PM +0200, Pierre Muller wrote: > > I am a bit lost in the numerous > > changes that we introduced and I am > > unsure that I have a current complete and up-to-date > > patch, could you commit this change? > > Here's what I checked in. It has a KFAIL for the string type problem, > an XFAIL for gpc's missing line number, and a failure for the GPC > name-of-main issue (could have been a KFAIL but I was tired of waiting > for gnats, and it looks like it will be fixed soon). > > > -- > Daniel Jacobowitz > CodeSourcery > > 2007-10-08 Pierre Muller <muller(a)ics.u-strasbg.fr> > Daniel Jacobowitz <dan(a)codesourcery.com> > > * Makefile.in (ALL_SUBDIRS): Add gdb.pascal. > * configure.ac (AC_OUTPUT): Add gdb.pascal/Makefile. > * configure: Regenerated. > * gdb.pascal/Makefile.in, gdb.pascal/hello.exp, > gdb.pascal/hello.pas, > gdb.pascal/types.exp, lib/pascal.exp: New files. > > Index: Makefile.in > =================================================================== > RCS file: /cvs/src/src/gdb/testsuite/Makefile.in,v > retrieving revision 1.18 > diff -u -p -r1.18 Makefile.in > --- Makefile.in 27 Mar 2007 18:09:35 -0000 1.18 > +++ Makefile.in 8 Oct 2007 12:40:12 -0000 > @@ -37,7 +37,7 @@ RPATH_ENVVAR = @RPATH_ENVVAR@ > ALL_SUBDIRS = gdb.ada gdb.arch gdb.asm gdb.base gdb.cp gdb.disasm \ > gdb.dwarf2 \ > gdb.fortran gdb.server gdb.java gdb.mi \ > - gdb.objc gdb.threads gdb.trace gdb.xml \ > + gdb.objc gdb.pascal gdb.threads gdb.trace gdb.xml \ > $(SUBDIRS) > > EXPECT = `if [ -f $${rootme}/../../expect/expect ] ; then \ > Index: configure > =================================================================== > RCS file: /cvs/src/src/gdb/testsuite/configure,v > retrieving revision 1.24 > diff -u -p -r1.24 configure > --- configure 23 Sep 2007 13:56:56 -0000 1.24 > +++ configure 8 Oct 2007 12:40:12 -0000 > @@ -3104,7 +3104,7 @@ done > > > > - > ac_config_files="$ac_config_files Makefile gdb.ada/Makefile > gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile gdb.cp/Makefile > gdb.disasm/Makefile gdb.dwarf2/Makefile gdb.fortran/Makefile > gdb.server/Makefile gdb.java/Makefile gdb.mi/Makefile gdb.objc/Makefile > gdb.threads/Makefile gdb.trace/Makefile gdb.xml/Makefile" > + > ac_config_files="$ac_config_files Makefile gdb.ada/Makefile > gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile gdb.cp/Makefile > gdb.disasm/Makefile gdb.dwarf2/Makefile gdb.fortran/Makefile > gdb.server/Makefile gdb.java/Makefile gdb.mi/Makefile gdb.objc/Makefile > gdb.pascal/Makefile gdb.threads/Makefile gdb.trace/Makefile > gdb.xml/Makefile" > cat >confcache <<\_ACEOF > # This file is a shell script that caches the results of configure > # tests run on this system so they can be shared between configure > Index: configure.ac > =================================================================== > RCS file: /cvs/src/src/gdb/testsuite/configure.ac,v > retrieving revision 1.8 > diff -u -p -r1.8 configure.ac > --- configure.ac 23 Sep 2007 13:56:56 -0000 1.8 > +++ configure.ac 8 Oct 2007 12:40:12 -0000 > @@ -115,6 +115,6 @@ AC_OUTPUT([Makefile \ > gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile \ > gdb.cp/Makefile gdb.disasm/Makefile gdb.dwarf2/Makefile \ > gdb.fortran/Makefile gdb.server/Makefile \ > - gdb.java/Makefile gdb.mi/Makefile \ > - gdb.objc/Makefile gdb.threads/Makefile gdb.trace/Makefile \ > + gdb.java/Makefile gdb.mi/Makefile gdb.objc/Makefile \ > + gdb.pascal/Makefile gdb.threads/Makefile gdb.trace/Makefile \ > gdb.xml/Makefile]) > Index: gdb.pascal/Makefile.in > =================================================================== > RCS file: gdb.pascal/Makefile.in > diff -N gdb.pascal/Makefile.in > --- /dev/null 1 Jan 1970 00:00:00 -0000 > +++ gdb.pascal/Makefile.in 8 Oct 2007 12:40:12 -0000 > @@ -0,0 +1,24 @@ > +VPATH = @srcdir@ > +srcdir = @srcdir@ > + > +EXECUTABLES = hello/hello > + > +MISCELLANEOUS = > + > +all info install-info dvi install uninstall installcheck check: > + @echo "Nothing to be done for $@..." > + > +clean mostlyclean: > + -find . -name '*.o' -print | xargs rm -f > + -find . -name '*.ali' -print | xargs rm -f > + -find . -name 'b~*.ad[sb]' -print | xargs rm -f > + -rm -f *~ a.out xgdb *.x *.ci *.tmp > + -rm -f *~ *.o a.out xgdb *.x *.ci *.tmp > + -rm -f core core.coremaker coremaker.core corefile $(EXECUTABLES) > + -rm -f $(MISCELLANEOUS) twice-tmp.c > + > +distclean maintainer-clean realclean: clean > + -rm -f *~ core > + -rm -f Makefile config.status config.log > + -rm -f *-init.exp > + -rm -fr *.log summary detail *.plog *.sum *.psum site.* > Index: gdb.pascal/hello.exp > =================================================================== > RCS file: gdb.pascal/hello.exp > diff -N gdb.pascal/hello.exp > --- /dev/null 1 Jan 1970 00:00:00 -0000 > +++ gdb.pascal/hello.exp 8 Oct 2007 12:40:12 -0000 > @@ -0,0 +1,75 @@ > +# Copyright 2007 Free Software Foundation, Inc. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 3 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program. If not, see > <http://www.gnu.org/licenses/>. > + > +if $tracelevel then { > + strace $tracelevel > +} > + > +load_lib "pascal.exp" > + > +set testfile "hello" > +set srcfile ${testfile}.pas > +set binfile ${objdir}/${subdir}/${testfile} > + > +if {[gdb_compile_pascal "${srcdir}/${subdir}/${srcfile}" "${binfile}" > executable [list debug ]] != "" } { > + return -1 > +} > + > +gdb_exit > +gdb_start > +gdb_reinitialize_dir $srcdir/$subdir > +gdb_load ${binfile} > +set bp_location1 [gdb_get_line_number "set breakpoint 1 here"] > +set bp_location2 [gdb_get_line_number "set breakpoint 2 here"] > + > +if { [gdb_breakpoint ${srcfile}:${bp_location1}] } { > + pass "setting breakpoint 1" > +} > +if { [gdb_breakpoint ${srcfile}:${bp_location2}] } { > + pass "setting breakpoint 2" > +} > + > +# Verify that "start" lands inside the right procedure. > +if { [gdb_start_cmd] < 0 } { > + untested start > + return -1 > +} > + > +# This test fails for gpc > +# because debug information for 'main' > +# is in some <implicit code> > +gdb_test "" \ > + ".* at .*hello.pas.*" \ > + "start" > + > +gdb_test "cont" \ > + "Breakpoint .*:${bp_location1}.*" \ > + "Going to first breakpoint" > +gdb_test "print st" \ > + ".* = ''.*" \ > + "Empty string check" > + > +# This test also fails for gpc because the program > +# stops after the string has been written > +# while it should stop before writing it > +if { $pascal_compiler_is_gpc } { > + setup_xfail *-*-* > +} > +gdb_test "cont" \ > + "Breakpoint .*:${bp_location2}.*" \ > + "Going to second breakpoint" > +gdb_test "print st" \ > + ".* = 'Hello, world!'.*" \ > + "String after assignment check" > Index: gdb.pascal/hello.pas > =================================================================== > RCS file: gdb.pascal/hello.pas > diff -N gdb.pascal/hello.pas > --- /dev/null 1 Jan 1970 00:00:00 -0000 > +++ gdb.pascal/hello.pas 8 Oct 2007 12:40:12 -0000 > @@ -0,0 +1,15 @@ > +program hello; > + > +var > + st : string; > + > +procedure print_hello; > +begin > + Writeln('Before assignment'); { set breakpoint 1 here } > + st:='Hello, world!'; > + writeln(st); {set breakpoint 2 here } > +end; > + > +begin > + print_hello; > +end. > Index: gdb.pascal/types.exp > =================================================================== > RCS file: gdb.pascal/types.exp > diff -N gdb.pascal/types.exp > --- /dev/null 1 Jan 1970 00:00:00 -0000 > +++ gdb.pascal/types.exp 8 Oct 2007 12:40:12 -0000 > @@ -0,0 +1,110 @@ > +# Copyright 1994, 1995, 1997, 1998, 2007 Free Software Foundation, > Inc. > +# Copyright 2007 Free Software Foundation, Inc. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 3 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program. If not, see > <http://www.gnu.org/licenses/>. > + > +# Please email any bugs, comments, and/or additions to this file to: > +# bug-gdb(a)prep.ai.mit.edu > + > +# This file was adapted from old Chill tests by Stan Shebs > +# (shebs(a)cygnus.com). > +# Adapted to pascal by Pierre Muller > + > +if $tracelevel then { > + strace $tracelevel > +} > + > +set prms_id 0 > +set bug_id 0 > + > +# Set the current language to pascal. This counts as a test. If it > +# fails, then we skip the other tests. > + > +proc set_lang_pascal {} { > + global gdb_prompt > + > + if [gdb_test "set language pascal" ""] { > + return 0; > + } > + > + if ![gdb_test "show language" ".* source language is > \"pascal\".*"] { > + return 1; > + } else { > + return 0; > + } > +} > + > +proc test_integer_literal_types_accepted {} { > + global gdb_prompt > + > + # Test various decimal values. > + # Should be integer*4 probably. > + gdb_test "pt 123" "type = int" > +} > +proc test_character_literal_types_accepted {} { > + global gdb_prompt > + > + # Test various character values. > + > + gdb_test "pt 'a'" "type = char" > +} > + > +proc test_string_literal_types_accepted {} { > + global gdb_prompt > + > + # Test various character values. > + > + setup_kfail *-*-* gdb/2326 > + gdb_test "pt 'a simple string'" "type = string" > +} > + > +proc test_logical_literal_types_accepted {} { > + global gdb_prompt > + > + # Test the only possible values for a logical, TRUE and FALSE. > + > + gdb_test "pt TRUE" "type = bool" > + gdb_test "pt FALSE" "type = bool" > +} > + > +proc test_float_literal_types_accepted {} { > + global gdb_prompt > + > + # Test various floating point formats > + > + # this used to guess whether to look for "real*4" or > + # "real*8" based on a target config variable, but noone > + # maintained it properly. > + > + gdb_test "pt .44" "type = double" > + gdb_test "pt 44.0" "type = double" > + gdb_test "pt 10e20" "type = double" > + gdb_test "pt 10E20" "type = double" > +} > + > +# Start with a fresh gdb. > + > +gdb_exit > +gdb_start > +gdb_reinitialize_dir $srcdir/$subdir > + > +if [set_lang_pascal] then { > + test_integer_literal_types_accepted > + test_logical_literal_types_accepted > + test_character_literal_types_accepted > + test_string_literal_types_accepted > + test_float_literal_types_accepted > +} else { > + warning "$test_name tests suppressed." 0 > +} > Index: lib/pascal.exp > =================================================================== > RCS file: lib/pascal.exp > diff -N lib/pascal.exp > --- /dev/null 1 Jan 1970 00:00:00 -0000 > +++ lib/pascal.exp 8 Oct 2007 12:40:12 -0000 > @@ -0,0 +1,152 @@ > +# Copyright 2007 Free Software Foundation, Inc. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; either version 3 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program. If not, see > <http://www.gnu.org/licenses/>. > + > +load_lib libgloss.exp > + > +set pascal_init_done 0 > + > +# This procedure looks for a suitable pascal compiler > +# For now only GNU pascal compiler and Free Pascal compiler > +# are searched. > +# First, environment variable GPC is checked > +# if present, GPC compiler is assumed to be the value of > +# that environment variable. > +# Second, environment variable FPC is checked > +# if present, Free Pascal compiler is assumed to be the value of > +# that environment variable. > +# Third, gpc executable is searched using `which gpc` > +# Lastly, fpc executable is searched using `which fpc` > +# Using environment variable allows to force > +# which compiler is used in testsuite > + > +proc pascal_init {} { > + global pascal_init_done > + global pascal_compiler_is_gpc > + global pascal_compiler_is_fpc > + global gpc_compiler > + global fpc_compiler > + global env > + > + if { $pascal_init_done == 1 } { > + return > + } > + > + set pascal_compiler_is_gpc 0 > + set pascal_compiler_is_fpc 0 > + set gpc_compiler [transform gpc] > + set fpc_compiler [transform fpc] > + > + if ![is_remote host] { > + if { [info exists env(GPC)] } { > + set pascal_compiler_is_gpc 1 > + set gpc_compiler $env(GPC) > + verbose -log "Assuming GNU Pascal ($gpc_compiler)" > + } elseif { [info exists env(FPC)] } { > + set pascal_compiler_is_fpc 1 > + set fpc_compiler $env(FPC) > + verbose -log "Assuming Free Pascal ($fpc_compiler)" > + } elseif { [which $gpc_compiler] != 0 } { > + set pascal_compiler_is_gpc 1 > + verbose -log "GNU Pascal compiler found" > + } elseif { [which $fpc_compiler] != 0 } { > + set pascal_compiler_is_fpc 1 > + verbose -log "Free Pascal compiler found" > + } > + } > + set pascal_init_done 1 > +} > + > +proc gpc_compile {source dest type options} { > + global gpc_compiler > + set add_flags "" > + if {$type == "object"} { > + append add_flags " -c" > + } > + > + if { $type == "preprocess" } { > + append add_flags " -E" > + } > + > + if { $type == "assembly" } { > + append add_flags " -S" > + } > + > + foreach i $options { > + if { $i == "debug" } { > + if [board_info $dest exists debug_flags] { > + append add_flags " [board_info $dest debug_flags]"; > + } else { > + append add_flags " -g" > + } > + } > + } > + > + set result [remote_exec host $gpc_compiler "-o $dest --automake > $add_flags $source"] > + return $result > +} > + > +proc fpc_compile {source dest type options} { > + global fpc_compiler > + set add_flags "" > + if {$type == "object"} { > + append add_flags " -Cn" > + } > + > + if { $type == "preprocess" } { > + return "Free Pascal can not preprocess" > + } > + > + if { $type == "assembly" } { > + append add_flags " -al" > + } > + > + foreach i $options { > + if { $i == "debug" } { > + if [board_info $dest exists debug_flags] { > + append add_flags " [board_info $dest debug_flags]"; > + } else { > + append add_flags " -g" > + } > + } > + } > + > + set result [remote_exec host $fpc_compiler "-o$dest $add_flags > $source"] > + return $result > +} > + > +proc gdb_compile_pascal {source dest type options} { > + global pascal_init_done > + global pascal_compiler_is_gpc > + global pascal_compiler_is_fpc > + > + if { $pascal_init_done == 0 } { > + pascal_init > + } > + > + if { $pascal_compiler_is_fpc == 1 } { > + set result [fpc_compile $source $dest $type $options] > + } elseif { $pascal_compiler_is_gpc == 1 } { > + set result [gpc_compile $source $dest $type $options] > + } else { > + unsupported "No pascal compiler found" > + return "No pascal compiler. Compilation failed." > + } > + > + if ![file exists $dest] { > + unsupported "Pascal compilation failed: $result" > + return "Pascal compilation failed." > + } > +} > +

1 0

Re: [RFC] adding gdb.pascal subdir: updated version
by Pierre Muller 08 Oct '07

08 Oct '07

This is the BIG problem about GDB pascal expression parser: - the single quotes are used in the C expression parser for these "quoted symbol reference", which I did not want to remove from the pascal expression parser, mainly because I did not really know what its use was, and I still don't know :(. Question to GPC people: does anyone use this "quoted symbol reference"? I thought that it could be very useful for overloaded functions (functions having the same name, but a diffent arg list, which is allowed in pascal). Thus I also left the double quote parsing as a string constant even though it is not the real pascal syntax. - but pascal strings are started by single quotes, not double quotes... I have a patch that would still search for quoted symbol reference, but would default to a pascal string in case nothing is found. The patch is rather simple, it just sets a variable named is_pascal_string, that is used if no symbol is found later to transform the character sequence into a real string. See diff below. The main problem is that doing this would give you subtle bugs like (gdb) pt 'Hello world' (gdb) type = array [0..11] of char (gdb) pt 'main' type = function .... Which is not really nice. I wanted to wait until the pascal subdirectory of the testsuite is added to start coping with this BIG problem... Index: p-exp.y =================================================================== RCS file: /cvs/src/src/gdb/p-exp.y,v retrieving revision 1.36 diff -u -p -r1.36 p-exp.y --- p-exp.y 3 Jul 2007 01:01:13 -0000 1.36 +++ p-exp.y 25 Sep 2007 15:52:23 -0000 @@ -1062,11 +1063,12 @@ yylex () int explen, tempbufindex; static char *tempbuf; static int tempbufsize; + int is_pascal_string; retry: prev_lexptr = lexptr; - + is_pascal_string = 0; tokstart = lexptr; explen = strlen (lexptr); /* See if it is a special token of length 3. */ @@ -1129,6 +1131,7 @@ yylex () error ("Unmatched single quote."); namelen -= 2; tokstart++; + is_pascal_string = 1; uptokstart = uptok(tokstart,namelen); goto tryname; } @@ -1648,6 +1651,16 @@ yylex () /* Any other kind of symbol */ yylval.ssym.sym = sym; yylval.ssym.is_a_field_of_this = is_a_field_of_this; + if (!sym && is_pascal_string) + { + /* Handle this as a normal pascal string. */ + tempbuf = (char *) realloc (tempbuf, namelen + 1); + strncpy (tempbuf, tokstart, namelen); + tempbuf[namelen] = '\0'; + yylval.sval.ptr = tempbuf; + yylval.sval.length = namelen; + return (STRING); + } return NAME; } } > -----Original Message----- > From: gdb-patches-owner(a)sourceware.org [mailto:gdb-patches- > owner(a)sourceware.org] On Behalf Of 'Daniel Jacobowitz' > Sent: Saturday, October 06, 2007 5:42 PM > To: Pierre Muller > Cc: gdb-patches(a)sourceware.org; gpc(a)gnu.de > Subject: Re: [RFC] adding gdb.pascal subdir: updated version > > On Sat, Sep 08, 2007 at 12:38:47AM +0200, Pierre Muller wrote: > > +proc test_string_literal_types_accepted {} { > > + global gdb_prompt > > + > > + # Test various character values. > > + > > + gdb_test "pt 'a simple string'" "type = string" > > +} > > Pierre, is this the correct Pascal syntax for a string or not? > > We have: > > case '\'': > /* We either have a character constant ('0' or '\177' for > example) > or we have a quoted symbol reference ('foo(int,int)' in object > pascal > for example). */ > > and there is a separate case for double-quoted strings. > > Resolving that question will take care of one failure for both fpc and > gpc. The other two GPC failures should be handled like in the patch > I've attached. The failure at "start" is a GDB bug, so we label that > a KFAIL ("known failure"). The shouldn't be committed with gdb/NNNN > still in it. It should either have a bug number in our bug database, > or else just wait until the patch to fix it is checked in. > > The other test is definitely a bug in GPC. I read through the DWARF > dump and there is no reference to line 10, so GDB will never display > it. So that's an XFAIL, an expected failure due to our environment. > It needs to get a little more complicated if the GPC bug is fixed > some day, using gdb_test_multiple. > > -- > Daniel Jacobowitz > CodeSourcery > > diff -u gdb.pascal/hello.exp gdb.pascal/hello.exp > --- gdb.pascal/hello.exp 7 Sep 2007 21:46:31 -0000 > +++ gdb.pascal/hello.exp 6 Oct 2007 15:39:32 -0000 > @@ -50,6 +50,9 @@ > # This test fails for gpc > # because debug information for 'main' > # is in some <implicit code> > +if { $pascal_compiler_is_gpc } { > + setup_kfail *-*-* gdb/NNNN > +} > gdb_test "" \ > ".* at .*hello.pas.*" \ > "start" > @@ -64,6 +67,9 @@ > # This test also fails for gpc because the program > # stops after the string has been written > # while it should stop before writing it > +if { $pascal_compiler_is_gpc } { > + setup_xfail *-*-* > +} > gdb_test "cont" \ > "Breakpoint .*:${bp_location2}.*" \ > "Going to second breakpoint"

1 0

Mod operator issue
by Adriaan van Os 04 Oct '07

04 Oct '07

The following two programs fail on i386-apple-darwin when using gpc version 20051116 with gcc-3.4.5, but not when using gpc version 20070904 with gcc-4.1.2. This was reported by Stéphane Nicolet on the mac-pascal mailiong list. Does someone remember if this is a back-end or front-end problem ? {$mac-pascal} program modbug; var a,b: integer; c: boolean; begin a := 22; b := 12; c:= ((a - 15) mod b) = (b-1) end. {$borland-pascal} program modbug; var a,b: integer; c: boolean; begin a := 22; b := 12; c:= ((a - 15) mod b) = (b-1) end. Regards, Adriaan van Os

3 2

[RFA] Handle GPC specific name for main function
by Pierre Muller 03 Oct '07

03 Oct '07

This is my final patch to be able to detect the fact that GPC was used to compile the main procedure and set the name of that main procedure (which is either "pascal_main_program" or "_p__M0_main_program"). The whole thread started with http://sourceware.org/ml/gdb-patches/2007-09/msg00373.html Is it OK to commit? Pierre Muller Pascal language maintainer. ChangeLog entry: 2007-10-03 Pierre Muller <muller(a)ics.u-strasbg.fr> * p-lang.h (pascal_main_name): New function. p-lang.c (GPC_P_INITIALIZE, GPC_MAIN_PROGRAM_NAME_1), (GPC_MAIN_PROGRAM_NAME_2): New char array constants corresponding to the three minimal symbols used by GPC compiler. (pascal_main_name): Try to find minimal symbol corresponding to the entry of GPC compiled programs. symtab.c: New include p-lang.h. (find_main_name): Try to find pascal specific main name by calling pascal_main_name. * Makefile.in (symtab.o): Add dependency on p-lang header. Index: p-lang.h =================================================================== RCS file: /cvs/src/src/gdb/p-lang.h,v retrieving revision 1.12 diff -u -p -r1.12 p-lang.h --- p-lang.h 23 Aug 2007 18:08:36 -0000 1.12 +++ p-lang.h 3 Oct 2007 09:21:58 -0000 @@ -21,6 +21,9 @@ struct value; +/* Defined in p-lang.c */ +extern char *pascal_main_name (void); + extern int pascal_parse (void); /* Defined in p-exp.y */ extern void pascal_error (char *); /* Defined in p-exp.y */ Index: p-lang.c =================================================================== RCS file: /cvs/src/src/gdb/p-lang.c,v retrieving revision 1.33 diff -u -p -r1.33 p-lang.c --- p-lang.c 23 Sep 2007 16:25:05 -0000 1.33 +++ p-lang.c 3 Oct 2007 09:21:58 -0000 @@ -35,6 +35,63 @@ extern void _initialize_pascal_language (void); +/* All GPC versions until now (2007-09-27) also define a symbol called + '_p_initialize'. Check for the presence of this symbol first. */ + static const char GPC_P_INITIALIZE[] + = "_p_initialize"; + +/* The name of the symbol that GPC uses as the name of the main + procedure (since version 20050212). */ +static const char GPC_MAIN_PROGRAM_NAME_1[] + = "_p__M0_main_program"; + +/* Older versions of GPC (versions older than 20050212) were using + a different name for the main procedure. */ +static const char GPC_MAIN_PROGRAM_NAME_2[] + = "pascal_main_program"; + +/* Function returning the special symbol name used + by GPC for the main procedure in the main program + if it is found in minimal symbol list. + This function tries to find minimal symbols generated by GPC + so that it finds the even if the program was compiled + without debugging information. + According to information supplied by Waldeck Hebisch, + this should work for all versions posterior to June 2000. */ + +char * +pascal_main_name (void) +{ + struct minimal_symbol *msym; + + msym = lookup_minimal_symbol (GPC_P_INITIALIZE, NULL, NULL); + + /* If '_p_initialize' was not found, + the program doesn't seem to be compiled with GPC. + Thus default name "main" should work. */ + if (msym == NULL) + return NULL; + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_1, NULL, NULL); + + if (msym != NULL) + { + return (char *)GPC_MAIN_PROGRAM_NAME_1; + } + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_2, NULL, NULL); + + if (msym != NULL) + { + return (char *)GPC_MAIN_PROGRAM_NAME_2; + } + +/* No known entry procedure found, use default 'main' name. + According to Waldek Hebish, this should not happen for any GPC version + after June 2000 and up to 2007-09-27. */ + return NULL; +} + /* Determines if type TYPE is a pascal string type. Returns 1 if the type is a known pascal type This function is used by p-valprint.c code to allow better string display. Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.165 diff -u -p -r1.165 symtab.c --- symtab.c 24 Sep 2007 07:40:32 -0000 1.165 +++ symtab.c 3 Oct 2007 09:21:59 -0000 @@ -40,6 +40,7 @@ #include "filenames.h" /* for FILENAME_CMP */ #include "objc-lang.h" #include "ada-lang.h" +#include "p-lang.h" #include "hashtab.h" @@ -4151,6 +4152,13 @@ find_main_name (void) return; } + new_main_name = pascal_main_name (); + if (new_main_name != NULL) + { + set_main_name (new_main_name); + return; + } + /* The languages above didn't identify the name of the main procedure. Fallback to "main". */ set_main_name ("main"); Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.939 diff -u -p -r1.939 Makefile.in --- Makefile.in 27 Sep 2007 18:48:32 -0000 1.939 +++ Makefile.in 3 Oct 2007 09:22:00 -0000 @@ -2751,7 +2751,7 @@ symtab.o: symtab.c $(defs_h) $(symtab_h) $(filenames_h) $(objc_lang_h) $(ada_lang_h) $(hashtab_h) \ $(gdb_obstack_h) $(block_h) $(dictionary_h) $(gdb_string_h) \ $(gdb_stat_h) $(cp_abi_h) $(observer_h) $(gdb_assert_h) \ - $(solist_h) $(ada_lang_h) + $(solist_h) $(p_lang_h) target.o: target.c $(defs_h) $(gdb_string_h) $(target_h) $(gdbcmd_h) \ $(symtab_h) $(inferior_h) $(bfd_h) $(symfile_h) $(objfiles_h) \ $(gdb_wait_h) $(dcache_h) $(regcache_h) $(gdb_assert_h) $(gdbcore_h) \

1 0

gpc issue with some record structure
by Peter Schorn 02 Oct '07

02 Oct '07

I did some further investigations on the gpc issue I recently discovered on Mac OS X 10.4.10 PowerPC (gpc 20070904, based on gcc-4.1.2). The following program exhibits the problem: program schorn3; type abc = record a, b, c: Extended; end; const d = 22092007.192016; procedure outer; var x: abc; procedure inner(p: abc); begin if x.a = d then writeln('OK') else writeln('Fail. Got x.a = ', x.a, '. Expected x.a =', d); end; begin { outer } x.a := d; inner(x); end; begin outer; end. The following behavior is observed: peter% /Developer/Pascal/gpc412/bin/gpc -o schorn3 schorn3.pas peter% schorn3 Fail. Got x.a = -3.066700750256657e-231. Expected x.a = 2.209200719201600e+07 Now with --pack-struct (although it seems there is nothing to pack) peter% /Developer/Pascal/gpc412/bin/gpc --pack-struct -o schorn3 schorn3.pas peter% schorn3 OK The previous test program for this issue caused bus errors or segmentation faults on Macintoshes but also had a chance to succeed by chance (only a boolean at a possibly wrong address was tested). Maybe the issue now shows up on other platforms as well. Peter ----- peter.schorn at acm.org

5 7

Re: [RFC-3] Handle GPC specific name for main function
by Pierre Muller 27 Sep '07

27 Sep '07

> -----Original Message----- > From: Joel Brobecker [mailto:brobecker@adacore.com] > Sent: Thursday, September 27, 2007 6:32 PM > To: Pierre Muller; 'Adriaan van Os'; gpc(a)gnu.de; gdb- > patches(a)sourceware.org > Subject: Re: [RFC-3] Handle GPC specific name for main function > > > > > Anyhow, this can only lead to failures to detect > > > > GPC properly. I think that the patch, even if it might > > > > miss more cases, is also much more safe this way, because > > > > we only use (_p_MO__main_program or pascal_main_program) > > > > as start command breakpoint if '_p_initialize' was also found. > > > > > > Seems reasonable to me. Joel? > > > > Seems reasonable to me too. > > Actually, is it really reducing the potential for false positives? > > Let's recap: _p_initialize is defined when the Pascal runtime is linked > in. _p_MO__main_program is sufficiently unlikely that such a symbol > name > should be a Pascal procedure pretty much all the time. So I'm wondering > whether checking for _p_initialize will help reducing the number of > false positive at all (because would _p_MO__main_program => > _p_initialize). > So is this patch really better than the previous one? Yes, because it was not simply '_p__M0_main_program' but basically: if msym('_p_M0_main_program') exists, return '_p__M0_main_program' else if sym('pascal_main_program') exist, return 'pascal_main_program' else return NIL. The old name is more usual, and could be generated by any compiler (its even a valid C function name, if if there is not underscore prepended!). To avoid false positives on the second version mainly, it is better. We could decide to do the check of '_p_initialize' only for that second case; that would probably reduce the number of recent GPC compilation misses. Pierre Muller

1 0

[RFC-3] Handle GPC specific name for main function
by Pierre Muller 27 Sep '07

27 Sep '07

Based on comments from Waldek and concerns from Joel, I propose that we first check for the presence of the '_p_initialize' minimal symbol, and only look for '_p_M0_main_program' and 'pascal_main_program' if the '_p_initialize' was found. This should reduce substantially the risks of false catches. Joel, does this seem enough for you, or should we really insist on checking if the program was compiled by gcc, like Waldek also suggested, but which would mean that only programs having debug information present would get a chance of being detected correctly, while the present patch also works for programs without debugging information. Pierre Muller ChangeLog entry: 2007-09-27 Pierre Muller <muller(a)ics.u-strasbg.fr> * p-lang.h (pascal_main_name): New function. p-lang.c (GPC_P_INITIALIZE, GPC_MAIN_PROGRAM_NAME_1), (GPC_MAIN_PROGRAM_NAME_2): New char array constants corresponding to the three minimal symbols used by GPC compiler. (pascal_main_name): Try to find minimal symbol corresponding to the entry of GPC compiled programs. symtab.c: New include p-lang.h. (find_main_name): Try to find pascal specific main name by calling pascal_main_name. * Makefile.in (symtab.o): Add dependency on p-lang header. $ cvs diff -up p-lang.h p-lang.c symtab.c Makefile.in Index: p-lang.h =================================================================== RCS file: /cvs/src/src/gdb/p-lang.h,v retrieving revision 1.12 diff -u -p -r1.12 p-lang.h --- p-lang.h 23 Aug 2007 18:08:36 -0000 1.12 +++ p-lang.h 27 Sep 2007 07:20:00 -0000 @@ -21,6 +21,9 @@ struct value; +/* Defined in p-lang.c */ +extern char *pascal_main_name (void); + extern int pascal_parse (void); /* Defined in p-exp.y */ extern void pascal_error (char *); /* Defined in p-exp.y */ Index: p-lang.c =================================================================== RCS file: /cvs/src/src/gdb/p-lang.c,v retrieving revision 1.33 diff -u -p -r1.33 p-lang.c --- p-lang.c 23 Sep 2007 16:25:05 -0000 1.33 +++ p-lang.c 27 Sep 2007 07:20:00 -0000 @@ -35,6 +35,63 @@ extern void _initialize_pascal_language (void); +/* All GPC versions until now (2007-09-27) also define a symbol called + '_p_initialize'. Check for the presence of this symbol first. */ + static const char GPC_P_INITIALIZE[] + = "_p_initialize"; + +/* The name of the symbol that GPC uses as the name of the main + procedure (since version 20050212). */ +static const char GPC_MAIN_PROGRAM_NAME_1[] + = "_p__M0_main_program"; + +/* Older versions of GPC (versions older than 20050212) were using + a different name for the main procedure. */ +static const char GPC_MAIN_PROGRAM_NAME_2[] + = "pascal_main_program"; + +/* Function returning the special symbol name used + by GPC for the main procedure in the main program + if it is found in minimal symbol list. + This function tries to find minimal symbols generated by GPC + so that it finds the even if the program was compiled + without debugging information. + According to information supplied by Waldeck Hebisch, + this should work for all versions posterior to June 2000. */ + +char * +pascal_main_name (void) +{ + struct minimal_symbol *msym; + + msym = lookup_minimal_symbol (GPC_P_INITIALIZE, NULL, NULL); + + /* If '_p_initialize' was not found, + the program doesn't seem to be compiled with GPC. + Thus default name "main" should work. */ + if (msym == NULL) + return NULL; + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_1, NULL, NULL); + + if (msym != NULL) + { + return (char *)GPC_MAIN_PROGRAM_NAME_1; + } + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_2, NULL, NULL); + + if (msym != NULL) + { + return (char *)GPC_MAIN_PROGRAM_NAME_2; + } + +/* No known entry procedure found, use default 'main' name. + According to Waldek Hebish, this should not happen for any GPC version + after June 2000 and up to 2007-09-27. */ + return NULL; +} + /* Determines if type TYPE is a pascal string type. Returns 1 if the type is a known pascal type This function is used by p-valprint.c code to allow better string display. Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.165 diff -u -p -r1.165 symtab.c --- symtab.c 24 Sep 2007 07:40:32 -0000 1.165 +++ symtab.c 27 Sep 2007 07:20:01 -0000 @@ -40,6 +40,7 @@ #include "filenames.h" /* for FILENAME_CMP */ #include "objc-lang.h" #include "ada-lang.h" +#include "p-lang.h" #include "hashtab.h" @@ -4151,6 +4152,13 @@ find_main_name (void) return; } + new_main_name = pascal_main_name (); + if (new_main_name != NULL) + { + set_main_name (new_main_name); + return; + } + /* The languages above didn't identify the name of the main procedure. Fallback to "main". */ set_main_name ("main"); Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.938 diff -u -p -r1.938 Makefile.in --- Makefile.in 17 Sep 2007 19:32:53 -0000 1.938 +++ Makefile.in 27 Sep 2007 07:20:02 -0000 @@ -2751,7 +2751,7 @@ symtab.o: symtab.c $(defs_h) $(symtab_h) $(filenames_h) $(objc_lang_h) $(ada_lang_h) $(hashtab_h) \ $(gdb_obstack_h) $(block_h) $(dictionary_h) $(gdb_string_h) \ $(gdb_stat_h) $(cp_abi_h) $(observer_h) $(gdb_assert_h) \ - $(solist_h) $(ada_lang_h) + $(solist_h) $(p_lang_h) target.o: target.c $(defs_h) $(gdb_string_h) $(target_h) $(gdbcmd_h) \ $(symtab_h) $(inferior_h) $(bfd_h) $(symfile_h) $(objfiles_h) \ $(gdb_wait_h) $(dcache_h) $(regcache_h) $(gdb_assert_h) $(gdbcore_h) \

3 5

Re: [RFC-3] Handle GPC specific name for main function
by Pierre Muller 27 Sep '07

27 Sep '07

> -----Original Message----- > From: gdb-patches-owner(a)sourceware.org [mailto:gdb-patches- > owner(a)sourceware.org] On Behalf Of Daniel Jacobowitz > Sent: Thursday, September 27, 2007 2:11 PM > To: Pierre Muller > Cc: 'Adriaan van Os'; gpc(a)gnu.de; gdb-patches(a)sourceware.org > Subject: Re: [RFC-3] Handle GPC specific name for main function > > On Thu, Sep 27, 2007 at 09:57:41AM +0200, Pierre Muller wrote: > > > On second thought - are these symbols present when linking to a > dynamic > > > libgpc ? > > > > Does this matter anyhow? > > We are just trying to get the > > gdb command 'start' to end up at the right location, > > i.e. for a pascal program, at the start of > > the main procedure of the main source. > > Yes, it matters. libgpc will not be loaded yet, so _p_initialize > might be missing when we try to find the main function. Would then looking after __imp_p_initialize find something? You need to excuse me, but I have no idea of the library loading works... Anyhow, this can only lead to failures to detect GPC properly. I think that the patch, even if it might miss more cases, is also much more safe this way, because we only use (_p_MO__main_program or pascal_main_program) as start command breakpoint if '_p_initialize' was also found. Pierre

1 0

[RFC] Handle GPC specific name for main function
by Pierre Muller 27 Sep '07

27 Sep '07

This patch looks up for GPC specific minimal symbols and assumes that if they are present, the executable was compiled by GPC. GPC used 'pascal_main_program' and now uses '_p__M0_main_program'. Is there some other way to check that the program was really compiled by GPC? (Any C compiled program could have a 'pascal_main_program' function...) Maybe by looking up some other symbol? I found 'GPC_init' as a possible candidate, but I am not sure that this symbol is defined for all versions of GPC, so I did not include it in the present RFC. I tested the patch on Cygwin and it allows to use 'start' command and get directly at the right location. This will also help to reduce the gap between GPC and FreePascal for the (not yet committed) gdb.pascal testsuite directory. Any feedback from GPC users would be most helpful here. Pierre Muller Pascal language maintainer. ChangeLog entry: 2007-09-26 Pierre Muller <muller(a)ics.u-strasbg.fr> * p-lang.h (pascal_main_name): New function. p-lang.c (GPC_MAIN_PROGRAM_NAME_1, GPC_MAIN_PROGRAM_NAME_2): New char array constants corresponding to the two minimal symbols used by GPC compiler. (pascal_main_name): Try to find minimal symbol corresponding to the entry of GPC compiled programs. symtab.c (find_main_name): Try to find pascal specific main name by calling pascal_main_name. $ cvs diff -up p-lang.h p-lang.c symtab.c Index: p-lang.h =================================================================== RCS file: /cvs/src/src/gdb/p-lang.h,v retrieving revision 1.12 diff -u -p -r1.12 p-lang.h --- p-lang.h 23 Aug 2007 18:08:36 -0000 1.12 +++ p-lang.h 26 Sep 2007 14:26:08 -0000 @@ -21,6 +21,8 @@ struct value; +extern char *pascal_main_name (void); + extern int pascal_parse (void); /* Defined in p-exp.y */ $ Index: p-lang.c =================================================================== RCS file: /cvs/src/src/gdb/p-lang.c,v retrieving revision 1.33 diff -u -p -r1.33 p-lang.c --- p-lang.c 23 Sep 2007 16:25:05 -0000 1.33 +++ p-lang.c 26 Sep 2007 14:26:09 -0000 @@ -35,6 +35,43 @@ extern void _initialize_pascal_language (void); +/* The name of the symbol used by GPC compiler. */ + +static const char GPC_MAIN_PROGRAM_NAME_1[] + = "pascal_main_program"; +static const char GPC_MAIN_PROGRAM_NAME_2[] + = "_p__M0_main_program"; + +char * +pascal_main_name (void) +{ + struct minimal_symbol *msym; + CORE_ADDR main_program_name_addr; + static char main_program_name[1024]; + + /* For GPC, main procedure s a special name. + . */ + + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_1, NULL, NULL); + + if (msym != NULL) + { + return (char *)GPC_MAIN_PROGRAM_NAME_1; + } + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_2, NULL, NULL); + + if (msym != NULL) + { + return (char *)GPC_MAIN_PROGRAM_NAME_2; + } + + /* The main procedure doesn't seem to be in GPC. + Thus default "main" should work. */ + return NULL; +} + /* Determines if type TYPE is a pascal string type. Returns 1 if the type is a known pascal type This function is used by p-valprint.c code to allow better string display. Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.165 diff -u -p -r1.165 symtab.c --- symtab.c 24 Sep 2007 07:40:32 -0000 1.165 +++ symtab.c 26 Sep 2007 14:26:10 -0000 @@ -40,6 +40,7 @@ #include "filenames.h" /* for FILENAME_CMP */ #include "objc-lang.h" #include "ada-lang.h" +#include "p-lang.h" #include "hashtab.h" @@ -4151,6 +4152,13 @@ find_main_name (void) return; } + new_main_name = pascal_main_name (); + if (new_main_name != NULL) + { + set_main_name (new_main_name); + return; + } + /* The languages above didn't identify the name of the main procedure. Fallback to "main". */ set_main_name ("main");

2 1

Re: [RFC] Handle GPC specific name for main function
by Pierre Muller 26 Sep '07

26 Sep '07

> I am mostly concerned about the effect on the other languages. > I just want to make sure that the rest of the testsuite results > stay unchanged. If you don't have access to a machine where you > can run the testsuite, then let me know, and I'll give it a quick > run on one of our fast machines for you. Your change looks relatively > straightforward, but it never hurts to be cautious. > I finally ran the testsuite on Ubuntu (inside VMWare) The outcome is a bit better after the patch, but I do NOT understand how this patch could have any influence on 'help' behavior. Thus I suspect that this is just non-reproducable... Pierre gdb.sum.before is for a clean CVS, gdb.sum is after applying the patch. fpc@ubuntu:/usr/local/src/build/gdb/testsuite$ diff gdb.sum.before gdb.sum 1c1 < Test Run By fpc on Wed Sep 26 22:41:20 2007 --- > Test Run By fpc on Wed Sep 26 23:37:23 2007 3056,3060c3056,3060 < FAIL: gdb.base/help.exp: help clear (timeout) < FAIL: gdb.base/help.exp: help commands < FAIL: gdb.base/help.exp: help condition < FAIL: gdb.base/help.exp: help core-file < FAIL: gdb.base/help.exp: help delete "d" abbreviation --- > PASS: gdb.base/help.exp: help clear > PASS: gdb.base/help.exp: help commands > PASS: gdb.base/help.exp: help condition > PASS: gdb.base/help.exp: help core-file > PASS: gdb.base/help.exp: help delete "d" abbreviation 11129,11130c11129,11130 < # of expected passes 10489 < # of unexpected failures 38 --- > # of expected passes 10494 > # of unexpected failures 33

1 1

Re: [RFC] Handle GPC specific name for main function
by Pierre Muller 26 Sep '07

26 Sep '07

> -----Original Message----- > From: Joel Brobecker [mailto:brobecker@adacore.com] > Sent: Wednesday, September 26, 2007 7:58 PM > To: Pierre Muller > Cc: gdb-patches(a)sourceware.org; gpc(a)gnu.de > Subject: Re: [RFC] Handle GPC specific name for main function > > Hello Pierre, > > > 2007-09-26 Pierre Muller <muller(a)ics.u-strasbg.fr> > > * p-lang.h (pascal_main_name): New function. > > p-lang.c (GPC_MAIN_PROGRAM_NAME_1, > > GPC_MAIN_PROGRAM_NAME_2): New char array constants > > corresponding to the two minimal symbols used > > by GPC compiler. > > (pascal_main_name): Try to find minimal symbol > > corresponding to the entry of GPC compiled programs. > > symtab.c (find_main_name): Try to find > > pascal specific main name by calling pascal_main_name. > > This is mostly OK, except for the tiny comment formatting pointed out > by Eli. I have a few suggestions: > > > +/* The name of the symbol used by GPC compiler. */ > > I find this is too vague. I suggest something like: > > /* The name of the symbol that GPC uses as the name of the main > subprogram. There are several possibilities depending on > the version of GPC. */ > > I might even go one step further and put a comment for each entry. > Something like: > > /* The name of the symbol that GPC uses as the name of the main > subprogram (since version ...). */ Here, I really need feedback from GPC developers! > And then, for the other one say: > > /* Older versions of GPC (version ... and older) were using > a different name for the main subprogram. */ > > > +static const char GPC_MAIN_PROGRAM_NAME_1[] > > + = "pascal_main_program"; > > +static const char GPC_MAIN_PROGRAM_NAME_2[] > > + = "_p__M0_main_program"; > > Also, I think you might want to order them the opposite way. > The net effect is that you'll end up trying the newer symbol > first, and then fallback to the older symbol. When people > start using the newer compiler, GDB will need to do only one > symbol lookup to find a match. You are perfectly right, chances are higher that the program will be compiled by a recent or future GPC. > > + /* For GPC, main procedure s a special name. > > + . */ > > I think making the comment above a bit more expressive makes > this comment superfluous. > > > @@ -40,6 +40,7 @@ > > #include "filenames.h" /* for FILENAME_CMP */ > > #include "objc-lang.h" > > #include "ada-lang.h" > > +#include "p-lang.h" > > > > #include "hashtab.h" > > > > You also need to update Makefile.in, since you added a dependency. Funny, while trying to add this, I noticed that ${ada_lang_h} was twice in the dependency list, so I just replaced the second one with ${p_lang_h} > With these adjustments in, your patch is pre-approved (but please > remember to give it a round of testing, just in cases). Thanks, but my problem is that I am unable to run the testsuite, and anyhow gdb.pascal is not yet in CVS, and its mainly there where I expect a change. Pierre

1 0

Re: [RFC] Handle GPC specific name for main function
by Pierre Muller 26 Sep '07

26 Sep '07

Sorry, Could you please point me again to the right place for comment formatting? I remember that single line is different from multi-line, and that multi-line comments should end with a point and two spaces before the closing '*/' http://www.gnu.org/prep/standards/ does not seem very explicit about this, unless I did not find the right place inside... Concerning the comment below, should it be 1) /* For GPC, main procedure has a special name */ 2) /* For GPC, main procedure has a special name. */ or something else? Pierre > -----Original Message----- > From: Eli Zaretskii [mailto:eliz@gnu.org] > Sent: Wednesday, September 26, 2007 5:04 PM > To: Pierre Muller > Cc: gdb-patches(a)sourceware.org; gpc(a)gnu.de > Subject: Re: [RFC] Handle GPC specific name for main function > > > From: "Pierre Muller" <muller(a)ics.u-strasbg.fr> > > Cc: <gpc(a)gnu.de> > > Date: Wed, 26 Sep 2007 16:40:30 +0200 > > > > + /* For GPC, main procedure s a special name. > > + . */ > > What happened here? this comment is not formatted according to GNU > coding style.

2 1

Question about fields alignment
by Pascal Viandier 21 Sep '07

21 Sep '07

Hi, I have a question about field's alignment in GNU Pascal records on different platforms. Consider the sample program below: Program offsets; Type Rec1_t = Record Str16 : String(16); R : Real; End; Rec2_t = Record Str11 : String(11); Rec1 : Rec1_t; End; Rec3_t = Record Str11 : String(11); Str16 : String(16); R : Real; End; Var Rec1 : Rec1_t; Rec2 : Rec2_t; Rec3 : Rec3_t; Begin WriteLn('Offset of Str11 in Rec2 : ', LongInt((a)Rec2.Str11) - LongInt(@Rec2)); WriteLn('Offset of Rec1 in Rec2 : ', LongInt((a)Rec2.Rec1) - LongInt(@Rec2)); WriteLn('Offset of Str16 in Rec2 : ', LongInt((a)Rec2.Rec1.Str16) - LongInt(@Rec2)); WriteLn('Offset of R in Rec2 : ', LongInt((a)Rec2.Rec1.R) - LongInt(@Rec2)); WriteLn; WriteLn('Offset of Str11 in Rec3 : ', LongInt((a)Rec3.Str11) - LongInt(@Rec3)); WriteLn('Offset of Str16 in Rec3 : ', LongInt((a)Rec3.Str16) - LongInt(@Rec3)); WriteLn('Offset of R in Rec3 : ', LongInt((a)Rec3.R) - LongInt(@Rec3)); End. When compiled under X86 linux: dibm0014:/home/gnu-port/tests$ gpc --version gpc 20050331, based on gcc-3.4.5 20050821 (prerelease) (Debian 3.4.4-8) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The program produces the following results: Offset of Str11 in Rec2 : 0 Offset of Rec1 in Rec2 : 20 Offset of Str16 in Rec2 : 20 Offset of R in Rec2 : 48 Offset of Str11 in Rec3 : 0 Offset of Str16 in Rec3 : 20 Offset of R in Rec3 : 48 This looks good to me. Rec1 and Rec3 map on each other. However when compiled under SUN Sparc Solaris 10, the same program produces this result: <gnu-pascal> gpc --version gpc 20051116, based on gcc-3.4.4 Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. <gnu-pascal> offsets Offset of Str11 in Rec2 : 0 Offset of Rec1 in Rec2 : 24 Offset of Str16 in Rec2 : 24 Offset of R in Rec2 : 56 Offset of Str11 in Rec3 : 0 Offset of Str16 in Rec3 : 20 Offset of R in Rec3 : 48 So my question is: How come the difference in alignment of Rec1 in Rec2 between Sparc and Linux? I know that Real data is aligned on 8 bytes boundaries on Sparc platforms but why is the address of Rec1 aligned on 8 bytes instead of 4? So the two records (Rec2 and Rec3) containing the same data are of different sizes and do not map anymore. This causes some trouble in my programs since this kind of data structures are passed back and forth to C code, in order to interface with a database engine. This difference does not happen if there is no Real in the sub-structure. I can manage this with 'dummy' fields in record declarations - enclosed in {$ifdef }...{$endif} but I would like to be sure to understand how the alignment is done in order to avoid recurrent problems on this matter. Kind regards Pascal Viandier

3 2

New gpc snapshot released
by Waldek Hebisch 20 Sep '07

20 Sep '07

I have put a new gpc snapshot at: http://www.math.uni.wroc.pl/~hebisch/gpc-20070904.tar.bz2 This snaphshot contains mostly bugfixes. Main feature is that gcc-4.1.x support is now integrated. NOTE: there is a change of licence: this snapshot uses GPL version 3. For new features see: http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20070904 and for fixed bugs: http://www.math.uni.wroc.pl/~hebisch/gpc/Fixed-20070904 -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

8 37

Re: New gpc snapshot released
by Waldek Hebisch 08 Sep '07

08 Sep '07

I wrote: > I have put a new gpc snapshot at: > > http://www.math.uni.wroc.pl/~hebisch/gpc-20070904.tar.bz2 Sorry for wrong link, the snapshot is at: http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20070904.tar.bz2 -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 3

[RFC] adding gdb.pascal subdir: updated version
by Pierre Muller 07 Sep '07

07 Sep '07

I resend here the result of some discussion with Daniel to add a new directory to test pascal language features. I updated the headers to the new GNU v3 licence and used gdb_get_line_number function as suggested by Daniel. The current patch adds one failure to gdb testsuite if the compiler is Free Pascal and three failures if it it GNU pascal, the increase is related to GNU Pascal specific startup code that is not yet recognized by gdb. The common error has to do with pascal strings. It is not an easy issue to solve because pascal string are using single quotes, but single quotes are also used for specific purpose inside the gdb expression parser, and I do not want to alter this behavior. Comments are most welcome as always, Pierre Muller 2007-09-08 Pierre Muller <muller(a)ics.u-strasbg.fr> Daniel Jacobowitz <dan(a)codesourcery.com> * Makefile.in (ALL_SUBDIRS): Add gdb.pascal. * configure.ac (AC_OUTPUT): Add gdb.pascal/Makefile. * configure: Regenerated. * gdb.pascal/Makefile.in, gdb.pascal/hello.exp, gdb.pascal/hello.pas, gdb.pascal/types.exp, lib/pascal.exp: New files. Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/testsuite/Makefile.in,v retrieving revision 1.18 diff -u -p -r1.18 Makefile.in --- Makefile.in 27 Mar 2007 18:09:35 -0000 1.18 +++ Makefile.in 7 Sep 2007 21:46:12 -0000 @@ -37,7 +37,7 @@ RPATH_ENVVAR = @RPATH_ENVVAR@ ALL_SUBDIRS = gdb.ada gdb.arch gdb.asm gdb.base gdb.cp gdb.disasm \ gdb.dwarf2 \ gdb.fortran gdb.server gdb.java gdb.mi \ - gdb.objc gdb.threads gdb.trace gdb.xml \ + gdb.objc gdb.pascal gdb.threads gdb.trace gdb.xml \ $(SUBDIRS) EXPECT = `if [ -f $${rootme}/../../expect/expect ] ; then \ Index: configure =================================================================== RCS file: /cvs/src/src/gdb/testsuite/configure,v retrieving revision 1.23 diff -u -p -r1.23 configure --- configure 23 Jan 2007 17:11:54 -0000 1.23 +++ configure 7 Sep 2007 21:46:24 -0000 @@ -3102,7 +3102,7 @@ done - ac_config_files="$ac_config_files Makefile gdb.ada/Makefile gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile gdb.cp/Makefile gdb.disasm/Makefile gdb.dwarf2/Makefile gdb.fortran/Makefile gdb.server/Makefile gdb.java/Makefile gdb.mi/Makefile gdb.objc/Makefile gdb.threads/Makefile gdb.trace/Makefile gdb.xml/Makefile" + ac_config_files="$ac_config_files Makefile gdb.ada/Makefile gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile gdb.cp/Makefile gdb.disasm/Makefile gdb.dwarf2/Makefile gdb.fortran/Makefile gdb.server/Makefile gdb.java/Makefile gdb.mi/Makefile gdb.objc/Makefile gdb.pascal/Makefile gdb.threads/Makefile gdb.trace/Makefile gdb.xml/Makefile" cat >confcache <<\_ACEOF # This file is a shell script that caches the results of configure # tests run on this system so they can be shared between configure Index: configure.ac =================================================================== RCS file: /cvs/src/src/gdb/testsuite/configure.ac,v retrieving revision 1.7 diff -u -p -r1.7 configure.ac --- configure.ac 23 Aug 2007 17:58:44 -0000 1.7 +++ configure.ac 7 Sep 2007 21:46:24 -0000 @@ -113,6 +113,6 @@ AC_OUTPUT([Makefile \ gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile \ gdb.cp/Makefile gdb.disasm/Makefile gdb.dwarf2/Makefile \ gdb.fortran/Makefile gdb.server/Makefile \ - gdb.java/Makefile gdb.mi/Makefile \ - gdb.objc/Makefile gdb.threads/Makefile gdb.trace/Makefile \ + gdb.java/Makefile gdb.mi/Makefile gdb.objc/Makefile \ + gdb.pascal/Makefile gdb.threads/Makefile gdb.trace/Makefile \ gdb.xml/Makefile]) Index: gdb.pascal/Makefile.in =================================================================== RCS file: gdb.pascal/Makefile.in diff -N gdb.pascal/Makefile.in --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/Makefile.in 7 Sep 2007 21:46:31 -0000 @@ -0,0 +1,24 @@ +VPATH = @srcdir@ +srcdir = @srcdir@ + +EXECUTABLES = hello/hello + +MISCELLANEOUS = + +all info install-info dvi install uninstall installcheck check: + @echo "Nothing to be done for $@..." + +clean mostlyclean: + -find . -name '*.o' -print | xargs rm -f + -find . -name '*.ali' -print | xargs rm -f + -find . -name 'b~*.ad[sb]' -print | xargs rm -f + -rm -f *~ a.out xgdb *.x *.ci *.tmp + -rm -f *~ *.o a.out xgdb *.x *.ci *.tmp + -rm -f core core.coremaker coremaker.core corefile $(EXECUTABLES) + -rm -f $(MISCELLANEOUS) twice-tmp.c + +distclean maintainer-clean realclean: clean + -rm -f *~ core + -rm -f Makefile config.status config.log + -rm -f *-init.exp + -rm -fr *.log summary detail *.plog *.sum *.psum site.* Index: gdb.pascal/hello.exp =================================================================== RCS file: gdb.pascal/hello.exp diff -N gdb.pascal/hello.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/hello.exp 7 Sep 2007 21:46:31 -0000 @@ -0,0 +1,72 @@ +# Copyright 2007 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +if $tracelevel then { + strace $tracelevel +} + +load_lib "pascal.exp" + +set testfile "hello" +set srcfile ${testfile}.pas +set binfile ${objdir}/${subdir}/${testfile} + +if {[gdb_compile_pascal "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable [list debug ]] != "" } { + return -1 +} + +gdb_exit +gdb_start +gdb_reinitialize_dir $srcdir/$subdir +gdb_load ${binfile} +set bp_location1 [gdb_get_line_number "set breakpoint 1 here"] +set bp_location2 [gdb_get_line_number "set breakpoint 2 here"] + +if { [gdb_breakpoint ${srcfile}:${bp_location1}] } { + pass "setting breakpoint 1" +} +if { [gdb_breakpoint ${srcfile}:${bp_location2}] } { + pass "setting breakpoint 2" +} + +# Verify that "start" lands inside the right procedure. +if { [gdb_start_cmd] < 0 } { + untested start + return -1 +} + +# This test fails for gpc +# because debug information for 'main' +# is in some <implicit code> +gdb_test "" \ + ".* at .*hello.pas.*" \ + "start" + +gdb_test "cont" \ + "Breakpoint .*:${bp_location1}.*" \ + "Going to first breakpoint" +gdb_test "print st" \ + ".* = ''.*" \ + "Empty string check" + +# This test also fails for gpc because the program +# stops after the string has been written +# while it should stop before writing it +gdb_test "cont" \ + "Breakpoint .*:${bp_location2}.*" \ + "Going to second breakpoint" +gdb_test "print st" \ + ".* = 'Hello, world!'.*" \ + "String after assignment check" Index: gdb.pascal/hello.pas =================================================================== RCS file: gdb.pascal/hello.pas diff -N gdb.pascal/hello.pas --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/hello.pas 7 Sep 2007 21:46:31 -0000 @@ -0,0 +1,15 @@ +program hello; + +var + st : string; + +procedure print_hello; +begin + Writeln('Before assignment'); { set breakpoint 1 here } + st:='Hello, world!'; + writeln(st); {set breakpoint 2 here } +end; + +begin + print_hello; +end. Index: gdb.pascal/types.exp =================================================================== RCS file: gdb.pascal/types.exp diff -N gdb.pascal/types.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/types.exp 7 Sep 2007 21:46:31 -0000 @@ -0,0 +1,109 @@ +# Copyright 1994, 1995, 1997, 1998, 2007 Free Software Foundation, Inc. +# Copyright 2007 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +# Please email any bugs, comments, and/or additions to this file to: +# bug-gdb(a)prep.ai.mit.edu + +# This file was adapted from old Chill tests by Stan Shebs +# (shebs(a)cygnus.com). +# Adapted to pascal by Pierre Muller + +if $tracelevel then { + strace $tracelevel +} + +set prms_id 0 +set bug_id 0 + +# Set the current language to pascal. This counts as a test. If it +# fails, then we skip the other tests. + +proc set_lang_pascal {} { + global gdb_prompt + + if [gdb_test "set language pascal" ""] { + return 0; + } + + if ![gdb_test "show language" ".* source language is \"pascal\".*"] { + return 1; + } else { + return 0; + } +} + +proc test_integer_literal_types_accepted {} { + global gdb_prompt + + # Test various decimal values. + # Should be integer*4 probably. + gdb_test "pt 123" "type = int" +} +proc test_character_literal_types_accepted {} { + global gdb_prompt + + # Test various character values. + + gdb_test "pt 'a'" "type = char" +} + +proc test_string_literal_types_accepted {} { + global gdb_prompt + + # Test various character values. + + gdb_test "pt 'a simple string'" "type = string" +} + +proc test_logical_literal_types_accepted {} { + global gdb_prompt + + # Test the only possible values for a logical, TRUE and FALSE. + + gdb_test "pt TRUE" "type = bool" + gdb_test "pt FALSE" "type = bool" +} + +proc test_float_literal_types_accepted {} { + global gdb_prompt + + # Test various floating point formats + + # this used to guess whether to look for "real*4" or + # "real*8" based on a target config variable, but noone + # maintained it properly. + + gdb_test "pt .44" "type = double" + gdb_test "pt 44.0" "type = double" + gdb_test "pt 10e20" "type = double" + gdb_test "pt 10E20" "type = double" +} + +# Start with a fresh gdb. + +gdb_exit +gdb_start +gdb_reinitialize_dir $srcdir/$subdir + +if [set_lang_pascal] then { + test_integer_literal_types_accepted + test_logical_literal_types_accepted + test_character_literal_types_accepted + test_string_literal_types_accepted + test_float_literal_types_accepted +} else { + warning "$test_name tests suppressed." 0 +} Index: lib/pascal.exp =================================================================== RCS file: lib/pascal.exp diff -N lib/pascal.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ lib/pascal.exp 7 Sep 2007 21:46:32 -0000 @@ -0,0 +1,152 @@ +# Copyright 2007 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +load_lib libgloss.exp + +set pascal_init_done 0 + +# This procedure looks for a suitable pascal compiler +# For now only GNU pascal compiler and Free Pascal compiler +# are searched. +# First, environment variable GPC is checked +# if present, GPC compiler is assumed to be the value of +# that environment variable. +# Second, environment variable FPC is checked +# if present, Free Pascal compiler is assumed to be the value of +# that environment variable. +# Third, gpc executable is searched using `which gpc` +# Lastly, fpc executable is searched using `which fpc` +# Using environment variable allows to force +# which compiler is used in testsuite + +proc pascal_init {} { + global pascal_init_done + global pascal_compiler_is_gpc + global pascal_compiler_is_fpc + global gpc_compiler + global fpc_compiler + global env + + if { $pascal_init_done == 1 } { + return + } + + set pascal_compiler_is_gpc 0 + set pascal_compiler_is_fpc 0 + set gpc_compiler [transform gpc] + set fpc_compiler [transform fpc] + + if ![is_remote host] { + if { [info exists env(GPC)] } { + set pascal_compiler_is_gpc 1 + set gpc_compiler $env(GPC) + verbose -log "Assuming GNU Pascal ($gpc_compiler)" + } elseif { [info exists env(FPC)] } { + set pascal_compiler_is_fpc 1 + set fpc_compiler $env(FPC) + verbose -log "Assuming Free Pascal ($fpc_compiler)" + } elseif { [which $gpc_compiler] != 0 } { + set pascal_compiler_is_gpc 1 + verbose -log "GNU Pascal compiler found" + } elseif { [which $fpc_compiler] != 0 } { + set pascal_compiler_is_fpc 1 + verbose -log "Free Pascal compiler found" + } + } + set pascal_init_done 1 +} + +proc gpc_compile {source dest type options} { + global gpc_compiler + set add_flags "" + if {$type == "object"} { + append add_flags " -c" + } + + if { $type == "preprocess" } { + append add_flags " -E" + } + + if { $type == "assembly" } { + append add_flags " -S" + } + + foreach i $options { + if { $i == "debug" } { + if [board_info $dest exists debug_flags] { + append add_flags " [board_info $dest debug_flags]"; + } else { + append add_flags " -g" + } + } + } + + set result [remote_exec host $gpc_compiler "-o $dest --automake $add_flags $source"] + return $result +} + +proc fpc_compile {source dest type options} { + global fpc_compiler + set add_flags "" + if {$type == "object"} { + append add_flags " -Cn" + } + + if { $type == "preprocess" } { + return "Free Pascal can not preprocess" + } + + if { $type == "assembly" } { + append add_flags " -al" + } + + foreach i $options { + if { $i == "debug" } { + if [board_info $dest exists debug_flags] { + append add_flags " [board_info $dest debug_flags]"; + } else { + append add_flags " -g" + } + } + } + + set result [remote_exec host $fpc_compiler "-o$dest $add_flags $source"] + return $result +} + +proc gdb_compile_pascal {source dest type options} { + global pascal_init_done + global pascal_compiler_is_gpc + global pascal_compiler_is_fpc + + if { $pascal_init_done == 0 } { + pascal_init + } + + if { $pascal_compiler_is_fpc == 1 } { + set result [fpc_compile $source $dest $type $options] + } elseif { $pascal_compiler_is_gpc == 1 } { + set result [gpc_compile $source $dest $type $options] + } else { + unsupported "No pascal compiler found" + return "No pascal compiler. Compilation failed." + } + + if ![file exists $dest] { + unsupported "Pascal compilation failed: $result" + return "Pascal compilation failed." + } +} +

1 1

Re: New gpc snapshot released
by Russell Whitaker 07 Sep '07

07 Sep '07

Hi Results here: Native configuration is i686-pc-linux-gnu (bigred) === gpc tests === Running target any Running testsuite ... UNSUPPORTED: aregextest.pas FAIL: fjf1102.pas FAIL: fjf322.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas === gpc Summary === # of tests 5111 # of expected passes 5105 # of unexpected failures 5 # of unsupported tests 1 /home/russ/src/gcc_collection/gpc-20070904/build/gcc/xgpc version 20070904, based on gcc-4.1.2 Good job. I wonder, though, how many of the failures are due to back end bugs. Russ

1 0

indirect jmp redux (Mac OS on Intel)
by Frederick Karl Kepner DuPuy 04 Sep '07

04 Sep '07

Hi. Regarding gpc for Mac OS X on Intel, I found a thread in the archives (see below) from October 2006 concerning an error message a user (Nestor Aguilera) got in compiling even the simplest programs. Unless I'm misreading the thread, no final conclusion was reached. Is anything further known now? Here's the thread: http://www.gnu-pascal.de/crystal/gpc/en/mail13854.html And the gist of the error messages: indirect jmp without `*' I'm having the same issue he had: programs which used to compile and execute happily with the gpc for PPC compiler are less happy with the gpc for Intel compiler--- they're still compiling, but issuing this error message repeatedly as they do so. I believe the output executes OK; but you can see why this is unsettling. So: is this a problem, or just an annoyance to be lived with? And is it happening to everybody trying to use gpc for Mac on Intel? (If so I'm curious as to why it hasn't been discussed since October.) (Please pardon my near-complete ignorance, by the way.) Thanks a lot, Rick DuPuy

3 5

linux test results for gpc based on GCC-4.1.2
by Matthias Klose 30 Aug '07

30 Aug '07

please find attach test results for gpc based on GCC-4.1.2 built on Ubuntu gutsy development. Listing for each architecture the results for the build based on 4.1.2 and then for the build based on 3.4.6. The packages (gpc-2.1-3.4 and gpc-4.1) are available in the Ubuntu archives. Looks like there are some regressions, or I'm missing some patches. Matthias ----- i486-linux-gnu ----------------------------------------------- Running target any FAIL: agettext2test.pas FAIL: asmtest.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf524f.pas FAIL: fjf524g.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf958c.pas FAIL: fjf998r.pas FAIL: nicola4c.pas === gpc Summary === # of tests 5070 # of expected passes 5051 # of unexpected failures 18 # of unsupported tests 1 3.4.6: Running target any FAIL: agettext2test.pas FAIL: fjf998r.pas === gpc Summary === # of tests 5057 # of expected passes 5054 # of unexpected failures 2 # of unsupported tests 1 ----- i686-linux-gnu ----------------------------------------------- Running target any FAIL: asmtest.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf524f.pas FAIL: fjf524g.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf958c.pas FAIL: nicola4c.pas === gpc Summary === # of tests 5070 # of expected passes 5053 # of unexpected failures 16 # of unsupported tests 1 3.4.6: Running target any === gpc Summary === # of tests 5057 # of expected passes 5056 # of unsupported tests 1 ----- amd64-linux-gnu ---------------------------------------------- Running target any FAIL: chuck6.pas FAIL: fieldw.pas FAIL: fjf23.pas FAIL: fjf30b.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf524f.pas FAIL: fjf524g.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf958c.pas FAIL: fsc22.pas FAIL: fsc24.pas FAIL: nicola4c.pas FAIL: writeb.pas FAIL: writec.pas FAIL: writee.pas FAIL: writeg.pas === gpc Summary === # of tests 5070 # of expected passes 5043 # of unexpected failures 25 # of unsupported tests 2 3.4.6: Running target any FAIL: chief40.pas FAIL: chuck6.pas FAIL: fieldw.pas FAIL: fjf23.pas FAIL: fjf30b.pas FAIL: fjf327.pas FAIL: fjf526a.pas FAIL: fjf526b.pas FAIL: fsc22.pas FAIL: fsc24.pas FAIL: shl.pas FAIL: writeb.pas FAIL: writec.pas FAIL: writee.pas FAIL: writeg.pas === gpc Summary === # of tests 5057 # of expected passes 5040 # of unexpected failures 15 # of unsupported tests 2 ----- powerpc-linux-gnu -------------------------------------------- Running target any FAIL: agettext2test.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf998r.pas FAIL: nicola4c.pas FAIL: prep2p.pas === gpc Summary === # of tests 5070 # of expected passes 5052 # of unexpected failures 15 # of unsupported tests 3 3.4.6: Running target any FAIL: agettext2test.pas FAIL: fjf998r.pas FAIL: prep2p.pas === gpc Summary === # of tests 5057 # of expected passes 5051 # of unexpected failures 3 # of unsupported tests 3 ----- sparc-linux-gnu ---------------------------------------------- Running target any FAIL: agettext2test.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf746.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf967e.pas FAIL: fjf998r.pas FAIL: nicola4c.pas === gpc Summary === # of tests 5070 # of expected passes 5052 # of unexpected failures 16 # of unsupported tests 2 3.4.6: Running target any FAIL: agettext2test.pas FAIL: fjf980a.pas FAIL: fjf980b.pas FAIL: fjf998r.pas === gpc Summary === # of tests 5057 # of expected passes 5050 # of unexpected failures 4 # of unsupported tests 3 ----- ia64-linux-gnu ----------------------------------------------- Running target any FAIL: chief35b.pas FAIL: chuck6.pas FAIL: fieldw.pas FAIL: fjf23.pas FAIL: fjf30b.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf524f.pas FAIL: fjf524g.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf958c.pas FAIL: fsc22.pas FAIL: fsc24.pas FAIL: nicola4c.pas FAIL: writeb.pas FAIL: writec.pas FAIL: writee.pas FAIL: writeg.pas === gpc Summary === # of tests 5070 # of expected passes 5042 # of unexpected failures 26 # of unsupported tests 2 3.4.6: Running target any FAIL: chief40.pas FAIL: chuck6.pas FAIL: fieldw.pas FAIL: fjf23.pas FAIL: fjf30b.pas FAIL: fjf327.pas FAIL: fjf526a.pas FAIL: fjf526b.pas FAIL: fsc22.pas FAIL: fsc24.pas FAIL: shl.pas FAIL: writeb.pas FAIL: writec.pas FAIL: writee.pas FAIL: writeg.pas === gpc Summary === # of tests 5057 # of expected passes 5040 # of unexpected failures 15 # of unsupported tests 2

1 0

Re: AKFAvatar
by M. Uhle sen. 18 Aug '07

18 Aug '07

This seems to me to be another version of a very academic discussion about our "new" students, who all know how to "click"......Sorry, they are as the are. Trying to teach "programming" to undergraduate students for years now, I do see the problem from a different point of view. It is NOT a question of IDE's, debugging-Systems, sophisticated tools, not even languages. To me it seems to be a problem of missing applications. What I mean? Student: To program my first "hallo world" is simply boaring, I am not interested to print a simple sin-table.. and the like. What on earth all this programming is to be used for? Some years ago Iswitched to: A simple editor, a plain compiler, and a textbased console and AN INTERESTING JOB to do. Say: simulate an atomobile on a 10 km long road with traffic lights. Answer the question: does it make sense to ignore speed limits or does it not? So jump, dive, and swim.. And the advice to our beginners is: Start with a small program saying 'Program Speed Simulation Start' 'Program Speed Simulation Stop' If that works, you know: I can use the editor, it worked I can use the compiler, it worked I wrote my first program, it worked. I save it as version 0, copy ist to version 1, and I will expand it now to version n+1. Output will be written to screen and (later) redirected to a file from where it can be plotted by eg. xmgrace or so. We all in the teaching business should think about interesting 'real life' examples, it seems there are just a few! The sophisticated tools should NOT be used. To be honest: even the above example is - in my opinion - not real enough! What I mean? try to use "Kdevelop" (or any of the like) with beginners. Even the "hallo world" project creates "thousands" of files in the associated directories, no beginner will understand that not to talk about keeping track. I dropped it completely (for beginners, not for later real work). If I am allowed to add one thing: my students are still using GPC 2004.12.18 Why? There is no newer binary available on "www.gnu-pascal.de", and beginners are NOT able to compile GPC from scratch. And: most Pascal users are not experts for c! Mathias Uhle -- Univ.-Prof. Dr.-Ing. Mathias Uhle, Messtechnik, Universitaet Dortmund Leonhard Euler Str. 5, D-44221 Dortmund Tel: +49.231.755.3257 Fax: +49.231.755.2631 email: uhle(a)mt.mb.uni-dortmund.de http://www.mt.mb.uni-dortmund.de

3 3

[Fwd: Re: AKFAvatar]
by Adriaan van Os 17 Aug '07

17 Aug '07

-------- Original Message -------- Subject: Re: AKFAvatar Date: Thu, 16 Aug 2007 22:53:46 +0200 From: marcov(a)stack.nl (Marco van de Voort) To: Adriaan van Os <gpc(a)microbizz.nl> References: <20070814101911.GA5425(a)castrophe.akfoerster.de> <46C3FF48.50100(a)microbizz.nl> In gmane.comp.compilers.gpc, you wrote: >> your program to use my library. (The program may not use the CRT unit or >> any other nonstandard output facility) > > The same mistake was made in teaching mathematics the-modern-way, with > much graphics and much less exact reasoning nor proofs-of-correctness. > Well, indeed in a democratic society the Pythogorean Theorem > <http://en.wikipedia.org/wiki/Pythagorean_theorem> should no longer be > proofed, which is dictatorial, or even be thought about, which is > elitarian, but decided on by voting .... > > This is all bullsh..., I mean nonsense. Programming, like mathematics, > *is* about exact reasoning and it *is* about abstract thinking. The task > of teachers is to lead pupils into this new world and to bring young > people to spiritual maturity. It is *not* the task of teachers to succumb > to the first shallow prejuduce, like whether something yet unknown is > "boring" or not. I talked a bit with teachers on the FPC booth at Systems 2005, and I got a different feeling; Teachers have had a love for the consoles tools because their simplicity somewhat put a brake on the time being spent in e.g. form designers making blinkenlightes with buttons and the like. (and because they are generally too lazy to re-setup their courses) However slowly that is becoming a problem because current students seem to miss any feel for the textconsole at all, having never used Dos. It is simply not a common skill anymore. And yes, that is not a really hard skill to teach, but every course day lost also detracts from the real objective of the course. The consensus seemed to be that a simple IDE maybe integrated with a lib to do some minimal work (few textfields/memo's input, a few output ones) would be the best. IOW one should separate "old and simple" and the real issue "can't be abused" here. Anyway, TP is probably still too free for a CS practicum, though the skills to exploit it may have decreased in new students A cut down compiler,IDE and lib that can't do anything communicating with the outside world except this special lib would be best. So one of the open source compilers, cut down and an IDE (Bloodshed?). Main problem probably: the debugger.

1 0

AKFAvatar
by Andreas K. Foerster 17 Aug '07

17 Aug '07

Hello, you know the problem? You want to teach somebody how to program in Pascal, so you start with simple line oriented programs. And then you get the answer "Pascal is boring, because you can only write old DOS programs with it" (Yes, some even call them "DOS programs", although they run under GNU/Linux). So for those who want to teach Pascal my project AKFAvatar might be a solution. You can take any Pascal program, which uses only the standard input/output and compile it into a funny graphical program with no extra effort (apart from the first installation). Yes, there is no need to make any changes to the program, just use a wrapper-script to compile your program to use my library. (The program may not use the CRT unit or any other nonstandard output facility) If you want to make use of more features, you can leave the script away and include the unit with "uses avatar;". There are some funny additional procedures to use. For example you can show image files, or play audio files... So programming with it is fun, but still easy enough for beginners. Please have a look at it: http://akfoerster.de/akfavatar/ It is still alpha and almost only tested under GNU/Linux so far. Please tell me what you think about it. -- AKFoerster

2 2

Re: Newbie Q: Porting TObject to gpc?
by Alexander von Below 10 Aug '07

10 Aug '07

Thanks! To be very honest, all I care about is that it compiles on a Mac, so FreePascal is good enough! Alex Am 10.08.2007 um 12:00 schrieb Marco van de Voort: >> You are absolutely correct, sorry for not adding a code snippet: > > This is Delphi code, not Turbo Pascal. > > Note that I only monitor the GPC list for certain interfacing with FPC > purposes (which will compile this flawlessly), so I can't really > comment on > the GPC status. > > Best to post that code (and the Delphi observation) to the list too. >

1 0

Newbie Q: Porting TObject to gpc?
by Alexander v. Below 10 Aug '07

10 Aug '07

Hello, this is probably a silly newbie question, but I have searched the archives and documentation without much enlightenment for me. I have existing sourcecode, which probably comes from Borland Pascal and uses TObject. Can I use TObject in gpc, or do I have to replace it with some other object? Is there some comprehensive list of pitfalls when porting Borland stuff over to gpc? Am I better off rewriting it from scratch ;) ? Thanks Alex

2 1

Re: Newbie Q: Porting TObject to gpc?
by Alexander von Below 10 Aug '07

10 Aug '07

You are absolutely correct, sorry for not adding a code snippet: Here we go, I hope this gives you an idea unit Someunit; interface uses Classes, Sysutils, U_Global, L_Lockdata, U_Strings, U_RegExpr, L_Wintol, U_Images, U_Stream, U_Tiff, U_Tiff_Tags, U_Tiff_Global, U_Pixels, L_Mathe, LeanOcr, U_Wininfo; TMyFile = class(TObject) private FFilename: String; { etc } procedure SetFilename(const Value: String); public destructor destroy; override; property Filename: String read FFilename write SetFilename; { etc } end; Alex Am 10.08.2007 um 10:58 schrieb Marco van de Voort: > In gmane.comp.compilers.gpc, you wrote: >> this is probably a silly newbie question, but I have searched the >> archives and documentation without much enlightenment for me. >> >> I have existing sourcecode, which probably comes from Borland Pascal >> and uses TObject. Can I use TObject in gpc, or do I have to >> replace it >> with some other object? >> >> Is there some comprehensive list of pitfalls when porting Borland >> stuff over to gpc? Am I better off rewriting it from scratch ;) ? > > I can't answer the direct question, but please note that both Borland > dialects (Turbo Pascal and Delphi) have an TObject. So make sure > about which > one you are talking. A code fragment might help.

1 0

PortAudio package
by Adriaan van Os 09 Aug '07

09 Aug '07

PortAudio <http://www.portaudio.com/> Pascal units can be downloaded from <http://www.microbizz.nl/portaudio-20070809.tar.gz>. Next step will be to do some tests to see if everything (or anything) works. The units compile with both FPC and GPC. Regards, Adriaan van Os

1 0

Re: [PATCH] Unbounded array support implemented (for Modula-2)
by Pierre Muller 27 Jul '07

27 Jul '07

> > Modula-2 is not the only language supporting unbounded arrays, I > > would be interested in using the same kind of code for pascal > > language support. > > sure, I'm all for refactoring code.. > > > Maybe a more general approach would be useful? > > maybe - although I suspect the devil is in the detail. Basically > Modula-2 assumes that all unbounded arrays start at index 0 and the > caller can be legally access all indices 0..HIGH(a). GNU Modula-2 > implements unbounded arrays by creating a structure whose first field > is a pointer to type, and the second structure is the HIGH value > (unsigned int). So the patches basically detect if the array > declaration matches a GNU Modula-2 unbounded structure (testing field > names and types and language). If so then it maps any reference to > a[i] onto a->_m2_contents[i] and HIGH(a) onto a->_m2_high. How does > GNU Pascal implement unbounded arrays? This is basically also the case for parameter unbounded arrays: the valid indexes are from 0 to high(a) and high(a) is passed as an additional hidden parameter, called highA (high in lower case followed by the uppercase name of the parameter) for free pascal and open_array_length_0 (or _x for the X+1 open array parameter) for GNU pascal. The open array type can be recongnized by the fact that the lower bound is 0, while the higher bound is -1. Free pascal now also supports global open array variables which are allocated by using SetLength function. They are basically hidden pointers. The high values is at offset -4 (or size of pointer more generally) relative to the pointer address. I don't know if GPC supports this syntax. Maybe someone from GPC team can answer this question. Pierre Muller

1 0

bug: gpc+gcc-4.1.2
by Russ Whitaker 22 Jul '07

22 Jul '07

Hi A while back patched gcc-4.1.2 with gcc-4.1.5f.diff and built c,pascal compilers. Recently discovered the patched version of gcc has a bug that the unpatched version does not have. Attempting to build gcc with the patched gcc: [...] stage1/xgcc -Bstage1/ -B/usr/local/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.1.2/gcc -I../../gcc-4.1.2/gcc/. -I../../gcc-4.1.2/gcc/../include -I../../gcc-4.1.2/gcc/../libcpp/include ../../gcc-4.1.2/gcc/c-common.c -o c-common.o ../../gcc-4.1.2/gcc/c-common.c: In function 'c_common_nodes_and_builtins': ../../gcc-4.1.2/gcc/c-common.c:2954: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [c-common.o] Error 1 make[2]: Leaving directory `/home/russ/src/gcc_collection/gcc-4.1.2/build/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/home/russ/src/gcc_collection/gcc-4.1.2/build/gcc' make: *** [bootstrap] Error 2 Thanks russ

1 1

Re: [RFC] adding gdb.pascal subdir
by Pierre Muller 18 Jul '07

18 Jul '07

>On Tue, Jul 17, 2007 at 04:22:26PM +0200, Pierre Muller wrote: >> A possible work-around would be to fix breakpoints at specific >> positions in the file, but this would require to re-edit hello.exp >> each time someone changes hello.pas source. >> I have no idea if this is acceptable. > >Take a look at the testsuite function "gdb_get_line_number". You're >exactly right that fixing the breakpoints at specific positions is a >bad idea, but this way they can "float" along with the source. I tried to use that and it seems to work partially. gpc seems to have problems in setting the correct position for a breakpoint. After 'break 10' and 'cont' gdb ends up at line 11 :( I suspect that this is not specific to gpc, but it might be related to the fact that default optimizations are too high, and that thus the debug information is not completely reliable. >> The other failure is common to gpc and fpc: >> (gdb) ptyp 'a simple string' ^M >> gives a strange error: >> No symbol table is loaded: use "file" command. >> I have no idea why this happens. > >It is probably trying to call malloc to allocate the string. No, it must be something else: if I first load the hello executable, then it claims: No symbol "a simple string" in current context. This probably means that it is still looking for a symbol instead of taking it for a constant string. This is indeed a bug that should be fixed. I get 3 errors for gpc and one for fpc with the files below. What should we do? Comment out all failing test, or simplify them so that they succeed? Failing tests are good ways to get things fixed, no? If we remove all failing tests, chances are higher that we will not fix them. Pierre Muller Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/testsuite/Makefile.in,v retrieving revision 1.18 diff -u -p -r1.18 Makefile.in --- Makefile.in 27 Mar 2007 18:09:35 -0000 1.18 +++ Makefile.in 18 Jul 2007 08:53:29 -0000 @@ -37,7 +37,7 @@ RPATH_ENVVAR = @RPATH_ENVVAR@ ALL_SUBDIRS = gdb.ada gdb.arch gdb.asm gdb.base gdb.cp gdb.disasm \ gdb.dwarf2 \ gdb.fortran gdb.server gdb.java gdb.mi \ - gdb.objc gdb.threads gdb.trace gdb.xml \ + gdb.objc gdb.pascal gdb.threads gdb.trace gdb.xml \ $(SUBDIRS) EXPECT = `if [ -f $${rootme}/../../expect/expect ] ; then \ Index: configure =================================================================== RCS file: /cvs/src/src/gdb/testsuite/configure,v retrieving revision 1.23 diff -u -p -r1.23 configure --- configure 23 Jan 2007 17:11:54 -0000 1.23 +++ configure 18 Jul 2007 08:53:31 -0000 @@ -3102,7 +3102,7 @@ done - ac_config_files="$ac_config_files Makefile gdb.ada/Makefile gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile gdb.cp/Makefile gdb.disasm/Makefile gdb.dwarf2/Makefile gdb.fortran/Makefile gdb.server/Makefile gdb.java/Makefile gdb.mi/Makefile gdb.objc/Makefile gdb.threads/Makefile gdb.trace/Makefile gdb.xml/Makefile" + ac_config_files="$ac_config_files Makefile gdb.ada/Makefile gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile gdb.cp/Makefile gdb.disasm/Makefile gdb.dwarf2/Makefile gdb.fortran/Makefile gdb.server/Makefile gdb.java/Makefile gdb.mi/Makefile gdb.objc/Makefile gdb.pascal/Makefile gdb.threads/Makefile gdb.trace/Makefile gdb.xml/Makefile" cat >confcache <<\_ACEOF # This file is a shell script that caches the results of configure # tests run on this system so they can be shared between configure Index: configure.ac =================================================================== RCS file: /cvs/src/src/gdb/testsuite/configure.ac,v retrieving revision 1.6 diff -u -p -r1.6 configure.ac --- configure.ac 23 Jan 2007 17:11:55 -0000 1.6 +++ configure.ac 18 Jul 2007 08:53:31 -0000 @@ -115,6 +115,6 @@ AC_OUTPUT([Makefile \ gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile \ gdb.cp/Makefile gdb.disasm/Makefile gdb.dwarf2/Makefile \ gdb.fortran/Makefile gdb.server/Makefile \ - gdb.java/Makefile gdb.mi/Makefile \ - gdb.objc/Makefile gdb.threads/Makefile gdb.trace/Makefile \ + gdb.java/Makefile gdb.mi/Makefile gdb.objc/Makefile \ + gdb.pascal/Makefile gdb.threads/Makefile gdb.trace/Makefile \ gdb.xml/Makefile]) Index: gdb.pascal/Makefile.in =================================================================== RCS file: gdb.pascal/Makefile.in diff -N gdb.pascal/Makefile.in --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/Makefile.in 18 Jul 2007 08:53:33 -0000 @@ -0,0 +1,24 @@ +VPATH = @srcdir@ +srcdir = @srcdir@ + +EXECUTABLES = hello/hello + +MISCELLANEOUS = + +all info install-info dvi install uninstall installcheck check: + @echo "Nothing to be done for $@..." + +clean mostlyclean: + -find . -name '*.o' -print | xargs rm -f + -find . -name '*.ali' -print | xargs rm -f + -find . -name 'b~*.ad[sb]' -print | xargs rm -f + -rm -f *~ a.out xgdb *.x *.ci *.tmp + -rm -f *~ *.o a.out xgdb *.x *.ci *.tmp + -rm -f core core.coremaker coremaker.core corefile $(EXECUTABLES) + -rm -f $(MISCELLANEOUS) twice-tmp.c + +distclean maintainer-clean realclean: clean + -rm -f *~ core + -rm -f Makefile config.status config.log + -rm -f *-init.exp + -rm -fr *.log summary detail *.plog *.sum *.psum site.* Index: gdb.pascal/hello.exp =================================================================== RCS file: gdb.pascal/hello.exp diff -N gdb.pascal/hello.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/hello.exp 18 Jul 2007 08:53:33 -0000 @@ -0,0 +1,74 @@ +# Copyright 2007 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, +# USA. + +if $tracelevel then { + strace $tracelevel +} + +load_lib "pascal.exp" + +set testfile "hello" +set srcfile ${testfile}.pas +set binfile ${objdir}/${subdir}/${testfile} + +if {[gdb_compile_pascal "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable [list debug ]] != "" } { + return -1 +} + +gdb_exit +gdb_start +gdb_reinitialize_dir $srcdir/$subdir +gdb_load ${binfile} +set bp_location1 [gdb_get_line_number "set breakpoint 1 here"] +set bp_location2 [gdb_get_line_number "set breakpoint 2 here"] + +if { [gdb_breakpoint ${srcfile}:${bp_location1}] } { + pass "setting breakpoint 1" +} +if { [gdb_breakpoint ${srcfile}:${bp_location2}] } { + pass "setting breakpoint 2" +} + +# Verify that "start" lands inside the right procedure. +if { [gdb_start_cmd] < 0 } { + untested start + return -1 +} + +# This test fails for gpc +# because debug information for 'main' +# is in some <implicit code> +gdb_test "" \ + ".* at .*hello.pas.*" \ + "start" + +gdb_test "cont" \ + "Breakpoint .*:${bp_location1}.*" \ + "Going to first breakpoint" +gdb_test "print st" \ + ".* = ''.*" \ + "Empty string check" + +# This test also fails for gpc because the program +# stops after the string has been written +# while it should stop before writing it +gdb_test "cont" \ + "Breakpoint .*:${bp_location2}.*" \ + "Going to second breakpoint" +gdb_test "print st" \ + ".* = 'Hello, world!'.*" \ + "String after assignment check" Index: gdb.pascal/hello.pas =================================================================== RCS file: gdb.pascal/hello.pas diff -N gdb.pascal/hello.pas --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/hello.pas 18 Jul 2007 08:53:33 -0000 @@ -0,0 +1,15 @@ +program hello; + +var + st : string; + +procedure print_hello; +begin + Writeln('Before assignment'); { set breakpoint 1 here } + st:='Hello, world!'; + writeln(st); {set breakpoint 2 here } +end; + +begin + print_hello; +end. Index: gdb.pascal/types.exp =================================================================== RCS file: gdb.pascal/types.exp diff -N gdb.pascal/types.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/types.exp 18 Jul 2007 08:53:33 -0000 @@ -0,0 +1,109 @@ +# Copyright 1994, 1995, 1997, 1998, 2007 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +# Please email any bugs, comments, and/or additions to this file to: +# bug-gdb(a)prep.ai.mit.edu + +# This file was adapted from old Chill tests by Stan Shebs +# (shebs(a)cygnus.com). +# Adapted to pascal by Pierre Muller + +if $tracelevel then { + strace $tracelevel +} + +set prms_id 0 +set bug_id 0 + +# Set the current language to pascal. This counts as a test. If it +# fails, then we skip the other tests. + +proc set_lang_pascal {} { + global gdb_prompt + + if [gdb_test "set language pascal" ""] { + return 0; + } + + if ![gdb_test "show language" ".* source language is \"pascal\".*"] { + return 1; + } else { + return 0; + } +} + +proc test_integer_literal_types_accepted {} { + global gdb_prompt + + # Test various decimal values. + # Should be integer*4 probably. + gdb_test "pt 123" "type = int" +} +proc test_character_literal_types_accepted {} { + global gdb_prompt + + # Test various character values. + + gdb_test "pt 'a'" "type = char" +} + +proc test_string_literal_types_accepted {} { + global gdb_prompt + + # Test various character values. + + gdb_test "pt 'a simple string'" "type = string" +} + +proc test_logical_literal_types_accepted {} { + global gdb_prompt + + # Test the only possible values for a logical, TRUE and FALSE. + + gdb_test "pt TRUE" "type = bool" + gdb_test "pt FALSE" "type = bool" +} + +proc test_float_literal_types_accepted {} { + global gdb_prompt + + # Test various floating point formats + + # this used to guess whether to look for "real*4" or + # "real*8" based on a target config variable, but noone + # maintained it properly. + + gdb_test "pt .44" "type = double" + gdb_test "pt 44.0" "type = double" + gdb_test "pt 10e20" "type = double" + gdb_test "pt 10E20" "type = double" +} + +# Start with a fresh gdb. + +gdb_exit +gdb_start +gdb_reinitialize_dir $srcdir/$subdir + +if [set_lang_pascal] then { + test_integer_literal_types_accepted + test_logical_literal_types_accepted + test_character_literal_types_accepted + test_string_literal_types_accepted + test_float_literal_types_accepted +} else { + warning "$test_name tests suppressed." 0 +} Index: lib/pascal.exp =================================================================== RCS file: lib/pascal.exp diff -N lib/pascal.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ lib/pascal.exp 18 Jul 2007 08:53:33 -0000 @@ -0,0 +1,154 @@ +# Copyright 2007 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, +# USA. + +load_lib libgloss.exp + +set pascal_init_done 0 + +# This procedure looks for a suitable pascal compiler +# For now only GNU pascal compiler and Free Pascal compiler +# are searched. +# First, environment variable GPC is checked +# if present, GPC compiler is assumed to be the value of +# that environment variable. +# Second, environment variable FPC is checked +# if present, Free Pascal compiler is assumed to be the value of +# that environment variable. +# Third, gpc executable is searched using `which gpc` +# Lastly, fpc executable is searched using `which fpc` +# Using environment variable allows to force +# which compiler is used in testsuite + +proc pascal_init {} { + global pascal_init_done + global pascal_compiler_is_gpc + global pascal_compiler_is_fpc + global gpc_compiler + global fpc_compiler + global env + + if { $pascal_init_done == 1 } { + return + } + + set pascal_compiler_is_gpc 0 + set pascal_compiler_is_fpc 0 + set gpc_compiler [transform gpc] + set fpc_compiler [transform fpc] + + if ![is_remote host] { + if { [info exists env(GPC)] } { + set pascal_compiler_is_gpc 1 + set gpc_compiler $env(GPC) + verbose -log "Assuming GNU Pascal ($gpc_compiler)" + } elseif { [info exists env(FPC)] } { + set pascal_compiler_is_fpc 1 + set fpc_compiler $env(FPC) + verbose -log "Assuming Free Pascal ($fpc_compiler)" + } elseif { [which $gpc_compiler] != 0 } { + set pascal_compiler_is_gpc 1 + verbose -log "GNU Pascal compiler found" + } elseif { [which $fpc_compiler] != 0 } { + set pascal_compiler_is_fpc 1 + verbose -log "Free Pascal compiler found" + } + } + set pascal_init_done 1 +} + +proc gpc_compile {source dest type options} { + global gpc_compiler + set add_flags "" + if {$type == "object"} { + append add_flags " -c" + } + + if { $type == "preprocess" } { + append add_flags " -E" + } + + if { $type == "assembly" } { + append add_flags " -S" + } + + foreach i $options { + if { $i == "debug" } { + if [board_info $dest exists debug_flags] { + append add_flags " [board_info $dest debug_flags]"; + } else { + append add_flags " -g" + } + } + } + + set result [remote_exec host $gpc_compiler "-o $dest --automake $add_flags $source"] + return $result +} + +proc fpc_compile {source dest type options} { + global fpc_compiler + set add_flags "" + if {$type == "object"} { + append add_flags " -Cn" + } + + if { $type == "preprocess" } { + return "Free Pascal can not preprocess" + } + + if { $type == "assembly" } { + append add_flags " -al" + } + + foreach i $options { + if { $i == "debug" } { + if [board_info $dest exists debug_flags] { + append add_flags " [board_info $dest debug_flags]"; + } else { + append add_flags " -g" + } + } + } + + set result [remote_exec host $fpc_compiler "-o$dest $add_flags $source"] + return $result +} + +proc gdb_compile_pascal {source dest type options} { + global pascal_init_done + global pascal_compiler_is_gpc + global pascal_compiler_is_fpc + + if { $pascal_init_done == 0 } { + pascal_init + } + + if { $pascal_compiler_is_fpc == 1 } { + set result [fpc_compile $source $dest $type $options] + } elseif { $pascal_compiler_is_gpc == 1 } { + set result [gpc_compile $source $dest $type $options] + } else { + unsupported "No pascal compiler found" + return "No pascal compiler. Compilation failed." + } + + if ![file exists $dest] { + unsupported "Pascal compilation failed: $result" + return "Pascal compilation failed." + } +} +

2 1

Re: [RFC] adding gdb.pascal subdir
by Pierre Muller 17 Jul '07

17 Jul '07

Hi Daniel, sorry to have let you wait so long, but I completely missed your email (I have a mailbox rule that puts everything that contains gpc emails into a special folder and, despite looking regularly on my gdb folder, I missed your email for two weeks as I did not check the gpc mailbox). I just added some comment in pascal.exp and modified hello.exp so that gpc and fpc only fail once. It is difficult to completely remove the failures present in the tests, as they are due to two different problems 1) the gpc failure comes from the fact that 'start' command ends up in some implicit code which does not contain the main source file name. A possible work-around would be to fix breakpoints at specific positions in the file, but this would require to re-edit hello.exp each time someone changes hello.pas source. I have no idea if this is acceptable. 2) the fpc failure comes from the implicit "up-casing" made inside Free Pascal for all procedure/function names. I had a specific patch, that I used in the libgdb generation for our IDE that tried also a up-cased version if the as given pattern did not match any function, but it seems very Free Pascal specific. The other failure is common to gpc and fpc: (gdb) ptyp 'a simple string' ^M gives a strange error: No symbol table is loaded: use "file" command. I have no idea why this happens. Otherwise all your modifications seem very fine to me, Pierre Muller 2007-07-17 Pierre Muller <muller(a)ics.u-strasbg.fr> Daniel Jacobowitz <dan(a)codesourcery.com> * Makefile.in (ALL_SUBDIRS): Add gdb.pascal. * configure.ac (AC_OUTPUT): Add gdb.pascal/Makefile. * configure: Regenerated. * gdb.pascal/Makefile.in, gdb.pascal/hello.exp, gdb.pascal/hello.pas, gdb.pascal/types.exp, lib/pascal.exp: New files. Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/testsuite/Makefile.in,v retrieving revision 1.18 diff -u -p -r1.18 Makefile.in --- Makefile.in 27 Mar 2007 18:09:35 -0000 1.18 +++ Makefile.in 17 Jul 2007 14:01:57 -0000 @@ -37,7 +37,7 @@ RPATH_ENVVAR = @RPATH_ENVVAR@ ALL_SUBDIRS = gdb.ada gdb.arch gdb.asm gdb.base gdb.cp gdb.disasm \ gdb.dwarf2 \ gdb.fortran gdb.server gdb.java gdb.mi \ - gdb.objc gdb.threads gdb.trace gdb.xml \ + gdb.objc gdb.pascal gdb.threads gdb.trace gdb.xml \ $(SUBDIRS) EXPECT = `if [ -f $${rootme}/../../expect/expect ] ; then \ Index: configure =================================================================== RCS file: /cvs/src/src/gdb/testsuite/configure,v retrieving revision 1.23 diff -u -p -r1.23 configure --- configure 23 Jan 2007 17:11:54 -0000 1.23 +++ configure 17 Jul 2007 14:02:00 -0000 @@ -3102,7 +3102,7 @@ done - ac_config_files="$ac_config_files Makefile gdb.ada/Makefile gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile gdb.cp/Makefile gdb.disasm/Makefile gdb.dwarf2/Makefile gdb.fortran/Makefile gdb.server/Makefile gdb.java/Makefile gdb.mi/Makefile gdb.objc/Makefile gdb.threads/Makefile gdb.trace/Makefile gdb.xml/Makefile" + ac_config_files="$ac_config_files Makefile gdb.ada/Makefile gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile gdb.cp/Makefile gdb.disasm/Makefile gdb.dwarf2/Makefile gdb.fortran/Makefile gdb.server/Makefile gdb.java/Makefile gdb.mi/Makefile gdb.objc/Makefile gdb.pascal/Makefile gdb.threads/Makefile gdb.trace/Makefile gdb.xml/Makefile" cat >confcache <<\_ACEOF # This file is a shell script that caches the results of configure # tests run on this system so they can be shared between configure Index: configure.ac =================================================================== RCS file: /cvs/src/src/gdb/testsuite/configure.ac,v retrieving revision 1.6 diff -u -p -r1.6 configure.ac --- configure.ac 23 Jan 2007 17:11:55 -0000 1.6 +++ configure.ac 17 Jul 2007 14:02:00 -0000 @@ -115,6 +115,6 @@ AC_OUTPUT([Makefile \ gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile \ gdb.cp/Makefile gdb.disasm/Makefile gdb.dwarf2/Makefile \ gdb.fortran/Makefile gdb.server/Makefile \ - gdb.java/Makefile gdb.mi/Makefile \ - gdb.objc/Makefile gdb.threads/Makefile gdb.trace/Makefile \ + gdb.java/Makefile gdb.mi/Makefile gdb.objc/Makefile \ + gdb.pascal/Makefile gdb.threads/Makefile gdb.trace/Makefile \ gdb.xml/Makefile]) Index: gdb.pascal/Makefile.in =================================================================== RCS file: gdb.pascal/Makefile.in diff -N gdb.pascal/Makefile.in --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/Makefile.in 17 Jul 2007 14:02:02 -0000 @@ -0,0 +1,24 @@ +VPATH = @srcdir@ +srcdir = @srcdir@ + +EXECUTABLES = hello/hello + +MISCELLANEOUS = + +all info install-info dvi install uninstall installcheck check: + @echo "Nothing to be done for $@..." + +clean mostlyclean: + -find . -name '*.o' -print | xargs rm -f + -find . -name '*.ali' -print | xargs rm -f + -find . -name 'b~*.ad[sb]' -print | xargs rm -f + -rm -f *~ a.out xgdb *.x *.ci *.tmp + -rm -f *~ *.o a.out xgdb *.x *.ci *.tmp + -rm -f core core.coremaker coremaker.core corefile $(EXECUTABLES) + -rm -f $(MISCELLANEOUS) twice-tmp.c + +distclean maintainer-clean realclean: clean + -rm -f *~ core + -rm -f Makefile config.status config.log + -rm -f *-init.exp + -rm -fr *.log summary detail *.plog *.sum *.psum site.* Index: gdb.pascal/hello.exp =================================================================== RCS file: gdb.pascal/hello.exp diff -N gdb.pascal/hello.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/hello.exp 17 Jul 2007 14:02:02 -0000 @@ -0,0 +1,64 @@ +# Copyright 2007 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, +# USA. + +if $tracelevel then { + strace $tracelevel +} + +load_lib "pascal.exp" + +set testfile "hello" +set srcfile ${srcdir}/${subdir}/${testfile}.pas +set binfile ${objdir}/${subdir}/${testfile} + +if {[gdb_compile_pascal "${srcfile}" "${binfile}" executable [list debug ]] != "" } { + return -1 +} + +gdb_exit +gdb_start +gdb_reinitialize_dir $srcdir/$subdir +gdb_load ${binfile} + +# Verify that "start" lands inside the right procedure. +if { [gdb_start_cmd] < 0 } { + untested start + return -1 +} +gdb_test "" \ + ".* at .*hello.pas.*" \ + "start" +if { [gdb_breakpoint "print_hello"] } { + pass "setting breakpoint at print_hello" + set breakpointname "print_hello" +} elseif { [gdb_breakpoint "PRINT_HELLO"] } { + pass "setting breakpoint at PRINT_HELLO" + set breakpointname "PRINT_HELLO" +} + +gdb_test "cont" \ + "Breakpoint .*, ${breakpointname}.* at .*hello.pas.*" \ + "cont" +gdb_test "print st" \ + ".* = ''.*" \ + "Empty string check" +gdb_test "next" \ + ".*" \ + "Going to next line" +gdb_test " print st" \ + ".* = 'Hello, world!'.*" \ + "String after assignment check" Index: gdb.pascal/hello.pas =================================================================== RCS file: gdb.pascal/hello.pas diff -N gdb.pascal/hello.pas --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/hello.pas 17 Jul 2007 14:02:02 -0000 @@ -0,0 +1,14 @@ +program hello; + +var + st : string; + +procedure print_hello; +begin + st:='Hello, world!'; + writeln(st); +end; + +begin + print_hello; +end. Index: gdb.pascal/types.exp =================================================================== RCS file: gdb.pascal/types.exp diff -N gdb.pascal/types.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/types.exp 17 Jul 2007 14:02:02 -0000 @@ -0,0 +1,109 @@ +# Copyright 1994, 1995, 1997, 1998, 2007 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +# Please email any bugs, comments, and/or additions to this file to: +# bug-gdb(a)prep.ai.mit.edu + +# This file was adapted from old Chill tests by Stan Shebs +# (shebs(a)cygnus.com). +# Adapted to pascal by Pierre Muller + +if $tracelevel then { + strace $tracelevel +} + +set prms_id 0 +set bug_id 0 + +# Set the current language to pascal. This counts as a test. If it +# fails, then we skip the other tests. + +proc set_lang_pascal {} { + global gdb_prompt + + if [gdb_test "set language pascal" ""] { + return 0; + } + + if ![gdb_test "show language" ".* source language is \"pascal\".*"] { + return 1; + } else { + return 0; + } +} + +proc test_integer_literal_types_accepted {} { + global gdb_prompt + + # Test various decimal values. + # Should be integer*4 probably. + gdb_test "pt 123" "type = int" +} +proc test_character_literal_types_accepted {} { + global gdb_prompt + + # Test various character values. + + gdb_test "pt 'a'" "type = char" +} + +proc test_string_literal_types_accepted {} { + global gdb_prompt + + # Test various character values. + + gdb_test "pt 'a simple string'" "type = string" +} + +proc test_logical_literal_types_accepted {} { + global gdb_prompt + + # Test the only possible values for a logical, TRUE and FALSE. + + gdb_test "pt TRUE" "type = bool" + gdb_test "pt FALSE" "type = bool" +} + +proc test_float_literal_types_accepted {} { + global gdb_prompt + + # Test various floating point formats + + # this used to guess whether to look for "real*4" or + # "real*8" based on a target config variable, but noone + # maintained it properly. + + gdb_test "pt .44" "type = double" + gdb_test "pt 44.0" "type = double" + gdb_test "pt 10e20" "type = double" + gdb_test "pt 10E20" "type = double" +} + +# Start with a fresh gdb. + +gdb_exit +gdb_start +gdb_reinitialize_dir $srcdir/$subdir + +if [set_lang_pascal] then { + test_integer_literal_types_accepted + test_logical_literal_types_accepted + test_character_literal_types_accepted + test_string_literal_types_accepted + test_float_literal_types_accepted +} else { + warning "$test_name tests suppressed." 0 +} Index: lib/pascal.exp =================================================================== RCS file: lib/pascal.exp diff -N lib/pascal.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ lib/pascal.exp 17 Jul 2007 14:02:02 -0000 @@ -0,0 +1,154 @@ +# Copyright 2007 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, +# USA. + +load_lib libgloss.exp + +set pascal_init_done 0 + +# This procedure looks for a suitable pascal compiler +# For now only GNU pascal compiler and Free Pascal compiler +# are searched. +# First, environment variable GPC is checked +# if present, GPC compiler is assumed to be the value of +# that environment variable. +# Second, environment variable FPC is checked +# if present, Free Pascal compiler is assumed to be the value of +# that environment variable. +# Third, gpc executable is searched using `which gpc` +# Lastly, fpc executable is searched using `which fpc` +# Using environment variable allows to force +# which compiler is used in testsuite + +proc pascal_init {} { + global pascal_init_done + global pascal_compiler_is_gpc + global pascal_compiler_is_fpc + global gpc_compiler + global fpc_compiler + global env + + if { $pascal_init_done == 1 } { + return + } + + set pascal_compiler_is_gpc 0 + set pascal_compiler_is_fpc 0 + set gpc_compiler [transform gpc] + set fpc_compiler [transform fpc] + + if ![is_remote host] { + if { [info exists env(GPC)] } { + set pascal_compiler_is_gpc 1 + set gpc_compiler $env(GPC) + verbose -log "Assuming GNU Pascal ($gpc_compiler)" + } elseif { [info exists env(FPC)] } { + set pascal_compiler_is_fpc 1 + set fpc_compiler $env(FPC) + verbose -log "Assuming Free Pascal ($fpc_compiler)" + } elseif { [which $gpc_compiler] != 0 } { + set pascal_compiler_is_gpc 1 + verbose -log "GNU Pascal compiler found" + } elseif { [which $fpc_compiler] != 0 } { + set pascal_compiler_is_fpc 1 + verbose -log "Free Pascal compiler found" + } + } + set pascal_init_done 1 +} + +proc gpc_compile {source dest type options} { + global gpc_compiler + set add_flags "" + if {$type == "object"} { + append add_flags " -c" + } + + if { $type == "preprocess" } { + append add_flags " -E" + } + + if { $type == "assembly" } { + append add_flags " -S" + } + + foreach i $options { + if { $i == "debug" } { + if [board_info $dest exists debug_flags] { + append add_flags " [board_info $dest debug_flags]"; + } else { + append add_flags " -g" + } + } + } + + set result [remote_exec host $gpc_compiler "-o $dest --automake $add_flags $source"] + return $result +} + +proc fpc_compile {source dest type options} { + global fpc_compiler + set add_flags "" + if {$type == "object"} { + append add_flags " -Cn" + } + + if { $type == "preprocess" } { + return "Free Pascal can not preprocess" + } + + if { $type == "assembly" } { + append add_flags " -al" + } + + foreach i $options { + if { $i == "debug" } { + if [board_info $dest exists debug_flags] { + append add_flags " [board_info $dest debug_flags]"; + } else { + append add_flags " -g" + } + } + } + + set result [remote_exec host $fpc_compiler "-o$dest $add_flags $source"] + return $result +} + +proc gdb_compile_pascal {source dest type options} { + global pascal_init_done + global pascal_compiler_is_gpc + global pascal_compiler_is_fpc + + if { $pascal_init_done == 0 } { + pascal_init + } + + if { $pascal_compiler_is_fpc == 1 } { + set result [fpc_compile $source $dest $type $options] + } elseif { $pascal_compiler_is_gpc == 1 } { + set result [gpc_compile $source $dest $type $options] + } else { + unsupported "No pascal compiler found" + return "No pascal compiler. Compilation failed." + } + + if ![file exists $dest] { + unsupported "Pascal compilation failed: $result" + return "Pascal compilation failed." + } +} +

1 0

Merci Beaucoup Pour La Reponse et Pour L'Exemple
by pascaltomath＠yahoo.fr 13 Jul '07

13 Jul '07

Cher Monsieur Lombardi; Je vous remercie beaucoup pour votre rapide reponse, et pour votre explication nette et precise. Votre exemple demontre tout tres clairement. Vous etes vraiment tres gentille. Kadir Yuce --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail

1 0

About GNU Pascal Record Type
by pascaltomath＠yahoo.fr 11 Jul '07

11 Jul '07

Dear All; I would like to ask you if it is possible in 32 Bit and/or 64 Bit GNU Pascal; to determine, to precise the 'Bit' value of each member of a Record, as it is so for a Structure in C. Thanks a lot for a prospective reply. With kind regards. Kadir Yuce Below is a C code example : #include <stdio.h> struct bitprecising { char ch : 8; int n : 2; long l : 3; } ; int main() { struct bitprecising x; struct bitprecising *p; p= &x; (*p).ch= 'a'; (*p).n= 1; (*p).l= 2L; printf("x.ch= %c\n", x.ch); printf("x.n= %d\n", x.n); printf("x.l= %ld\n", x.l); } --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail

1 0

attempted build with gcc-4.2.0
by Russ Whitaker 17 Jun '07

17 Jun '07

hi Applied Waldek's gcc patch for an older gcc. Got these rejects: dbxout.c.rej *************** *** 1916,1922 **** { stabstr_S ("@s"); stabstr_D (BITS_PER_UNIT * int_size_in_bytes (type)); - stabstr_S (";-20;"); } else { --- 1916,1922 ---- { stabstr_S ("@s"); stabstr_D (BITS_PER_UNIT * int_size_in_bytes (type)); + stabstr_S (";-20"); } else { gimplify.c.rej *************** *** 4948,4953 **** case POINTER_TYPE: case REFERENCE_TYPE: gimplify_type_sizes (TREE_TYPE (type), list_p); break; --- 4952,4959 ---- case POINTER_TYPE: case REFERENCE_TYPE: + break; + gimplify_type_sizes (TREE_TYPE (type), list_p); break; tree-flow-inline.h.rej *************** *** 1470,1476 **** return false; return (AGGREGATE_TYPE_P (TREE_TYPE (v)) && - TREE_CODE (TREE_TYPE (v)) != ARRAY_TYPE); } --- 1470,1477 ---- return false; return (AGGREGATE_TYPE_P (TREE_TYPE (v)) && + TREE_CODE (TREE_TYPE (v)) != ARRAY_TYPE + && TREE_CODE (TREE_TYPE (v)) != SET_TYPE); } varasm.c.rej *************** *** 2725,2731 **** VEC(constructor_elt, gc) *v; unsigned HOST_WIDE_INT idx; tree purpose, value; - v = VEC_alloc(constructor_elt, gc, VEC_length(constructor_elt, CONSTRUCTOR_ELTS (exp))); FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (exp), idx, purpose, value) --- 2725,2731 ---- VEC(constructor_elt, gc) *v; unsigned HOST_WIDE_INT idx; tree purpose, value; + v = VEC_alloc(constructor_elt, gc, VEC_length(constructor_elt, CONSTRUCTOR_ELTS (exp))); FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (exp), idx, purpose, value) *************** *** 3765,3771 **** /* Allow conversions to struct or union types if the value inside is okay. */ if (TREE_CODE (dest_type) == RECORD_TYPE - || TREE_CODE (dest_type) == UNION_TYPE) return initializer_constant_valid_p (src, endtype); } break; --- 3765,3776 ---- /* Allow conversions to struct or union types if the value inside is okay. */ if (TREE_CODE (dest_type) == RECORD_TYPE + || TREE_CODE (dest_type) == UNION_TYPE + #ifdef GPC + || TREE_CODE (TREE_TYPE (value)) == ARRAY_TYPE + #endif + ) + return initializer_constant_valid_p (src, endtype); } break; However, for that last one was able to find where the patch belongs, so here's a diff: 3843c3843,3847 < || TREE_CODE (dest_type) == UNION_TYPE) --- > || TREE_CODE (dest_type) == UNION_TYPE > #ifdef GPC > || TREE_CODE (TREE_TYPE (value)) == ARRAY_TYPE > #endif > ) 4017c4021 < --- > Wasn't sure how to correct the other rejects, so at least I got this far: *** glibc detected *** corrupted double-linked list: 0x08aa5f50 *** ../../gcc-4.2.0/gcc/tree-ssa-loop-ivopts.c In function 'find_optimal_iv_set': ../../gcc-4.2.0/gcc/tree-ssa-loop-ivopts.c: 5271 internal complier error: aborted Hope this helps Russ

1 0

Re: Bit packing
by Contestcen＠aol.com 15 Jun '07

15 Jun '07

In a message dated 6/14/2007 1:40:34 AM Eastern Standard Time, florian(a)freepascal.org writes: How does the pascal macro compiler solve it? It tries to solve it for bit/booleans arrays but not for subrange types which are much harder because of endian issues. Tries because it doesn't take care of things like debugging. (Continuing previous answer) If the problem is that some Pascal compilers store large integers with the least-significant byte first, while others store the most-significant byte first, one solution would be to form the concatenation of bit fields into a string of integers, and let each compiler store them according to its own rules. How complex the macros become depends on what is needed. Do the bit fields need to cross boundaries of integer fields? Are mixed-sized integers needed within each record? Are you carving up a large array into bit fields whose lengths will be determined at runtime? If the problem is that one compiler stores array elements in order x[1], x[2], x[3], ... which another compiler stores them x[100], x[99], ... then you simply let the compiler use its own array indexing scheme. Frank ************************************** See what's free at http://www.aol.com.

1 0

Re: Bit packing
by Contestcen＠aol.com 15 Jun '07

15 Jun '07

In a message dated 6/14/2007 1:40:34 AM Eastern Standard Time, florian(a)freepascal.org writes: How does the pascal macro compiler solve it? It tries to solve it for bit/booleans arrays but not for subrange types which are much harder because of endian issues. Tries because it doesn't take care of things like debugging. I try to provide the library functions which the Macro Compiler users find most useful. If there is a need for subrange bit fields, and you can describe clearly what is needed, then I will try to provide it on a time-available basis. If this is a make-or-break issue for you, then I will try harder. Frank ************************************** See what's free at http://www.aol.com.

1 0

Bit packing
by Contestcen＠aol.com 14 Jun '07

14 Jun '07

On 13 jun 2007, at 07:26, Contestcen(a)aol.com wrote: > That's precisely the point. The Borland, TMT, FPC and GPC > compilers are not > compatible on bit-packing. By using the Macro Compiler you get bit- > packing > which is independent of the compiler, so that programs compiled > with any of > these Pascal compilers can exchange data. The bitpacking format is defined in the ABI of the respective platforms (at least all SYSV processor-specific supplements define how you should bitpack), and gcc follows that ABI. Some documentation: * http://www.sco.com/developers/devspecs/abi386-4.pdf : i386 sysv abi supplement, see p. 3-6 and following (look, SCO is still useful for something after all :) * http://refspecs.freestandards.org/elf/elfspec_ppc.pdf : ppc sysv abi supplement, see p. 3-8 and following Jonas Let me see if I follow this. You posted to this forum because you were having problems with bit-packing. You said that you wanted bit-packing that would allow data exchange between programs that were compiled with different compilers, and perhaps ran on different platforms. The Pascal Macro Compiler could make that possible. Now you say that there are standards for bit-packing, and that the GCC compiler follows the standards. Apparently the other Pascal compilers don't follow the standard. (So far as I know, the Borland and TMT compilers don't do bit-packing at all.) Also, the standard does not seem to work across multiple platforms because of different unit sizes. But you still won't use the Pascal Macro Compiler because it solves the bit-packing problem by a means other than enforcing the bit-packing standard on all Pascal compilers. Does that sum it up? Frank ************************************** See what's free at http://www.aol.com.

3 2

TR : GP Internal error
by Pascal Viandier 13 Jun '07

13 Jun '07

Sorry, the gp version I use is 0.61 not 0.60 - typo :-( - Pascal -----Message d'origine----- De : gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] De la part de Pascal Viandier Envoyé : June 13, 2007 14:12 À : gpc(a)gnu.de Objet : GP Internal error In the course of the SUN Pascal to GNU Pascal conversion of a all set of programs, I use gp to handle the compilation of a program that has many - around 750 - modules. I call gp with the main program and correct errors progressively as they are encountered. I already compiled more than 600 modules this way. Until now all was going well but today I got an error message from gp when it calls "gpc --interface-only" for a module that has never been compiled yet: gp: internal error: complete cycle not found Since gp worked perfectly well for the previous modules, I suspect something wrong in this particular module but I don't see any error when looking at the Pascal code. What kind of twist in the source code can produce this error? I use gp 0.60 build with gpc 20051116 based on gcc-3.4.4 under SPARC Solaris 10 Kind regards. Pascal Viandier

1 0

GP Internal error
by Pascal Viandier 13 Jun '07

13 Jun '07

In the course of the SUN Pascal to GNU Pascal conversion of a all set of programs, I use gp to handle the compilation of a program that has many - around 750 - modules. I call gp with the main program and correct errors progressively as they are encountered. I already compiled more than 600 modules this way. Until now all was going well but today I got an error message from gp when it calls "gpc --interface-only" for a module that has never been compiled yet: gp: internal error: complete cycle not found Since gp worked perfectly well for the previous modules, I suspect something wrong in this particular module but I don't see any error when looking at the Pascal code. What kind of twist in the source code can produce this error? I use gp 0.60 build with gpc 20051116 based on gcc-3.4.4 under SPARC Solaris 10 Kind regards. Pascal Viandier

1 0

Packing of 64 bit values
by Jonas Maebe 13 Jun '07

13 Jun '07

Hello, After noticing that gdb does not print 64 bit fields of (bit)packed records properly if they don't start on a byte boundary (both with fpc and with gpc), I decided to check what gcc does. It turns out that gcc (4.0.1, Mac OS X/ppc) only bitpacks values up to and including 59 bits. Fields declared as 60-64 bits are automatically aligned to the target-specific alignment boundary. Does anyone here know why this is the case, and possibly where this is documented? I can't find anything with Google. Thanks, Jonas Simple test case follows (compile with -c -gdwarf-2, then use dwarfdump/elfread --debug-dump on the .o file to look at the debug info). both l and l2 are aligned on an 8 byte boundary for ppc64 and to a 4 byte boundary for ppc32. *** struct tt { int a; int j; }; struct S { int j:5; long long l:60; long long l2:60; int k:6; int m:5; int n:8; struct tt s; }; int main(struct S s) { } *** Compare with a Pascal program: *** {$ifdef fpc} {$bitpacking on} {$endif} type {$ifndef fpc} int64 = longint; {$endif} tenum = (ea,eb,ec,ed,ee,ef,eg,eh); tr = packed record a: 0..3; // 2 bits i: int64; c: boolean; // 1 bit d: 0..31; // 5 bits e: tenum; // 3 bits end; procedure t(var r2: tr); var r: tr; begin r.a := 2; r.i := 1234567890123456789; r.c := true; r.d := 5; r.e := ed; r2 := r; end; var r: tr; begin t(r); if (r.a <> 2) or (r.i <> 1234567890123456789) or (not r.c) or (r.d <> 5) or (r.e <> ed) then halt(1); end. *** If you debug this, step over the "t" call and print r, you get (for gpc): (gdb) p r $1 = { A = 2, I = 0, C = true, D = 5, E = Ed } (gdb) ptype r type = record A : 0..3 : 2; I : Int64 : 64; C : Boolean : 1; D : 0..31 : 5; E : Tenum : 3; end Looking at the stabs (the gpc for Mac OS X I have doesn't support dwarf), gpc also puts the 64 bit int right after the two first bits, without aligning to a byte/4 byte/8 byte boundary first.

2 3

Bit-packing
by Contestcen＠aol.com 13 Jun '07

13 Jun '07

> Maybe you should be looking into the bit-packing macros provided > with the > Pascal Macro Compiler. This will give you bit-packing which is > independent of > the particular Pascal compiler you happen to be using. See > www.mastersoftware.biz/pasbit.htm Thanks, but I want to implement bit packing which is compatible with what gcc and other compilers use so data exchange is possible. Jonas That's precisely the point. The Borland, TMT, FPC and GPC compilers are not compatible on bit-packing. By using the Macro Compiler you get bit-packing which is independent of the compiler, so that programs compiled with any of these Pascal compilers can exchange data. Frank ************************************** See what's free at http://www.aol.com.

2 1

Unreachable label
by Adriaan van Os 13 Jun '07

13 Jun '07

Any comment on <http://www.freepascal.org/mantis/view.php?id=9053> and Daniël Mantione's note ? Regards, Adriaan van Os

7 10

Bit packing
by Contestcen＠aol.com 12 Jun '07

12 Jun '07

Hello, After noticing that gdb does not print 64 bit fields of (bit)packed records properly if they don't start on a byte boundary (both with fpc and with gpc), I decided to check what gcc does. It turns out that gcc (4.0.1, Mac OS X/ppc) only bitpacks values up to and including 59 bits. Fields declared as 60-64 bits are automatically aligned to the target-specific alignment boundary. Does anyone here know why this is the case, and possibly where this is documented? I can't find anything with Google. Thanks, Jonas Maybe you should be looking into the bit-packing macros provided with the Pascal Macro Compiler. This will give you bit-packing which is independent of the particular Pascal compiler you happen to be using. See www.mastersoftware.biz/pasbit.htm Frank Rubin ************************************** See what's free at http://www.aol.com.

2 1

GPC on Cygwin having a problem compiling using crt
by Bruce Mahfood 12 Jun '07

12 Jun '07

Hello, I have posted my problem to the Cygwin mailing list, and have been told by the person who handles the gcc installation that it doesn't seem to be their issue. I am hoping that someone on the gpc list will be able to help me. I have a number of pascal files that must be compiled to be tested, and am having a hard time doing so. I have installed Cygwin base (version: 1.5.24) on my Windows Server 2003 system and have added all packages that I can think would be useful for this compilation. I am attaching the output of a run of cygcheck so that you can see the environment I have installed. All installed packages are listed at the bottom of the file. Using gpc to compile code which contains the statement "Uses Crt", I get over 600 error lines. I am attaching also attaching the output that I am getting from my compilation, as well as a test file that I have created which gives me these errors. The command line that I am using is: gpc --automake test.pas I have also used: For some reason the compilation, because of the inclusion of the "Uses Crt" statement, thinks that it needs to compile crtc.c, instead of using the binaries that already exist in the Cygwin environment according to the guy I mentioned above who handles the gcc install. I am not sure what I need to add to my command line in order to get this compilation to work. Is there someone who can help me here. I would highly appreciate it. Thanks... Bruce

5 7

Re: GPC on Cygwin having a problem compiling using crt
by Bruce Mahfood 12 Jun '07

12 Jun '07

Thanks for the lead on that IDE. I haven't touched Pascal in many years, so I don't really know what's out there. I've done quite a bit of looking around, but having seen a couple of other IDEs for pascal that I didn't find useful, I decided to stick with GNU stuff, which I was hoping would work for me. The gpc compiler was looking hopeful for a little bit there, but then I ran into these problems. Thanks for the pointer to use this IDE. It's much nicer. I am having an issue with my compilation using the IDE. I did a compile of my project and two errors are popping up in different places that I am not sure what to do with. The Intr() procedure is not recognized, and it's used throughout most of the thirteen project files that I have inherited. Getting an "undeclared identifier 'Intr'" error message. I found a note in the file gpc.info-2 that says that the procedures Intr and MsDos are only supported under DJGPP if `__BP_UNPORTABLE_ROUTINES__' is defined with the `-D__BP_UNPORTABLE_ROUTINES__' option. I didn't know whether this IDE relied on DJGPP or not, but I tried it anyway. It didn't help. Any ideas here? Thanks... Bruce ----- Original Message ----- From: "The African Chief" <chiefsoft(a)bigfoot.com> To: "Bruce Mahfood" <bruce.mahfood(a)tseboston.com> Cc: gpc(a)gnu.de Sent: Monday, June 11, 2007 1:44:55 PM (GMT-0500) America/New_York Subject: Re: GPC on Cygwin having a problem compiling using crt On Mon, 2007-06-11 at 12:27 -0400, Bruce Mahfood wrote: > Hi all, I am on the warpath trying to compile a set of pascal files > that were left to me by a predecessor. My latest issue is that my > files have the statement "Uses graph". Looking online, I find that > this is a Borland thing referring to the use of the Borland Graphics > Interface (BGI). > > I have found that GNU supports a package called GRX > (http://grx.gnu.de/download/index.html), and the link > "http://www.gnu-pascal.de/gpc/Graph-unit.html#Graph-unit" says it's > known to work under Cygwin. I have extracted the files into my cygwin > installation at /usr/local/src, and am looking at the makefiles. > Unfortunately, there is only a mingw specific makefile and not a > cygwin specific one. I have not yet worked with mingw, and don't > really know how these two correlate. > > Can anyone point me in the right direction for compiling this for > cygwin? > Is there any particular reason why you are using Cygwin? You might want to try a Mingw version, which has all that stuff built in (with an IDE): http://www.gnu-pascal.de/contrib/chief/win32/dev_gnu_pascal-1.9.4.8.exe -- Best regards, TheChief email: chiefsoft(a)bigfoot.com www: http://www.greatchief.plus.com

3 5

Re: GPC on Cygwin having a problem compiling using crt
by Bruce Mahfood 12 Jun '07

12 Jun '07

Ooops, forgot to say that I had noticed that the Intr() procedure calls are all being made from files belonging to the TechnoJock's Turbo Toolkit. This project is using the 5.1 version. From what I can tell online, this is the last version put out (back in '93). I used TP and TASM to build a full distribution of these files in order to come up with the .tpu files that I talked about in my last email. Bruce ----- Original Message ----- From: "The African Chief" To: "Bruce Mahfood" Cc: gpc(a)gnu.de Sent: Monday, June 11, 2007 5:47:43 PM (GMT-0500) America/New_York Subject: Re: GPC on Cygwin having a problem compiling using crt On Mon, 2007-06-11 at 17:21 -0400, Bruce Mahfood wrote: > Thanks for the lead on that IDE. I haven't touched Pascal in many > years, so I don't really know what's out there. I've done quite a bit > of looking around, but having seen a couple of other IDEs for pascal > that I didn't find useful, I decided to stick with GNU stuff, which I > was hoping would work for me. The gpc compiler was looking hopeful > for a little bit there, but then I ran into these problems. Thanks > for the pointer to use this IDE. It's much nicer. > > I am having an issue with my compilation using the IDE. I did a > compile of my project and two errors are popping up in different > places that I am not sure what to do with. The Intr() procedure is > not recognized, and it's used throughout most of the thirteen project > files that I have inherited. Getting an "undeclared identifier > 'Intr'" error message. I found a note in the file gpc.info-2 that > says that the procedures Intr and MsDos are only supported under DJGPP > if `__BP_UNPORTABLE_ROUTINES__' is defined with the > `-D__BP_UNPORTABLE_ROUTINES__' option. I didn't know whether this IDE > relied on DJGPP or not, but I tried it anyway. It didn't help. Any > ideas here? The Intr routine works only on DJGPP (DOS-32). This IDE is based on Mingw. Unless you can find a portable way to do what you want to do with Intr, I think you are well and truly stuck there. -- Best regards, TheChief email: chiefsoft(a)bigfoot.com www: http://www.greatchief.plus.com

1 0

[Fwd: Re: Unreachable label]
by Adriaan van Os 11 Jun '07

11 Jun '07

-------- Original Message -------- Subject: Re: Unreachable label Date: Mon, 11 Jun 2007 13:13:06 +0200 From: MegaBrutal <megabrutal(a)gmail.com> To: Adriaan van Os <gpc(a)microbizz.nl> References: <466D0430.70706(a)microbizz.nl> I don't recommend to use labels and goto statements at all. It just messes the code and tells about bad programming manners. 2007/6/11, Adriaan van Os <gpc(a)microbizz.nl>: > > Any comment on <http://www.freepascal.org/mantis/view.php?id=9053> and > Daniël Mantione's note ? > > Regards, > > Adriaan van Os > > >

3 2

Port of Knuth's WEB to latest unstable release of GPC
by FL 01 Jun '07

01 Jun '07

Hello, I was unable to locate change files for Knuth's original TANGLE and CWEAVE programs on CTAN, so I've written a port of the system for the gpc version 20060325. I reverted the file I/O in Knuth's code that he ported to C back to GNU Pascal. I might have preserved Knuth's I/O routines in C, except that GNU Pascal changed the way it makes file structures available to the programmer since Knuth wrote his port (around 2000). The GNU PASCAL function GetFile() might have been used to pass a C-style FILE pointer to this code, but GetFile() is no longer availble. In its place, GNU PASCAL provides a BindingType data structure and related functions; these might have been usable if they had provided a valid file descriptor, but on my Debian Linux system, the value of BindingType.Handle is always -1 (if I may abuse the PASCAL language by referring to a variable of BindingType by its type). Am I mistaken about this? Florian P.S. I've made the change files, the mysterious GPCtypes.h file and a modified tangext.c file available at http://research.gc.cuny.edu/wiki/index.php/Port_of_Knuth%27s_TANGLE_and_WEA…

2 1

Parallel GPC?
by Mirsad Todorovac 30 May '07

30 May '07

HI all, Is there a chance that there would be a support for parallel programming constructs in GPC any time soon? This is inspired by OpenMP/GOMP initiative support added to GCC 4.2. I know a couple of projects where this would be useful, and I could smuggle this as a research subject in my main project at my daily 9-5 job. Do you think just a unit/module is required to implement this to GPC; or an actual change of compiler proper? Frank? Thx Mirsad "Be conservative in what you do, be liberal in what you accept from others." -- Jon Postel

4 3

Internal compiler error
by Pascal Viandier 22 May '07

22 May '07

Hi gpc masters, I think I found a bug in gpc. I use gpc 20051116 based on gcc3.4.4 on Sparc Solaris 10. It gives: Internal compiler error: Segmentation Fault when compiling the following code: Module Test1 Interface; Export Test1 = All; Type String200 = String(200); Function TranlateString(S : String200) : String200; End. Module Test1 Implementation; Function TranlateString(S : String) : String200; Begin End; { TranlateString } End. The error is: the type of the function parameter does not match in the interface and implementation sections. Interesting enough, if I reverse the error (that is, put 'String' in the Interface and 'String200' in the Implementation) I get the right error message: 'Routine definition does not match previous declaration'. Kind Regards. Pascal Viandier

1 0

Re: Internal GPC Problem
by Matthew Blaine 20 May '07

20 May '07

Prof. Abimbola A. Olowofoyeku wrote: >What is your Windows version? It seems that the problem might be with a >path that is too long for Windows to handle ... I'm running Windows XP Professional SP2. Do you know what I could change? Thank you, Matt Blaine ____________________________________________________________________________________Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469

1 0

Re: Internal GPC Problem
by Matthew Blaine 19 May '07

19 May '07

Prof. A Olowofoyeku (The African Chief) wrote: >On 18 May 2007 at 22:02, Matthew Blaine wrote: > >> Hello, >> I've downloaded and successfully installed Dev+GNU Pascal from: >> http://gnu-pascal.de/contrib/chief/win32/dev_gnu_pascal-1.9.4.8.exe >> >> I've successfully built build_units.pas, however now I'm having trouble >> using the gpc compiler. Trying to compile the GrClock.pas example, for >> instance, works. However, trying to compile a project that includes >> multiple source files, as opposed to just a single source file, does >> not work. I receive the following error: >> gpc: Internal GPC problem: internal option `--amtmpfile' not given > >Is it your own programs, or the test programs supplied with the package? > >Are you compiling from the IDE or from the command line? > >If compiling from the command line, are you supplying the right switches >(e.g., "--automake", etc?). > >If you have built build_units.pas, then the compiler is working correctly. >As you may notice when you look at the sources, build_units uses a whole >load of units. GrClock itself uses two units. > >Best regards, The Chief >-------- >Prof. Abimbola A. Olowofoyeku (The African Chief) >web: http://www.greatchief.plus.com/ Thank you very much for replying. It is one of my own programs that I've compiled on another Pascal compiler (Free Pascal) before. I'm using the IDE, here's what it shows me under the "Compile Log" tab. Compiling files : C:\DEV-PA~1\bin\gpc C:\DOCUME~1\Matthew\Desktop\Pascal\Copy\SOLITA~1.PAS -o.\solita~1.exe -fno-inline -s -fno-io-checking -fno-range-checking -fimplicit-result -O1 -Wno-warnings -fno-assertions -fextended-syntax -fignore-function-results -fcstrings-as-strings -fpointer-arithmetic -march=i686 -mcpu=i686 -funit-path=c:\dev-pa~1\units -fexecutable-path=. -funit-destination-path=c:\dev-pa~1\units -Bc:\DEV-PA~1\units -BC:\DEV-PA~1\bin\ And here's what I see under the "Compiler tab". gpc: Internal GPC problem: internal option `--amtmpfile' not given Again, thank you for your time. Matthew Blaine ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/

2 1

2025

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