Gpc December 2002

gpc@gnu.de

35 participants
51 discussions

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

25 Oct '10

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

10 16

Re: Conformant array curiosity
by Wood David 24 Mar '03

24 Mar '03

Frank, Thanks for your reply. I've managed to cut down the module to this very short module so I just get two errors, both - prior parameter's size depends on 'A': MODULE Test interface; export Test=(Test_proc); PROCEDURE Test_proc(List : ARRAY[a..b :INTEGER] OF DOUBLE); END. MODULE Test implementation; PROCEDURE Test_proc; BEGIN List[a]:= 2.3; List[2]:= 2.3; END; { Test_proc } END. The errors correspond to each assignment although the error line is the declaration. Sure enough, converting this to a unit fixes the problem: UNIT Test; Interface PROCEDURE Test_proc(List : ARRAY[a..b :INTEGER] OF DOUBLE); Implementation PROCEDURE Test_proc; BEGIN List[a]:= 2.3; List[2]:= 2.3; END; { Test_proc } END. Is the module syntax illegal or is it a bug? If it is a bug, at least you can take comfort in knowing it can kill the DEC Pascal compiler too! Regards David Wood, QinetiQ Farnborough The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

2 2

Range Checking
by Frank Heckenbach 05 Mar '03

05 Mar '03

Hi, after some friendly requests and discussion, I'm planning to implement range checking as one of the next major things in GPC (probably in Januaray, if nothing urgent gets in between ...). Note, I'm using "range checking" in the specific meaning I explained recently, not generally for all kinds of runtime checks, and not including overflow checking of arithmetic operations etc. (that will be a separate issue). Also, as I said before, I'll do an "easy" implementation. I'm still not convinced that anything more is worth the (big) effort when the programmer in the rare (AFAICS) cases where it matters could just as well use explicit types etc. to avoid checks where he doesn't want them. Since some of you have said they'd like to help, but can't code in the compiler itself, here are at least 2 chances: 1. Help finding all places where range checking must be applied In mean this from a Pascal point of view, covering, of course, all standards, dialects and extensions that GPC supports. So far I've found the following ones: - assignment to variables and function results, - value parameter passing to user-defined and built-in (e.g., `Chr', `FillChar', ...) routines, - array indexing (R/W), - array slice indexing (R/W), - `for' loop bounds, - conformant array range, - actual schema discriminants, - initialization of types, variables and typed constants, - `asm' targets 2. Write test programs Test programs should follow the guidelines in the manual. In particular, since most of the tests will check for errors, each one must be a separate test for each situation (each of the cases above plus any that others of you will come up with). For a way to test runtime errors see, e.g., fjf424d.pas. Range checking will be on by default, and can be switched on/off with the options `--[no-]range-checking' and the compiler directives `{$[no-]range-checking}', and `{$R+}', `{$R-}'. A complete set of tests should also test all of those. If you'd like to do so, please post a short note, so several of you won't duplicate efforts, but can coordinate. 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

6 15

Testing GNU Pascal
by Artur Zaroda 28 Jan '03

28 Jan '03

Hello, All the tests below were on the latest (?) binary release of GNU Pascal for mingw. The result of "gpc -v" is: gpc version 2.1 (20020510), based on 2.95.3-6 (mingw special) I'm interested in standard (ISO) modes, especially ISO 7185, so I have been using the "--classic-pascal" option. I'm only indicating that (in FLAG comments) where I suspect that, what GNU Pascal currently does may be appropriate, when standard compliance is not requested. First, some test programs with non-standard features: program az1(output); (* FLAG --classic-pascal *) const c=2+2; (* WRONG - violation of 6.3 of ISO 7185 *) begin writeln('failed') end. program az2(output); (* FLAG --classic-pascal *) const p=nil; (* WRONG - violation of 6.3 of ISO 7185 *) begin writeln('failed') end. program az3(output); (* FLAG --classic-pascal *) procedure q(x:integer); const xx=x*x; (* WRONG - violation of 6.3 of ISO 7185 *) begin end; begin writeln('failed') end. program az4(output); (* FLAG --classic-pascal *) begin case 4 of 2+2: (* WRONG - violation of 6.8.3.5 of ISO 7185 *) end; writeln('failed') end. program az5(output); (* FLAG --classic-pascal *) var r:record case boolean of false..true:() (* WRONG - violation of 6.8.3.5 of ISO 7185 *) end; begin writeln('failed') end. program az6(output); (* FLAG --extended-pascal *) begin if ord('')=32 then; (* WRONG - violation of 6.7.6.4 of ISO 10206 *) writeln('failed') end. program az7(output); (* FLAG --classic-pascal *) begin if []<[1] then; (* WRONG - violation of 6.7.2.5 of ISO 7185 *) writeln('failed') end. program az8(output); (* FLAG --classic-pascal *) type t=set of char; function f:t; (* WRONG - violation of 6.6.2 of ISO 7185 *) begin f:=[] end; begin writeln('failed') end. program az9(output); (* FLAG --classic-pascal *) type t=record end; var x:t; function f:t; (* WRONG - violation of 6.6.2 of ISO 7185 *) begin f:=x end; begin writeln('failed') end. program az10(output); (* FLAG --classic-pascal *) procedure q(procedure r); begin end; begin q(nil); (* WRONG - violation of 6.6.3.4 of ISO 7185 *) writeln('failed') end. program az11(output); (* FLAG --classic-pascal *) var a:record case b:boolean of true,false:() end; procedure p(var x:boolean); begin end; begin p(a.b); (* WRONG - violation of 6.6.3.3 of ISO 7185 *) writeln('failed') end. program az12(output); (* FLAG --classic-pascal *) procedure q(procedure r); begin r:=r (* WRONG - violation of 6.4.6 of ISO 7185 *) end; begin writeln('failed') end. program az13(output); (* FLAG --classic-pascal *) var t:array [boolean] of integer; begin if t=t then; (* WRONG - violation of 6.7.2.5 of ISO 7185 *) writeln('failed') end. program az14(output); (* FLAG --classic-pascal *) begin if 'ab'='abc' then; (* WRONG - violation of 6.7.2.5 of ISO 7185 *) writeln('failed') end. program az15(output); (* FLAG --classic-pascal *) begin write('failed'); writeln('1':0,'22':0,3:0) (* WRONG - violation of 6.9.3.1 of ISO 7185 *) (* Besides, writing "13" seems inconsistent *) end. program az16(output); (* FLAG --classic-pascal *) var r:record end; begin with (r) do; (* WRONG - violation of 6.8.3.10 of ISO 7185 *) writeln('failed') end. program az17(output); (* FLAG --classic-pascal *) var p:^integer; begin new((p)); (* WRONG - violation of 6.6.5.3 of ISO 7185 *) writeln('failed') end. program az18(output); (* FLAG --classic-pascal *) var a:array [1..1] of integer; begin (a)[1]:=10; (* WRONG - violation 6.5.3.2 of ISO 7185 *) writeln('failed') end. Correct programs, which don't compile: (* az19.pas: In main program: az19.pas:4: division by zero *) program az19(output); begin if false then writeln('failed: ',1/0) else writeln('OK') end. (* az20.pas: In main program: az20.pas:7: warning: ISO Pascal forbids this use of packed array components *) program az20(output); (* FLAG --classic-pascal -Werror *) var t:packed array [1..1,1..1] of boolean; i:integer; begin i:=1; t[1,i]:=false; writeln('OK') end. (* az21.pas: In main program: az21.pas:11: type mismatch in array index az21.pas:11: array subscript is not of ordinal type *) program az21(output); var t:array [1..1] of integer; procedure r(x:integer); begin end; function q:integer; begin q:=1 end; begin r(t[q]); writeln('OK') end. (* az22.pas: In procedure `P': az22.pas:5: function definition does not match previous declaration az22.pas: In function `X': az22.pas:6: undeclared identifier `Y' (first use in this routine) az22.pas:6: (Each undeclared identifier is reported only once az22.pas:6: for each routine it appears in.) az22.pas:7: warning: return value of function not assigned *) program az22(output); function x:integer;forward; procedure p; function x(y:integer):integer; begin x:=y end; begin end; function x; begin x:=1 end; begin writeln('OK') end. (* az23.pas: In main program: az23.pas:3: parse error before `..' az23.pas:5: parse error before `Else' *) program az23(output); begin if []=(..) then writeln('OK') else writeln('failed') end. Incorect programs - should not compile: program az24(output); begin if 1.1 in [] then; (* WRONG - real is not an ordinal type *) writeln('failed') end. program az25(output); var real:real; (* WRONG - can't create new definition and use the old one *) begin writeln('failed') end. program az26(output); begin writeln('failed: ',1:2.3) (* WRONG - field width should be integer *) end. program az27(output); begin writeln('failed: ','xx':true) (* WRONG - field width should be integer *) end. program az28(output); var i:integer; begin for i:=0 to nil do; (* WRONG - type of final value not compatible with integer *) writeln('failed') end. program az29(output); var f:file of file of char; (* WRONG - file type is an illegal component type *) begin writeln('failed') end. program az30(output,output); (* WRONG - program parameters are not distinct *) begin writeln('failed') end. program az31(output); type t=record x:^r(* WRONG *)eal end; begin writeln('failed') end. program az32(output); procedure q;forward; (* WRONG - no definition of procedure q *) begin writeln('failed') end. program az33(output); begin writeln('failed: ',3:2:1) (* WRONG - that form is only applicable to reals *) end. program az34(output); function f:integer; begin f:=1 end; procedure p(function f); (* WRONG - incorrect declaration of functional parameter *) begin end; begin writeln('failed') end. program az35(output); var output:file of real; begin writeln('failed') (* WRONG - output is not of type "text" *) end. Programs demonstrating internal compiler error: (* d:\src\gcc-2.95.3-20010828\gcc\p\gpc-common.c:1390:build_pascal_binary_op: failed assertion `result' az36.pas: In main program: az36.pas:4: Internal compiler error. *) program az36(output); begin if 0 in ([]*[1]) then writeln('failed') else writeln('OK') end. (* az37.pas: In main program: az37.pas:3: ISO Pascal requires an entire `for' variable az37.pas:3: invalid operands to binary <= az37.pas:3: invalid lvalue in assignment az37.pas:3: Internal compiler error in `do_abort', at toplev.c:2301 *) program az37(output); begin for char:=1 to 1 do; (* WRONG *) writeln('failed') end. Programs crashing compiler: program az38(output); begin if 1 in 1 then; (* WRONG *) writeln('failed') end. program az39(output); var s:set of boolean; begin s:=1; (* WRONG *) writeln('failed') end. program az40(output); procedure q(x:integer);forward; procedure q; begin end; function r; (* WRONG *) begin r:=1 end; begin writeln('failed') end. program az41(output); var t:array [(a)] of integer; begin t[char]:=1; (* WRONG *) writeln('failed') end. program az42(output); const s=1; type t=^s; (* WRONG *) begin writeln('failed') end. Finally, programs giving incorrect results: program az43(output); (* FLAG --classic-pascal *) (* The reason, I'm including that option is that there may be some dialect implemented by GNU Pascal, which does not define the order of evaluation for parameters of "write". ISO standards are clear about it *) var a,b,c,d,x:integer; f:text; (* Result is correct if you change that to f:file of integer *) function g(y:integer):integer; begin write(f,x*y); x:=x+2; g:=x+y; end; begin rewrite(f); x:=1; write(f,g(3),g(1)); reset(f); read(f,a,b,c,d); if (a=3) and (b=6) and (c=3) and (d=6) then writeln('OK') else writeln('failed: ',a,b,c,d) end. program az44(output); var x:integer; function f:integer; begin f:=x; x:=2 end; begin x:=1; if [1]=[f] then writeln('OK') else writeln('failed') end. program az45(output); var x:boolean; function f:integer; begin f:=1; x:=true end; begin x:=false; if 1 in [1,f] then if x then writeln('OK') else writeln('failed') end.

4 8

Compilation problem with gpc 20021128
by Martin Liddle 23 Jan '03

23 Jan '03

I am experimenting with gpc 20021128 built with gcc 3.2.1. However I have a compilation problem. The following code fails to compile with the error message: ml.p:12: passing arg1 of Sys_stat from incompatible array. The code compiles OK under 20020426 based on gcc 2.95.2. Am I doing something wrong or is this a bug? (Note if the function rmdir line is commented out in ml2 then the program compiles. If the code of ml2 is merged with ml then the code compiles). unit ml2; interface Const CstrSize = 254; type StatRecord = Array[1..20] of Integer; CstrIndex = 1..CstrSize+1; Cstring0 = packed array [CstrIndex] of char; function Cstr(protected S: string): Cstring0; function rmdir(protected Path: Cstring0): integer; C_language; function sys_stat(protected Path: Cstring0; var Buf: StatRecord): integer; asmname 'stat'; implementation function Cstr; var I, U: CstrIndex; Result: Cstring0; begin U := length(S); if U > CstrSize then U := CstrSize; for I := 1 to U do Result[I] := S[I]; Result[U+1] := chr(0); Cstr := Result; end { Cstr }; end. Program ml; uses gpc, { cstrings,} ml2; procedure make_standard_error(progname:Tstring); var retval1:integer; statrec:statrecord; begin retval1:=sys_stat(Cstr(progname+'.err'),statrec); end; Begin Writeln('Starting'); Make_standard_error('ml'); end. -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.

4 17

Rép : The Preprocessor
by Pascal 09 Jan '03

09 Jan '03

Hi Adriaan, I've try many times to port GPC to MAC OS X / Darwin without the succes I wished, before I fall in Ada language, more strict but more functionnal. Nevertheless I've modified 'gpcpp.c' the preprocessor source code in order to accept Mac Pascal directives. If you or any one want it let me know I will put it on my web site. Best , Pascal Pignard. http://perso.wanadoo.fr/blady Best > Frank Heckenbach wrote: > >> I.e., we might choose to implement them for compatibility's sake. >> Then again, how far is GPC compatible to CW in other respects? Is it >> reasonable to claim (or strive for) compatibility at all? > > Well, I don't mind writing different code, where compilers and > platforms are different. I am striving for the possibility to do so > within one conditionalized source code. One might call this the lowest > level of compatibility, the possibilty to write a conditional compiler > expression IFxx ELSExx ENDxx in a way that both compilers understand. > > In CodeWarrior Pascal, you have the choice between "Apple style" and > "BP style" conditional expressions (the latter not strictly BP, but > enhanced with Apple-like features) You can use either, but you can't > mix them in the same project, e.g. > > {$ifc condition} ... {$elsec} ... {$endc} > > or either > > {$if condition} ... {$else} ... {$endif} > > in all sources. > > Most Macintosh programmers traditionally will use "Apple style" > conditional expressions, since they are used in Apple's Pascal > Interfaces to MacOS. I, for one, am lucky to maintain my own Pascal > Interfaces to MacOS, so for me the choice is free. Also, I am free to > make any changes to those Interfaces, needed for GPC. > > To put it in a nutshell, I will be very grateful if GPC supports > > {$if condition} ... {$else} ... {$endif} > > and it would be nice if > > {$ifc condition} ... {$elsec} ... {$endc} > > is supported also. The other items from the CodeWarrior Reference are > non-essential. > > Best regards, > > Adriaan van Os

3 2

Building GPC with GCC-3.2.1 on Darwin
by Adriaan van Os 05 Jan '03

05 Jan '03

Here is a first report of my attempt to build GPC-20021128 with the GCC-3.2.1 backend on Mac OS X "Darwin". The GPC build is on a 1.1 GB 450 MHz PowerMac G4 running Mac OS X 10.2. Note: I am also trying to build GPC with an Apple-patched GCC backend (named "GCC3-1151"), but I will report about that separately. P r o b l e m 1 During Configure, conftest crashes, but the Configure process happily continues. This is not a GPC problem. The crash also appears if I try to build GCC-3.2.1 (without GPC). ********** Date/Time: 2002-12-24 14:40:01 +0100 OS Version: 10.2 (Build 6C115) Host: G4.local. Command: conftest PID: 3948 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x00088000 Thread 0 Crashed: #0 0x000026d4 in test_1 (configure:127) #1 0x00002a9c in main (configure:237) #2 0x00002298 in _start (crt.c:267) #3 0x00002118 in start PPC Thread State: srr0: 0x000026d4 srr1: 0x0000f030 vrsave: 0x00000000 xer: 0x00000000 lr: 0x000026b8 ctr: 0x90015040 mq: 0x00000000 r0: 0x00000001 r1: 0xbffffb40 r2: 0x84000482 r3: 0x000025e0 r4: 0x00000000 r5: 0x00000000 r6: 0x90015040 r7: 0x00000000 r8: 0x00000000 r9: 0x00001000 r10: 0x00087000 r11: 0xa0004254 r12: 0x90015040 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000 r24: 0x00000000 r25: 0x00000000 r26: 0xbffffd70 r27: 0x00000008 r28: 0x00000001 r29: 0x000033a8 r30: 0xbffffd74 r31: 0x000025e0 P r o b l e m 2 The file "builtin-attrs.def" causes problems. This is not a GPC problem either: same problems if I try to build GCC (without GPC). Being a C ignoramus, I simply commented away the offending lines (in order to at least continue the build process). In file included from /Users/adriaan/gpcx/gcc/c-common.c:4110: /Users/adriaan/gpcx/gcc/builtin-attrs.def:94: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:95: redefinition of `ATTR_PRINTF_1' /Users/adriaan/gpcx/gcc/builtin-attrs.def:94: `ATTR_PRINTF_1' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:95: redefinition of `ATTR_FORMAT_PRINTF_1' /Users/adriaan/gpcx/gcc/builtin-attrs.def:94: `ATTR_FORMAT_PRINTF_1' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:97: redefinition of `ATTR_PRINTF_2' /Users/adriaan/gpcx/gcc/builtin-attrs.def:96: `ATTR_PRINTF_2' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:97: redefinition of `ATTR_FORMAT_PRINTF_2' /Users/adriaan/gpcx/gcc/builtin-attrs.def:96: `ATTR_FORMAT_PRINTF_2' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:99: redefinition of `ATTR_PRINTF_3' /Users/adriaan/gpcx/gcc/builtin-attrs.def:98: `ATTR_PRINTF_3' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:99: redefinition of `ATTR_FORMAT_PRINTF_3' /Users/adriaan/gpcx/gcc/builtin-attrs.def:98: `ATTR_FORMAT_PRINTF_3' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:101: redefinition of `ATTR_SCANF_1' /Users/adriaan/gpcx/gcc/builtin-attrs.def:100: `ATTR_SCANF_1' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:101: redefinition of `ATTR_FORMAT_SCANF_1' /Users/adriaan/gpcx/gcc/builtin-attrs.def:100: `ATTR_FORMAT_SCANF_1' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:103: redefinition of `ATTR_SCANF_2' /Users/adriaan/gpcx/gcc/builtin-attrs.def:102: `ATTR_SCANF_2' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:103: redefinition of `ATTR_FORMAT_SCANF_2' /Users/adriaan/gpcx/gcc/builtin-attrs.def:102: `ATTR_FORMAT_SCANF_2' previously defined here /Users/adriaan/gpcx/gcc/builtin-attrs.def:170:3: warning: style of line directive is a GCC extension /Users/adriaan/gpcx/gcc/c-common.c:4225:3: warning: style of line directive is a GCC extension In file included from /Users/adriaan/gpcx/gcc/c-common.c:4225: /Users/adriaan/gpcx/gcc/builtin-attrs.def:2:3: warning: style of line directive is a GCC extension In file included from /Users/adriaan/gpcx/gcc/c-common.c:4225: /Users/adriaan/gpcx/gcc/builtin-attrs.def: In function `c_init_attributes': /Users/adriaan/gpcx/gcc/builtin-attrs.def:94: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:94: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:95: parse error before "_2" /Users/adriaan/gpcx/gcc/builtin-attrs.def:95: parse error before "_2" /Users/adriaan/gpcx/gcc/builtin-attrs.def:96: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:96: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:97: parse error before "_3" /Users/adriaan/gpcx/gcc/builtin-attrs.def:97: parse error before "_3" /Users/adriaan/gpcx/gcc/builtin-attrs.def:98: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:98: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:99: parse error before "_4" /Users/adriaan/gpcx/gcc/builtin-attrs.def:99: parse error before "_4" /Users/adriaan/gpcx/gcc/builtin-attrs.def:100: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:100: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:101: parse error before "_2" /Users/adriaan/gpcx/gcc/builtin-attrs.def:101: parse error before "_2" /Users/adriaan/gpcx/gcc/builtin-attrs.def:102: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:102: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:103: parse error before "_3" /Users/adriaan/gpcx/gcc/builtin-attrs.def:103: parse error before "_3" /Users/adriaan/gpcx/gcc/builtin-attrs.def:104: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:104: parse error before "_0" /Users/adriaan/gpcx/gcc/builtin-attrs.def:105: parse error before "_4" /Users/adriaan/gpcx/gcc/builtin-attrs.def:105: parse error before "_4" /Users/adriaan/gpcx/gcc/builtin-attrs.def:170:3: warning: style of line directive is a GCC extension /Users/adriaan/gpcx/gcc/c-common.c:4254:3: warning: style of line directive is a GCC extension In file included from /Users/adriaan/gpcx/gcc/c-common.c:4254: /Users/adriaan/gpcx/gcc/builtin-attrs.def:2:3: warning: style of line directive is a GCC extension In file included from /Users/adriaan/gpcx/gcc/c-common.c:4254: /Users/adriaan/gpcx/gcc/builtin-attrs.def: In function `c_common_insert_default_attributes': /Users/adriaan/gpcx/gcc/builtin-attrs.def:126: `ATTR_FORMAT_PRINTF_1_2' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:126: (Each undeclared identifier is reported only once /Users/adriaan/gpcx/gcc/builtin-attrs.def:126: for each function it appears in.) /Users/adriaan/gpcx/gcc/builtin-attrs.def:127: `ATTR_FORMAT_PRINTF_2_3' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:136: `ATTR_FORMAT_SCANF_1_2' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:137: `ATTR_FORMAT_SCANF_2_3' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:139: `ATTR_FORMAT_PRINTF_1_0' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:140: `ATTR_FORMAT_PRINTF_2_0' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:142: `ATTR_FORMAT_STRFTIME_3_0' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:150: `ATTR_FORMAT_PRINTF_3_4' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:151: `ATTR_FORMAT_PRINTF_3_0' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:152: `ATTR_FORMAT_SCANF_1_0' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:153: `ATTR_FORMAT_SCANF_2_0' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:166: `ATTR_FORMAT_STRFMON_3_4' undeclared (first use in this function) /Users/adriaan/gpcx/gcc/builtin-attrs.def:170:3: warning: style of line directive is a GCC extension make[1]: *** [c-common.o] Error 1 make: *** [all-gcc] Error 2 P r o b l e m 3 A stament in the file stmt.c" causes problems. /Users/adriaan/gpcx/gcc/stmt.c:5170:21: attempt to use poisoned "calloc" The C source reads: if (size > 0 && size < 600000 /* We deliberately use calloc here, not cmalloc, so that we can suppress this optimization if we don't have enough memory rather than aborting, as xmalloc would do. */ && (cases_seen = (unsigned char *) really_call_calloc (bytes_needed, 1)) != NULL) Being a C ignoramus, I changed "really_call_calloc" into "xcalloc" (to at least continue the build process). P r o b l e m 4 The next problem seems to be GPC related. I guess that the GPC experts will be able to help here. The build process ends with the statement: cpp-precomp: could not open 'RTS_VERSION_CHECK="__GPC_RTS_VERSION_20021128__"' gcc -o p/util.o -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -I. -Ip -I/Users/adriaan/gpcx/gcc -I/Users/adriaan/gpcx/gcc/p -I/Users/adriaan/gpcx/gcc/config -I/Users/adriaan/gpcx/gcc/../include -DGPC -I/Users/adriaan/gpcx/gcc/p -D RTS_VERSION_CHECK="\"__GPC_RTS_VERSION_`cat /Users/adriaan/gpcx/gcc/p/rts/rts-version`__\"" /Users/adriaan/gpcx/gcc/p/util.c cpp-precomp: could not open 'RTS_VERSION_CHECK="__GPC_RTS_VERSION_20021128__"' make[1]: *** [p/util.o] Error 1 make: *** [all-gcc] Error 2 I can send in more information, make and configure files, etcetera. Regards, Adriaan van Os

2 8

[beebe@math.utah.edu: Re: Typos in gpc-20021111/p/doc/en/*.texi]
by Anja Gerwinski 31 Dec '02

31 Dec '02

Hello, this is one of the non-spam postings that got delayed. As I am not sure who is taking care of the .texi documentation, I am forwarding it to the list. Best wishes, Anja ----- Forwarded message from "Nelson H. F. Beebe" <beebe(a)math.utah.edu> ----- Date: Fri, 27 Dec 2002 09:54:18 -0700 (MST) From: "Nelson H. F. Beebe" <beebe(a)math.utah.edu> To: Anja Gerwinski <anja(a)44615166.theo-phys.uni-essen.de> Cc: beebe(a)math.utah.edu X-US-Mail: "Center for Scientific Computing, Department of Mathematics, 110 LCB, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 585 1640, +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: Typos in gpc-20021111/p/doc/en/*.texi Thanks for the reponse about my postings to the GNU Pascal list. They report minor typos in the manuals. Copies are attached below: they probably only need to go to a single person who can make the corrections and update the archive; the whole gpc list need not be bothered with them. --------------- 1) 19-Dec "Nelson H. F Typos in gpc-20021111/p/doc/en/* (3401 chars) 2) 19-Dec "Nelson H. F Another typo: gpc-20021111/p/doc (1676 chars) Date: Thu, 19 Dec 2002 07:22:47 -0700 (MST) From: "Nelson H. F. Beebe" <beebe(a)math.utah.edu> To: gpc(a)gnu.de Cc: beebe(a)math.utah.edu Subject: Typos in gpc-20021111/p/doc/en/*.texi While browsing the info node for gpc from the gpc-20021111 release, I noted some typos (spelling and doubled words) in p/doc/en: unsing -> unsign orientate -> orient % egrep -n 'unsing|orientate' `find en -type f` internals.texi:385:object-orientated programming languages yet, a lot of effort has programming.texi:33:* OOP:: How object-orientated programming is implemented. programming.texi:1464:@item @t{MedInt} @tab @t{MedCard} @tab @t{MedWord} @tab @t{[unsinged] long int} @tab @t{32} programming.texi:1465:@item @t{LongInt} @tab @t{LongCard} @tab @t{LongWord} @tab @t{[unsinged] long long int} @tab @t{64} programming.texi:1489:and unsinged integer types. The type programming.texi:3287:@cindex object-orientated programming reference.texi:6860:ISO Pascal does not support Object-orientated programming. There Doubled words errors: gpcs.texi:1861: WriteLn ('Is is a spider?') ^^---should be "it" install.texi:357:To install a ZIP archive under DOS with @samp{PKunzip}, @samp{cd} the install.texi:358:the appropriate directory (usually @samp{\} for EMX, @samp{\DJGPP} for ^^^^---- delete this word reference.texi:2765:omitted, the sub-string will will range to the end of @var{S}. ^^^^----delete reference.texi:3764:@samp{Extend} is an ISO 10206 Extended extension. Borland Pascal reference.texi:3765:Pascal has @ref{Append} instead. ^^^^^^^----delete reference.texi:9598:@samp{Word}. On most platforms it is 16 bits wide and thus has a range of reference.texi:9599:of @samp{0..65535}. It is the same as @ref{ShortCard}. ^^^----delete reference.texi:10299:omitted, the sub-string will will range to the end of @var{S}. ^^^^----delete Date: Thu, 19 Dec 2002 12:14:11 -0700 (MST) From: "Nelson H. F. Beebe" <beebe(a)math.utah.edu> To: gpc(a)gnu.de Cc: beebe(a)math.utah.edu Subject: Another typo: gpc-20021111/p/doc/en/gpcs.texi In gpc-20021111/p/doc/en/gpcs.texi: gpcs.texi:191:The are times when you deal with large packages and you can't easily ^^^^---- Should be "There" ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe(a)math.utah.edu - - Department of Mathematics, 110 LCB beebe(a)acm.org beebe(a)computer.org - - 155 S 1400 E RM 233 beebe(a)ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ------------------------------------------------------------------------------- ----- End forwarded message -----

2 1

Questions about gpc syntax
by Artur Bac 29 Dec '02

29 Dec '02

Hello I've got few questions because I'm working on some C library port to GNU GPC. On the assumption that best reasult will be maintained if 1) There will not be any unit file but only original include files with orignal tree structure {$ifndef __NAME__} {$define __NAME__} {$include <sothing.inc>} works perfectly with GPC and also -llibname -L/usr/lib/.... -I/usr/include...... too 2) all macro definitions will be converted to macro definitions NOT to wrpaer functions to avoid not neccesery function jumps in generated code 3) all inlines, functions implemented in interface of headers will be keeped as they are without any new function wrappers all this as mentioned before i did but i found one thing strange for me Why this don't work : we've got an pointer array inside a redord field type ppointer = ^pointer; type our_rec = packed record ptr_data : ppointer; end; var some_array : ^our_rec; needed_pointer : pointer; imagine we got an array of pointers and some_array^.ptr_data points at this array when i try to acces elements in that way as it is in C ,freepascal needed_pointer := some_array^.ptr_data[2]^ {3rd element , pointer in array} i got an error something like '...trying to acces an array on somthing is not an array ...' BUT this works needed_pointer := (some_array^.ptr_data+2)^ In GPC manual http://www.gnu-pascal.de/gpc_120.html#SEC120 there is written GPC allows to increment, decrement, compare, and subtract pointers or to use them in `for' loops just like the C language. a: array [1 .. 7] of Char; p, q: ^Char; .......... for p := @A[1] Isn't nearly the same as my example ? Maybe this is a problem of latest snapshot of gpc i use with GCC 3.2.1 ? 20021128, based on gcc-3.2.1 Second problem I got in C function like that with variable number of arguments type name (arg,arg, ....) so i implemented it as function name (arg;arg; var add_arg_) : type But i can pass only one aditional argument Is possible to implement variable number of arguments for functions ? Or maybe i have to overload it with 2 or more similar functions ? but the way is function overloading allowed in GNU Gpc ? 3rd Question any ideas how to implement C++ library with classes inside ? PS: GPC is going to be the best Objective Pascal compiler .... Sincerelly Artur Bać

2 3

problems installing gnu pascal
by Frank Thomas Braun 27 Dec '02

27 Dec '02

I am using the PC version (DJGPP, MingWin) of the gcc (MS-DOS, Windows 95/NT/XP) for several years in lectures and for programming purposes. Never I found any severe problem or error. Formerly I wrote many Pascal programs and I would like to install a version of the GPC compiler to be able to recompile these program for Win32. I never was successful to complete this installation. After the recent installation of gcc 3.20 I found a new copy of gpc on the Simtel mirrors and tried another gpc installation. Download and unzipping of gpc together with gcc/djgpp (version gpc2953b.zip, 13.5.2002) produced a startable installation of gpc (the gpc command is working when either typing "gpc" alone or "gpc --verbose"), but I am not able to compile any program. ( "gpc lix.pas" results in the error message "gpcpp.exe: djgpp.ver: No such file or directory (ENOENT)", see attachment x.x or more verbose x.a) ). In a second try I fetched gpc directly from the site http://www.gnu-pascal.de/ in the file gpc-2.1.i586-pc-msdosdjgpp.zip. Installing this file together with the necessary gcc tools results in the same problem as above. (see attachment x.y and inst-p.bat) What is the reason of the error message gpcpp.exe: djgpp.ver: No such file or directory (ENOENT) By the way I didn't succeed to install gpc with MingWin too. Compiling programs with "gpc lix.pas" results in "ld: cannot open crt2.o: No such file or directory" Could you please kindly help me solving the problem? Yours sincerely Frank Braun PS: Yes I read readme, news, install, faq, and bugs. Yes I wrote a similar gpc section like the gcc section in djgpp.env: ( [gpc] COMPILER_PATH=%/>;COMPILER_PATH%%DJDIR%/bin LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib;%DJDIR%/contrib/grx20/ lib ) res. ( [gcc] LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib [gpc] LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib ) Yes I tried getting the right files but the files mentioned in the documentation are sometimes no longer available. In these cases I used the next higher version or alternativly the newest version. i.e.: http://www.gnu-pascal.de/gpc_20.html says `v2/djdev203.zip' (C library) `v2gnu/bnu2951b.zip' (assembler, ...) `v2gnu/gcc2952b.zip' (gcc) `v2gnu/gdb418b.zip' (debugger) `v2gnu/mak379b.zip' (make) `v2gnu/txi40b.zip' The file install. says: - the C library, `v2/djdev201.zip', and - `binutils' (assembler, etc.), `v2gnu/bnu270b.zip'. I tried both djdev201/203. bnu2951b/270b is not available so I used bnu213b Frank Braun Rechenzentrum Universitaetsstrasse 31 D-93053 Regensburg Germany Tel.: +49-941-943-4891 email: frank.braun(a)rz.uni-regensburg.de d:\PRIVAT\BILANZ\PROGRAM>gpc -v x.pas Using builtin specs. gpc version 2.1 (20020510), based on 2.95.3 20010315/djgpp (release) d:/djgpp/lib/gcc-lib/djgpp/2.953/gpcpp.exe -lang-pascal -v -famtmpfile=d:/djgpp /tmp\ccaaaaaa -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MI NOR__=95 -D__GPC__=2 -D__GPC_MINOR__=1 -D__GPC_VERSION__=2.1 -D__GPC_RELEASE__=2 0020510 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -Dunix -Di386 -DGO32 -DDJGPP=2 -DMSDOS -D__ OS_DOS__=1 -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 -D__MSDOS__ -D__OS_DOS __=1 -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asystem(unix) -Asystem(ms dos) -Acpu(i386) -Amachine(i386) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D_ _i386__ -D__tune_pentium__ -imacros djgpp.ver -remap x.pas d:/djgpp/tmp\cc6uaS61 .i GNU Pascal Compiler PreProcessor version 2.1 (20020510), based on gcc-2.95.3 200 10315/djgpp (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: d:/djgpp/lang/pascal d:/djgpp/include /usr/local/include d:/djgpp/i586-pc-msdosdjgpp/include d:/djgpp/lib/gcc-lib/djgpp/2.953/include d:/djgpp/include End of search list. gpcpp.exe: djgpp.ver: No such file or directory (ENOENT) d:\PRIVAT\BILANZ\PROGRAM>gpc GNU Pascal version 2.1 (20020510), based on gcc-2.95.3 20010315/djgpp (release). Copyright (C) 1987-2002 Free Software Foundation, Inc. GNU Pascal 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, or (at your option) any later version. GNU Pascal 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. For more version information on components of the GNU Pascal compiler, especially useful when reporting bugs, type the command `gpc.exe --verbose'. Most used command line options: -c Compile or assemble the source files, but do not link. -o FILE Place output in file FILE. --automake Automatically (re)compile modules/units. -v Be verbose. The command line options are described in the online documentation. `info -f gpc invoking' describes them in detail. Report bugs to <gpc(a)gnu.de>. d:\PRIVAT\BILANZ\PROGRAM>gpc x.pas >x.y gpcpp.exe: djgpp.ver: No such file or directory (ENOENT) d:\PRIVAT\BILANZ\PROGRAM>gpc GNU Pascal version 2.1 (20020510), based on gcc-2.95.3 20010315/djgpp (release). Copyright (C) 1987-2002 Free Software Foundation, Inc. GNU Pascal 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, or (at your option) any later version. GNU Pascal 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. For more version information on components of the GNU Pascal compiler, especially useful when reporting bugs, type the command `gpc.exe --verbose'. Most used command line options: -c Compile or assemble the source files, but do not link. -o FILE Place output in file FILE. --automake Automatically (re)compile modules/units. -v Be verbose. The command line options are described in the online documentation. `info -f gpc invoking' describes them in detail. Report bugs to <gpc(a)gnu.de>. d:\PRIVAT\BILANZ\PROGRAM>gpc x.pas gpcpp.exe: djgpp.ver: No such file or directory (ENOENT) call un-inst rem unzip32 gpc2953b.zip < d:\djgpp\a.a rem unzip32 djdev201.zip < d:\djgpp\a.a unzip32 gpc-2.1.i586-pc-msdosdjgpp.zip < d:\djgpp\a.a unzip32 djdev201.zip < d:\djgpp\a.a unzip32 bnu213b.zip < d:\djgpp\a.a unzip32 gcc2952b.zip < d:\djgpp\a.a unzip32 gdb418b.zip < d:\djgpp\a.a unzip32 mak3791b.zip < d:\djgpp\a.a unzip32 txi40b.zip < d:\djgpp\a.a unzip32 mak3791b.zip < d:\djgpp\a.a

2 1

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 December 2002