Gpc

gpc@gnu.de

5400 discussions

Strings problem
by LUJOP 20 Dec '99

20 Dec '99

First of all excusme for my little english. I'm new and I haven't experience with GPC, in fact I don't like Pascal very much. But I need to do a work for the university. The version I run is: Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 And I have some problems comparing strings. If I compile and run the next program: Program test; var a,b:string(20); begin a:='Hello'; b:='Bye'; if(a<b) then writeln('Hello<Bye'); if(a>b) then writeln('Hello>Bye'); if(b<a) then writeln('Bye<Hello'); if(b>a) then writeln('Bye>Hello'); end. The output generated is: Bye<Hello Bye>Hello And, logically it isn't very nice :-) My question is simple: why the program don't function as desired? Or, if the error is mine, What I do bad? Postdate: I need to compile the program in the metionated version, and I can't update to a newer (university's administrators are not very servicial) Thus, if we can give a solution for the above version I'll be very happy. Otherwise I will be to codify strings with arrays of chars. Please , if someone reply to this message can send a copy to jpujo012(a)correu.udg.es Thanks And, another time excusme for me english.

1 0

Re: Modules/units, separate compilation, minimal re-compilations
by Frank Heckenbach 15 Dec '99

15 Dec '99

David James wrote: I have several applications which I'm porting to GPC on Linux from another (almost) ISO-10206 extended Pascal. > The application is structured in several layers, in this sort of > scheme: > > modules A, B, C export constants, types, variables, procedures and > functions which are used by modules D, E, F which in turn export > constants, types, variables, procedures and functions which are > imported by modules G, H, I which in turn ... are imported by > programs X, Y, Z. > > The previous compiler allowed (as GPC does) the interface and > implementation parts of each module to be in separate files (usually > .h for the interface and .p for the implementation). > > When deciding what needed re-building when re-compiling program X, > it only checked for updates since the last re-build to the *interface* > parts of the modules imported by X (and, recursively, the modules it > imported). > > This lead to a major reduction in the amount of compilation needed > when re-building one of the applications, for example, if a change > was made to the implementation part of module A, rebuilding program X > would result in module A being re-compiled and then program X being > re-linked. > > So, finally my question: is it possible to do this with GPC? Not currently, but one of the next releases will probably contain a feature to do this. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

GPC and Red Hat 6.0
by Ken_A_Munro＠keane.com 15 Dec '99

15 Dec '99

Hi. Sorry if I missed something in the documentation, but I think I've read it all over. I have installed the binaries for GPC on my Red Hat 6.0 system. I can get Pascal programs to compile, but when they execute, they core dump. (I have attached the output from a verbose gpc compile of the pi.pas demo program.) The Red Hat 6.0 compiler is egcs-1.1.2, but the GPC binary (from gpc-19990118-egcs-1_1_1_i386-linux-glibc2.tar) was compiled with egcs-1.1.1. Is that why the executables are core dumping? I have also tried compiling GPC, but when I "make LANGUAGES=pascal", I get a lot of "assignment makes pointer from integer without a cast" errors when gcc is compiling gpc.c. Why should that be happening, and how can I remedy it? Also, is this mailing list archived anywhere? Thanks in advance. Any help would be greatly appreciated. Ken Munro **************************** versions of gcc and gpc *************************************************** [root@client11 demos]# egcs -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) [root@client11 demos]# gpc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/specs gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) ******************* verbose ouput of pascal compile of sample pi.pas program ****************** [root@client11 demos]# gpc --automake pi.pas -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/specs gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -D__ELF__ -Dunix -Di386 -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ pi.pas /tmp/cceao36i.i GNU CPP version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/i386-redhat-linux/include /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/include /usr/include End of search list. /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/gpc1 /tmp/cceao36i.i -quiet -dumpbase pi.pas -version -famtmpfile=/tmp/cc2OLhLJ.gpc -fautomake -o /tmp/cceao36i.s GNU Pascal version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i386-redhat-linux) compiled by GNU C version egcs-2.91.60 19981201 (egcs-1.1.1 release). GPC AutoMake: gpc --automake -v --amtmpfile=/tmp/cc2OLhLJ.gpc -M /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/units/gpc.pas -o /tmp/cc0clDMX Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/specs gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/gpc-cpp -lang-pascal -v -nocharescape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -D__ELF__ -Dunix -Di386 -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/units/gpc.pas -o /tmp/cc0clDMX GNU CPP version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/i386-redhat-linux/include /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/include /usr/include End of search list. GPC AutoMake: done GPC AutoMake: gpc --automake -v --amtmpfile=/tmp/cc2OLhLJ.gpc -M /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/units/gmp.pas -o /tmp/cceFAqbP Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/specs gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/gpc-cpp -lang-pascal -v -nochar escape -D__GNU_PASCAL__ -M -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=19990118 -D__ELF__ -Dunix -Di386 -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/units/gmp.pas -o /tmp/cceFAqbP GNU CPP version egcs-2.91.60 19981201 (egcs-1.1.1 release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/i386-redhat-linux/include /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/include /usr/include End of search list. GPC AutoMake: done as -V -Qy -o /tmp/cceao36i1.o /tmp/cceao36i.s GNU assembler version 2.9.1 (i386-redhat-linux), using BFD version 2.9.1.0.23 ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/crtbegin.o -L/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60 -L/usr/i386-redhat-linux/lib gmp.o gpc.o /tmp/cceao36i1.o -lgpc -lm -lgmp -lgcc -lc -lgcc /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.60/crtend.o /usr/lib/crtn.o [root@client11 demos]#

1 0

Re: Behaviour of reset and extend on text file
by david＠tcs01.demon.co.uk 12 Dec '99

12 Dec '99

In message <199912112317.SAA26060(a)mail.bcpl.net> "J. David Bryan" writes: > On 11 Dec 99, at 13:31, David James wrote: > > > I'm still not sure what my example should do. Looking at the copy of > > Extended Pascal ISO/TEC 10206:1990(E) that I found on (I think) a > > DEC site somewhere, I *think* it is saying (in section 6.7.5.2) that > > after the call to 'extend' the file should be in 'Generation' mode. > > Right. There is no precondition for "extend" that the file be closed. In > fact, there is no "close" predefined function in EP. That explains why I cannot find 'close' in the standard :-). So how should one 'close' a file in EP - would that be 'unbind'? [snip] > > I make no claim to expertise with the EP standard, and the prose in the > standard is nearly impenetrable :-), I think you have an extraneous word there - it's the "nearly" :-) > but as far as I can see, "extend" > following a "reset" is perfectly OK. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

2 1

Re: Behaviour of reset and extend on text file
by david＠tcs01.demon.co.uk 11 Dec '99

11 Dec '99

In message <19991211124359.A4186(a)esmeralda.gerwinski.de> Peter Gerwinski writes: > David James wrote: > > [...] > > The previous compiler allowed one to write to a text file that had been > > opened with 'reset' and then 'extend'ed. GPC says: > > > > ./daj13: cannot write to read only file `daj13.pas' (error #422) > > > > ===== > > program daj13(input,output); > > > > var f:text; > > > > begin > > reset(f,'daj13.pas'); > > extend(f); > > writeln(f,'extra text'); > > end. > > If you `close' the file before the `extend', it works. I'm still not sure what my example should do. Looking at the copy of Extended Pascal ISO/TEC 10206:1990(E) that I found on (I think) a DEC site somewhere, I *think* it is saying (in section 6.7.5.2) that after the call to 'extend' the file should be in 'Generation' mode. I think the run-time error on the 'writeln' is incorrect. However, it is possible that there should be an error on the call to 'extend' (it's not clear to me whether calling 'extend' on a file that has already been 'reset' is allowed). > > Do you happen to know what Extended Pascal thinks about how > `close' should work? No, I'm afraid I don't. I cannot find any reference to 'close' in the index of ISO 10206, and I cannot see anything referring to 'close' in section 6.7.5.2 'File Handling procedures'. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

3 2

Behaviour of reset and extend on text file
by david＠tcs01.demon.co.uk 11 Dec '99

11 Dec '99

I'm not sure what the correct behaviour should be in the attached program, but GPC's behaviour is different from the previous extended Pascal compiler I used (I'm not saying that the previous compiler was right). The previous compiler allowed one to write to a text file that had been opened with 'reset' and then 'extend'ed. GPC says: ./daj13: cannot write to read only file `daj13.pas' (error #422) ===== program daj13(input,output); var f:text; begin reset(f,'daj13.pas'); extend(f); writeln(f,'extra text'); end. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

3 3

Problem with rewrite on file of packed array of packed record
by david＠tcs01.demon.co.uk 11 Dec '99

11 Dec '99

The attached program declares a direct access file whose elements are PACKED ARRAYS of a PACKED RECORD. The program fails with error #405 when a rewrite is issued for the file. Removing the PACKED from the array declaration makes the error go away. Is this correct behaviour? program daj7(input,output); const maxcontrol = 170; maxcomp = 200; type TCHECK1=PACKED RECORD CHECH:0..47; (*6 bits*) CHECM:0..60; (*6 bits*) CHECS:0..60; (*6 bits*) CHECT:0..999; (*10 bits*) GENERATED:BOOLEAN; QUERY:BOOLEAN; from_audit:boolean; END; TCHECK=PACKED ARRAY [0..MAXCONTROL] OF TCHECK1; (*if declared as PACKED, get error 405 on the rewrite if not declared PACKED, runs OK*) var count:integer; f:file [0..maxcomp] of tcheck; begin rewrite(f,'daj7.fil'); (*./daj7: could not open `daj7.fil' (error #405) here *) for count:=0 to maxcomp do begin seekwrite(f,count); f^[0].chect:=count; put(f); end; close(f); reset(f,'daj7.fil'); for count:=1 to maxcomp do begin seekread(f,count); writeln(count:1,' ',f^[0].chect:1); end; close(f); end. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

Modules/units, separate compilation, minimal re-compilations
by david＠tcs01.demon.co.uk 11 Dec '99

11 Dec '99

I have several applications which I'm porting to GPC on Linux from another (almost) ISO-10206 extended Pascal. The application is structured in several layers, in this sort of scheme: modules A, B, C export constants, types, variables, procedures and functions which are used by modules D, E, F which in turn export constants, types, variables, procedures and functions which are imported by modules G, H, I which in turn ... are imported by programs X, Y, Z. The previous compiler allowed (as GPC does) the interface and implementation parts of each module to be in separate files (usually .h for the interface and .p for the implementation). When deciding what needed re-building when re-compiling program X, it only checked for updates since the last re-build to the *interface* parts of the modules imported by X (and, recursively, the modules it imported). This lead to a major reduction in the amount of compilation needed when re-building one of the applications, for example, if a change was made to the implementation part of module A, rebuilding program X would result in module A being re-compiled and then program X being re-linked. So, finally my question: is it possible to do this with GPC? If it is, how do I need to structure my source code to make it happen. If it isn't possible, can I offer this as a development suggestion. A final note, I'm in the process of converting all my source code from modules to units, since the problem I've already reported in program daj3 makes the use of modules impossible in my applications. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

Precompiled units
by Mariusz Zynel 07 Dec '99

07 Dec '99

Hi All How to tell gpc where the precompiled units are? I would like to keep standard/shared object files (precompiled units) in one directory and make them available for all the projects I'm working on. I'm using the latest beta 1030 on Solaris 7. Thanks for suggestions -- . Mariusz Zynel Institute of Mathematics | phone: +48 (85) 745 75 52 University of Bialystok | Akademicka 2 St | mailto:mariusz@math.uwb.edu.pl 15-267 Bialystok | Poland | http://math.uwb.edu.pl/~mariusz/

2 2

Help with GPC installation on Mingw32 on NT...
by Rod Chapman 06 Dec '99

06 Dec '99

Perhaps someone could help me with installing GPC 19990118 for mingw32 on NT. I've unzipped the binaries into d:\rod\gpc\ on my machine and I have GCC_EXEC_PREFIX set to d:\rod\gpc\lib\gcc-lib\ Compiling my application works OK, but linking fails with... D:\rod\lalr>gpc -o sparklalr sparklalr.o ld: cannot open crt1.o: No such file or directory D:\rod\lalr>gpc -o sparklalr -v sparklalr.o Reading specs from d:\rod\gpc\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 ld -o sparklalr.exe crt1.o -Ld:\rod\gpc\lib\gcc-lib\i386-mingw32\2.8.1 -Ld:\rod\gpc\lib\gcc-lib -LD:\GNATPRO\lib sparklalr.o -lgpc -lcrtdll -lmingw32 -lgcc -lmoldname -lcrtdll -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lcrtdll ld: cannot open crt1.o: No such file or directory I can't find crt1.o anywhere on my system - where does it come from? Thanks, Rod Chapman Praxis Critical Systems ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. This email has been swept for the presence of known computer viruses. **********************************************************************

2 1

Jump to page:

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