Gpc May 2004

gpc@gnu.de

25 participants
38 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

-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-20040516 released
by Frank Heckenbach 22 Jul '04

22 Jul '04

I have uploaded a new beta version of GPC to <http://www.gnu-pascal.de/beta/>. This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work. Waldek Hebisch and I are currently working on some larger changes, including qualified identifiers, range checking and support for gcc-3.4.0. An alpha version with these changes, which might be less stable, will probably be released in a few weeks. BUILD NOTE: If you modify the GPC sources, you now need bison-1.875c and flex-2.5.27 (<http://lex.sourceforge.net>) to rebuild. These versions must be matched exactly. Newer flex versions, in particular 2.5.31, might work as well, but contain a known unportability, so I did not test them, and I recommend 2.5.27. (Other programs such as yacc and lex instead of bison and flex also will not do.) I have included the files generated by bison and flex in the distribution (also in the "minimal" distribution), so you should not need these tools when you only want to build GPC. NOTE: The `Pipe' unit was renamed to `Pipes' because of a name conflict. Unfortunately, this requires a small change to all programs that use this unit. New features: * arithmetic expressions now work as lower array/subrange bounds (fjf248.pas, fjf293.pas, fjf336.pas, fjf346a.pas, fjf622.pas) * records/objects with many fields are processed faster * parameters of procedural types now support Standard Pascal procedural parameters, conformant/open arrays and `type of' inquiries (fjf939*.pas) * empty parameter lists can be written as `()' (chief54*.pas, delphi6*.pas) (D) * GMP unit: `mpf_sin', `mpf_cos' * the test suite output is now by default stored in DejaGnu compatible files `gpc.log' and `gpc.sum' in the `p/test/' directory; other available test targets are `pascal.check-short' and `pascal.check-long' (@) * new options `-W[no-]dynamic-arrays' (fjf931*.pas) * new argument to `_p_initialize' (@) * new function `UMask' * new option `--no-debug-source' * new lexer (no directly user-visible difference, but should allow for better handling of lexer-based problems in the future) Fixed bugs: * `pow' and `**' are really EP conformant now (in particular `x pow y' and `x ** y' are an error if x = 0 and y <= 0) (emil27*.pas) * `protected var' parameters must only accept references (unlike `const' parameters) (gale5*.pas) * `pack' must not pack the component type of arrays (fjf940[b-e].pas) * in some circumstances packed fields were allowed as `var' parameters (fjf940a.pas) * bugs with nonlocal gotos out of routines declaring file variables (nonloc*.pas) (fix involved a change in the internal representation of file variables) * 'foo'#42 must not be rejected in `--borland-pascal' (chief53.pas) * `--implementation-only' didn't work correctly (bo4-19.pas) * messages referring to object methods now point to the method declaration rather than the end of the object type declaration * initializers for types containing nested schemata now work (fjf914*.pas) * various smaller bugs 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

11 50

Bad stabs
by Adriaan van Os 10 Jul '04

10 Jul '04

The output below from objdump suggests that stabs debugging info from gpc is broken. Does this happen on other platforms also ? Regards, Adriaan van Os ------- [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c hello.pas -g [G4:~/gnu/testgpc/adriaan] adriaan% objdump -g hello.o hello.o: file format mach-o-be Bad stab: Datevalid:(0,5)=@s8;- 16;,0,1;Timevalid:(0,5),1,1;Year:(0,1),2,32;Month:(0,6)=r(0,1);1;12;,34, 4;Day:(0,7)=r(0,1);1;31;,38,5;Dayofweek:(0,8)=r(0,1);0;6;,43,3;Hour:(0,9 )=r(0,1);0;23;,46,5;Minute:(0,10)=r(0,1);0;59;,51,6;Second:(0,11)=r(0,1) ;0;61;,57,6;Microsecond:(0,12)=r(0,1);0;999999;,63,20;Timezone:(0,1),83, 32;Dst:(0,5),115,1;Tzname1:(0,13)=s44Capacity:(0,14)=r(0,14);00000000000 00;0037777777777;,0,32;length:(0,14),32,32;_p_Schema_:(0,15)=ar(0,1);1;3 3;(0,2),64,264;;,128,352;Tzname2:(0,16)=s44Capacity:(0,14),0,32;length:( 0,14),32,32;_p_Schema_:(0,17)=ar(0,1);1;33;(0,2),64,264;;,480,352;; Last stabs entries before error: n_type n_desc n_value string SO 0 0000000000000000 /Users/adriaan/gnu/testgpc/adriaan/ SO 0 0000000000000000 hello.pas OPT 0 0000000000000000 gcc2_compiled. LSYM 0 0000000000000000 integer:t(0,1)=r(0,1);-2147483648;2147483647; LSYM 0 0000000000000000 char:t(0,2)=@s8;-20; LSYM 0 0000000000000000 Complex:t(0,3)=R4;16;0; LSYM 0 0000000000000000 Timestamp:t(0,4)=s104Datevalid:(0,5)=@s8;- 16;,0,1;Timevalid:(0,5),1,1;Year:(0,1),2,32;Month:(0,6)=r(0,1);1;12;,34, 4;Day:(0,7)=r(0,1);1;31;,38,5;Dayofweek:(0,8)=r(0,1);0;6;,43,3;Hour:(0,9 )=r(0,1);0;23;,46,5;Minute:(0,10)=r(0,1);0;59;,51,6;Second:(0,11)=r(0,1) ;0;61;,57,6;Microsecond:(0,12)=r(0,1);0;999999;,63,20;Timezone:(0,1),83, 32;Dst:(0,5),115,1;Tzname1:(0,13)=s44Capacity:(0,14)=r(0,14);00000000000 00;0037777777777;,0,32;length:(0,14),32,32;_p_Schema_:(0,15)=ar(0,1);1;3 3;(0,2),64,264;;,128,352;Tzname2:(0,16)=s44Capacity:(0,14),0,32;length:( 0,14),32,32;_p_Schema_:(0,17)=ar(0,1);1;33;(0,2),64,264;;,480,352;; [G4:~/gnu/testgpc/adriaan] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc332d1/lib/gcc-lib/powerpc-apple-darwin/3.3.2/specs Configured with: ../gpc-332d1/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc332d1 --enable-threads=posix --target=powerpc-apple-darwin Thread model: posix gpc version 20030830, based on gcc-3.3.2 [G4:~/gnu/testgpc/adriaan] adriaan% objdump -v GNU objdump 2.13.90 20030128 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty.

4 10

GP
by Frank Heckenbach 02 Jun '04

02 Jun '04

I've put a new version of GP with the minor changes discussed here at <http://gnu-pascal.de/contrib/frank/misc/gp-0.55.tar.gz>. 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

13 45

Installation problem with gpc (djgpp, Windows XP)
by Frank Thomas Braun 01 Jun '04

01 Jun '04

I am working successfully with a gpc installation from 2002 and wanted to update to the current version. So I downloaded from "GNU Pascal download area: Current" / binaries / DJGPP (http://www.gnu-pascal.de/binary/djgpp/) all files. After unzipping and a successful installation (gpc -v is working) a try to compile even simple files results in: D:\xxy>gpc HALLO.PAS gpc.exe: Internal GPC problem: internal option `--amtmpfile' not given I read and followed any instructions of http://www.gnu- pascal.de/gpc/Installing-GPC-on-DJGPP.html set DJGPP=c:\gpc\djgpp.env Additions to djgpp are entered and correct. (My first installation of gpc together with djgpp was very problematic too and I succeeded to install a working compiler only after help from the mailing list. That is the reason, that I didn't update the compiler). Frank Braun Frank Braun Rechenzentrum Universitaetsstrasse 31 D-93053 Regensburg Germany Tel.: +49-941-943-4891 email: frank.braun(a)rz.uni-regensburg.de

3 7

GNU Modula 2 binary for MinGW searched
by Gerrit P. Haase 31 May '04

31 May '04

Hello, I'm looking for a binary package of GNU Modula 2 for MinGW, is there one available? Gerrit -- =^..^=

1 0

Module madness
by Neil Santos 31 May '04

31 May '04

Hi guys. I've been scratching my head for about two hours now, trying to figure out what kind of incantation I need to do in order to compile a module whose interface and implementation sections reside in different files. -STOP- Okay, I've composed two other mails before this (with the first couple of paragraphs being part of the second), and I've finally found what I needed. It turns out that, in order to compile a module that has its interface and implementation sections in two different files, one has to compile them this way: gpc -c --interface-only TAttributes.int.pas gpc -c --implementation-only TAttributes.imp.pas --include TAttributes.int.pas Now, my question is, why do we need to include the interface part with the implementation part manually? Can't we tell gpc where to look, to find what it needs? The --unit-path command-line option did not help, and gpc warned about using --auto[make/build]. Also, --unit-destination-path doesn't work for me; I have compile from inside the directory where I want the .gpi and .o files to be placed. Using (as per gpc -v): gpc version 20040516, based on gcc-3.3.3 Also tried with 20030830 (both with gcc 3.2.2). Anyway, back to those unit tests. :D -- Political Dissident Neil Santos Free Software Advocate Jabber: nsantos(a)jabber.org Please avoid sending me attachments encoded in secret formatting. See http://www.fsf.org/philosophy/no-word-attachments.html

5 9

gp-0.54 released
by Frank Heckenbach 28 May '04

28 May '04

I have uploaded the first public beta version of GP to <http://gnu-pascal.de/contrib/frank/misc/gp-0.54.tar.gz>. GP is a utility to automate the building of Pascal programs using the GPC compiler. It is the intended replacement for GNU Pascal's problematic automake feature. If you have been using automake, please try building with GP instead. When GP works sufficiently, it will be included with GPC in one of the next releases, and automake support will later be dropped from GPC. If you only ever used GPC without automake (e.g., using self-written Makefiles or otherwise manually) and do not plan otherwise, you probably do not need GP. Please read the included files REAMD and INSTALL, as usual. The GP Manual is contained in `gp.info' which you can read with any info reader. You can also make a printable documentation with `make dvi' if you have texi2dvi installed or `make pdf' using texi2pdf. Quick start: * Use `gp' instead of `gpc --automake --executable-file-name'. Most other GPC options can be used the same way with GP. * If the source file given on the command line is a unit or module, GP recognizes this automatically and does not try to link it, so you don't have to give the option `-c'. * If your compilers are not called `gpc' and `gcc' you can set `PC' and `CC' wither on the command line or as environment variables. This is mostly the same you would do when using `make'. * Note the new `.gpd' files, e.g. if you want to clean a build directory. (But you might want to consider using `gp --clean' or `gp --clean-objects' for this purpose.) The main features of GP are: * Automatically finds all dependencies, units used and include files as well as C, assembler and object files and libraries referenced in `{$L}' and `{$R}' directives. * Recompiles everything when necessary (no need to give `--automake'). * Avoids unnecessary recompilations if only the implementation of a unit used has changed since the last compilation, by comparing a MD5 value of the interfaces of units. Recompilation is even avoided if only comments in the interface have changed, but not when they influence line numbers - since the GNU tools store line number information in object and other files, this does constitute a small difference. * Supports `--autobuild' to recompile everything. * Does not use GPC's buggy automake feature, so it should work also on systems where automake doesn't. Also, in many cases, it will use less total memory than GPC's automake because it calls the compiler iteratively rather than recursively. * Recognizes and supports transparently cyclic unit dependencies (where, naturally, at least one dependency in each cycle must be in the implementation rather than the interface). * Uses the base name of the main program's file name as the executable name by default, rather than `a.out' (no need to give `--executable-file-name' or `-o foo', but these options are also supported). In the strange case that you want your output file to be called `a.out', you can use `-o a.out'. * Does not try to link a unit given on the command line (no need to give `-c' for units, but `-c' is also supported in case you want to compile, but not link, a program). * Tries appending a `.pas', `.p', `.pp' or `.dpr' suffix (in this order) to the file name given on the command line when necessary, i.e. you can invoke it as `gp foo.pas' or just `gp foo'. * Calls `gcc' rather than `cc1' (which GPC would call) to compile C files, so it also works if the versions of the installed GCC compiler and the backend the installed GPC is based on don't match. * Supports GPC's path options (`--unit-path', `--object-path', `--unit-destination-path', `--object-destination-path', `--executable-path') transparently, also for units given on the command line (where GPC ignores `--unit-destination-path'). * Supports `--include-path' and `--library-path' which work the same way as `-I' and `-L', respectively, but can be given multiple directories at once. * Uses all unit and object paths as include paths automatically, to simplify using units or C files with includes in other directories. * Stores the compiler version, target platform and options given (together with other dependency information) in files with suffix `.gpd' ("GNU Pascal Dependencies") and recompiles files when the compiler version, platform or options differ from those they were compiled with. * Compiles the main program to an object file before linking, so it does not have to be recompiled when only a unit's implementation changes, and you have it available in case you want to link it explicitly. * The options `--progress-messages' and `--progress-bar' are extended to give information on the progress of the compilation of the whole project (not only of a single source file as when calling `gpc' directly). Some limitations: * The handling of default options and simpler usage of dialect options (as discussed on the mailing list) is not yet included. This will be added in a later revision. However, this does not have any influence on the main functionality of building Pascal programs (you just have to give your options explicitly, as you do when calling `gpc'). * Extended Pascal module support is experimental. * More than one unit/module/program in one source file is not supported. * Modules with interface and implementation parts in separate source files are not supported. This seems to be difficult to do at all, since the information where to find the implementation module is simply missing from the source. If you have any good ideas on this topic, please send them to the GPC list. * Other more or less strange things may not be supported. If you find anything, let me know, so I can decide whether to support it or to document that it's not supported. GP is Copyright (C) 2000-2004 Free Software Foundation, Inc. It was written by Frank Heckenbach <frank(a)pascal.gnu.de>. It is distributed under the terms of the GNU General Public License, version 2. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

8 25

`MacTypes' could not be imported
by Adriaan van Os 27 May '04

27 May '04

Arnaud Gautier wrote: > HI, > I think I have all installed ok on my mac (osX 10,2): > jack:~/gpc-332d1-build arnaudgautier$ gpc -v > Reading specs from > /Developer/Pascal/gpc332d1/lib/gcc-lib/powerpc-apple-darwin/3.3.2/> specs > Configured with: ../gpc-332d1/configure --enable-languages=pascal,c > --prefix=/Developer/Pascal/gpc332d1 --enable-threads=posix > --target=powerpc-apple-darwin > Thread model: posix > gpc version 20030830, based on gcc-3.3.2 > > > But when I make: (t is my file) > jack:~/gpc-332d1-build arnaudgautier$ gpc t.pas > > I get: > t.pas:1: error: module/unit interface `MacTypes' could not be imported > > should be a simple stuff, but I just start gnu 1. Specify --automake (see <http://www.microbizz.nl/gpcfaq.html>) 2. Download and install Apple’s Universal PInterfaces, as ported to GNU Pascal (see <http://www.microbizz.nl/gpc.html>) 3. Specify --unit-path=/Developer/Pascal/GPCPInterfaces/ Hope this helps. Please direct further questions to the gpc mailing list. Regards, Adriaan van Os

1 0

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 May 2004