March 2003 - Gpc

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

26 Oct '10

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

10 16

range check test programs
by Francois Schoubben 12 Jul '03

12 Jul '03

For the main tests, i hope it's the end... Up to you to correct my tests... http://www.info.fundp.ac.be/~fsc/dvpt/fsc.tar.gz or, "online" http://www.info.fundp.ac.be/~fsc/dvpt/ fsc01-05 : array R/W fsc06-10 : packed array R/W fsc11 : array in a record (just one, i dont think it's usefull :) ) fsc12 : enum fsc13-14 : string (R/W) fsc15-16 : range write (integer and char) fsc 17-18 : functions and range fsc 19-25 : predefined functions (chr, fillchar, ...) fsc26-27 : conformant array R/W fsc28-30 : slice array fsc31-35 : actual schema discriminant fsc36-37 : "for loops", i'm not sure it's what you expect... For asm target, i have a problem... The only "assembler language" i know is MIX (thanks D. Knuth :-) )... And i haven't really got time to learn it before... long time i'm afraid... Can anybody help here??? For the remaining... What's missing? wrong? misunderstood? I've never played with delphi extensions, the OO language i used was java. And i'm teaching the very basics of programming so, i never used slice array and other schema discriminant before, it's possible i missed a lot of thing... Just explain me (or point me to a relatively short tutorial), i only ask to learn :) -- Francois Schoubben

3 7

Upper/lower case in identifiers
by Frank Heckenbach 22 May '03

22 May '03

As you probably know, GPC currently converts all identifiers to first letter upper-case/rest lower-case. Since this is often not nice, I plan to change this. This would affect at least the following things: - error messages - the file name chosen with `--transparent-file-names' (makes a difference only on case-sensitive file systems, i.e. not Dos/Windows); is this ok (to those who use this option)? - the file name prompt with external files without binding While I'm at it, it might be easy to add a warning if an identifier is used with varying case (something like `var Foo: Integer; [...] WriteLn (FOO)'). - Any ideas for the name of the option? (`-Widentifier-case'?) - Default? (I suppose off, though I think I myself would prefer on.) - Should it work across units/modules? Or should it be a tri-state option (never/current file/global)? Frank -- Frank Heckenbach, frank(a)g-n-u.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: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

8 8

Weird type/identifier conflicts
by Grant Jacobs 30 Apr '03

30 Apr '03

This is an *updated* version of my previous message, which I mistaken sent to gpc-doc (my apologies). (See the bits 'Addendum' for the new stuff I've added.) Excuse my being frustrated. I am trying damn hard to get GPC (2.1 (20020510), based on gcc-2.95.3 20010315 (release)) to compile a Pascal program I wrote some time ago but keep running it things I can't make sense of. Maybe I'm being unfair, but I'll give you the whole story just in case its something new. The latest issue I'm having is a run of type vs. identifier conflict errors of the form: ./GHJ_AARegions.pas:49: type name expected, identifier `Fnames' given ./GHJ_AARegions.pas:49: warning: missing type in declaration of `Infname' ./GHJ_AARegions.pas:54: warning: parameter has incomplete type My trouble was fnames *is* a type. It is *only* defined as a type. So how the heck does the compiler come away thinking that its an identifier????? I eventually resolved this by directly 'using' modules, rather than rely on the hierarchy (read on). When this error occurred the GHJ_AARegions unit uses GHJFnames. GHJFnames in turn uses GHJFiles, which is where the type fnames is defined. (Really these two levels need to be the other way around, but this is a legacy program I am porting, so I have to deal with that after the port.) Since these uses statements were within the interface section, I presumed the definitions would propagate upwards so that they form a hierarchy. Or, put another way, I assumed the interface of a unit is extended by any units it uses in its interface section. Originally, I had: unit GHJ_AARegions ; interface uses GHJStdDefs, GHJStdMaths { for inrange() }, GHJttInterface { for press_return() }, GHJStrings { for get_string8() }, {=>} GHJFnames { for get_fname() }, GHJ_AAErrors, GHJ_AAUtils, GHJ_AAGlobalUnit ; By getting GHJ_AARegions to explicitly, directly, use GHJFiles, the compiler stopped complaining. ie. I changed the above code to: unit GHJ_AARegions ; interface uses GHJStdDefs, GHJStdMaths { for inrange() }, GHJttInterface { for press_return() }, GHJStrings { for get_string8() }, {=>} GHJFiles, GHJFnames { for get_fname() }, GHJ_AAErrors, GHJ_AAUtils, GHJ_AAGlobalUnit ; {=>} points out the offending line of source. If this is truly the problem, then I presume there is no way of building a hierarchy of units in GPC at present? (In this case my safest strategy is to have every unit uses *all* the lower units directly, "just in case". Or put, another way, I might just as well use includes to make everything one big flat program. Sorry, but I *am* frustrated!) Three thoughts: 1. This is the correct behaviour?: surely I should be able to use a higher-level module and have all the lower-level modules definitions within that higher-level module "gotten" at the same time without have to explicitly duck behind the scenes and drag out each module??? Excuse me for asking this, but its not terribly clear from the docs, at least on my reading of it. Addendum: I've since seen section 6.1.8.2. The source structure of UCSD/Borland units of the docs say "A units exports everything declared in the interface section". This it doesn't appear to do if we consider things in the units imported via uses. 2. Why the heck does the compiler report the message it does? "Missing type fnames" perhaps, but since fnames is only ever defined as a type and never as an identifier, it shouldn't be able to report the message it did... 3. Is there any chance you can tell the user where the "identifier" (see the error message) is defined so that in future users might have chance of trying to second-guess just what the compiler is "thinking"? Sorry I can't provide a full code example: I am porting a largish program (approx. 60,000 lines of source in a dozen or so modules) and in any event I can't understand the problem well enough to create an example - catch-22... Looking at the known bugs for ver. 2.1 there are a couple that might be relevant, esp."Types declared in a module interface are not visible in the implementation" (but does this refer to the same module's interface section and how are units and modules related with reference to this?) While I'm writing, is there any chance you can make the compiler keep trying after one unit has failed, rather than stopping at that point? It seems that if there is even one error in a unit, the compilation is abandoned at the end of that unit. Now to try figure out how GPC claims a type-mismatch on something that is definitely the same type and the type is only defined in one place... probably the same issue, we'll see... Addendum: Nope. It proves to be a unit issue, but a different one. It seems that --automake doesn't "drill down". If you modify a lower level unit, then recompile a higher-level one that uses the lower-level unit, GPC doesn't re-compile the lower-level unit first and instead comes out with (apparently) misleading error messages. --automake in my hands isn't so auto ;-) ! Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs(a)bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents.

8 77

Progress of Mac OS X port
by Adriaan van Os 20 Apr '03

20 Apr '03

Yesterday, I wrote a small test program and linked it against Apple's "Carbon framework". To my surprise, it worked. So, against all expectations, the current compiler is able to link to Apple "dylibs" and Apple "frameworks". The compiler produces ".o" code and the Apple-"ld" linker takes care of the rest. This implies, that I am loosing interest in the Apple-patched GCC compiler. Apple writes "we're not even sure what all of them [the compiler changes] are, because the existing compiler has many undocumented changes inherited from 10 years of NeXT and Apple hacking, and nobody knows what some of them are for." This doesn't inspire confidence. Besides, important changes (like precompiled header support) are now getting integrated into mainline FSF. So, I am slowly considering it an advantage (rather than a disadvantage) that the current port is based on mainline FSF-GCC 3.2.1. And isn't it fun to read in officlal Apple docs for some compiler option "Not supported on Mac OS X" where the GPC compiler actually does .... As a further experiment, I compiled hello.pas into hello.o and tried to link it with "mwld", the command-line version of the MetroWerks CodeWarrior linker. Again, to my surprise, it worked. I added "hello.o" to a CodeWarrior Project and disassembled it there. It worked. So, maybe some day there will be a GNU Pascal compiler plug-in CodeWarrior (not a promise, just an idea) .... Regards, Adriaan van Os

6 13

gpc-20030323 released (IMPORTANT NOTES ABOUT BACKWARD-INCOMPATIBILITY)
by Frank Heckenbach 18 Apr '03

18 Apr '03

I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/ You will hate this release ... at least if you make heavy use of external declarations or other directives. We all knew that some backward-incompatible changes in this area would have to be made, now that's happened. PLEASE READ THE NOTES BELOW FOR DETAILS. Changes that affect building GPC: ================================= - Dwarf2 debug info (the default under Linux and many other systems with gcc-3) finally works. This means you can now build GPC with gcc-3 without `-g0' or `-gstabs'. - Building GPC no more requires gperf (those who maintain build dependencies please note this). - Besides the source distributions as before, there is now also a "minimal" distribution. This is compressed with bzip2 instead of gzip and does not contain any generated files. These files will be generated automatically when building GPC, but you need some additional tools installed: bzip2, bash, *GNU* sed, GNU awk, GNU m4, bison, flex, autoconf, help2man, makeinfo (at least version 4.1). Other changes: ============== - Forward referencing pointers generate proper debug info now. - Discriminant identifiers are allowed as variant record selectors. - `export Foo = all (...)' (fjf811*.pas) - Delphi-compatible `initialization', `finalization' (chief43*.pas) - Type-casts are BP compatible now, in particular, value type-casts between ordinal and real or complex types don't work anymore. - All non-ISO-7185 keywords can be used as identifiers (with two small exceptions). (fjf440.pas) - `pack-struct' does not imply bit-level packing anymore (only explicit `packed' records and arrays do). - New options `--[no-]ignore-packed' (`--ignore-packed' is the default in BP mode). (fjf796*.pas) - New option `--maximum-field-alignment=N' - `{$[no-]pack-struct}' as a compiler directive - New options `-W[no-]local-external' (implied by `-Wall') - New options `--vax-pascal', `--mac-pascal' - Mac Pascal directives `definec', `macro', `undefc', `ifc', `ifoptc', `elsec', `elifc', `endc', `errorc' - Units without `implementation' part - When passing a schema variable as an untyped argument, the whole schema, including the discriminants is passed. (fjf798.pas) - `TimeZone' in `TimeStamp' counts seconds *east* of UTC now (not west, as before). (datetimedemo.pas) - Some bug fixes related to operator overloading. - Variables declared in interfaces of modules are now initialized (capacity of strings etc.). (daj3.pas, sven14c.pas, nick1.pas) - Various other bug fixes. Directives and attributes: ========================== - `external name' works (BP compatible). So procedure Foo; external; asmname 'bar'; or (equivalent previously) procedure Foo; asmname 'bar'; can be changed to procedure Foo; external name 'bar'; GPC also accepts procedure Foo; external 'libname' name 'bar'; but ignores 'libname'. It could be supported via automake, but since automake is to be replaced by gp, anyway, it seems pointless to do it now. - `name' works as an attribute. - `attribute's with single parameters can be written with `=', so attribute (name ('foo')) and attribute (name = 'foo') are equivalent. - Linker names (whether by `external name' or as an `attribute') can be string constant expressions now (e.g., involving declared string constants and `+'). The same applies to module/unit file names specified with `in'. - `asmname' is deprecated (and will be dropped in a future version). * External `asmname' constructions can be changed as shown above. * In a unit interface, change procedure Foo; asmname 'bar'; to procedure Foo; external name 'bar'; *if* the routine is really external (e.g. implemented in a C file or library); otherwise to procedure Foo; attribute (name = 'bar'); (previously, GPC didn't care, but now you have to distinguish these cases). - `external' without an asmname (whether by `external name' or as an `attribute') defaults to all-lowercase linker names now. GPC will give a warning now (because of the change). This warning will disappear in the future (but the change will remain in effect, of course). Routines without `external' or asmname still use first-uppercase linker names, for those who care. But it's not recommended to rely on this. So change procedure Foo; external; to procedure Foo; external name 'Foo'; (or change the corresponding C code to `foo' if that's under your control). - All of the above applies to variables as well. - `c', `c_language' are also deprecated. Instead of procedure Foo; c; or procedure Foo; c_language; write procedure Foo; external; (if you don't mind the warning for now), or procedure Foo; external name 'foo'; (if you prefer to make the linker name more explicit). - `static', `volatile' and `register' for variables are no prefix directives anymore, but attributes. E.g. var Foo: static Integer; becomes var Foo: Integer; attribute (static); - Same for `inline' with routines. inline procedure Foo; becomes procedure Foo; attribute (inline); - A new attribute `const' for variables (really read-only -- unlike BP's "typed constants", and also applicable to external variables). - `attribute' for routines doesn't imply `forward' anymore, so you don't have to declare routines twice in a program or implementation part when setting the linker name or some other attribute. E.g. procedure Foo; attribute (noreturn); { forward; -- ignored here before } procedure Foo; begin Halt end; becomes: procedure Foo; attribute (noreturn); begin Halt end; A final example: procedure Foo; asmname 'bar'; attribute (noreturn); procedure Foo; begin Halt end; becomes: procedure Foo; attribute (noreturn, name = 'bar'); begin Halt end; Frank -- Frank Heckenbach, frank(a)g-n-u.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: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

9 66

Re: gpc-20030323 - compiler crash
by Prof A Olowofoyeku (The African Chief) 31 Mar '03

31 Mar '03

Hi Frank [...] > Never say impossible ... > > program Chief44; > > uses Chief44u; > > type > TMemoStrings = abstract object (TStrings) > end; > > begin > WriteLn ('OK') > end. > > unit Chief44u; > > interface > > type > TStrings = abstract object > procedure foo; abstract; > end; > > implementation > > end. > > --- p/gpc-decl.c.orig Tue Mar 25 13:33:12 2003 > +++ p/gpc-decl.c Wed Mar 26 08:48:09 2003 [...] Unfortunately, while the patch works for the test program that you have created (above), the problem still exists with my code, and I still get precisely the same error as before. I have been trying hard (without success) to reduce the problem to a small program, but I have no idea what to look for, or what could possibly be the matter. Perhaps it could relate to lots and lots of sub-classing? Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

5 15

no EOF in untyped files?
by Eike Lange 31 Mar '03

31 Mar '03

Hi Folks! I've problems in one of my programs using untyped files. EOF does not work as expected: program Foo; var f: File; i, v: Integer; begin Assign (f, 'foo.dat'); Rewrite (f, SizeOf (Integer)); v := 101; for i := 0 to 10 do BlockWrite (f, v, 1); Close (f); Reset (f, SizeOf (Integer)); while not EOF (f) do begin BlockRead (f, v, 1); WriteLn (v) end; Close (f) end. The output is _not_ 11 times 101 as expected but six lines garbage. Replacing the while-loop with a for-loop (0 to 10), all works fine. What do I wrong? I'm using gpc 20030323 with gcc 3.2.2 Eike

2 1

Happy Birthday GPC
by Frank Heckenbach 31 Mar '03

31 Mar '03

According to the ChangeLog, Jukka Virtanen started implementing GPC exactly 15 years ago. Time for a little celebration! :-) Frank -- Frank Heckenbach, frank(a)g-n-u.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: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

3 2

Re: gpc-20030323 testsuite
by Prof A Olowofoyeku (The African Chief) 27 Mar '03

27 Mar '03

Hi Frank [...] > > "./test_sum" | tee test_summary ./test_run: fatal: > > `--print-needed-options' yields: ./test_run: /mingw/bin/gpc: Invalid > > argument Nothing was run." > > Looks like an installation problem. What happens if you insert > > echo "$PC $PFLAGS --print-needed-options dummy.pas" >&2 > > in test_run before the needed-options stuff, and execute the command > that is shown manually (or from bash)? I get nothing. No errors, no output - just nothing. Looking in the directories in which I am building GPC, I see files called "needed-options" in the p/rts and p/utils directories, of zero bytes in size. I believe that this file has always had zero bytes, but that has not been a problem until now. > Is /mingw/bin/gpc the GPC executable? Yes. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

2 4