- Gpc - gnu.de

Building GPC as a cross compiler for AVR Target (Linux x86 host)
by antony 13 May '04

13 May '04

hi all , i'm a newbie in compiler compiling, and in this mailing list. I'am trying to build an AVR gpc pascal compiler. with gcc-3.2.2, binutils 2.14, and gpc-20330507 gcc c cross compiler builds fine (with ../gcc-3.2.2/configure --prefix=$prefix --target=$target --enable-languages=c -v; make all) BUT ../gcc-3.2.2/configure --prefix=$prefix --target=$target --enable-languages=pascal -v; make all ends after a while with CC="`echo /home/data/gcc-3.2.2/build/gcc/xgcc -B/home/data/gcc-3.2.2/build/gcc/ -B/home/data/AVR/avr/bin/ -B/home/data/AVR/avr/lib/ -isystem /home/data/AVR/avr/include' ' | sed -e 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[^/][^:]*/$,../../\1,'`" PC="`echo ./xgpc -B./' ' | sed -e 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[^/][^:]*/$,../../\1,'`" CONFIG_SITE=nonexisting-file \ $src/p/rts/configure --silent > /dev/null --srcdir=$src/p/rts \ `if [ x@with_shared@ = xyes ]; then echo '--with-shared'; fi` configure: error: installation or configuration problem: C compiler cannot create executables. make[1]: *** [p/rts/Makefile] Erreur 1 make[1]: Leaving directory `/home/data/gcc-3.2.2/build/gcc' make: *** [all-gcc] Erreur 2 SO here are my questions: -Did someone tried such a cross building ? -successfully ? ;-) anything to help should be welcome. In fact, i dont't know where to begin thanks. Antony

2 1

gpc-20030830 released
by Frank Heckenbach 13 May '04

13 May '04

I've uploaded a new alpha to <http://www.gnu-pascal.de/alpha/>. IMPORTANT LICENSING NOTE: Due to the recent disputes over the GNU Free Documentation License by some parties, we made a detailed investigation of the license status of GPC's documentation. Thereby it turned out that the change to the FDL last November might not have been done absolutely correctly, since neither permission of some earlier authors nor of the FSF as the copyright holder was obtained for that change. To avoid any possible problems resulting from that, we decided to rewind the complete documentation to the state of 2002-11-27, the last version licensed under the GPL, and redo all later changes with explicit permission of the respective authors under the GPL. As the result, the whole documentation is now licensed under the GPL (again), and the license status of GPC versions 20021128, 20030209, 20030323 and 20030507 remains dubious. (Note: This affects only the documentation. The compiler itself has not changed its license and is therefore safe. Neither are programs compiled by such a GPC version affected.) I am not a lawyer, so I can't give you any advice what to do if you have used such a version, but my personal suggestion (also for technical reasons) is to change to the current release as soon as possible. Therefore, we have removed the problematic distributions from our server. Those who have made available binaries of one of the problematic versions are suggested to do the same (which, I suppose, they will do anyway, replacing them by the new release). For the same reason, we do not offer a patch against gpc-20030507, so you will have to download the whole GPC distribution to upgrade. (A patch against gpc-20021111 would be safe, but probably rather large and not worth the effort, since many users might not have gpc-20021111 handy anymore.) To avoid similar problems, we do not plan another attempt to change the license in the nearer future. It may be required for GCC integration someday, but not until the disputes over the FDL are finally settled. If you have any suggestions regarding these matters, please contact Peter Gerwinski or me by private mail. BUILD NOTE: This GPC version requires quite a recent version of Bison. (And building CVS Bison again requires bleeding edge versions of some other utilities.) Therefore, I have included the Bison generated files in the distribution (also in the "minimal" distribution), so you won't need Bison at all unless you remove them or change parse.y. New features: * `CompilerAssert' (fjf904*.pas) * options `--[no]-assert' renamed to `--[no]-assertions' (necessary to avoid a conflict with GCC) (@) * new options `--[no-]range-checking', also as short compiler directives `{$R+}'/`{$R-}' (default is on) (C, E, B, @) * new options `--[no-]methods-always-virtual' (fjf903*.pas) (M) * new options `--[no-]pointer-arithmetic', `--[no-]cstrings-as-strings', `-W[no-]absolute' (all of which `--[no-]extended-syntax' implies) * `Integer2StringBase', `Integer2StringBaseExt' * new constants `NumericBaseDigits', `NumericBaseDigitsUpper' * allow assigning, passing by value and returning objects, with assignments of an object of derived type to one of a base type (chief35[ab].pas, fjf451*.pas, fjf696[ef].pas, fjf884*.pas), BP compatible except for a bug in the BP feature itself (see the comment in `p/test/fjf451h.pas') (B) * new options `-W[no-]object-assignment' * warn (except in `--borland-pascal') if a virtual method overrides a non-virtual one (chief52*.pas) * warn when an non-abstract object type has virtual methods, but no constructor (chief51*.pas) * `--maximum-field-alignment' does not apply to `packed' records * `ArcSin', `ArcCos' Note: Range checking options are recognized, but range checking in general is *not* yet implemented. Only some special cases are checked, such as sets and dynamic subranges (subranges in local declarations and array slice access). Fixed bugs: * open internal files with `O_EXCL' on `Rewrite' (as a protection against symlink attacks) * `pow' and `**' are EP conformant now (in particular `x pow y = (1 div x) pow (Ây)' if `y' is negative and `x <> 0') (fjf908.pas) * `--enable-keyword'/`--disable-keyword' on the command-line makes GPC crash (david5.pas) * GPC accepts, but ignores, options with invalid suffixes (e.g. `--delphi-pascal') * wrong type-error when applying `Inc' to a type-casted pointer (peter3.pas) * with range checking enabled, check dynamic subrange/array size (fjf222*.pas, fjf813*.pas, fjf900*.pas) * GPC allows modification of conformant array bounds, result of `High'/`Low' etc. (fjf897*.pas) * don't allow linker names starting with a digit (fjf894.pas) * `SubStr' with constant arguments doesn't work in constants (gale1.pas) * handle `BitSizeOf' correctly for packed array fields, don't allow `SizeOf' on them (fjf891*.pas) * System: `BPReal' must be a packed record <3EE8A26D.C919BE7D(a)flexim.de> * schema types with initializers (drf1.pas, fjf886*.pas) * `Return' doesn't work for sets (fjf885.pas) * bug with arrays as fields of `packed' records (waldek6.pas) * don't allow duplicate imports in a module interface and implementation (nick1b.pas) * compensate for parser read-ahead in the lexer, so compiler directives don't become effective too early and error messages refer more closely to the correct source position (still not quite correct due to issues with Bison) * bug when dividing two integers with `/' (fjf481.pas) * don't allow `absolute' in type definitions * subranges with variable limits (couper[23].pas) 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

9 23

Compiler crash
by Marten Jan de Ruiter 12 May '04

12 May '04

Dear all, The reason I tried to switch to a newer compiler is that the older compiler crashed on, I suspect, memory usage. Increasing a const that determines the size of a number of arrays causes the crash. Restoring the const to the old value gives a fine compilation. Compiler gpc 20030830, based on gcc-3.2.1 also crashes on a linux machine. The crashes are consistent in the following way: At a clean start, i.e. after removing all the object and gpi files, the compiler crashes after line 86 in writestruct.p (see below). Subsequent compile runs, with the already compiled .o and .gpi files available, consistently show line 120 of the same file. Could be a --progress-messages thing, not related to the real cause of the crash, but I am not sure. I do not know how to single out the problem for this case. Aside of posting the backtrace, I am in the dark. Can anyone point me to information on how to attack this problem? Thanks for your consideration, Regards, Marten Jan % uname -a Linux so3 2.4.18-14smp #1 SMP Wed Sep 4 12:34:47 EDT 2002 i686 i686 i386 GNU/Linux % make_fem <snip> #progress# IO/writestruct.p (86) gpc: Internal error: Segmentation fault (program gpc1) Please submit a full bug report. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. gpc1: gpc exited with status 1 % gdb \ /cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/gpc1 \ core.22274 GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `/cluster3/deruiter/system/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/gpc1 /tmp/ccgaf2M'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 emit_library_call_value_1 (retval=0, orgfun=0x40014b60, value=0x0, fn_type=1076180224, outmode=VOIDmode, nargs=3, p=0xbfbddaf8 "�@~�\b�\b0۽ zC@\030\t>@\030B\001@") at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:3811 3811 memcpy (stack_usage_map, initial_stack_usage_map, (gdb) backtrace #0 emit_library_call_value_1 (retval=0, orgfun=0x40014b60, value=0x0, fn_type=1076180224, outmode=VOIDmode, nargs=3, p=0xbfbddaf8 "�@~�\b�\b0۽ zC@\030\t>@\030B\001@") at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:3811 #1 0x081020ed in emit_library_call (orgfun=0xbf7bd370, fn_type=3212563312, outmode=3212563312, nargs=-1082403984) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:4228 #2 0x080ac770 in emit_push_insn (x=0x403ecb40, mode=BLKmode, type=0x40294b60, size=0x403e0918, align=1, partial=0, reg=0x0, extra=0, args_addr=0x4024e070, args_so_far=0x527, reg_parm_stack_space=0, alignment_pad=0x40014210) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/expr.c:3467 #3 0x08102702 in store_one_arg (arg=0xbfffe2f8, argblock=0x4024e070, flags=0, variable_size=0, reg_parm_stack_space=0) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:4587 #4 0x080ffb23 in expand_call (exp=0x40437640, target=0x0, ignore=1) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/calls.c:2968 #5 0x080b35f3 in expand_expr (exp=0x40437a20, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/expr.c:7379 #6 0x0825c05a in expand_expr_stmt_value (exp=0xbfffe2f8, want_value=1, maybe_last=1076180224) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/stmt.c:2247 #7 0x0825bf91 in expand_expr_stmt (exp=0xbf7bd370) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/stmt.c:2201 #8 0x08051e1b in yyuserAction (yyn=562, yyrhslen=3, yyvsp=0x840e650, yyvalp=0xbfffe88c, yylocp=0xbfffe890, yystack=0xbfffe8f0) at parse.c:4580 #9 0x08058367 in yydoAction (yystack=0xbfffe8f0, yyk=0, yyrule=562, yyvalp=0xbfffe88c, yylocp=0xbfffe890) at parse.c:8218 #10 0x08057ee9 in yyglrReduce (yystack=0xbfffe8f0, yyk=0, yyrule=562, yyforceEval=1 '\001') at parse.c:8290 #11 0x08057436 in main_yyparse () at parse.c:8991 #12 0x080e3954 in compile_file () at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/toplev.c:2124 #13 0x080e85e9 in do_compile () at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/toplev.c:5218 #14 0x080e8659 in toplev_main (argc=-1082403984, argv=0x0) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/toplev.c:5250 #15 0x080f168b in main (argc=-1082403984, argv=0xbf7bd370) at /cluster3/deruiter/system/src/gcc-3.2.1/gcc/main.c:35 #16 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

4 6

Protected Var parameter bug
by Gale Paeper 11 May '04

11 May '04

While investigating a different issue, I found what I think is a problem with GPC's enforcement of Extended Pascal's actual parameter requirements for formal protected var parameters. The problem is that GPC allows function-access expressions to be used as the actual parameter for a formal protected var parameter and the function-access isn't a variable-access as required by Extended Pascal. For formal variable parameters, Extended Pascal requires the actual-parameter ... "shall be variable-access" (see paragraph 6.7.3.3) regardless of whether 'protected' is used in the formal parameter declaration. ('Protected' does not change the requirements for the actual-parameter. It just requires that no statements within the procedure/function shall threaten a protected formal-parameter identifier.) While GPC doesn't allow function-access expression actual-parameters for non-protected formal variable parameters, it incorrectly allows function-access expression actual-parameters to be used for protected formal variable parameters. A short test program that demonstrates the problem: {$extended-pascal} program ProtectVarParameterTest(input, output); var globalInt : Integer; function GetInteger: Integer; begin GetInteger := 1; end; procedure DoSomethingProtectedVar(protected var anInt : Integer); begin globalInt := anInt; end; procedure DoSomethingVar(var anInt : Integer); begin globalInt := anInt; end; begin globalInt := 0; DoSomethingProtectedVar(GetInteger); {WRONG} writeln('FAIL'); {DoSomethingVar(GetInteger); writeln('FAIL');} end. With the last two statements commented out, GPC compiles the program with no errors and running the compiled program produces and output of: FAIL. Uncommenting out the last two statements, GPC doesn't compile the program and generates error messages: ProtectVarParameterTest.pas: In main program: ProtectVarParameterTest.pas:26: error: type mismatch in argument 1 of `DoSomethingVar' ProtectVarParameterTest.pas:18: error: routine declaration (Note - the error messages in this test example are pretty obtuse. In the program where I initial found the problem, the error message of "error: reference expected, value given" is much clearer as to what the real cause of the problem is.) The command line and compiler information used on both versions of the test program were: gpc --automake -v ProtectVarParameterTest.pas -o ProtectVarParameterTest Reading specs from /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d6/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d6 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3 /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/gpcpp -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -quiet -v -iprefix /usr/bin/../lib/gcc-lib/powerpc-apple-darwin/3.3/ -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__DYNAMIC__ ProtectVarParameterTest.pas -fautomake -famtmpfile=/var/tmp//cc2sio8x.gpa /var/tmp//ccmxZG89.i GNU Pascal Compiler PreProcessor version 20030507, based on gcc-3.3 (Darwin/PowerPC) /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/gpc1 /var/tmp//ccmxZG89.i -fPIC -quiet -dumpbase ProtectVarParameterTest.pas -auxbase ProtectVarParameterTest -version -fautomake -famtmpfile=/var/tmp//cc2sio8x.gpa -o /var/tmp//ccPyvMwU.s GNU Pascal version is actually 20030507, based on gcc-3.3 GNU Pascal version 3.3 (powerpc-apple-darwin) compiled by GNU C version 3.3. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Gale Paeper gpaeper(a)empirenet.com

2 1

Re: FlateDecode
by Prof A Olowofoyeku (The African Chief) 11 May '04

11 May '04

Frank Heckenbach wrote: >I suggest to link to the existing C libraries (libz and/or libpng). I >don't generally recommend translating standard libraries to Pascal. >The C libraries are tested by more people and (usually) maintained, >and writing a Pascal interface is much easier than translating the >whole library (especially if only a small part of the library >interface is actually needed, like in many cases I know). In principle, yes. However, the problem that I find is that many of the existing C libraries contain mainly low level stuff (at least, to me). Eike's zlib unit is an excellent interface to the C library, but I find that I am struggling to use it to decompress a compressed file, or to create one. What I personally find helpful are high level functions, built on top of the interface units, so that, for example, I can "BlockRead" from a file to a buffer, pass that buffer to a high level (de)compression routine, retrieve the processed data in another buffer, and "BlockWrite" that to a file, or do whatever with it. PasZlib provides this kind of facility, which is why I decided to use it. But of course, it won't compile under GPC. Perhaps Eike could provide some high level functions if he has the time? e.g., 1. zlib_compress (inbuf, outbuf : pointer; insize, outsize : cardinal; Var result : cardinal); 2. zlib_decompress (inbuf, outbuf : pointer; insize, outsize : cardinal; Var result : cardinal); Then one can do something like; while not eof (infile) do begin blockread (infile, infbuf^, sizeof (infbuf^), bRead); zlib_compress (infbuf, outbuf, bRead, sizeof (outbuf^), compsize); blockwrite (outfile, outbuf^, compsize, bWritten); end; Or perhaps I am just underestimating how difficult it would be to write such high level functions ... Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

4 3

Linking libraries between C and pascal
by Marten Jan de Ruiter 11 May '04

11 May '04

Dear all, The default name for a pascal procedure does not work correctly anymore. (See the output for version number and so on below). Explicitly declaring the name works, so a workaround is available. That can be done as follows: procedure p_routine; attribute (name='P_routine') If I am making a mistake somewhere, I would be glad to hear. Regards, Marten Jan de Ruiter % gpc --version gpc 20030830, based on gcc-3.2.1 % cat c_unit.c #include <stdio.h> extern void c_routine(); extern void P_routine(); void c_routine() { printf("c_routine invoked\n"); P_routine(); printf("c_routine done\n"); } % cat use_c_unit.p program test_c_unit; (*$L c_unit.c *) procedure c_routine; external name 'c_routine' ; procedure p_routine; begin writeln('pascal routine invoked'); end; begin c_routine; p_routine; end. % gpc --automake use_c_unit.p -o use_c_unit c_unit.o: In function `c_routine': c_unit.o(.text+0x13): undefined reference to `P_routine' collect2: ld returned 1 exit status # hmmm... does P_routine actually exist? Or does it have another name? % gpc -c --automake use_c_unit.p ; grep P_routine use_c_unit.o Binary file use_c_unit.o matches # Now I am stuck...

3 4

Noddy question
by John Ollason 11 May '04

11 May '04

I think that the following program ought to produce a run-time error but it doesn't. I have had a look at the GPC manual but I can't find any compiler directive that says Check array bounds, and I did rather think that the philosophy of Pascal was to prevent this sort of thing happening without the user having to take any special action. So, is there a way of generating the code that says 'Check array bounds' (I know other dialects of Pascal that do this by default). Version 2.95.2 19991024 (release), running under RedHat 6.1, Cartman. Yes, I know it's old, but my version of VMWare won't work on the later kernels. ----------------- program arraytest(output); var i:integer; a,b:array[1..5] of integer; begin for i:=1 to 5 do a[i]:=i; for i:=1 to 10 do b[i]:=a[i]; for i:=1 to 20 do writeln(i,' ',b[i]); end. ------------------- The results file follows: ----------- 1 1 2 2 3 3 4 4 5 5 6 1 7 2 8 3 9 4 10 5 11 0 12 0 13 0 14 0 15 0 16 0 17 0 18 0 19 0 20 0 --------- John O.

3 2

gpc compilation failed under BSD
by karim_f＠mysunrise.ch 11 May '04

11 May '04

Hello I had tried to compile gpc under freebsd last year. But didn`t get far. Now I`m trying with a newer version of the compiler. gpc-20030830 gcc-3.3.1 . This is the last make output : gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -Wtraditional -pedantic -Wnong-long -o xgpc p/gpc.o prefix.o version.o intl.o ./intl/libintl.a ../libiberty/libiberty.a gcc -o p/diagnostic.o -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -II/usr/home/karim/pascal/gcc-3.3.1/gcc -I/usr/home/karim/pascal/gcc-3.3.1/gcc/p -I/usr/home/karim/pascal/gcc-3.3.1/gcc/config -I/usr/home/km/pascal/gcc-3.3.1/gcc/../include -DGPC gcc: No input files specified *** Error code 1 Stop in /usr/home/karim/pascal/gpc-build/gcc. *** Error code 1 Stop in /usr/home/karim/pascal/gpc-build. Has anybody a clue how to solve this problem ? Greetings Karim

3 5

FlateDecode
by Adriaan van Os 10 May '04

10 May '04

Does anyone on the list know about source code in Pascal for FlateDecode compression ? It is used in PNG images and in PDF files. Regards, Adriaan van Os

4 3

Missing BP feature
by Prof A Olowofoyeku (The African Chief) 09 May '04

09 May '04

Hi I think I have a missing feature or incompatibility with BP. I am trying to compile the paszlib units with GPC. Given these declarations: { Data structure describing a single value and its code string. } type ct_data_ptr = ^ct_data; ct_data = record fc : record case byte of 0:(freq : ush); { frequency count } 1:(code : ush); { bit string } end; dl : record case byte of 0:(dad : ush); { father node in Huffman tree } 1:(len : ush); { length of bit string } end; end; this code does not compile: var static_ltree : array[0..L_CODES+2-1] of ct_data = ( (fc:(freq: 12);dl:(len: 8)), (fc:(freq:140);dl:(len: 8)), (fc:(freq: 76);dl:(len: 8)), (fc:(freq:204);dl:(len: 8)), (fc:(freq: 44);dl:(len: 8)), (fc:(freq:172);dl:(len: 8)), (fc:(freq:108);dl:(len: 8)), (fc:(freq:236);dl:(len: 8)), (fc:(freq: 28);dl:(len: 8)), [....] Instead, I get the error: "trees.pas:448: field `freq' not found" Any clues? Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

2 1