Gpc June 1998

gpc@gnu.de

38 participants
59 discussions

Files
by berend＠beard.nest.nl 01 Feb '02

01 Feb '02

* Moved (from: gpc) by Berend de Boer using timEd 1.10.b3+. Peter Gerwinski wrote in a message to Berend de Boer: PG> I tried to use Extended Pascal "binding" to assign a file PG> variable to an external -- existing -- file. I just copied PG> the "Assign" pro- cedure by Berend as published in PG> borland2ep.doc. It does not always work: I often get a PG> runtime error saying that the file did not exist. If you can repeat it, compile with another Extended Pascal compiler, for example Prospero's one. If that fails too, there is really something wrong with the code. But I suspect gpc. You're using which OS? Groetjes, Berend (-: fido: 2:281/527.23 email: berend(a)beard.nest.nl

4 3

unsubscribe
by jgouv＠pop03.ca.us.ibm.net 30 Jun '98

30 Jun '98

unsubscribe

1 0

unsubscribe
by csap00jp 28 Jun '98

28 Jun '98

Unsubscribe me please

1 0

SizeOf bug
by Maurice Lombardi 27 Jun '98

27 Jun '98

Hi all, When looking to a redent discussion on the fpk-mailing list with this subject, I have tried to make the same tests on gpc. I have found a bug in gpc which has nothing to do with the subject of the discussion. Working on plain dos djgpp with gpc-980511. The program is: program size_bug; type Time = object h,m,s:byte; constructor init; destructor done; virtual; end; var OT:Time; constructor Time.init; begin end; destructor Time.done; begin end; begin OT.init; writeln(SizeOf(OT)); end. when compiling it says Abort! with the message: Reading specs from f:/djgpp/lib/gcc-lib/djgpp/2.81/specs gpc driver version 2.81 executing gpc version 2.8.1 f:/djgpp/lib/gcc-lib/djgpp/2.81/gpc-cpp.exe -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__DJGPP_MINOR__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 size_bug.pas G:/ccba5tpj GNU CPP version 2.81 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: f:/djgpp/contrib/grx23/include /usr/local/include JDIR/djgpp/include JDIR/lib/gcc-lib/djgpp/2.81/include $DJDIR/include End of search list. f:/djgpp/lib/gcc-lib/djgpp/2.81/gpc1.exe G:/ccba5tpj -quiet -dumpbase size_bug.pas -version -famtmpfile=size_bug.gpc -o G:/ccca5tpj GNU Pascal version 2.81 (djgpp) compiled by GNU C version 2.8.1. size_bug.pas: In function `Time_Init': size_bug.pas:13: `with' element is of wrong type Abort! It is the identifier Time which causes the problem. All becomes correct if it is replaced everywhere by Tim. As far as I know time is not a reserved word, and anyway you have allowed to redefine nearly all identifiers. ??? (otherwise gpc has the correct behaviour with respect to the purpose of the test: it bangs under CWSDPMI for dereferencing uninitialized pointer if OT is not initialized before computing SizeOf(OT), and gives a nonsense result when working in a WIN 3.11 DOS box which does not catch this illegal memory addressing, but this behavior is different from BP) -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

gpc for aix
by Nick Cremelie 25 Jun '98

25 Jun '98

Hi all, After a few days work, I finally got gpc compiled on a powerpc based RS/6000 with AIX4.1.4. I thought I'd first try it with a simple program called littletest.pas: program littletest; var i,j: integer; begin i:=1; j:=2; writeln('Sum is ',i+j); end. Well, this is the result: $ gpc --verbose littletest.pas Reading specs from /usr/local/lib/gcc-lib/powerpc-ibm-aix4.1.4.0/2.7.2.1/specs gpc version 971001(2.7.2.1) /usr/local/lib/gcc-lib/powerpc-ibm-aix4.1.4.0/2.7.2.1/gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=7 -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -Asystem(unix) -Asystem(aix) -Acpu(powerpc) -Amachine(powerpc) -D__CHAR_UNSIGNED__ -D_ARCH_PPC littetest.pas /tmp/ccQLxsya.i GNU CPP version 971001(2.7.2.1) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/powerpc-ibm-aix4.1.4.0/include /usr/local/lib/gcc-lib/powerpc-ibm-aix4.1.4.0/2.7.2.1/include /usr/include End of search list. /usr/local/lib/gcc-lib/powerpc-ibm-aix4.1.4.0/2.7.2.1/gpc1 /tmp/ccQLxsya.i -quiet -dumpbase littletest.pas -version -famtmpfile=littletest.gpc -o /tmp/ccQLxsya.s GNU PASCAL version 971001(2.7.2.1) compiled by GNU C version 2.7.2.1. gpc: Internal compiler error: program gpc1 got fatal signal 6 Needless to say, I get a beautiful coredump out of that which my debugger dbx can't read very well, but anyways this is the result of a "where": raise(??) at 0xd0077eac abort() at 0xd0019a70 emit_stack_save(??, ??, ??), line 887 in "explow.c" init_main_program_rtx(), line 1588 in "util.c" yyparse(), line 545 in "parse.y" compile_file(name = "/tmp/ccQLxsya.i")line 2232 in "toplev.c" main(argc = 9, argv = 0x2ff22b94, envp = 0xffffffff), line 3931 in "toplev.c" If anyone would have any idea on how to solve this, it would be greatly appreciated. Please reply by mail as I am not yet subscribed to this mailing list! Nick Cremelie

2 1

ld problem under RH 5.0 with gpc rpm
by dtroeger＠ix.netcom.com 25 Jun '98

25 Jun '98

I have installed (Redhat 5.0) gpc-2.0-1.i386.rpm, but running it on any pascal program produces an error: ld: cannot open crtbegin.o: No such file or directory (If I use gpc -S hello.pas, I _do_ get successful compilation; the problems clearly arise later.) Can anyone point me in the right direction on this? Specifically, are there configuration steps which must be taken _after_ rpm has completed its installation? Thanks, Doug Troeger

2 1

unsubacribe
by Dr Montaz Ali 25 Jun '98

25 Jun '98

Unsubscribe me please ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Montaz Ali, Ph.D | Email : mali(a)pc55.cam.wits.ac.za Dept. of Computational & Applied | Tel :(011)-716-3969 (W) Mathematics, | Tel :(011)-403-0250 (H) The University of Witwatersrand | Fax :(011)-403-9317 (W) Private Bag - 3, Wits - 2050 | Johannesburg, Republic of South Africa| ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: Test files (was: No crt0.o with cygwin32 version solved)
by Frank Heckenbach 24 Jun '98

24 Jun '98

Hans Lunsing wrote: > I commented out iso.pas, because it gave errors: > > iso.pas: In function `program_Iso': > iso.pas:13: parse error before `Operator' > iso.pas:13: comma missing after identifier `Uses' > iso.pas:13: parse error before `Shl' > iso.pas:13: comma missing after identifier `Uses' > iso.pas:13: parse error before `;' > iso.pas:14: comma missing after identifier `Uses' > iso.pas:14: pointer domain type undefined > iso.pas:14: parse error before `Uses' > iso.pas:14: comma missing after identifier `Uses' > iso.pas:14: parse error before `Value' > iso.pas:14: comma missing after identifier `Uses' > iso.pas:14: parse error before `Absolute' > iso.pas:21: comma missing after identifier `Uses' > iso.pas:21: parse error before `(' > iso.pas:21: comma missing after identifier `Uses' > iso.pas:21: parse error before `Operator' > iso.pas:21: extra comma following id_list This file seems to be in the wrong directory. It must not be compiled with --borland-pascal, but with --extended-pascal. > That was not the case in GPC for Cygwin32 b17.1. Harakiri.pas in = > test\misc gave errors as well: > > harakiri.pas: In function `Paramstr': > harakiri.pas:40: condition must be of Boolean type This message is correct. The test program declares some obsolete external functions (now built-in), and it even does it twice (???) and wrong (it tries to use an integer as a boolean -- wrong language ;-). If GPC didn't complain before, that was a bug. Removing all the ParamCount and ParamStr declarations (C, external and Pascal) gets rid of this error. > harakiri.pas: In function `Atoi': > harakiri.pas:54: warning: cast to type of different size > harakiri.pas:54: invalid lvalue in address expression Another bug in the test file. It tries to round a real number by "casting" it into an integer which is AFAIK wrong. Replace "integer" by "round" in this line, and the program works. (Of course, one could also get rid of atoi altogether, and use ReadStr instead...) Oh yes, and getpid and kill should also be declared only once. -- Seems like this test suite really is outdated... Well, here's the corrected program, just in case anyone cares: (* Commit suicide with a signal of your choice *) program Harakiri(output); (* I assume these are in your C library: * pid_t getpid(void); * int kill(pid_t pid, int sig); * and pid_t is really int *) {$X+} type pid_t = integer; (* We really should get some standard libraries <sigh> *) function getpid: pid_t; C; function kill(pid: pid_t; sig: integer): integer; C; var signal: Integer; begin if (ParamCount < 1) then writeln('Usage: ', ParamStr(0), ' [signal number]') else begin ReadStr (ParamStr(1), signal); kill(getpid, signal); end end. -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

No crt0.o with cygwin32 version solved
by Hans Lunsing 23 Jun '98

23 Jun '98

Hi, Regarding my problem with the linker not able to open crt0.o: it is solved. But oh, to get the system working! Peter Gerwinski wrote me: >Not being a CygWin32 expert I can only recommend to double-check whether >you have installed the corresponding (beta-??) version of CygWin32 for >your version of GPC. It must contain `crt0.o'. > >Hope this helps, :-/ It did indeed. I had installed the beta 18 version of Cygwin32(it was compatible with 17.1, so I could use it with the GPCWIN version for 17.1), but only the usertools. After I installed the complete C development kit, it worked. That is to say, after a while. It proved rather difficult to let the compiler and the linker both find the files they needed. The environment variables mentioned in GPC.HLP did nothing. I had to point the environment variabele GCC_EXEC_PREFIX to the Cygwin32 directory containing crt0.o, to use the -B (directory for binaries) and -L (directory for libraries) switches on the GPC command line, and to point the DOS path to the compiler itself and to the Cygwin32 binaries (assembler and linker). The make files I had to adjust accordingly. But after some hours of experimenting it worked as it should do! My setup batch file for the new version working with Cygwin32 b18 is now as follows (assuming I installed Gpcwin32 in c:\gpcwin32): set GPC_EXEC_PREFIX=c:\gpcwin32\lib\gcc-lib\i386-cygwin32\2.7.2.1\ set GCC_EXEC_PREFIX=c:\gpcwin32\lib\ set PATH=%PATH%;c:\gpcwin32\bin and I use the following command line: gpc -B%GPC_EXEC_PREFIX% -L%GPC_EXEC_PREFIX% (well, I use a 4DOS alias instead, that's easier!) As regards makefiles, this is now my makefile for the Borland_Pascal test sources (without the comments): #-------------------------------------------------------------------- # c:\bin\sh.exe must exist! .SUFFIXES: .p .pas .o .h .pas.o: $(PC) -c $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< PC = gpc DIRFLAGS = -B$(subst \,\\,$(GPC_EXEC_PREFIX)) -L$(subst \,\\,$(GPC_EXEC_PREFIX)) ALLPFLAGS = $(PFLAGS) -g -O3 --automake="$(DIRFLAGS) -g -O3" EXE = .exe TESTS = abso$(EXE) asmnames$(EXE) bitmanip$(EXE) caseelse$(EXE) \ cstparam$(EXE) head$(EXE) incdec$(EXE) kohl$(EXE) \ mem$(EXE) minimax$(EXE) nohead$(EXE) objects$(EXE) \ openarr$(EXE) switches$(EXE) varrec$(EXE) voidparm$(EXE) TESTSRC = head.pas nohead.pas cstparam.pas caseelse.pas switches.pas \ bitmanip.pas incdec.pas minimax.pas mem.pas abso.pas \ asmnames.pas openarr.pas varrec.pas voidparm.pas all: bptest bptest: for x in $(TESTSRC) ; do \ rm -f a.out 2>/dev/null ; \ $(PC) $(ALLPFLAGS) $$x 2>/dev/null ; \ echo -n "$$x: " ; \ if [ -f "a.out" ] ; then ./a.out ; else echo "failed" ; fi ; \ done ; \ rm myunit.o myunit.gpi a.out 2>/dev/null ; # DOS can't run shell script dostest: $(TESTS) clean: -rm -f $(TESTS) -rm -f *.o *.gpi *.gpc distclean: clean -rm -f *~ core a.out #* *.BAK *.bak *.orig # empty install: abso$(EXE): abso.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ asmnames$(EXE): asmnames.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ bitmanip$(EXE): bitmanip.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ caseelse$(EXE): caseelse.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ cstparam$(EXE): cstparam.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ head$(EXE): head.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ incdec$(EXE): incdec.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ #iso$(EXE): iso.pas # $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< # strip $@ # :-) kohl$(EXE): kohl.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ mem$(EXE): mem.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ minimax$(EXE): minimax.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ nohead$(EXE): nohead.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ objects$(EXE): objects.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ openarr$(EXE): openarr.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ switches$(EXE): switches.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ varrec$(EXE): varrec.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ voidparm$(EXE): voidparm.pas $(PC) $(DIRFLAGS) $(ALLPFLAGS) -o $@ $< strip $@ #-------------------------------------------------------------------- A rule for making voidparm.exe had to be added, and I could run it with the command make dostest as Maurice Lombardi pointed out to me. I commented out iso.pas, because it gave errors: iso.pas: In function `program_Iso': iso.pas:13: parse error before `Operator' iso.pas:13: comma missing after identifier `Uses' iso.pas:13: parse error before `Shl' iso.pas:13: comma missing after identifier `Uses' iso.pas:13: parse error before `;' iso.pas:14: comma missing after identifier `Uses' iso.pas:14: pointer domain type undefined iso.pas:14: parse error before `Uses' iso.pas:14: comma missing after identifier `Uses' iso.pas:14: parse error before `Value' iso.pas:14: comma missing after identifier `Uses' iso.pas:14: parse error before `Absolute' iso.pas:21: comma missing after identifier `Uses' iso.pas:21: parse error before `(' iso.pas:21: comma missing after identifier `Uses' iso.pas:21: parse error before `Operator' iso.pas:21: extra comma following id_list That was not the case in GPC for Cygwin32 b17.1. Harakiri.pas in test\misc gave errors as well: harakiri.pas: In function `Paramstr': harakiri.pas:40: condition must be of Boolean type harakiri.pas: In function `Atoi': harakiri.pas:54: warning: cast to type of different size harakiri.pas:54: invalid lvalue in address expression and that was also not the case in the previous version of GPC. Till so far I didn't try the DLL demo. Kind regards, Hans Lunsing Leiden, The Netherlands, e-mail jlunsing(a)doge.nl

1 0

Re: Some GPC bugs
by Frank Heckenbach 22 Jun '98

22 Jun '98

Marius Gedminas wrote: > >> 3. (I think this one is not new) `--automake' does pass all required > >> .o files to the linker if it didn't need to recompile the > >> sources. > > > >That's not new, but again a better analysis of the problem. > >In order to hunt the bug, an example program which will output > >"OK" when the bug will be fixed would be helpful. (Or do we > >already have one? I have lost overview a little ... #-) > > I never had it (overview, that is), but I do not think it is easy to write > such a program. Well, maybe... Well, it was almost perfect! :-) > First time it compiles nicely, second time ld complains about `Callsecond' > being undefined. It might be possible to write a wrapper to execute > `gpc --automake automakebug.pas' twice and output 'Ok' if the second > compilation succeeds. The test suite currently doesn't support this, but I think it's easy to achieve by just putting two copies of the main program into the test suite. This would look like the following (I just renamed the files and changed the output string): --- marius2.pas AND marius2c.pas: program Marius2; { This tests a bug in the automake mechanism. When the first program (marius2.pas) is compiled, it works well, but when the seconds program (marius2c.pas, identical to marius2.pas!) is compiled, and the pre-compiled units are already there, it fails. -- Just in case anyone wonders why there are two identical files in the test suite... } uses Marius2a; begin CallFirst; end. --- marius2a.pas: unit Marius2a; interface procedure CallFirst; implementation uses Marius2b; procedure CallFirst; begin CallSecond; end; end. --- marius2b.pas: unit Marius2b; interface procedure CallSecond; implementation procedure CallSecond; begin WriteLn('OK'); end; end. --- When I run it through the test suite, it gives "OK" for marius2.pas and an error for marius2c.pas. -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

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