Gpc June 2007

gpc@gnu.de

15 participants
20 discussions

GP Internal error
by Pascal Viandier 13 Jun '07

13 Jun '07

In the course of the SUN Pascal to GNU Pascal conversion of a all set of programs, I use gp to handle the compilation of a program that has many - around 750 - modules. I call gp with the main program and correct errors progressively as they are encountered. I already compiled more than 600 modules this way. Until now all was going well but today I got an error message from gp when it calls "gpc --interface-only" for a module that has never been compiled yet: gp: internal error: complete cycle not found Since gp worked perfectly well for the previous modules, I suspect something wrong in this particular module but I don't see any error when looking at the Pascal code. What kind of twist in the source code can produce this error? I use gp 0.60 build with gpc 20051116 based on gcc-3.4.4 under SPARC Solaris 10 Kind regards. Pascal Viandier

1 0

Packing of 64 bit values
by Jonas Maebe 13 Jun '07

13 Jun '07

Hello, After noticing that gdb does not print 64 bit fields of (bit)packed records properly if they don't start on a byte boundary (both with fpc and with gpc), I decided to check what gcc does. It turns out that gcc (4.0.1, Mac OS X/ppc) only bitpacks values up to and including 59 bits. Fields declared as 60-64 bits are automatically aligned to the target-specific alignment boundary. Does anyone here know why this is the case, and possibly where this is documented? I can't find anything with Google. Thanks, Jonas Simple test case follows (compile with -c -gdwarf-2, then use dwarfdump/elfread --debug-dump on the .o file to look at the debug info). both l and l2 are aligned on an 8 byte boundary for ppc64 and to a 4 byte boundary for ppc32. *** struct tt { int a; int j; }; struct S { int j:5; long long l:60; long long l2:60; int k:6; int m:5; int n:8; struct tt s; }; int main(struct S s) { } *** Compare with a Pascal program: *** {$ifdef fpc} {$bitpacking on} {$endif} type {$ifndef fpc} int64 = longint; {$endif} tenum = (ea,eb,ec,ed,ee,ef,eg,eh); tr = packed record a: 0..3; // 2 bits i: int64; c: boolean; // 1 bit d: 0..31; // 5 bits e: tenum; // 3 bits end; procedure t(var r2: tr); var r: tr; begin r.a := 2; r.i := 1234567890123456789; r.c := true; r.d := 5; r.e := ed; r2 := r; end; var r: tr; begin t(r); if (r.a <> 2) or (r.i <> 1234567890123456789) or (not r.c) or (r.d <> 5) or (r.e <> ed) then halt(1); end. *** If you debug this, step over the "t" call and print r, you get (for gpc): (gdb) p r $1 = { A = 2, I = 0, C = true, D = 5, E = Ed } (gdb) ptype r type = record A : 0..3 : 2; I : Int64 : 64; C : Boolean : 1; D : 0..31 : 5; E : Tenum : 3; end Looking at the stabs (the gpc for Mac OS X I have doesn't support dwarf), gpc also puts the 64 bit int right after the two first bits, without aligning to a byte/4 byte/8 byte boundary first.

2 3

Bit-packing
by Contestcen＠aol.com 13 Jun '07

13 Jun '07

> Maybe you should be looking into the bit-packing macros provided > with the > Pascal Macro Compiler. This will give you bit-packing which is > independent of > the particular Pascal compiler you happen to be using. See > www.mastersoftware.biz/pasbit.htm Thanks, but I want to implement bit packing which is compatible with what gcc and other compilers use so data exchange is possible. Jonas That's precisely the point. The Borland, TMT, FPC and GPC compilers are not compatible on bit-packing. By using the Macro Compiler you get bit-packing which is independent of the compiler, so that programs compiled with any of these Pascal compilers can exchange data. Frank ************************************** See what's free at http://www.aol.com.

2 1

Unreachable label
by Adriaan van Os 13 Jun '07

13 Jun '07

Any comment on <http://www.freepascal.org/mantis/view.php?id=9053> and Daniël Mantione's note ? Regards, Adriaan van Os

7 10

Bit packing
by Contestcen＠aol.com 12 Jun '07

12 Jun '07

2 1

GPC on Cygwin having a problem compiling using crt
by Bruce Mahfood 12 Jun '07

12 Jun '07

Hello, I have posted my problem to the Cygwin mailing list, and have been told by the person who handles the gcc installation that it doesn't seem to be their issue. I am hoping that someone on the gpc list will be able to help me. I have a number of pascal files that must be compiled to be tested, and am having a hard time doing so. I have installed Cygwin base (version: 1.5.24) on my Windows Server 2003 system and have added all packages that I can think would be useful for this compilation. I am attaching the output of a run of cygcheck so that you can see the environment I have installed. All installed packages are listed at the bottom of the file. Using gpc to compile code which contains the statement "Uses Crt", I get over 600 error lines. I am attaching also attaching the output that I am getting from my compilation, as well as a test file that I have created which gives me these errors. The command line that I am using is: gpc --automake test.pas I have also used: For some reason the compilation, because of the inclusion of the "Uses Crt" statement, thinks that it needs to compile crtc.c, instead of using the binaries that already exist in the Cygwin environment according to the guy I mentioned above who handles the gcc install. I am not sure what I need to add to my command line in order to get this compilation to work. Is there someone who can help me here. I would highly appreciate it. Thanks... Bruce

5 7

Re: GPC on Cygwin having a problem compiling using crt
by Bruce Mahfood 12 Jun '07

12 Jun '07

Thanks for the lead on that IDE. I haven't touched Pascal in many years, so I don't really know what's out there. I've done quite a bit of looking around, but having seen a couple of other IDEs for pascal that I didn't find useful, I decided to stick with GNU stuff, which I was hoping would work for me. The gpc compiler was looking hopeful for a little bit there, but then I ran into these problems. Thanks for the pointer to use this IDE. It's much nicer. I am having an issue with my compilation using the IDE. I did a compile of my project and two errors are popping up in different places that I am not sure what to do with. The Intr() procedure is not recognized, and it's used throughout most of the thirteen project files that I have inherited. Getting an "undeclared identifier 'Intr'" error message. I found a note in the file gpc.info-2 that says that the procedures Intr and MsDos are only supported under DJGPP if `__BP_UNPORTABLE_ROUTINES__' is defined with the `-D__BP_UNPORTABLE_ROUTINES__' option. I didn't know whether this IDE relied on DJGPP or not, but I tried it anyway. It didn't help. Any ideas here? Thanks... Bruce ----- Original Message ----- From: "The African Chief" <chiefsoft(a)bigfoot.com> To: "Bruce Mahfood" <bruce.mahfood(a)tseboston.com> Cc: gpc(a)gnu.de Sent: Monday, June 11, 2007 1:44:55 PM (GMT-0500) America/New_York Subject: Re: GPC on Cygwin having a problem compiling using crt On Mon, 2007-06-11 at 12:27 -0400, Bruce Mahfood wrote: > Hi all, I am on the warpath trying to compile a set of pascal files > that were left to me by a predecessor. My latest issue is that my > files have the statement "Uses graph". Looking online, I find that > this is a Borland thing referring to the use of the Borland Graphics > Interface (BGI). > > I have found that GNU supports a package called GRX > (http://grx.gnu.de/download/index.html), and the link > "http://www.gnu-pascal.de/gpc/Graph-unit.html#Graph-unit" says it's > known to work under Cygwin. I have extracted the files into my cygwin > installation at /usr/local/src, and am looking at the makefiles. > Unfortunately, there is only a mingw specific makefile and not a > cygwin specific one. I have not yet worked with mingw, and don't > really know how these two correlate. > > Can anyone point me in the right direction for compiling this for > cygwin? > Is there any particular reason why you are using Cygwin? You might want to try a Mingw version, which has all that stuff built in (with an IDE): http://www.gnu-pascal.de/contrib/chief/win32/dev_gnu_pascal-1.9.4.8.exe -- Best regards, TheChief email: chiefsoft(a)bigfoot.com www: http://www.greatchief.plus.com

3 5

Re: GPC on Cygwin having a problem compiling using crt
by Bruce Mahfood 12 Jun '07

12 Jun '07

Ooops, forgot to say that I had noticed that the Intr() procedure calls are all being made from files belonging to the TechnoJock's Turbo Toolkit. This project is using the 5.1 version. From what I can tell online, this is the last version put out (back in '93). I used TP and TASM to build a full distribution of these files in order to come up with the .tpu files that I talked about in my last email. Bruce ----- Original Message ----- From: "The African Chief" To: "Bruce Mahfood" Cc: gpc(a)gnu.de Sent: Monday, June 11, 2007 5:47:43 PM (GMT-0500) America/New_York Subject: Re: GPC on Cygwin having a problem compiling using crt On Mon, 2007-06-11 at 17:21 -0400, Bruce Mahfood wrote: > Thanks for the lead on that IDE. I haven't touched Pascal in many > years, so I don't really know what's out there. I've done quite a bit > of looking around, but having seen a couple of other IDEs for pascal > that I didn't find useful, I decided to stick with GNU stuff, which I > was hoping would work for me. The gpc compiler was looking hopeful > for a little bit there, but then I ran into these problems. Thanks > for the pointer to use this IDE. It's much nicer. > > I am having an issue with my compilation using the IDE. I did a > compile of my project and two errors are popping up in different > places that I am not sure what to do with. The Intr() procedure is > not recognized, and it's used throughout most of the thirteen project > files that I have inherited. Getting an "undeclared identifier > 'Intr'" error message. I found a note in the file gpc.info-2 that > says that the procedures Intr and MsDos are only supported under DJGPP > if `__BP_UNPORTABLE_ROUTINES__' is defined with the > `-D__BP_UNPORTABLE_ROUTINES__' option. I didn't know whether this IDE > relied on DJGPP or not, but I tried it anyway. It didn't help. Any > ideas here? The Intr routine works only on DJGPP (DOS-32). This IDE is based on Mingw. Unless you can find a portable way to do what you want to do with Intr, I think you are well and truly stuck there. -- Best regards, TheChief email: chiefsoft(a)bigfoot.com www: http://www.greatchief.plus.com

1 0

[Fwd: Re: Unreachable label]
by Adriaan van Os 11 Jun '07

11 Jun '07

-------- Original Message -------- Subject: Re: Unreachable label Date: Mon, 11 Jun 2007 13:13:06 +0200 From: MegaBrutal <megabrutal(a)gmail.com> To: Adriaan van Os <gpc(a)microbizz.nl> References: <466D0430.70706(a)microbizz.nl> I don't recommend to use labels and goto statements at all. It just messes the code and tells about bad programming manners. 2007/6/11, Adriaan van Os <gpc(a)microbizz.nl>: > > Any comment on <http://www.freepascal.org/mantis/view.php?id=9053> and > Daniël Mantione's note ? > > Regards, > > Adriaan van Os > > >

3 2

Port of Knuth's WEB to latest unstable release of GPC
by FL 01 Jun '07

01 Jun '07

Hello, I was unable to locate change files for Knuth's original TANGLE and CWEAVE programs on CTAN, so I've written a port of the system for the gpc version 20060325. I reverted the file I/O in Knuth's code that he ported to C back to GNU Pascal. I might have preserved Knuth's I/O routines in C, except that GNU Pascal changed the way it makes file structures available to the programmer since Knuth wrote his port (around 2000). The GNU PASCAL function GetFile() might have been used to pass a C-style FILE pointer to this code, but GetFile() is no longer availble. In its place, GNU PASCAL provides a BindingType data structure and related functions; these might have been usable if they had provided a valid file descriptor, but on my Debian Linux system, the value of BindingType.Handle is always -1 (if I may abuse the PASCAL language by referring to a variable of BindingType by its type). Am I mistaken about this? Florian P.S. I've made the change files, the mysterious GPCtypes.h file and a modified tangext.c file available at http://research.gc.cuny.edu/wiki/index.php/Port_of_Knuth%27s_TANGLE_and_WEA…

2 1

2025

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 June 2007