February 2005 - Gpc

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

Passing by reference
by Adriaan van Os 06 Jun '05

06 Jun '05

Another problem, also reported on the macpascal mailing list and reproduced by the following program: [G5:gcc/p/test] adriaan% cat avo12.pas program avo12; type Str255 = record sLength: Byte; sChars: packed array[1..255] of char; end; function StringToStr255 ( const s: String ) = Result : Str255; begin Result.sLength := Min( Length( s ), 255 ); if Result.sLength > 0 then begin Result.sChars[1..Result.sLength] := s[1..Result.sLength]; end; end; procedure DrawString1( const s: Str255); external name 'DrawString'; procedure DrawString2( protected var s: Str255); external name 'DrawString'; begin DrawString1( StringToStr255( 'Hello')); {OK} DrawString2( StringToStr255( 'Hello')) {Error: reference expected, value given} end. [G5:gcc/p/test] adriaan% gpc avo12.pas avo12.pas: In main program: avo12.pas:19: error: reference expected, value given In gpc-20030830, this was no problem, but now it is no longer allowed, which is quite inconvenient. In the GPC interfaces for Mac OS X, we use the external declaration form with a "protected var" because (according to the gc docs) the "const" declaration form doesn't guarantuee that the parameter is passed by reference, which is an ABI requirement. Regards, Adriaan van Os

5 23

-mlong-double-128
by Adriaan van Os 13 May '05

13 May '05

The following produces an internal compiler error: [G4:~/gnu/testgpc/adriaan] adriaan% cat compare.pas program Compare; procedure R ( var r1, r2: real); begin if r1 <> r2 then r1:= r2 - 1.0 end; begin end. [G4:~/gnu/testgpc/adriaan] adriaan% gpc -o compare compare.pas -mlong-double-128 compare.pas: In procedure `R': compare.pas:6: error: unrecognizable insn: (insn 26 34 27 2 0x0 (set (reg:SI 126) (subreg:SI (reg:TF 33 f1) 0)) -1 (nil) (nil)) compare.pas:6: internal compiler error: in extract_insn, at recog.c:2175 It may be, of course, that the Darwin target doesn't properly support the -mlong-double-128 PowerPC processor option. If it's a gcc back-end bug, I can report it to Bugzilla. However, the "real" type used is 64-bit on the Darwin target, with or without -mlong-double-128 ... The option only changes the size of the "longreal" and "extended" types to 128-bit. Regards, Adriaan van Os [G4:~/gnu/testgpc/adriaan] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc33d7/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d7/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d7 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3

6 15

GPC ALPHA 20050217 released
by Frank Heckenbach 11 Mar '05

11 Mar '05

I have uploaded a new alpha version of GPC to <http://www.gnu-pascal.de/alpha/>. Important notes: - This is an ALPHA version, as discussed on the mailing list before. Not so many extensive tests have been made (though the test suite passes on my system). I'm not uploading binaries, diffs, separate test suite archives, updated web pages etc., just the source distribution. (Of course, others may feel free to upload binaries for various platforms.) I'm not aware of any serious bugs, but you have to decide for yourself whether to use it for production work. - Bison (building GPC) Bison version 2.0 has been released. It can be obtained at <ftp://ftp.gnu.org/gnu/bison/bison-2.0.tar.gz>. This is now the recommended version for all GPC compilations. Fortunately, we now don't depend on changing alpha/beta versions of bison anymore. Bison is required when building a minimal distribution of GPC (which now doesn't include the Bison generated files anymore, as it did temporarily); when building a full source distribution and not modifying the bison input files (*.y), bison is not strictly needed, but in case of doubt, it can't hurt to install the new bison version. New features: - Support for gcc-3.4.x (tested with 3.4.3) The caveats that apply to gcc-3.3.x (especially on Dos/Windows) also apply here. - Renamed options Due to the way that gcc-3.4.x handles options, we had to rename two options (command line and compiler directive, respectively). To avoid confusion, we did this for all backend versions: --no-default-paths -> --disable-default-paths --no-debug-info -> --disable-debug-info Note: `--disable-debug-info' is only used in very special cases, and usually as a compiler directive. To turn off debug info one would normally use `-g0' which remains unaffected. - Qualified identifiers (chief18.pas, fjf260*.pas, fjf921*.pas, grp1.pas, kurzw1.pas, mod{9,10,13..17}*.pas) GPC now supports qualified identifiers, both Extended Pascal and Borland Pascal style. A small incompatibility to previous versions arises when a declaration has the same name as an interface, which is not EP conformant, but GPC previously allowed. This will now cause compile-time errors. The solution is to rename either the interface or the declaration. The linker names, if not specified explicitly, are now completely different. Since those linker names should not be relied upon anyway, we hope this is no problem. If you get problems here, just add `name' attributes where necesssary. (This will also make the code more robust, in case the internal conventions ever change again.) - Importing within a routine (EP feature) works now. (mod15[c-e].pas) - Range checking (chuck5.pas, fjf446.pas, fjf989*.pas, fjf992*.pas, fsc{01..37}*.pas, miklos1[bc].pas, mir{016,021..028,030..047}*.pas, russ4*.pas) GPC now supports full range checking (previously it did so only for dynamic ranges and sets). Range checking is on by default (in all dialects) and can be turned off and on again by command-line arguments or compiler directives (`{$[no-]range-checking}' and also `{$R-}' and `{$R+}', BP compatible). Note, this is not overflow checking, which may be implemented later and will be a separate option, just like in BP. Range checking applies when a value of a larger type (e.g., an `Integer' variable or the result of an integer operation) is used in a place where a subrange is expected (e.g., an array index, or assignment to a variable with more limited range). Overflow checking would apply if the result of an arithmetic or other operation exceeds the representable values (e.g., `var a: Integer = MaxInt; [...] WriteLn (a + a)'). This is not yet checked. For input operations (`Read', `ReadLn', `ReadStr', `Val'), range checking errors are treated as I/O errors, so they can be trapped with `{$I-}' via `IOResult' (for `Read*'), or for `Val' via the 3rd parameter (while range errors in the 3rd parameter of `Val' itself are treated as regular runtime errors; this paramter is the error position, so range errors there can be avoided simply by declaring it of a sufficiently larger type, usually just `Integer' or `Cardinal'). For strings, range checking is BP compatible (access up to the capacity allowed) in `--borland-pascal' and `--delphi' modes and EP compatible (access only up to the current length allowed) otherwise. So in default (EP) mode code such as if MyString[1] = '-' ... without a check if (MyString <> '') and ... may now fail with a range-checking error. This is useful, since the first test was always undefined if `MyString' was empty, but in my experience so far, this has been one of the most common causes of range-checking errors in my code. The same applies with `var' parameters and the address operator as well, so e.g. code such as: BlockRead (f, StringLength, SizeOf (StringLength)); BlockRead (f, s[1], StringLength); SetLength (s, StringLength); needs two changes to be range safe now: BlockRead (f, StringLength, SizeOf (StringLength)); SetLength (s, StringLength); if StringLength > 0 then BlockRead (f, s[1], StringLength); Another example (rather low-level code, found e.g. in the RTS): BufPtr := PChars0 (@s[1]); BufSize := Length (s); will fail if `s' is empty. Possible change (provided the using code doesn't access `BufPtr' if `BufSize' is empty, which would be undefined anyway when reading): if s = '' then BufPtr := nil else BufPtr := PChars0 (@s[1]); BufSize := Length (s); - `pow', `Trim', `Card', set operations (`-', `*', `><'), set comparisons, string comparisons and array slices with constant arguments can now be used in constants (fjf998*.pas, fjf1000*.pas, fjf1009*.pas) - Initialized types in record and object fields and in schemata work now. (inirec[24].pas, fjf1016*.pas) - Types and initializers containing variable expressions, including schemata with non-constant discriminants work now. (couper[45].pas, fjf186.pas, fjf548.pas, fjf612a.pas, fjf997*.pas, fjf1003*.pas, john1a.pas) - With `-Wnested-comments' and without `--nested-comments' warn about comment openers found within comments. (fjf1017*.pas) - New options `--[no-]case-value-checking' (fjf1012*.pas) - Arithmetics with a complex and a real operand are now better optimized. (<20020118143553.B28837(a)artax.karlin.mff.cuni.cz>) - Bug fixes: * warn if an lhs cast decreases alignment (avo9.pas) * don't require result variables in forward declarations except in strict ISO mode (marku10*.pas) * writing to a file buffer at EOF didn't work (eof1.pas) * don't allow `f^' for unopened files `f' (pcerror[ij].pas) * evaluate initializers exactly as often as specified (fjf1019.pas) * in standard Pascal modes, `EOF' is false on an empty file (tom7.pas) * wrong `arithmetical overflow' with `set of byte' (igor1.pas) * `ParamStr' evaluated its argument twice (fjf963b.pas) * user-defined operators must not be applied to implicit operations (fjf991.pas and many other cases) 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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

11 86

Re: Bug? Delphi-style result variable
by Markus Gerwinski 09 Mar '05

09 Mar '05

Frank Heckenbach wrote: > Markus Gerwinski wrote: > > compiling the program > > > > Program Test; > > > > var > > x: integer; > > > > Function foo: integer; > > > > Procedure bar; > > begin (* bar *) > > result:= 7; > > end (* bar *); > > > > begin (* foo *) > > bar; > > end (* foo *); > > > > begin > > x:= foo; > > end. > > > > yields an error message > > > > test.pas: In procedure `bar': > > test.pas:14: error: invalid access to `Result' > > test.pas: In function `foo': > > test.pas:20: error: result of function not assigned > > > > Bug or feature? > An interesting case indeed. Since `Result' is a Delphi feature, we > probably should check if Delphi allows this, and if so do so as > well. I just tested with Delphi and found that `Result' behaves exactly like an implicitly defined local variable here. I.e. the sub-function of a function has its own `Result' that shadows the one of the enclosing function. A sub-procedure correctly accesses the `Result' of the enclosing function. > Notice, though, that if it does, it's somewhat confusing (if both > `foo' and `bar' are functions, one implicit `Result' probably > shadows the other -- please try this case with Delphi as well), and > error-prone (in your example, if you later decide to make `bar' a > function with an integer type result, the code would silently change > its meaning). Indeed. That is another advantage of the explicitly declared result variable. (At least if you, like me, prefer to avoid using the function name as a write-only identifier.) Frank, is there any chance to change gpc's behaviour back to the way I started this thread with? I know it would violate a standard, but in this case I think the standard makes less sense than the "unwanted feature" we had before. Yours, Markus ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

9 23

c library imports revisited
by Rick Engebretson 04 Mar '05

04 Mar '05

OK, I've updated gpc and begun to probe for "clarification." I'm glad an automated c-header translator is being discussed. The fpc people have such a tool and have translated libc. A terrific pascal development. One issue to consider is naming conflicts. Since dot qualified names seem to be a problem, perhaps prepending the c library name to the pascal name will avoid name conflicts. For example using the fpc unit "libc"; the libc function "close()" takes a file descriptor parameter, while the native pascal "close()" takes a file type parameter. Thus, the fpc libc "close()" is singled out and renamed in "unistdh.inc" to "__close()". (if memory serves me) Perhaps such a naming confusion can be avoided with all libc imports being named libc_name(). A libc unit for pascal is a big departure from the dos world. Other c-libs like OpenGL, etc. will follow. I really don't care about ISO-this or ISO-that. Pascal is an elegant language that should allow casual programmers to tap into the c-library platform without too many paw prints.

2 3

Internal compiler errors
by Adriaan van Os 01 Mar '05

01 Mar '05

An Internal compiler error has been reported on the macpascal mailing list, as reproduced by the following program: [G5:gcc/p/test] adriaan% cat avo10.pas program avo10; type UInt16 = cardinal attribute( size = 16); StyleItemGPC = (bold,italic,underline,outline,shadow,condense,extend); StyleParameter = UInt16; procedure TextFace(face: StyleParameter); external name 'TextFace'; begin TextFace( [bold, italic]); {internal compiler error} end. [G5:gcc/p/test] adriaan% gpc avo10.pas ../../gcc-3.4.3/gcc/p/typecheck.c:123:incomplete_type_error: failed assertion `0' avo10.pas: In main program: avo10.pas:8: error: Internal compiler error. Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://www.gnu-pascal.de/todo.html> for details. G5:gcc/p/test] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc343d7/lib/gcc/powerpc-apple-darwin7/3.4.3/specs Configured with: ../gcc-3.4.3/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc343d7 --target=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 Thread model: posix gpc version 20050217, based on gcc-3.4.3 Adding a typecast triggers another error: G5:gcc/p/test] adriaan% cat avo11.pas program avo11; type UInt16 = cardinal attribute( size = 16); StyleItemGPC = (bold,italic,underline,outline,shadow,condense,extend); StyleParameter = UInt16; procedure TextFace(face: StyleParameter); external name 'TextFace'; begin TextFace( StyleParameter( [bold, italic])); {internal compiler error} end. [G5:gcc/p/test] adriaan% gpc avo11.pas avo11.pas: In main program: avo11.pas:8: warning: cast to type of different size avo11.pas:8: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. with backtrace: Command: gpc1 Path: /Developer/Pascal/gpc343d7/libexec/gcc/powerpc-apple-darwin7/3.4.3/gpc1 Version: ??? (???) PID: 1333 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000038 Thread 0 Crashed: 0 gpc1 0x000c66d4 get_set_constructor_bits + 0x34 (tree.c:4654) 1 gpc1 0x000c693c get_set_constructor_bytes + 0x4c (tree.c:4730) 2 gpc1 0x000e4204 const_hash_1 + 0x3b4 (varasm.c:2130) 3 gpc1 0x002f773c htab_find_slot + 0x2c (hashtab.c:560) 4 gpc1 0x000e34c8 output_constant_def + 0x38 (varasm.c:2496) 5 gpc1 0x0007d6b0 expand_expr_real + 0x3c88 (expr.c:6910) 6 gpc1 0x0007d54c expand_expr_real + 0x3b24 (expr.c:8863) 7 gpc1 0x0007e9a0 expand_expr_real + 0x4f78 (expr.c:7658) 8 gpc1 0x0007a620 expand_expr_real + 0xbf8 (expr.c:6952) 9 gpc1 0x0007e9a0 expand_expr_real + 0x4f78 (expr.c:7658) 10 gpc1 0x00196ac8 expand_call + 0x2760 (calls.c:793) 11 gpc1 0x0007b6a0 expand_expr_real + 0x1c78 (expr.c:7595) 12 gpc1 0x000c9ff4 expand_expr_stmt_value + 0xe0 (stmt.c:2171) 13 gpc1 0x00007e5c yyuserAction + 0x4cd8 (parse.c:4691) 14 gpc1 0x000114cc main_yyparse + 0x738 (parse.c:8136) 15 gpc1 0x000be2ec toplev_main + 0x7b8 (toplev.c:1826) 16 gpc1 0x00001ed8 _start + 0x188 (crt.c:267) 17 dyld 0x8fe1a558 _dyld_start + 0x64 Regards, Adriaan van Os

4 8

where could I get latest patches for gpc
by Igor Marnat 28 Feb '05

28 Feb '05

Hi, List! Latest version of GPC has some bugs and there are some patches available already. Does there exists any url to get these patches (or the latest one, "cumulative")? Sometimes it's not very comfortly to search them in the mailing list. Am I missed something and such a place already exists at www.gnu-pascal.de? If no, it would be nice to have such a place nearby GPC release. Regards, Igor Marnat marny(a)rambler.ru

5 6

Variant record constants
by Frank Heckenbach 27 Feb '05

27 Feb '05

I noticed that GPC allows non-constants in variant record lists which neither EP nor BP support. As it would cause additional difficulties when fixing Emil's test program and perhaps elsewhere, and I can't see much use for it, the attached patch forbids it. program fjf1028a (Output); var a: Integer value 1; type t = record case Integer of a: (b: Integer) { WRONG } end; begin end. program fjf1028b (Output); type t (a: Integer) = record case Integer of a: (b: Integer) { WRONG } end; begin 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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

1 0

warning: Operand with side-effects is not evaluated.
by Igor Marnat 25 Feb '05

25 Feb '05

Hello List! I've successfully built latest version with the same results of test suite like other people already have written. Range-checking is a really cool (great thanks to developers:))! It appears now new warning that I didn't see before (warning: Operand with side-effects is not evaluated). It isn't described in the documentation. It points to strings that look like: LocalVariable := GlobalVariable mod GlobalConst; Can I do something to avoid it? What does it mean? It means that the value evaluated will not be assigned to LocalVariable? Or it means that Global variable will not change its value as a result of this activity? Best regards, Igor Marnat mailto:marny@rambler.ru

2 1