- Gpc - gnu.de

Re: Protected parameters (Was: Some bug reports - and success report)
by Frank Heckenbach 04 Mar '97

04 Mar '97

Peter Gerwinski wrote: > According to Frank Heckenbach: > > Just wondering - what's the difference between "Const" and "Protected" > > parameters? Are they only handled differently internally in the compiler, > > or is there any semantic difference? > > `Protected' is a "modifier" which can be used with or without `Var' > in formal parameters. `Const' parameters are the same as `protected > Var' parameters Does that mean that protected (not protected var) parameters are passed by value? Especially in the case of large structures, can this be inefficient, taking up stack space and consuming time to copy the arguments? Since protected parameters are read-only anyway, actually I see no need to distinguish between passing them by value or by reference. Of course, it would be best if the compiler could automatically choose the more efficient way of passing (i.e. small structures by value, and large ones by reference), no matter if declared as "protected", "protected var" or "const". Or does the standard prescribe something different? Also, defining "Const" as "protected Var" is not completely compatible to BP, since in BP you can pass a calculated expression, not only an "lvalue" as a const parameter. But of course, these are no urgent issues, as long as one form of protected/const parameters works at all... :-) Frank -- 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: Some bug reports - and success report
by Peter Gerwinski 28 Feb '97

28 Feb '97

According to Frank Heckenbach: > Just wondering - what's the difference between "Const" and "Protected" > parameters? Are they only handled differently internally in the compiler, > or is there any semantic difference? `Protected' is a "modifier" which can be used with or without `Var' in formal parameters. `Const' parameters are the same as `protected Var' parameters, thus `protected Var' also yields a workaround for the "`protected' in GPI files" bug. > Another set problem is the following: > [...] > Again, more or less random values. It's probably another instance of the > problem with initialized set variables - I just wanted to mention it. I am adding this to ... you know. Thanks again! > But after I could work around this, too, now my program compiles and runs with > gpc for the first time! :-) And a whole lot faster than compiled with BP! :-) :-) :-) 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 - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Some bug reports - and success report
by Frank Heckenbach 27 Feb '97

27 Feb '97

> > > (And redirection is not easy with DJGPP anyway.) > > Why? The only problem I know of is that Command.Com can't redirect stdout. > You mean: `stderr'. Yes, of course. > > But that's merely a problem of Dos' shell, and is solved by the REDIR > > utility. Otherwise it works fine for me. Or are there any other problems? > That's what I meant with "not easy": you need `REDIR' to redirect `stderr'. Well, at least there is such a utility. If that was the biggest problem with Command.Com, it would be great... :-( > Yes. :-( It's a known bug in the GPI mechanism that pointer types > transported through a GPI file aren't compatible with themselves. > > To work around, patch your gpc-decl.c (or wait for the next alpha), > and use `Const' :-P instead fo `Protected'. Then you will get some > warnings, but the code will work. Just wondering - what's the difference between "Const" and "Protected" parameters? Are they only handled differently internally in the compiler, or is there any semantic difference? Another set problem is the following: PROGRAM x; TYPE IByte=__byte__ Integer; Byte=__unsigned__ IByte; TS=SET OF Byte; PROCEDURE p(s:TS); VAR k:Integer; BEGIN FOR k:=0 TO $FF DO IF k IN s THEN Write(k) END; BEGIN p([]) END. Again, more or less random values. It's probably another instance of the problem with initialized set variables - I just wanted to mention it. But after I could work around this, too, now my program compiles and runs with gpc for the first time! :-) And a whole lot faster than compiled with BP! :-) Frank

1 0

First bugs in gpc-970226 ...
by Peter Gerwinski 27 Feb '97

27 Feb '97

Hello again, sorry, but I overlooked a small, but severe bug in gpc-970226 which made in impossible to redefine built-in identifiers like "Byte" or "Assign" in Units - which is especially annoying because GPC does define, but not yet implement "Assign", so you *must* redefine it. As a side-effect, another bug vanished, too: Unexported functions were visible in the whole file. Now they have the correct scope. (: Yes, I know how this is related to redefinitions of built-in identifiers. ;) And there was another bug preventing us to initialize variables of a type which has been previously declared to be "Char" in a Unit or Module. (Weird, eh?:-) Below is the patch to make it all work; it's on agnes as well. I will upload new binaries this evening, about 23:00 MET. Till the next bug fix, Peter 8< ----------------------------------------------------------------------- --- gpc-970226/gpc-module.c Thu Feb 27 11:34:07 1997 +++ gpc/gpc-module.c Thu Feb 27 11:11:48 1997 @@ -1120,10 +1120,10 @@ store_flags (t, s); if (depth == 0) { - if (IDENTIFIER_GLOBAL_VALUE (t)) - store_tree (IDENTIFIER_GLOBAL_VALUE (t), s, depth + 1); - else if (IDENTIFIER_LOCAL_VALUE (t)) + if (IDENTIFIER_LOCAL_VALUE (t)) store_tree (IDENTIFIER_LOCAL_VALUE (t), s, depth + 1); + else if (IDENTIFIER_GLOBAL_VALUE (t)) + store_tree (IDENTIFIER_GLOBAL_VALUE (t), s, depth + 1); else store_tree (IDENTIFIER_LIMBO_VALUE (t), s, depth + 1); } @@ -1388,7 +1388,7 @@ t = get_identifier (id); load_flags (t, s); if (depth == 0) - IDENTIFIER_GLOBAL_VALUE (t) = load_tree (s, depth + 1); + IDENTIFIER_LOCAL_VALUE (t) = load_tree (s, depth + 1); break; } --- gpc-970226/gpc-typeck.c Thu Feb 27 11:34:07 1997 +++ gpc/gpc-typeck.c Thu Feb 27 11:26:33 1997 @@ -5811,6 +5811,9 @@ /* Handle scalar types, including conversions. */ if (code == INTEGER_TYPE || code == REAL_TYPE || code == POINTER_TYPE +#ifdef GPC + || code == CHAR_TYPE +#endif || code == ENUMERAL_TYPE || code == COMPLEX_TYPE) { /* Note that convert_for_assignment calls default_conversion

1 0

New Alpha
by Peter Gerwinski 27 Feb '97

27 Feb '97

Hello, everybody! The next alpha release, gpc-970226, is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/. This time I also provide binaries for FreeBSD - besides binaries for DOS (DJGPP) and Linux (ELF) - because there were many modifications in GPC's Extended Pascal sections. ;-) Changes since gpc-970221: * First Delphi extension: allow an optional source file name (a String constant) with `uses': Program Foo; uses MyUnit in 'my_pretty_unit.pas'; ... * The documentation now describes how `--standard-pascal', `--extended-pascal', `--borland-pascal', etc. work. There were more changes in the documentation, especially in the "Borland Pascal" chapter. * `Absolute' now works with initialized Strings, too. (Was a well-hidden bug.) * Sets of enumeral types work again. (This was broken in gpc-970215.) * Extended Pascal Modules: Now each module "foo" produces a file "foo.gpm" (GNU Pascal Module) which contains the names of the exported Interfaces, so an Implementation Module residing in a separate file can locate the GPI files. * Do not crash when an array TYPE instead of an array is passed as a `Var' parameter ... :-) * `Const' parameters (Borland Pascal) - same as `Protected Var' parameters (Extended Pascal) - work. * Initialize arrays of Strings correctly. * Extended Pascal initializers: They do not yet work in all cases, but at least in some now. Beware: array indices and record field names are not checked at all; it is assumed that they are in order without "holes". (The same problem holds for record field names with Borland Pascal initializers.) * Initialized Sets still don't work. Sorry. * Modules (Extended Pascal) and Units (Borland Pascal) which are in the same file as the main program do not any more export everything. Now they just export the exported stuff ... well almost. Functions are still exported even if you don't want to export them, but you get a warning. Beware: Since all export is done through GPM and GPI files, this disables the workaround to put everything into one file in case the GPI mechanism fails. This means that GPI *must* become stable now ... * `--automake' won't any more enter an infinite loop when it detects that the module to be recompiled is in the current file. * Virtual Methods and Constructors now survive transport through a GPI file. * Make the option `-x pascal' work. * Subrange specifications like array indices did not work in all situation. Now they do. I'd like to thank Larry Carter, Stefan A. Deutscher, Berend de Boeur, Pat Sharp, and Frank Heckenbach for useful hints, bug reports and very helpful example programs. I am keeping all example programs in a "GPC test suite" to ensure that reported bugs won't recur and implemented new features don't break. :-) 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 - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Some bug reports
by Peter Gerwinski 26 Feb '97

26 Feb '97

According to Frank Heckenbach: > Yes, I'm using DJGPP - sorry I forgot to mention. It seems redirection is > turned off by default even without the BPcompat package. This was confusing > me. I don't use Crt in my program, so I didn't think of DirectVideo. Now when > I copy the declaration of DirectVideo from Crt (I don't want to use the > whole unit in this program), it works. Sorry for that inconvenience; now `libgpc.a' will get "DirectVideo = false" by default. > I guess redirection is turned off by default because the usual output via > Dos is quite slow!? No, it was just a bug in the patched `libgpc.a'. (The unpatched version of `libgpc.a' from the gpc-2.0 distribution should work.) > > (And redirection is not easy with DJGPP anyway.) > > Why? The only problem I know of is that Command.Com can't redirect stdout. You mean: `stderr'. > But that's merely a problem of Dos' shell, and is solved by the REDIR > utility. Otherwise it works fine for me. Or are there any other problems? That's what I meant with "not easy": you need `REDIR' to redirect `stderr'. > 3. > Yes, I know. Actually I'm using now: > CONST MaxVar=$FFF0; > TYPE XArray=ARRAY[1..MaxVar {$IFDEF TP} DIV SizeOf(X) {$ENDIF}] OF X; The bug is fixed for the next alpha release. If you want the patch now, here is the diff for gpc-parse.y: if (PEDANTIC (E_O_PASCAL) && (! TREE_CONSTANT ($3) || ! TREE_CONSTANT ($1))) pedwarn ("ISO 7185 Pascal does not allow non-constant range bounds"); - if (TREE_TYPE ($1) != TREE_TYPE ($3)) + if (TREE_TYPE ($1) == TREE_TYPE ($3) + || (TREE_CODE (TREE_TYPE ($1)) == INTEGER_TYPE + && TREE_CODE (TREE_TYPE ($3)) == INTEGER_TYPE)) + $$ = build_range_type (TREE_TYPE ($1), $1, $3); + else { error ("subrange bounds are not of the same type"); $$ = error_mark_node; } - else - /* @@@ Changed in 2.4.3.1 */ - $$ = build_range_type (TREE_TYPE ($1), $1, $3); } ; > 6. > > > Is there anything like TP's Exit (return from current procedure/function)? > > > I couldn't find it in the docs. `Return'. In the alpha versions, `Exit' works, too. > 4. > {$DEFINE Const PROTECTED} > [...] > PROCEDURE p(Const c:t); That bug is fixed as well. Here is the diff for gpc-util.c: } else { + if (varparm && type != error_mark_node) + type = build_reference_type (type); + /* If this is a protected parameter, make it read-only */ if (protected) type = build_type_variant (type, 1, 0); - if (varparm && type != error_mark_node) - type = build_reference_type (type); - type = build_tree_list (NULL_TREE, type); for (link = idlist; link; link = TREE_CHAIN(link)) > 7. > ...but this led me to another problem. It seems more involved (perhaps > something about GPI files?). Yes. :-( It's a known bug in the GPI mechanism that pointer types transported through a GPI file aren't compatible with themselves. > gpc complains about > line {}: incompatible type for argument 1 of `F' To work around, patch your gpc-decl.c (or wait for the next alpha), and use `Const' :-P instead fo `Protected'. Then you will get some warnings, but the code will work. 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 - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Some bug reports
by Frank Heckenbach 26 Feb '97

26 Feb '97

Peter Gerwinski wrote: 1. > > The output of a compiler program is not redirectable (neither as stdout, > > nor stderr). > > Hmmm ... I am redirecting stderr all the time ... what OS are you using? > With DJGPP and the BPcompat package, redirection is turned off when > DirectVideo is `true'. Yes, I'm using DJGPP - sorry I forgot to mention. It seems redirection is turned off by default even without the BPcompat package. This was confusing me. I don't use Crt in my program, so I didn't think of DirectVideo. Now when I copy the declaration of DirectVideo from Crt (I don't want to use the whole unit in this program), it works. I guess redirection is turned off by default because the usual output via Dos is quite slow!? > (And redirection is not easy with DJGPP anyway.) Why? The only problem I know of is that Command.Com can't redirect stdout. But that's merely a problem of Dos' shell, and is solved by the REDIR utility. Otherwise it works fine for me. Or are there any other problems? 3. > Okay. I am adding it to my bug list. Thanks. :-) > > Workaround: GPC has no problems to deal with structures above 65520 bytes. > [...] Yes, I know. Actually I'm using now: CONST MaxVar=$FFF0; TYPE XArray=ARRAY[1..MaxVar {$IFDEF TP} DIV SizeOf(X) {$ENDIF}] OF X; I'm just hoping to reduce the number of IFDEFs required to get the program working on both TP and gpc. 6. > > Is there anything like TP's Exit (return from current procedure/function)? > > I couldn't find it in the docs. > > Return. Thanks! I really could have guessed that myself... 4. Berend de Boer wrote: > > PROCEDURE p(CONST c:t) > > This is BP, try the EP standard > > PROCEDURE p(protected c:t) > > as a workaround. Yes, that works. Thanks! With the help of the preprocessor (luckily it's case-sensitve!), I can even write the following code that compiles with TP and gpc: {$DEFINE Const PROTECTED} CONST a=1; PROCEDURE p(Const c:t); 7. ...but this led me to another problem. It seems more involved (perhaps something about GPI files?). I couldn't simplify the example more than the following, especially there has to be a unit, r must be a record (at least with r=Integer the bug doesn't show), and p has to be protected: UNIT u; INTERFACE TYPE r=RECORD a:Integer END; PROCEDURE f(PROTECTED p:r); IMPLEMENTATION PROCEDURE f(PROTECTED p:r); BEGIN END; END. PROGRAM x; USES u; VAR p:r; BEGIN f(p) {} END. gpc complains about line {}: incompatible type for argument 1 of `F' Frank

1 0

Re: Some bug reports
by Peter Gerwinski 25 Feb '97

25 Feb '97

Hallo, Frank; hello, everybody! According to Frank Heckenbach: > 1. > The output of a compiler program is not redirectable (neither as stdout, > nor stderr). Hmmm ... I am redirecting stderr all the time ... what OS are you using? With DJGPP and the BPcompat package, redirection is turned off when DirectVideo is `true'. (And redirection is not easy with DJGPP anyway.) It works fine on my Linux box. > 2. > Writeln('a','':5,'b'); > I think it should write "a b", but it just writes "ab". Okay. I am adding it to my bug list. Thanks. > 3. > My standard way for "variable size arrays" in BP doesn't work in gpc: > > PROGRAM t; > > CONST MaxVar=$FFF0; > > TYPE > X=Integer; > > XArray=ARRAY[1..MaxVar DIV SizeOf(X)] OF X; {} > > BEGIN > END. > > [...] Okay. I am adding it to my bug list. Thanks. :-) Workaround: GPC has no problems to deal with structures above 65520 bytes. (It has a 4GB limit instead.) So you can just write: Const MaxVar = 1000000; (* large random number *) Type X = Integer; XArray = array [ 1..MaxVar ] of X; > 4. > [...] Okay. I am ... etc. :-) > (I could provide all the register values if necessary.) That's not necessary. I have the example program, so I will be able to reproduce the bug. (I hope at least.) Also thanks for the detailed description in which situations the bug occurs. :-) > 5. (See above.:-) > 6. > Last but not least: > Is there anything like TP's Exit (return from current procedure/function)? > I couldn't find it in the docs. Return. But I am planning to support `Exit' as an alternative to it. 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 - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: Some bug reports
by Berend de Boer 25 Feb '97

25 Feb '97

> 1. The output of a compiler program is not redirectable (neither as stdout, > nor stderr). Which platform do you use? It works correctly on FreeBSD. > 2. Writeln('a','':5,'b'); > I think it should write "a b", but it just writes "ab". Correct. > 3. My standard way for "variable size arrays" in BP doesn't work in gpc: gpc doesn't have such limits, but your example should work. > 4. Problem with CONST parameters: > PROCEDURE p(CONST c:t) This is BP, try the EP standard PROCEDURE p(protected c:t) as a workaround. > 5. Initialized set variables don't seem to work: Known bug. > 6. Last but not least: > Is there anything like TP's Exit (return from current procedure/function)? A goto with an explicit label. Groetjes, Berend.

1 0

Some bug reports
by Frank Heckenbach 25 Feb '97

25 Feb '97

Hi everyone! I've got a number of bug reports. Perhaps some of them are already known, but I didn't find any information about them. I'm listing all the problems I encountered when I ported a BP program to gpc. The bugs were tested with 2.0, and "verified" with 970221. 1. The output of a compiler program is not redirectable (neither as stdout, nor stderr). 2. Writeln('a','':5,'b'); I think it should write "a b", but it just writes "ab". 3. My standard way for "variable size arrays" in BP doesn't work in gpc: PROGRAM t; CONST MaxVar=$FFF0; TYPE X=Integer; XArray=ARRAY[1..MaxVar DIV SizeOf(X)] OF X; {} BEGIN END. The error message for the line "{}" is: subrange bounds are not of the same type ordinal type expected It doesn't depend on the type of X, and it doesn't help to declare a constant with value MaxVar DIV SizeOf(X). 4. Problem with CONST parameters: PROGRAM x; TYPE t=ARRAY[1..1] OF Integer; PROCEDURE p(CONST c:t); BEGIN IF c[1]=0 THEN END; BEGIN END. gpc crashes with: Exiting due to signal SIGSEGV Page fault at... (I could provide all the register values if necessary.) It doesn't matter if I invoce it as gpc x.p or gpc -o x x.p or gpc -c x.p It doesn't seem to depend on the type of t (it must only be an array), and it doesn't matter if c[1] is accessed as above, or e.g. in a Write statement. 5. Initialized set variables don't seem to work: PROGRAM t; TYPE IByte=__byte__ Integer; Byte=__unsigned__ IByte; ByteSet=SET OF Byte; VAR m:ByteSet VALUE [1,2,3]; {"CONST ... = ..." gives the same result} k:Integer; {or k:Byte - the same} BEGIN { m:=[1,2,3]; ...then it works correctly } FOR k:=0 TO $FF DO IF k IN m THEN Write(Integer(k)) END. The numbers written are more or less random. 6. Last but not least: Is there anything like TP's Exit (return from current procedure/function)? I couldn't find it in the docs. Frank

1 0