Gpc

gpc@gnu.de

5400 discussions

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

Some GPC bugs
by Marius Gedminas 22 Jun '98

22 Jun '98

Hi, developers! I have successfully downloaded and compiled GPC-980511 for Linux. There still are two problems with the makefile: 1. Subdirectory /p in the gcc source directory may not be a symlink (make finds out the real directory and complains about missing `../configure') - I remember I've seen this problem reported together with a patch on the list. 2. Compiling the RTL for the first time fails because `gpc' is not found (it is still called `xgpc' at the moment) However I was unable to install RHIDE for Linux (rpm2tgz from Slackware 3.4 distribution fails with the rpm package) so I used DJGPP version to examine the following bugs: 1. GPC preprocessor outputs too many empty lines when removing text between {$IFDEF} ... {$ENDIF}. A sample program: {1} program LineNumberBug; {2} {3} {$IFDEF NotDefined} {4} This line is not compiled {5} {$ENDIF} {6} {7} begin {8} ! { Generate syntax error on line 8 } {9} end. ...>gpc main.pas main.pas: In function `program_Linenumberbug': main.pas:11: parse error before `!' ^^ should be 8 2. Procedural variables are always passed by value. program ProcBug; type TProc = procedure; procedure NoBug(X: TProc); begin { X is passed by value as it should be } end; procedure Bug(var X: TProc); begin { X is passed by value here too! } { If I tried to modify X, I would corrupt code of some procedure } end; var Tmp: TProc; begin NoBug(Tmp); { These two calls in .S file are identical } Bug(Tmp); end. 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. (Windows 95 crashed as usual and I had to retype everything from scratch. I should once again try to install RHIDE for Linux...) Yours, -- Marius Gedminas "A Hacker is any person who derives E-mail: mgedmin(a)pub.osf.lt joy from discovering ways to WWW: http://www-public.osf.lt/~mgedmin/ circumvent limitations." rab'86

2 3

UNSUBCRIBE
by moriaud＠drfmc.ceng.cea.fr 22 Jun '98

22 Jun '98

PLEASE UNSUBCRIBE ME FROM THIS MAILING LIST

1 0

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

21 Jun '98

Hi, 1. I installed GNU Pascal for Cygwin32. When I try to compile and link a pascal source file I get the message ld.exe: cannot open crt0.o: No such file or directory (ENOENT) I know crt0.o contains the startup code for C. Where can I find that file, and if found, where do I place it so that the linker can find it? 2. I tried to run the Makefile for the borland pascal extensions with GNU Make 3.75 for DJGPP V2. It gave an error message: for x in 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 ; do \ rm -f a.out 2>/dev/null ; \ gpc -g -O3 --automake="-g -O3" $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 ; Command line too long. make.exe: *** [bptest] Error -1 So I wonder, is this the right version of Make to use? 3. I also installed GNU Pascal for DJGPP version 2. That works fine (till now)! Hans Lunsing e-mail: jlunsing(a)doge.nl

3 2

GPC 2.1 for EGCS 1.1?
by Peter Gerwinski 19 Jun '98

19 Jun '98

Hello, Jeff! Hello, all! (I am citing everything, so the GPC list members know what we are talking about without browsing the HTML page.) On Wed, 17 Jun 1998 22:46:37 -0600, Jeffrey A Law (law(a)cygnus.com) wrote in http://www.cygnus.com/ml/egcs/1998-Jun/0628.html: > > egcs-1.1 > > The egcs project is rapidly approaching its second major release > (egcs-1.1). > > This page is meant to provide information about the current schedule > for egcs-1.1, the testing/release criteria for egcs-1.1, new features > to be found in egcs-1.1, etc. Maybe this schedule is also reasonable for the next mejor release of GPC (gpc-2.1). I don't know how realistic this is, but the list of bug reports for the latest alpha release was much shorter than for previous ones. It is probably not reasonable to try to integrate the BP compatibility package and other independent contributions (such as GRX) into the GPC distribution by this date, so let's keep them independent. > The tenative schedule for the egcs-1.1 release is: > * July 3, 1998. Feature freeze date. > All new features, optimizations, etc need to be submitted by this > date. It is very likely we will not be able to integrate all the > submissions, but we want to have all of them available for > evaluation by this date. > It is also possible some patches which have been submitted and are > accepted for egcs-1.1 will not have been installed by this date > due to EOQ committments for many of the Cygnus volunteers. > After July 3, 1998, only bugfix submissions will be considered for > the egcs-1.1 release. > By July 3, 1998, we also want to have a testing plan and release > criteria in place. For GPC this means that all scheduled features (e.g. some filled BP holes) have to be in place by that date. This merely concerns my own work. I will try to compose a new :-) beta (-: GPC snapshot by this weekend. > * July 11, 1998. Branch Creation & Testing. > We will create the egcs-1.1 branch on this date and snapshots will > occur from the egcs-1.1 branch instead of the mainline sources. > By this date we'd like to have all the new features, > optimizations, etc slated for the egcs-1.1 release installed in > the source tree. > We also expect wide scale, focused testing to start on July 11th. It would be desirable to release updated versions of BPcompat etc. together with gpc-2.1 (while in a separate package). In order to make this possible, gpc-980711 must be about the final version of gpc-2.1. > * July 31, 1998. Critial Bug Freeze Date. > If at all possible we would like to see the release sources freeze > except for critical bug fixes by July 31st. This may be overly > optimistic, but it's important to have a goal to shoot for. Besides the actual work on GPC, this means that all administrative tasks (copyright assignments etc.) must be finished before August. Those of you who are considering to contribute to the GPC compiler itself should contact me NOW so we have a chance to get these jobs done in time. (It involves papers that have to fly over the Atlantic!) > I would like to release as soon as possible in early August. > > Note that we have the ability to install changes into the mainline > sources during this process. However, I personally will be focusing > more and more on egcs-1.1 specific issues. > > It is highly likely we will have some minor releases based on > egcs-1.1; we will cross that bridge when the time comes. For GPC, we are planning to split the development into a "stable" line (gpc-2.1.x) and an "experimental" one (gpc-1998mmdd) in order to avoid long delays between the releases (about sqrt(3) years in this case)-: to happen again. > I also want to do a post-release review of the proposed schedule vs > the actual schedule used for egcs-1.1 so that we can improve the > process in the future. > > This message (and future updates) is available on > http://www.cygnus.com/egcs/egcs-1.1.html Greetings, Peter -- Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-980511 PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 Fight the SPAM and UBE! - http://spam.abuse.net/ - http://maps.vix.com/

3 3

GPC REF: do (texi)
by Miklos Cserzo 19 Jun '98

19 Jun '98

Hi Folks, here goes the "final" version. I am going to have a break for the next 3 weeks. More sections to come after that. miklos ___________________________ @c---------------------------------------------------------------------------- @node do @unnumberedsec do @cindex do @unnumberedsubsec Description The @samp{do} reserved word is used in combination with other Pascal keywords in many ways. For description and examples see the relevant reference sections: @samp{for}, @samp{while}, @samp{with}, @samp{to begin}, @samp{to end}. @unnumberedsubsec Standards @samp{do} is defined in the ISO-7185 Standard Pascal and supported by all known Pascal variants. @unnumberedsubsec See also @ref{for}, @ref{while}, @ref{with}, @ref{to begin}, @ref{to end}. @c----------------------------------------------------------------------------

1 0

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