May 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

License of the GNU Pascal documentation?
by Matthias Klose 09 Aug '03

09 Aug '03

On The debian-legal mailing list there currently is a major discussion about the "freeness" of the "GNU Free Documentation License". You may want to look at the archives yourself, one point to start is http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00307.html The problem are the "Invariant Sections" of the GFDL, which make the GFDL non-free from Debian's viewpoint. Looking at gpc's documentation, I see the GFDL-1.1 (with the short example GFDL license at the end), but in the man page I only find: COPYING Copyright (c) 1997-2003 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 version published by the Free Software Foundation. A copy of the GFDL comes as a texinfo document along with the GPC manual. In contrast with copying-fdl.texi, there is no mentioning of the "Invariant Sections": "If you have no Invariant Sections, write ``with no Invariant Sections'' instead of saying which ones are invariant. If you have no Front-Cover Texts, write ``no Front-Cover Texts'' instead of ``Front-Cover Texts being @var{list}''; likewise for Back-Cover Texts." Please clarify the copyright of the man page. I'll have to remove the info and html docs from the Debian main section (maybe somebody volunteers to repackage them to the non-free section), but to keep at least the manual pages in the package I'd like to see the license of the manual pages be clarified. Thanks, Matthias

6 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

gpc20030507 with gcc-3.3 on Mac OS X
by Adriaan van Os 08 Jul '03

08 Jul '03

Peter N Lewis wrote, > #### > #### FDE 0x2aea4 (OB 0x13fd60, fde_end 0x2affc) has zero > length!Aborting. > #### > Abort Fixed with gcc-3.3. Geoff Keating wrote: > > Adriaan van Os writes: >> (4) compiling any .c source with -ggdb or -gdwarf-2 (instead of >> -gstabs or -g) produces the following output: >> Internal compiler error in default_no_named_section, at varasm.c:5305 > > Darwin doesn't really support dwarf2 at present. Fixed with gcc-3.3, there is now a message "unknown or unsupported -g option". Geoff Keating wrote: > > Adriaan van Os writes: > >> Does anyone know what the status is of the following problems, >> encountered with gcc-3.2.1/3.2.2 on Darwin/Mac OS X ? >> >> (1) trampolines crash (I have a patch to fix it) >> >> (2) longjumps crash (I have a patch to fix it also) >> >> (3) non-local goto's don't work, e.g. > > These are all fixed in GCC 3.3. Well, not quite. Longjump crashes and non-local goto crashes have been fixed, but trampoline crashes not. The gcc-3.2.x trampoline patch can be applied to gcc-3.3 and it fixes most trampoline crashes, but ..... ./test_run: line 193: 766 Segmentation fault "$DIFF" testmake.tmp "$xo" TEST fproc.pas: failed ... running the testuite for fproc.pas takes a long time and fails. After a while the hardddisk starts to spin continuously, which might indicate that the system is allocating lots virtual memory (on a 1.25 GB Mac). After this, gpc1 crashes when compiling ANY .pas file, until a reboot. The typical backtrace looks like this: Date/Time: 2003-05-18 03:11:07 +0200 OS Version: 10.2.4 (Build 6I32) Host: G4.local. Command: gpc1 PID: 27979 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0 Crashed: #0 0x0014ec68 in find_reloads (reload.c:4000) #1 0x0011bbe8 in reload_as_needed (reload1.c:3893) #2 0x00115388 in reload (reload1.c:1107) #3 0x001dca60 in global_alloc (global.c:583) #4 0x000991ec in rest_of_compilation (toplev.c:3304) #5 0x00007b58 in finish_routine (declarations.c:2436) #6 0x0002d27c in main_yyparse (parse.c:1739) #7 0x00097ce0 in compile_file (toplev.c:2134) #8 0x0009ce94 in do_compile (toplev.c:5370) #9 0x0009cf60 in toplev_main (toplev.c:5400) #10 0x00002700 in _start (crt.c:267) #11 0x00002580 in start Maybe, virtual memory is corrupt after the fproc.pas testrun ?? Running the testsuite for fproc.pas with --longjmp-all-nonlocal-labels, results in a compiler error message: TEST fproc.pas: /var/tmp//ccMu9pMb.s:unknown:Can't emit reloc {- symbol "LSJR11"} @ file address 800. /var/tmp//ccMu9pMb.s:unknown:Can't emit reloc {- symbol "LSJR11"} @ file address 796. /var/tmp//ccMu9pMb.s:unknown:Undefined local symbol L3$pb failed Regards, Adriaan van Os

3 8

64 bit code generation
by Cserzo Miklos 11 Jun '03

11 Jun '03

Hi Folks, I need 64-bit code on Sun Solaris 2.9. The specification of the system (gpc -v): Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2.1/specs Configured with: /users/cserzo/big/src/gcc-3.2.1/configure --enable-languages=pascal --disable-nls --with-gnu-as --with-gnu-ld --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld Thread model: posix gpc version 20030507, based on gcc-3.2.1 Apparently, the 32-bit compiler should be able to generate 64-bit code. The problem is the missing 64-bit libgpc. The 64-bit version of the gcc library is there but its gpc counterpart not. How could I force the compilation of this library at build time? I made another test. With the 32-bit version one should be able to address ~ 4.3 Gb of the memory. In practice, I can allocate about 2Gb (array[1..500000000] of integer) but not much more. If I compile a code containing array[1..600000000] of integer the following error generated: /var/tmp//ccrvtgAm.s: Assembler messages: /var/tmp//ccrvtgAm.s:7: Error: .COMMon length (-1894967300.) <0! Ignored. /var/tmp//ccrvtgAm.s:7: Warning: rest of line ignored; first ignored character is `,' What is the correct way to make use of the memory in this case? Cheers, miklos

5 17

gpc-20030507 released
by Frank Heckenbach 07 Jun '03

07 Jun '03

I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/ The major incompatibility, compared to the previous release is that types liks `Integer (16)' have to be changed to `Integer attribute (Size = 16)' (as discussed recently). New features: * `Integer (16)' etc. changed to `Integer attribute (Size = 16)' (works for integer and Boolean types) (fjf861.pas) (@) * types can have attributes (note: no preceding `;') (fjf860*.pas) * object methods can have attributes (fjf826*.pas) * new attributes `iocritical' (fjf824*.pas), `ignorable' (fjf839*.pas) for routines * field names and array indices in initalizers are recognized (waldek5*.pas) (options `-W[no-]field-name-problem' removed, @) * object directives `published', `public' (both equivalent), `protected' (scope limited to object type and derived object types), `private' (scope limited to current unit/module) (fjf864*.pas) (options `-W[no-]object-directives' removed, @) * new options `-W[no-]parentheses' (fjf848*.pas) * new type `AnyFile' for parameters and pointer targets (fjf821*.pas) * Mac Pascal specific features are supported according to the dialect options (M) * GPC doesn't use `gpm' files anymore (instead, each module has an implicit `MODULENAME-all.gpi' interface which is a regular `gpi' file) * trimming string relations as functions (`EQPad' etc.) (fjf873.pas) * new options `-W[no-]interface-file-name' * `SeekEOF' and `SeekEOLn' use `Input' implicitly when no file is given (fjf871.pas) (B) * tagging for `with' statements (Sun Pascal) (tom6.pas) * new option `--sun-pascal' * the operator precedence and associativity of `+' and `-' is now as defined in EP by default (and as in BP with `--borland-pascal') <Pine.LNX.4.44.0210251249500.6181-100000(a)duch.mimuw.edu.pl> (fjf863*.pas) (@) * dynamic object methods (fjf859.pas) (B) * in `--borland-pascal' mode, `Assign' unconditionally (re-)initializes its file parameter (fjf858.pas) * make the program/module/unit finalizers non-public (`static' in C sense), omit them if easily possible * non-`interface' modules with empty implementation part (pmod1.pas, fjf843.pas) * `maximum-field-alignment' and `[no-]field-widths' work as local compiler directives now (fjf842.pas) * dropped `{$debug-statement}' (should not be necessary anymore, now that debug info mostly works) * new options `--[no-]longjmp-all-nonlocal-labels' * dropped computed `goto' (never worked for nonlocal `goto' into the main program, implementing it would be quite difficult, probably not worth it) (@) * `TimeStamp' is now a packed record (E) * `--interface-only' does not require `-S' or `-c' anymore (and does not create an object file) Fixed bugs: * some functions in boolean shortcuts are always called (fjf226*.pas) * possible stack overflow when using string concatenation in a loop (fjf419*.pas, fjf345e.pas, fjf460b.pas) - breaks berend3.pas (less important because strange test case, and just another instance of existing contourbug.pas) * declarations of a module interface are not visible in the implementation (kevin13.pas, mod12.pas) <Pine.BSI.3.96.971110210330.7570A-100000(a)malasada.lava.net> * check parameter and result variable names in repeated forward etc. declarations <20010321204051.A611@plato> (fjf284.pas, markus8.pas, fjf850*.pas) * initialized object variables don't work (fjf445*.pas) * the parser does not always recover well after a parse error <199911040915.KAA11168(a)humulus.daimi.au.dk> (fixed the case given in this report; if there are other cases, please report) * packed array/record fields don't work in `Read' etc. (tom5.pas) * file parameters must not automatically be bindable in `--extended-pascal' (fjf193[c-e].pas) * give an error rather than a warning when casting between types of different size in `{$X-}' * simplify code generated to compute size of dynamical variables if no bitfields are involved (ok with gcc-3) * detect invalid array slice access with constant indices at compile-time (peter2*.pas) * automatically close dynamically allocated files on `Dispose' and files declared in a statement block at the end of the statement block <6r9ir5$7v5$1(a)nntpd.lkg.dec.com> (fjf219[a-d].pas, fjf502.pas) * initialize local static variables in the main constructor, not in each routine call (fjf458*.pas) * modifying `for'-loop counters within the loop or in a subroutine is not allowed <200005240807.EAA05355(a)mail.bcpl.net>, <Pine.LNX.4.44.0210281004000.31943-100000(a)duch.mimuw.edu.pl> (az47.pas, fjf837*.pas) * label declarations must not be allowed in unit/module interfaces and module implementations (but in unit implementations, BP compatible, though we don't allow nonlocal `goto's into the constructor) (fjf835*.pas) 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

10 61

BUG REPORT: function (n: LongCard): String(64); -- bug or not allowed?
by Mirsad Todorovac 04 Jun '03

04 Jun '03

Hi, Frank! ------------------------------------------------------- program mirsad16(output); function testproc (n: LongCard): String(64); begin n := n; return 'OK'; end; begin WriteLN (testproc (42)); end. ------------------------------------------------------- bash-2.05b$ gpc -Wall mirsad16.pas mirsad16.pas:4: warning: missing string capacity -- assuming 255 mirsad16.pas:4: parse error before `(' I couldn't find in reference docs whether this is actually banned by specification, or is it a bug in parser. Thanks, Mirsad -- "I have a dream!" -- Martin Luther King Jr. "You can't hold someone down ... without staying down with him." -- Booker T. Washington "... one thing is for sure about the rat race: Even if you win, you're still a rat." -- S. Baars

8 18

Problems with installing GPC under Red Hat 9
by Tomasz Kowaltowski 02 Jun '03

02 Jun '03

I installed gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz under my previous Linux (Red Hat 8.) and it worked without any problems. I did the same under Red Hat 9. When I tried to compile a program 'gpc' complained: gpc: installation problem, cannot exec `gpcpp': No such file or directory I put then in /usr/local/bin a symbolic link: gpcpp ->/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/gpcpp Now I got the message: gpc: installation problem, cannot exec `gpc1': No such file or directory I added the link: gpc1 -> /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/gpc1 Now I got a series of messages from the linker; some of them: --------------------------------------------- /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o)(.text+0x5d6): In function `_p_LocaleUpCase': /home/frank/gpc/gcc-2.95.3/gcc/p/rts/rts.c:838: undefined reference to `__ctype_toupper' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o)(.text+0x5ea): In function `_p_LocaleLoCase': /home/frank/gpc/gcc-2.95.3/gcc/p/rts/rts.c:846: undefined reference to `__ctype_tolower' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o)(.text+0x5fe): In function `_p_IsUpCase': /home/frank/gpc/gcc-2.95.3/gcc/p/rts/rts.c:851: undefined reference to `__ctype_b' (... more deleted ...) ----------------------------------------------- Any idea what the problem is? I am not a Linux expert and would appreciate simple advice :-). Please send a copy of the answer to my address because I am not a subscriber to this list. Thanks! -- Tomasz Kowaltowski

2 3

problems with GPC/Mac OS X
by Boris Herman 01 Jun '03

01 Jun '03

Hello I have DLed the newest version listed and the Dec2002 Developer Tools from Apple and have proceeded to work on a more complex project. However, I am unable to compile the source - it gives me this error: > alan.pas: In procedure `f_b': > alan.pas:577: internal 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. > Any ideas? If anyone cares to look into it I have attached the source, the preprocessed source and the data file needed to run it. Regards, Boris

7 13

Could anyone please tell me how GPC will align variables of most used types by default on Intel platform? (+)
by Ingvar Marny 29 May '03

29 May '03

Hi, dear All. I have made exhaustive (at least, hope so) search in the documentation and mail list archives but found only that "GPC will align variables according to maximum performance", but how exactly? On what boundary will be aligned Integer, Boolean, Longint, Word, etc. On what boundary will be aligned string, record, array, their elements and are there any differences between default alignment of variable without record and variable as record field? And, if possible, I need information for the other platforms. I understand that I can make experiments to find it out but it seems to me it should appear in one or in other place (GPS manuals or mailing lists). Thanx, dear All. Best regards, Ingvar mailto:marny@rambler.ru

5 4