- Gpc - gnu.de

Re: New Alpha
by The African Chief 15 Apr '97

15 Apr '97

On Tue, 15 Apr 1997 14:45:40 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: [..] > >A minor "problem": If I compile a program with such a compiler switch with TP, >TP complains about an "Invalid compiler directive". Is there a way (perhaps >a simpler way than conditional defines) to supply the options so that gpc >will recognize them and TP will ignore them? I am writing a shell for GPC - "GPCC.PAS" (in Borland Pascal). All that it does is to parse the command line, parse the source file to see whether it is a unit/module or a program (and pass the necessary "-o" or "-c" switch accordingly, read a file called "GPCC.CFG", add any switches found in it to the list of parameters obtained from the command line, and then, run "GPC" with the whole list of parameters. I have had to write a number of "Borland" functions and procedures for GPC to make this program compile and work okay under GPC as well. The program can now be compiled under BP or GPC and works equally well under both. These (with full source code) will be released as soon as I am finished with what I am doing, as part of my contribution to GPC. Is anybody interested in all this? My current GPCC.CFG looks like this (lines beginning with a semi-colon are treated as comments and are ignored by GPCC); ; ---------------------------- GPCC.CFG begins -------------------------- ; full optimization; 486 optimized -O3 -m486 ; strip the symbol table -s ; "make" units --automake="-O3 --automake" ; use extended syntax --extended-syntax ; pack (align) all records --pack-struct ; ---------------------- GPCC.CFG ends --------------------------- I intend to make a number of template GPCC.CFG file (e.g., for EP, ISO, etc.) before releasing the stuff. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

Main distribution line (Was: How should ...)
by Frank Heckenbach 15 Apr '97

15 Apr '97

This goes back a few days... Peter Gerwinski wrote: > * GPC's configuration scripts are written using `autoconf'. > I have no idea how to implement such an option there. But even if > I had, it would disappear again when GPC will be integrated into > the main distribution line of the GNU compiler. Does this mean that gpc will then distributed widely and will be present on many (or most) systems? Now I had to make a version of my program in C because almost nobody had gpc installed - any hope that this situation will change? And are there any plans when this will happen - when gpc supports the standard(s) completely? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

2 1

Boolean operators (Was: Re: New Alpha)
by Frank Heckenbach 15 Apr '97

15 Apr '97

Berend de Boer wrote: > > * If statements and such now default to short-circuit operations. > > This can still be switched to complete evaluation using > > `--no-short-circuit', (*$B+*), or (*$no-short-circuit*). With > > `--standard-pascal' etc., the default becomes complete evaluation > > and can be switched to short circuit using `--short-circuit', > > (*$B-*), or (*$short-circuit*). > > > > (It is done this way because the cases where a program relies > >on > > complete evaluation of Boolean expressions are very rare; functions > > with side effects should not occur in such situations anyway because > > you cannot rely on the order of evaluation. OTOH, there are *many* > > programs which rely on short circuit evaluation.) > > I like to add that Extended Pascal has the or_else and and_then to force > short circuit evalutation. > > A quite clean solution IMHO. Indeed, I think this is good if one uses complete evaluation by default. However, I prefer to have short circuit evaluation by default. So what about similar operators to force complete evaluation - it would seem cleaner to me than using {$B+} ... {$B-}? -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: New Alpha
by Frank Heckenbach 15 Apr '97

15 Apr '97

Peter Gerwinski wrote: > * The GNU compiler's global configuration file `specs' (or `specs.gpc' > with DJGPP) now contains a line `*gpc1:' after which you can put > your site-wide default switches, e.g. > > *gpc1: > -fextended-pascal -ffield-widths -fno-clip-strings > Note that `specs' does not want `--foo' but `-ffoo'. BTW: You recently said that one has to use '-pedantic', not '-fpedantic' in specs. Is there a general rule when to use '-f...' and when simply '-...'? > * All command-line `--foobar' flags now can be given as compiler > directives. One example: > > (*$field-widths,NO-clip-strings,SetLimit=1024, AutoMake="-g -O3"*). Just to make sure: 'AutoMake="--foo"' means that '--foo' is used for the compilation of the units involved and the program itself, while 'AutoMake, --foo' would apply '--foo' only to the program. Is that right? A minor "problem": If I compile a program with such a compiler switch with TP, TP complains about an "Invalid compiler directive". Is there a way (perhaps a simpler way than conditional defines) to supply the options so that gpc will recognize them and TP will ignore them? What about compiler options for "-o foo", "foo.o" and/or "bar.c"? Are you working on them, or are they too difficult to implement? BTW: Is it legal (with the currect version) to use "gpc foo.c bar.pas"? I asked about this already in my mail about "Re: Linking directives..." on 3 Apr, but unfortunately got no replies. And another contribution to the GPC test suite... :-| The following program and unit cause the latest gpc to fail with SIGSEGV. It worked with a previous version of gpc: PROGRAM x; USES y; VAR v:t; BEGIN q(v) {or p(v) - both cause SIGSEGV} END. UNIT Y; INTERFACE TYPE t=ARRAY[0..1] OF Integer; PROCEDURE p(VAR v:t); PROCEDURE q(CONST v:t); IMPLEMENTATION PROCEDURE p(VAR v:t); BEGIN END; PROCEDURE q(CONST v:t); BEGIN END; END. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

GPC alpha 970412 win32 binary (cygwin32 b17.1) available.
by Jan-Jaap van der Heijden 13 Apr '97

13 Apr '97

Hello, The latest GNU Pascal alpha release is now available for the win32 platform at: ftp://agnes.dida.physik.uni-essen.de/home/janjaap/cygwin32/ Files in this directory: gpc-970412.i486-cygwin32-b17.1.zip Apr.12 snapshot binary of cygwin32 GPC. For a cygwin32-beta17.1 toolchain. devtools.i486-cygwin32-b17.1.zip For those who only want to do Pascal, it's a waist to download a complete toolchain from ftp.cygnus.com. This archive has all the tools (as, ld, libraries) needed to complete GPC. I also included some other tools (rcl etc.) and documentation in .hlp format. If you already have cygwin32-beta17.1 installed, you don't need this. Installation ------------ * create a subdirectory of your choice (`c:\gpcwin32') and unzip gpc-970412.i486-cygwin32-b17.1.zip and devtools.i486-cygwin32-b17.1.zip from there. Use a version of `unzip' that can handle long filenames, i.e. not PKunzip. * Add the directory where `gpc.exe' lives (`c:\gpcwin32\bin') to your path. * Set GCC_EXEC_PREFIX=C:\gpcwin32\lib\gcc-lib\ Beware of the trailing slash! * Set LIBRARY_PATH=c:\gpcwin32\lib;c:\gpcwin32\i386-cygwin32\lib Common problems --------------- These things often give problems: * Do NOT mix binaries from different beta's -- they are incompatible. * Be sure to have only one `cygwin.dll' in your path and it must be beta17.1 The symptoms of these are crashes, stack/register dumps and Windows telling you it cannot load a dll. Read the cygwin32 FAQ (http://www.cygnus.com/ or this directory) Most of the information also applies for GNU Pascal. And please, do not bother the people of the cygwin32 mailinglist if you have problems with GPC, send them to the gpc(a)hut.fi list instead. Have fun, JanJaap <j.j.vanderheijden(a)student.utwente.nl> --- The nice thing about standards is that there are so many to choose from - Andrew Tanenbaum

1 0

Re: New Alpha: compiler directives
by Peter Gerwinski 13 Apr '97

13 Apr '97

According to Berend de Boer: > > [...] using an ISO form of pascal like standard-pascal or > extended-pascal, compiler directives are turned off by default and you > explicitly have to enable them? This is the case in some sense: You get warnings when you use compiler directives together with `--standard-pascal', `--extended-pascal', or `--object-pascal'. Use `--pedantic-errors' to turn these warnings into error messages. > My concern is the following: I've a team of programmers building an > extended pascal program. How can I be sure that they don't use some gpc > feature? I have the -extended-pascal directive to check if it's Extended > Pascal, but how can I check if they use some compiler directive in the > source to force the compiler doing something?? How can you check whether they really use the `--extended-pascal' switch? You have to stand behind them and watch what commands they type to compile. What about just saying them that they must not use compiler directives? BTW, the `--pedantic' switch is intended to check whether some code is *completely* portable. With `--pedantic', you get warnings about everything for which a Pascal compiler is known not to accept it. (* Read: You get warnings about just *everything*. :*) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970412] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

New Alpha: compiler directives
by Berend de Boer 12 Apr '97

12 Apr '97

You wrote: > (* It seems that GPC will get more options than any other existing Pascal compiler ... :*) Absolutely true :-) But I'm not sure if I like this, but I hasten to add that I don't see a better way. My concern is the following: I've a team of programmers building an extended pascal program. How can I be sure that they don't use some gpc feature? I have the -extended-pascal directive to check if it's Extended Pascal, but how can I check if they use some compiler directive in the source to force the compiler doing something?? This particular directive very probably isn't supported by another Extended Pascal compiler, so I would like to automatically detect and forbid it's use. Let's add another compiler directive to disable compiler directives? :-) Or better maybe: using an ISO form of pascal like standard-pascal or extended-pascal, compiler directives are turned off by default and you explicitly have to enable them? This makes it easier by just compiling the source to see if it is portable. Groetjes, Berend.

1 0

Re: New Alpha
by Berend de Boer 12 Apr '97

12 Apr '97

You wrote: > * If statements and such now default to short-circuit operations. > This can still be switched to complete evaluation using > `--no-short-circuit', (*$B+*), or (*$no-short-circuit*). With > `--standard-pascal' etc., the default becomes complete evaluation > and can be switched to short circuit using `--short-circuit', > (*$B-*), or (*$short-circuit*). > > (It is done this way because the cases where a program relies >on > complete evaluation of Boolean expressions are very rare; functions > with side effects should not occur in such situations anyway because > you cannot rely on the order of evaluation. OTOH, there are *many* > programs which rely on short circuit evaluation.) I like to add that Extended Pascal has the or_else and and_then to force short circuit evalutation. A quite clean solution IMHO. Groetjes, Berend.

1 0

New Alpha
by Peter Gerwinski 12 Apr '97

12 Apr '97

Hello folks, here is the next GPC alpha version. It implements most of the field-width options recently discussed, fixes some bugs, etc. In detail: Changes since gpc-970401: * Field widths still default to 0, i.e. no blank is output in front of Integer, Boolean, or negative Real values; one blank is output in front of positive Real values according to ISO. A new option `--field-widths=II,RR,BB' changes the default field widths to the numbers `II' for Integers, `RR' for Reals, and `BB' for Booleans. The arguments may be omitted in whole or in part. Just `--field-widths' yields `--field-widths=11,23,6' which ensures that at least one blank is output in front of positive numbers. `--no-field-widths' means `--field-widths=0,0,0'. The dialect options `--standard-pascal-level-0', `--standard-pascal', `--extended-pascal', and `--object-pascal' imply `--field-widths'. * A new command line option `--no-real-blank' switches the blank in front of positive Reals off; `--real-blank' switches it on again. This is useful together with compiler directives in the source (*$see-below *). * To specify default field widths, the strings written for "True" and "False" and similar things while compiling GPC, you can #define the symbols in gpc-defs.h and rts/rts.h, e.g. make CFLAGS="-O2 -DINT_OUT_WIDTH=8 -DFALSE_str=\"FOO\"" A more comfortable solution is being worked on. * String clipping can be switched off with `--no-clip-strings' or on with `--clip-strings'. The default is "on" unless `--borland-pascal' or `--delphi' has been specified. * The GNU compiler's global configuration file `specs' (or `specs.gpc' with DJGPP) now contains a line `*gpc1:' after which you can put your site-wide default switches, e.g. *gpc1: -fextended-pascal -ffield-widths -fno-clip-strings Note that `specs' does not want `--foo' but `-ffoo'. * All command-line `--foobar' flags now can be given as compiler directives. One example: (*$field-widths,NO-clip-strings,SetLimit=1024, AutoMake="-g -O3"*). This is case-insensitive except inside the " ... ". Language dialect switches like `extended-pascal' do not enable or disable keywords, so they do not *exactly* mean the same as if they were given in the command-line. For instance with (*$extended-pascal*), `uses' triggers a warning (but still works), whereas with `--extended-pascal' GPC does not know `uses' at all. * `For' control variables are checked now: With `--standard-pascal' etc. GPC warns about structured variables and variables not in the nearest enclosing declaration scope; with `--borland-pascal' etc. structured variables and global variables are okay, but local variables must still be declared in the nearest scope. Without a dialect switch, GPC only warns if we are `--pedantic'. * Bug fixed: A field width of zero does no longer suppress output (except for Strings where ISO requires it (which can be overridden with `--no-clip-strings' - see above)). * Bug fixed: Writing out Chars no more crashes on FreeBSD. * Bug fixed: Char operators, e.g. comparision, work now. * Bug fixed: RTL dump generation (with option `-dr'; for debugging purposed) works now. * Bug fixed: String value parameters, Conformant arrays (Standard Pascal) and open array parameters (Borland Pascal) are passed correctly now. (Now it is taken into account that their size isn't known.) * GPC now warns about usage of conformant arrays if invoked with `--standard-pascal-level-0', `--borland-pascal', or `--delphi'. * Bug fixed concerning Objects: The implicit `Self' parameter is passed correctly now when calling inherited methods. * Arrays can be initialized with not-absolutly-constant values now. * In ASM statements, tabs and newlines are now inserted automatically between different lines. It was not good that one had to write '... \n\t' in Pascal programs. (It's still allowed with (*$E+*), but you are not *required* to use it in ASM statements any more.) * Bug fixed: Input and output parameter specifications in ASM statements may consist of a single character now. * If statements and such now default to short-circuit operations. This can still be switched to complete evaluation using `--no-short-circuit', (*$B+*), or (*$no-short-circuit*). With `--standard-pascal' etc., the default becomes complete evaluation and can be switched to short circuit using `--short-circuit', (*$B-*), or (*$short-circuit*). (It is done this way because the cases where a program relies on complete evaluation of Boolean expressions are very rare; functions with side effects should not occur in such situations anyway because you cannot rely on the order of evaluation. OTOH, there are *many* programs which rely on short circuit evaluation.) * Bugs fixed: GPC now better distinguishes between Integer numbers and Boolean values and also knows about the difference between the pointer value `Nil' and the number `0'. * Bug fixed: Set comparision with `<' and '>' works now. * Arrays of Chars now can be initialized by String constants even without `packed'. With `--standard-pascal' etc., a warning is given. * Bug fixed: Types declared equivalent to `CString' now work like `CString'. In particular, String constants can be given to parameters of such a type. * Like in Borland Pascal, `PChar' is now implemented as an alternative to `CString' as a built-in identifier which can be redefined without warning (just like `CString'). This is switched off with `--standard-pascal' etc. * With (*$X+*) or when GPC is invoked with `--extended-syntax', `CString' (or `PChar') variables can be initialized with String constants, and they can be indexed like other Strings, but starting with 0 instead of 1. This is not affected by the dialect options since ISO Pascal does not define `CString' or `PChar', and Borland Pascal also requires (*$X+*) to allow the above. (And it makes not much sense to combine (*$X+*) with dialect options other than `--borland-pascal' anyway.) Extensions of this type must be explicitly switched on because they conflict with Pascal's type-checking rules, so don't expect the above to become GPC's default behaviour. (This is a different situation than the definition of the data type `CString' itself because `CString' is just a redefinable built-in name for "^Char", but it is a type conflict to index a pointer variable.) * When I wanted to implement an option to enable pointer arithmetics I encountered that it already worked by default due to a bug. :-) Now pointer arithmetics works only with (*$X+*) or `--extended-syntax'. (Like `CString' indexing, this is too dangerous to stay GPC's default behaviour, but it must be explicitly enabled.) * GPC now checks whether the `for' variable is of ordinal type. With (*$X+*) or `--extended-syntax', pointer variables are okay, too. * Set member iteration ("for i in [ 2, 3, 5, 7 ] do ...") is now implemented into GPC. The source - a diff against gpc-970401 - is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ together with binaries for DOS (DJGPP), DOS and OS/2 (EMX), Linux (ELF), and FreeBSD. I thank everybody who reported these bugs, in particular Phil Nelson, Frank Heckenbach, Stephen Lindholm, Abimbola A. Olowofoyeku, and Jan-Jaap van der Heijden. (Again I hope that I didn't forget your contribution.) Jan-Jaap furthermore contributed very useful ideas - besides his own work on GPC. I also thank everybody who took part in the discussion about GPC's default behaviour and helped to clarify what the standard specifications say and what they don't, what is reasonable behaviour of a compiler and what isn't. (* It seems that GPC will get more options than any other existing Pascal compiler ... :*) My special thank goes to Larry Carter for the donation of a licensed copy of Delphi, and to Nick Burrett who did not only report the bug about RTL dump generation, but also fixed it and sent me the patch. Ah - is somebody out there willing to document all this? I wrote several announcements of this type since gpc-2.0, and right now they are the only existing documentation for the new features in GPC. Thanks in advance for your help! Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970412] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

setting up gpc
by Alan Bailey 12 Apr '97

12 Apr '97

I've recently downloaded gpc (dos-djgpp) and tried running it. I used the sample hello world program included. I first tried doing this: gpc.exe hello.pas But it said it oculdn't open ld.exe or something "c:/djgpp/bin\ld.exe: cannot open -lgpc: No such file or directory (ENOENT)" Note the slashes ^ I'm assuming this is the executable you use, but I tried gpc1.exe: gpc1.exe hello.pas This worked fine, and the output was hello.s, an assembly file. that's the current situation, I have a djgpp dir and a gpc dir on my computer, both with the included binaries and documentations. So what's wrong, am I missing a parameter running gpc.exe, or do I need an assembler after gpc1.exe? Mail privately or to the list... -- Compliments of: _-_-_-_-_-_-_-_ Alan Bailey mailto:bailala@mw.sisna.com IRC: Abalone Web: http://www.mw.sisna.com/users/bailala/

2 1