Gpc November 2002

gpc@gnu.de

33 participants
48 discussions

Re: gpc-20021111 supports gcc-3.1.1
by Waldek Hebisch 19 Nov '02

19 Nov '02

Maurice Lombardi wrote: >That was part of the solution. With this patch it goes up to the compilation >of strings.pas. It dies with > >------------------------------------------------------------------ > >../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes >-Wmissing-declarations -g -O2 --unit-path=/dev/c/djgpp/gnu/gcc311s2/gnu/gcc-3.11/gcc/p/rts >--automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat >/dev/c/djgpp/gnu/gcc311s2/gnu/gcc-3.11/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.11'" >/dev/c/djgpp/gnu/gcc311s2/gnu/gcc-3.11/gcc/p/rts/string.pas >gpc1.exe: internal error: Segmentation violation >Please submit a full bug report, >with preprocessed source if appropriate. >See <URL:http://www.gnu-pascal.de/todo.html> for instructions. >make.exe[3]: *** [string.o] Error 1 >make.exe[3]: Leaving directory `c:/djgpp/gnu/gcc311s2/gnu/gcc-3.11/build.djg/gcc/p/rts' >make.exe[2]: *** [pascal.rts] Error 2 >make.exe[2]: Leaving directory `c:/djgpp/gnu/gcc311s2/gnu/gcc-3.11/build.djg/gcMaurice Lombardi wrote: >That was part of the solution. With this patch it goes up to the compilation >of strings.pas. It dies with > >------------------------------------------------------------------ > >../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes >-Wmissing-declarations -g -O2 --unit-path=/dev/c/djgpp/gnu/gcc311s2/gnu/gcc-3.11/gcc/p/rts >--automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat >/dev/c/djgpp/gnu/gcc311s2/gnu/gcc-3.11/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.11'" >/dev/c/djgpp/gnu/gcc311s2/gnu/gcc-3.11/gcc/p/rts/string.pas >gpc1.exe: internal error: Segmentation violation >Please submit a full bug report, >with preprocessed source if appropriate. >See <URL:http://www.gnu-pascal.de/todo.html> for instructions. >make.exe[3]: *** [string.o] Error 1 >make.exe[3]: Leaving directory `c:/djgpp/gnu/gcc311s2/gnu/gcc-3.11/build.djg/gcc/p/rts' >make.exe[2]: *** [pascal.rts] Error 2 >make.exe[2]: Leaving directory `c:/djgpp/gnu/gcc311s2/gnu/gcc-3.11/build.djg/gc >make.exe[1]: *** [stage2_build] Error 2 >make.exe[1]: Leaving directory `c:/djgpp/gnu/gcc311s2/gnu/gcc-3.11/build.djg/gcc' >make.exe: *** [bootstrap] Error 2 > I was able to reproduce the problem in cross-compiler targetting djgpp. Looks like another bug with debug info. Try re-making with 'CFLAGS=-O2'. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

2 3

Re: Probs with variant records
by Wood David 19 Nov '02

19 Nov '02

Hi, I've tried Eike's example with DEC Pascal (no errors) and looked at the ref. manual. This notes that a variant must be the last component of the record (which it is). It also makes sense as the allocated memory can then be set to the biggest variant. There is also a run-time diagnostic (%PAS-F-REFINAVAR) which should pick up any attempt to read from or write to an inactive record variant. However, it is clear that this isn't happening - it should. GPC should as well. Experimenting with the data, I find that they do share memory - as soon as Width is assigned, Radius takes this value (if the types match). If Radius is a real, the value becomes scrambled. Run-time checking should be available, as the only benefit of variants is to either save memory or pick-up on erroneous data combinations. However, just like array bounds checking, it may be an undesirable overhead for which there should be appropriate compiler options. Dave Wood. The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

1 0

gpc driver
by Prof A Olowofoyeku (The African Chief) 18 Nov '02

18 Nov '02

Hi all Is anyone else interested in having environment variables for the GPC driver to cover things like "unit-path", etc.? I think that being able to set things like that (in addition to GxC_EXEC_PREFIX and LIBRARY_PATH, etc.) might be very useful to people who don't want to (or who don't know how to) use Makefiles, or who don't want very long command lines, or whatever other reason. I personally would like to be able to set something like: UNIT_PATH OBJECT_PATH, etc. I might well patch the GPC driver for Mingw to do just that - but I just thought I might not be the only one who might find something like this useful, and if so, then perhaps this could be added to the main GPC sources. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

5 14

Bug in lexer
by CBFalconer 18 Nov '02

18 Nov '02

The following source (cut down already) PROGRAM pprt(input, output); (* Nils Goesche <ngo(a)cartan.de> wrote in comp.programming 0 is defined as the empty set -- denoted {} 1 is defined as the set that contains 0 -- {0} = {{}} 2 is defined as the set containing 0 and 1 -- {0, 1} = {{}, {{}}} and so on. (Mathematicians will note that to have this ``definitionÂ´Â´ make sense, you'll first have to introduce the notion of an inductive set and the infinity axiom -- but I think this is enough to explain the idea behind the construction). Now, the programming problem is to produce a nice, pretty printed definition of a natural number n. *) VAR n : integer; (* 1----------------1 *) PROCEDURE prettyprt(n : integer); BEGIN (* prettyprt *) END; (* prettyprt *) (* 1----------------1 *) BEGIN (* pprt *) REPEAT write('Value to display: '); readln(n); IF n >= 0 THEN prettyprt(n); writeln; UNTIL n < 0; END. (* pprt *) results in the following error from gpc > [1] c:\p\pprt>gpc -v pprtx.p > Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.953/specs > gpc version 20020910, based on 2.95.3 20010315/djgpp (release) > c:/djgpp/lib/gcc-lib/djgpp/2.953/gpcpp.exe -lang-pascal -v -famtmpfile=c:/djgpp > /tmp\ccaaaaaa -fstandard-pascal -D__STANDARD_PASCAL__ -fmixed-comments -undef -D > __GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=1 -D__GPC_VERSION__=2 > .1 -D__GPC_RELEASE__=20020910 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN > __=1 -D__WORDS_LITTLE_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -Dunix -Di386 -DGO32 > -DDJGPP=2 -DMSDOS -D__OS_DOS__=1 -D__unix__ -D__i386__ -D__GO32__ -D__DJGPP__=2 > -D__MSDOS__ -D__OS_DOS__=1 -D__unix -D__i386 -D__GO32 -D__DJGPP=2 -D__MSDOS -Asy > stem(unix) -Asystem(msdos) -Acpu(i386) -Amachine(i386) -Acpu(i386) -Amachine(i38 > 6) -Di386 -D__i386 -D__i386__ -D__tune_pentium__ -imacros c:/djgpp/lib/gcc-lib/d > jgpp/2.953/djgpp.ver -remap pprtx.p c:/djgpp/tmp\ccSv07U1.i > GNU Pascal Compiler PreProcessor version 20020910, based on gcc-2.95.3 20010315/ > djgpp (release) (80386, BSD syntax) > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > c:/djgpp/i586-pc-msdosdjgpp/include > c:/djgpp/lib/gcc-lib/djgpp/2.953/include > c:/djgpp/include > End of search list. > pprtx.p:32: unterminated string or character constant > pprtx.p:10: possible real start of unterminated constant I suspect something in the quoted comment line 10 is driving it up the wall, such as a "'". gpc is being run through an alias that supplies --standard-pascal. Are you trying to have the lexer do too much at once? Once a comment is started nothing except *) (or maybe } or EOF) should close it. I took the isolated ' out of the comment, and the error changed. So I think there is enough to annoy it in there. It compiles through rhide150b though! Also PascalP has no problem. -- Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!

3 3

GPC with Emacs
by Florian Lindner 17 Nov '02

17 Nov '02

Hello, I'm looking for a tutorial or How-To for using GPC with Emacs 21 and pascal-mode. Thx, Florian

1 0

Dropping some predefined symbols
by Frank Heckenbach 16 Nov '02

16 Nov '02

Hi, as you might know, GPC predefines some symbols depending on the dialect options given on the command-line, e.g., `__BORLAND_PASCAL__' if `--borland-pascal' was given, so programs/units can check the dialect in `{$ifdef}' directives. Actually, I'm not sure if it's used at all -- generally it's better to write a program/unit for one specific dialect and, especially in case of units, put the respective dialect option (`{$gnu-pascal}' if the default is wanted) at the top, so it doesn't matter if the main program is compiled with a different dialect. However, the main problems with those symbols are that the internal handling is a little ugly and, what's more, that the symbols don't change when the dialect is changed via a compiler directive. E.g., the following program writes 3 times 'BP' if compiled with `--borland-pascal' and 3 times 'GPC' if not (unlike what one might expect): program Foo; begin {$ifdef __BORLAND_PASCAL__} WriteLn ('BP'); {$endif} {$ifdef __GNU_PASCAL__} WriteLn ('GPC'); {$endif} {$gnu-pascal} {$ifdef __BORLAND_PASCAL__} WriteLn ('BP'); {$endif} {$ifdef __GNU_PASCAL__} WriteLn ('GPC'); {$endif} {$borland-pascal} {$ifdef __BORLAND_PASCAL__} WriteLn ('BP'); {$endif} {$ifdef __GNU_PASCAL__} WriteLn ('GPC'); {$endif} end. Of course, it would be possible to change the behaviour, but this will take some effort and it would be rather obscure having the dialect options change the defines (e.g., what if the symbol corresponding to the previous dialect was defined manually, should it still be unset?). However, there's already an alternative that works well, that's `{$ifopt}'. The following program outputs what one would expect. program Foo; begin {$ifopt borland-pascal} WriteLn ('BP'); {$endif} {$ifopt gnu-pascal} WriteLn ('GPC'); {$endif} {$gnu-pascal} {$ifopt borland-pascal} WriteLn ('BP'); {$endif} {$ifopt gnu-pascal} WriteLn ('GPC'); {$endif} {$borland-pascal} {$ifopt borland-pascal} WriteLn ('BP'); {$endif} {$ifopt gnu-pascal} WriteLn ('GPC'); {$endif} end. `{$ifopt}' has been supported for quite some time, at least before GPC 2.1, so programs will not require a new GPC version or a GPC version conditional when changed to `{$ifopt}'. Therefore, to avoid confusion about the behaviour of the symbols (and to clean up GPC as always), I'd like to drop them. Any objections? 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

2 1

Re: gpc-20021111 supports gcc-3.1.1
by Frank Heckenbach 16 Nov '02

16 Nov '02

Prof A Olowofoyeku (The African Chief) wrote: > I am building the snapshot at the moment for Mingw (gcc-2.93-8). The > build process halted with errors relating to undefined "sys_siglist" in > gpc.c. I checked up on this, and had to comment out the declaration > below: > "#define strsignal(N) (sys_siglist[(N)])" > > Under Mingw strsignal() is defined in libiberty.h, In gcc-2.95.3 (I assume your 2.93 was a typo) the declaration in libiberty is commented out. Does Mingw use some special patches to libiberty.h? If so, what do they look like? If they `#define strsignal', it should be enough to put an `#ifndef strsignal' around the definition in gpc.c. Or does it provide an external declaration? Try the following: --- /home/gpc/orig/gpc.c Wed Nov 6 07:35:25 2002 +++ /home/gpc/p/gpc.c Thu Nov 14 00:38:03 2002 @@ -125,17 +125,21 @@ #define PEXECUTE_LAST 2 #define PEXECUTE_SEARCH 4 #define PEXECUTE_VERBOSE 8 +#ifndef HAVE_STRSIGNAL +#define strsignal(N) (sys_siglist[(N)]) +#endif #endif #if defined (EGCS) && !defined (EGCS97) +/* If the system doesn't provide strsignal, we get it defined in + libiberty but no declaration is supplied. */ +#if !defined (HAVE_STRSIGNAL) && !defined (strsignal) +extern const char *strsignal PARAMS ((int)); +#endif #undef _ #define _(String) String #endif #ifndef HOST_BIT_BUCKET #define HOST_BIT_BUCKET "/dev/null" -#endif - -#ifndef HAVE_STRSIGNAL -#define strsignal(N) (sys_siglist[(N)]) #endif #ifdef GCC_2_95_3 > but it seems that > the configure script doesn't look there. I suppose not. Since libiberty.h is distributed with gcc, it can assume it knows what's in there. Or is for some reason another libiberty.h (system-wide installed) used instead of the one that comes with gcc? That might be a bug in the build process. 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

4 7

installation problem with gcc 3.1.1
by Emil Jerabek 16 Nov '02

16 Nov '02

Hi, after building gpc 20021111 with the 3.1.1 backend (on Linux/IA32) I've installed it by "make pascal.install-with-gcc". The compiler then wouldn't compile even a trivial "program p; begin end.", collect2 died with a complain that it can't find libgcc_eh (sorry, I'm writing this on another machine, and I don't recall the exact error message). libgcc_eh.a was actually built, and moving it to the destination directory solved the problem, so I assume the trouble is in the above mentioned target in the Makefile. Emil

2 1

gpc-20021111 supports gcc-3.1.1
by Frank Heckenbach 16 Nov '02

16 Nov '02

Hi, I've uploaded a new alpha (gpc-20021111) to http://gnu-pascal.de/alpha/ It contains large changes compared to the previous version, as can be seen from the size of the diff file (if you've always fetched the diffs and were going to sometime get a fresh tarball in order to have a "reference point", now might be a good time ;-). The most important change is that GPC now works with gcc-3.1.1 (i.e., with the backend sources of gcc-3.1.1; the version of GCC used to compile GPC itself should not matter), thanks to Waldek Hebisch's patches. However, please note that this port is very new, and has not been tested as much as the gcc-2.x based GPC's. Thw two code generation bugs I mentioned in a recent mail have been fixed. There's only one new known bug with gcc-3.1.1 (fjf341b.pas), but it is a compile-time problem and only occurs in a very special situation. I'll try to fix it soon, but I didn't want to furter delay this release because of it. Debug info generation with gcc-3.1.1 is partially broken. The dwarf debug info format doesn't work yet. Since it's now the default under, e.g., Linux, you might want to try `-gstabs' (use the stabs format which was the default with gcc-2.x). Debug info for object methods also doesn't work yet, so if you use objects, you'll probably have to compile without debug info for now. If you need GPC in a production environment, we recommend not to use GPC based on gcc-3.1.1 yet. But we'd welcome if you like to help testing with gcc-3.1.1. In this case, please don't report any bugs related to debug info (for now). In particular, if you run the test suite, add `EXTRA_TEST_PFLAGS=-g0' on the test make command line (because otherwise, debug info is turned on by default when testing). I expect that most new bugs will be compiler crashes on wrong input programs (instead of in in addition to proper error messages). Please report them (as well as any other bugs, of course). You might want to try configuring GPC with `--enable-checking' (both for gcc-2.95.x and gcc-3.1.1). This will enable additional internal checks which make the compiler (not the generated code) a little slower, but may detect possible problems earlier and better. The compiler will abort with internal errors (usually tree check errors) then. Please also report such cases. The rest of the changes of this GPC release are mostly internal cleanups, in connection with the gcc-3 port and to generally make the compiler more robust -- though they might cause a few minor new problems in the short term, but that's what alphas are for. If you can, please test it with your code and report any new problems so we can fix them soon. There are also some changes in the automake mechanism again (thanks to Marten Jan de Ruiter for analysis and code). They should make it substantially faster in situations with many units where most of them are already up to date. I hope the changes don't break anything, but those who use automake in complex projects might want to test it carefully. As announced, I dropped the syntax `type foo = procedure (Integer, Real)' (i.e., without parameter names). If anyone had used it and gets errors now, just add the parameter names, and put a `;' in place of the `,'. Also, many obsolete and C-ish features from the preprocessor have been dropped. I suppose most of them were unknown to almost all GPC users, anyway, and I hope the change won't affect anyone. Those interested can find the details in the ChangeLog (entry of 2002-09-29 under gpcpp.c). Another possibly incompatible change is that GPC will now reject duplicate variable declarations (not yet for routines; I'll also do this, but it will be more complicated due to interfaces, `forward' declarations etc.). Of course, the new behaviour is according to (and even demanded by) the standard. It should only affect those who used "header files" in a C-ish way by which every "module" gets "external" declarations of its own variables. But since GPC has been supporting two real mechanisms for modularization (EP modules and BP units) for a long time, this should be no big issue, I hope. For a long time, it was not possible to build GPC when the `p' directory is a symlink in the gcc directory. This is now possible. Furthermore, GPC no more modifies the Makefiles depending on the GCC version. So it is now possible to use the same GPC source tree for building with several GCC versions at the same time (provided you use a separate build directory which is strongly recommended, anyway). 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

3 4

Environment Variables within Code.
by Andrew McCall 15 Nov '02

15 Nov '02

Hi, Is it possible to access environment variables within gpc code, for example $USER ? -- Thanks, Andrew McCall Internet/Linux System Administrator I.C.T. Division Oldham MBC Civic Centre West Street Oldham OL1 1UU Tel : 0161 911 3990 Fax : 0161 911 3998 Email : it.andrew.mccall(a)oldham.gov.uk ********************************************************************** 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. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.oldham.gov.uk **********************************************************************

5 4

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 November 2002