- Gpc - gnu.de

Internal GPC Problem
by Matthew Blaine 19 May '07

19 May '07

Hello, I've downloaded and successfully installed Dev+GNU Pascal from: http://gnu-pascal.de/contrib/chief/win32/dev_gnu_pascal-1.9.4.8.exe I've successfully built build_units.pas, however now I'm having trouble using the gpc compiler. Trying to compile the GrClock.pas example, for instance, works. However, trying to compile a project that includes multiple source files, as opposed to just a single source file, does not work. I receive the following error: gpc: Internal GPC problem: internal option `--amtmpfile' not given I've been searching the mailing list archives, as well as Google for a solution to this problem. I've found others with the same issue, but no solution. If anyone can help me, I'd really appreciate it. Thanks, M. Blaine ____________________________________________________________________________________Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/

2 1

gpc: Internal error
by Pascal Viandier 17 May '07

17 May '07

Hi all, Back on Sun to GPC conversion after a year or so. Things are going pretty well with gpc except on one point: I run gpc on a Sparc Solaris 10 box. As soon as the cpu gets a bit loaded gpc fails with the following error: gpc: Internal error: Alarm Clock (program gpc1) Please submit a full bug report. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. If I restart it it compiles some modules and stops again (I use gp). I searched for the words 'Alarm Clock' in gpc sources with no success so I cannot figure what is the problem. Any solution, clue, idea or patch is welcome. Regards. Pascal Viandier The gpc I use is: Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.4/specs Configured with: ../gcc-3.4.4/configure --enable-languages=pascal Thread model: posix gpc version 20051116, based on gcc-3.4.4

2 2

[Fwd: GCC 4.2.0 Released]
by Adriaan van Os 16 May '07

16 May '07

-------- Original Message -------- Subject: GCC 4.2.0 Released Date: Tue, 15 May 2007 17:29:42 -0700 From: Mark Mitchell <mark(a)codesourcery.com> Reply-To: mark(a)codesourcery.com To: gcc-announce(a)gcc.gnu.org GCC 4.2.0 has been released. GCC 4.2.0 is a major release, containing new functionality not available in GCC 4.1.x or previous GCC releases. See: http://gcc.gnu.org/gcc-4.2/changes.html for more information about changes in GCC 4.2.0. This release is available from the FTP servers listed here: http://www.gnu.org/order/ftp.html If you encounter difficulties using GCC 4.2, please do not contact me directly. Instead, please visit http://gcc.gnu.org for information about getting help. As always, a vast number of people contributed to this GCC releases -- far too many to thank individually! -- Mark Mitchell CodeSourcery mark(a)codesourcery.com (650) 331-3385 x713

2 1

Hi and Lo functions
by MegaBrutal 04 May '07

04 May '07

Hello for all. Sorry, if my question is too dumb, but I just started to make interest in GPC in the last few days. I'm advanced in Pascal language, I used Turbo Pascal and Borland Delphi before. But I haven't used GPC before, and I'm really not advanced in Unix-based operating systems. I'm trying to compile one of my projects under Debian Linux with GPC, but it stops with an error message, that GPC doesn't know the Hi and Lo functions. I don't know that they are present in GPC in another unit, or not. I think some functions that supports the same thing must be there. Here's the purpose of the mentioned funtions: function Hi(X: word): byte; function Hi(X: integer): byte; Hi function returns the high-order byte of the specified word or 16-bit integer. function Lo(X: word): byte; function Lo(X: integer): byte; Lo function returns the low-order byte of the specified word or 16-bit integer.

3 4

GPC cross-compilation error
by Ilya Minkov 29 Apr '07

29 Apr '07

Hello. I'm trying to build a GPC for a deeply embedded non-unixoid platform (sh-elf) and running into an error of this kind: --- 8< --- ../../gcc-3.4.6/gcc/p/script/mkdir-p p/rts src=`cd ../../gcc-3.4.6/gcc && pwd` && \ cd ./p/rts && \ CC="`echo /home/eye/dc/dc-chain/build-gcc-sh-elf-3.4.6/gcc/xgcc -B/home/eye/dc/dc-chain/build-gcc-sh-elf-3.4.6/gcc/ -B/home/eye/dc/sh-elf/sh-elf/bin/ -B/home/eye/dc/sh-elf/sh-elf/lib/ -isystem /home/eye/dc/sh-elf/sh-elf/include -isystem /home/eye/dc/sh-elf/sh-elf/sys-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[2]: *** [p/rts/Makefile] Fehler 1 make[2]: Verlasse Verzeichnis '/home/eye/dc/dc-chain/build-gcc-sh-elf-3.4.6/gcc' make[1]: *** [all-gcc] Fehler 2 make[1]: Verlasse Verzeichnis '/home/eye/dc/dc-chain/build-gcc-sh-elf-3.4.6' --- >8 --- And i believe the error message is quite correct too. The build process is working in the following steps, as far as i understood it. I am not the author of the compilation script, so i'm not quite sure. 1. compile a semi-broken C cross-compiler. 2. compile newlib (a C standard library) using this compiler. 3. throw away the compiler, use something from newlib to reconfigure GCC 4. compile the correct cross-compiler for selected languages, namely C, C++, and in my case also Pascal. It seems to me that xgcc is the broken compiler from the first step, which is not intended to produce executables, just libraries. Besides, it generates the code for the target system, where a compiler would be plain unable to run. The compilers have to be compiled with ordinary GCC and would run on this computer. If it helps, i have the script which steers the compilation attached to this message. It expects binutils-2.16, gcc-3.4.6, newlib-1.12.0, and gnupascal-20060325 unpacked in its directory. Other versions might work if Makefile is corrected, but e.g. binutils-2.17 and gcc starting with version 4 will not work. Please note that GPC is the only compiler whose compilation breaks. Before i added it, C and C++ compilers compiled and worked successfully. Does anyone have a clue where i start to fix it? Cheers, Ilya Minkov

2 1

[RFC] adding gdb.pascal subdir
by Pierre Muller 13 Apr '07

13 Apr '07

I managed to recompile autoconf 2.59 and it seems to work. I added several new files for this pascal testsuite. Even these basic tests already add two failures to the testsuite: One from types.exp ptyp 'a simple string' does not recognize this as a string. A second one from hello.exp this is specific to gpc compiler as explained in my previous email, because start does not stop the program at the logical expected first line of the main procedure in the program source. lib/pascal.exp contains code to look for both gpc and fpc but the result is inconsistent for me: On the bash prompt I find both gpc in /usr/bin and fpc in /usr/local/bin but the expect which function seems to only find gpc :( I struggled a lot with the expect syntax, and the result is probably far from nice for people used to program that kind of language. Comments most welcome... Pierre Muller GDB pascal language maintainer 2007-04-13 Pierre Muller <muller(a)ics.u-strasbg.fr> * lib/pascal.exp: New file. * gdb.pascal/types.exp: New file. Simply tests the type of literals, adapted from gdb.fortran/types.exp * gdb.pascal/hello/hello.pas: New file. Simple program printing 'Hello, world!'. * gdb.pascal/hello.exp: New file. Small tests on hello.pas source. * gdb.pascal/Makefile.in: New file. * configure.ac: gdb.pascal sub directory added to list of directories. * configure: Regenerated using autoconf 2.59. Index: configure =================================================================== RCS file: /cvs/src/src/gdb/testsuite/configure,v retrieving revision 1.23 diff -u -p -r1.23 configure --- configure 23 Jan 2007 17:11:54 -0000 1.23 +++ configure 13 Apr 2007 14:51:51 -0000 @@ -3669,6 +3669,7 @@ do "gdb.threads/Makefile" ) CONFIG_FILES="$CONFIG_FILES gdb.threads/Makefile" ;; "gdb.trace/Makefile" ) CONFIG_FILES="$CONFIG_FILES gdb.trace/Makefile" ;; "gdb.xml/Makefile" ) CONFIG_FILES="$CONFIG_FILES gdb.xml/Makefile" ;; + "gdb.pascal/Makefile" ) CONFIG_FILES="$CONFIG_FILES gdb.pascal/Makefile" ;; *) { { echo "$as_me:$LINENO: error: invalid argument: $ac_config_target" >&5 echo "$as_me: error: invalid argument: $ac_config_target" >&2;} { (exit 1); exit 1; }; };; Index: configure.ac =================================================================== RCS file: /cvs/src/src/gdb/testsuite/configure.ac,v retrieving revision 1.6 diff -u -p -r1.6 configure.ac --- configure.ac 23 Jan 2007 17:11:55 -0000 1.6 +++ configure.ac 13 Apr 2007 14:51:51 -0000 @@ -117,4 +117,4 @@ AC_OUTPUT([Makefile \ gdb.fortran/Makefile gdb.server/Makefile \ gdb.java/Makefile gdb.mi/Makefile \ gdb.objc/Makefile gdb.threads/Makefile gdb.trace/Makefile \ - gdb.xml/Makefile]) + gdb.xml/Makefile gdb.pascal/Makefile]) Index: gdb.pascal/Makefile.in =================================================================== RCS file: gdb.pascal/Makefile.in diff -N gdb.pascal/Makefile.in --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/Makefile.in 13 Apr 2007 14:51:54 -0000 @@ -0,0 +1,24 @@ +VPATH = @srcdir@ +srcdir = @srcdir@ + +EXECUTABLES = hello/hello + +MISCELLANEOUS = + +all info install-info dvi install uninstall installcheck check: + @echo "Nothing to be done for $@..." + +clean mostlyclean: + -find . -name '*.o' -print | xargs rm -f + -find . -name '*.ali' -print | xargs rm -f + -find . -name 'b~*.ad[sb]' -print | xargs rm -f + -rm -f *~ a.out xgdb *.x *.ci *.tmp + -rm -f *~ *.o a.out xgdb *.x *.ci *.tmp + -rm -f core core.coremaker coremaker.core corefile $(EXECUTABLES) + -rm -f $(MISCELLANEOUS) twice-tmp.c + +distclean maintainer-clean realclean: clean + -rm -f *~ core + -rm -f Makefile config.status config.log + -rm -f *-init.exp + -rm -fr *.log summary detail *.plog *.sum *.psum site.* Index: gdb.pascal/hello.exp =================================================================== RCS file: gdb.pascal/hello.exp diff -N gdb.pascal/hello.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/hello.exp 13 Apr 2007 14:51:54 -0000 @@ -0,0 +1,59 @@ +# Copyright 2007 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, +# USA. + +if $tracelevel then { + strace $tracelevel +} + +load_lib "pascal.exp" + +set testdir "hello" +set testfile "${testdir}/hello" +set srcfile ${srcdir}/${subdir}/${testfile}.pas +set binfile ${objdir}/${subdir}/${testfile} + +file mkdir ${objdir}/${subdir}/${testdir} +if {[gdb_compile_pascal "${srcfile}" "${binfile}" executable [list debug ]] != "" } { + return -1 +} + +gdb_exit +gdb_start +gdb_reinitialize_dir $srcdir/$subdir +gdb_load ${binfile} + +# Verify that "start" lands inside the right procedure. +if { [gdb_start_cmd] < 0 } { + untested start + return -1 +} +gdb_test "" \ + ".* at .*hello.pas.*" \ + "start" +gdb_test "break print_hello" \ + ".* at .*hello.pas.*" \ + "break print_hello" +gdb_test "cont" \ + "Breakpoint .*, print_hello.* at .*hello.pas.*" \ + "cont" +gdb_test "print st" \ + ".* = ''.*" \ + "" +send_gdb "next\n" +gdb_test " print st" \ + ".* = 'Hello, world!'.*" \ + "" Index: gdb.pascal/types.exp =================================================================== RCS file: gdb.pascal/types.exp diff -N gdb.pascal/types.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/types.exp 13 Apr 2007 14:51:54 -0000 @@ -0,0 +1,109 @@ +# Copyright 1994, 1995, 1997, 1998, 2007 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +# Please email any bugs, comments, and/or additions to this file to: +# bug-gdb(a)prep.ai.mit.edu + +# This file was adapted from old Chill tests by Stan Shebs +# (shebs(a)cygnus.com). +# Adapted to pascal by Pierre Muller + +if $tracelevel then { + strace $tracelevel +} + +set prms_id 0 +set bug_id 0 + +# Set the current language to pascal. This counts as a test. If it +# fails, then we skip the other tests. + +proc set_lang_pascal {} { + global gdb_prompt + + if [gdb_test "set language pascal" ""] { + return 0; + } + + if ![gdb_test "show language" ".* source language is \"pascal\".*"] { + return 1; + } else { + return 0; + } +} + +proc test_integer_literal_types_accepted {} { + global gdb_prompt + + # Test various decimal values. + # Should be integer*4 probably. + gdb_test "pt 123" "type = int" +} +proc test_character_literal_types_accepted {} { + global gdb_prompt + + # Test various character values. + + gdb_test "pt 'a'" "type = char" +} + +proc test_string_literal_types_accepted {} { + global gdb_prompt + + # Test various character values. + + gdb_test "pt 'a simple string'" "type = string" +} + +proc test_logical_literal_types_accepted {} { + global gdb_prompt + + # Test the only possible values for a logical, TRUE and FALSE. + + gdb_test "pt TRUE" "type = bool" + gdb_test "pt FALSE" "type = bool" +} + +proc test_float_literal_types_accepted {} { + global gdb_prompt + + # Test various floating point formats + + # this used to guess whether to look for "real*4" or + # "real*8" based on a target config variable, but noone + # maintained it properly. + + gdb_test "pt .44" "type = double" + gdb_test "pt 44.0" "type = double" + gdb_test "pt 10e20" "type = double" + gdb_test "pt 10E20" "type = double" +} + +# Start with a fresh gdb. + +gdb_exit +gdb_start +gdb_reinitialize_dir $srcdir/$subdir + +if [set_lang_pascal] then { + test_integer_literal_types_accepted + test_logical_literal_types_accepted + test_character_literal_types_accepted + test_string_literal_types_accepted + test_float_literal_types_accepted +} else { + warning "$test_name tests suppressed." 0 +} Index: gdb.pascal/hello/hello.pas =================================================================== RCS file: gdb.pascal/hello/hello.pas diff -N gdb.pascal/hello/hello.pas --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gdb.pascal/hello/hello.pas 13 Apr 2007 14:51:54 -0000 @@ -0,0 +1,14 @@ +program hello; + +var + st : string; + +procedure print_hello; +begin + st:='Hello, world!'; + writeln(st); +end; + +begin + print_hello; +end. Index: lib/pascal.exp =================================================================== RCS file: lib/pascal.exp diff -N lib/pascal.exp --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ lib/pascal.exp 13 Apr 2007 14:51:55 -0000 @@ -0,0 +1,123 @@ +# Copyright 2007 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, +# USA. + +load_lib libgloss.exp + +set pascal_compiler_is_gpc 0 +set pascal_compiler_is_fpc 0 +set pascal_compiler "" +set gpc_compiler "gpc" +set fpc_compiler "fpc" +set pascal_init_done 0 +proc pascal_init {} { + global pascal_init_done + global pascal_compiler_is_gpc + global pascal_compiler_is_fpc + global gpc_compiler + global fpc_compiler + global tool_root_dir + + if { $pascal_init_done == 1 } { + exit; + } + if ![is_remote host] { + if { [which $gpc_compiler] != 0 } { + set pascal_compiler "$gpc_compiler"; + set pascal_compiler_is_gpc 1; + verbose -log "GNU pascal compiler found"; + } +# } elseif { [which $fpc_compiler] != 0 } { + if { [which $fpc_compiler] != 0 } { + set pascal_compiler "$fpc_compiler"; + set pascal_compiler_is_fpc 1; + verbose -log "Free Pascal pascal compiler found"; + } + } + set pascal_init_done 1; + return $pascal_compiler +} + +proc gpc_compile {source dest type options} { + global gpc_compiler + set add_flags ""; + if {$type == "object"} { + append add_flags " -c" + } + + if { $type == "preprocess" } { + append add_flags " -E" + } + + if { $type == "assembly" } { + append add_flags " -S" + } + + if { $options == "debug" } { + append add_flags " -g" + } + + set result [remote_exec host $gpc_compiler "-o $dest --automake $add_flags $source"]; + return $result; +} + +proc fpc_compile {source dest type options} { + global fpc_compiler + set add_flags ""; + if {$type == "object"} { + append add_flags " -Cn" + } + + if { $type == "preprocess" } { +# There is no such option for Free Pascal +# append add_flags " -E" + } + + if { $type == "assembly" } { + append add_flags " -al" + } + + if { $options == "debug" } { + append add_flags " -g" + } + + set result [remote_exec host $fpc_compiler "-o$dest $add_flags $source"]; + return $result; +} + +proc gdb_compile_pascal {source dest type options} { + global pascal_init_done + global pascal_compiler_is_gpc + global pascal_compiler_is_fpc + + if { $pascal_init_done == 0 } { + pascal_init; + } + if { $pascal_compiler_is_fpc == 1 } { + set result [fpc_compile $source $dest $type $options] + } elseif { $pascal_compiler_is_gpc == 1 } { + set result [gpc_compile $source $dest $type $options] + } else { + unsupported "No pascal compiler found"; + return "No pascal compiler. Compilation failed." + } + + if ![file exists $dest] { + unsupported "Pascal compilation failed: $result" + return "Pascal compilation failed." + } +} +

1 0

range check 32-bit and 64-bit
by Chris Ferrall 11 Apr '07

11 Apr '07

The following program behaves differently under 32-bit and 64-bit compilation. In 64-bit the "max()" function returns a large integer when a value is sent out of bounds (output not shown). The point of the max() is to keep a value from going out of bounds. This problem does not occur in 32-bit code. To make sure that range checking was on in both cases I set "a" out of range after the max(). Is this a feature of the cpu option? And/or is there a more robust way of keeping within range? Thanks for any help. P.S. I've already received the following response from Frank. > I'm not using a 64 bit machine myself, so I can only speculate. I > hope Waldek can say more about it. > > I think the problem might be that GPC treats "arange" internally as > an unsigned type (i.e., as a subrange of "Cardinal", not "Integer") > and on the 64 bit machine performs the "a - 1" unsigned which causes > the range error. (On the 32 bit machine it can do it in LongestInt > which covers the range of "Cardinal" as well as negative values, but > on 64 bit, it currently doesn't support larger integer types. This > might explain the different behaviour.) > > Of course, this is a GPC bug as, according to ISO, your program is > perfectly valid (given a suitable definition of "Max" which isn't > part of ISO). > > So the bugfix might be to make subrange types signed when the range > allows (which would always be the case in valid ISO programs). > > Frank -------------------- program test(input,output); type arange = 0..5; var a,b : arange; begin a:= 0; b := max(a-1,0); /* keep b in range */ writeln('here ',b,' now really go out of range '); a := b-1; /* take a out of range to make sure range checking is on */ writeln('there ',a); end. -------------------- Output 32-bit: here 0 now really go out of range a.out: value out of range (error #300 at 180e3) 64-bit a.out: value out of range (error #300 at 100009d2b) 32-bit compilation gpc maxtest.pas 64-bit gpc $g64pth $m64opt maxtest.pas where $m64opt= "-mcpu=ultrasparc3 -m64" --------------------- Here is the version output hpc1014@sfnode0$ gpc -v Reading specs from /opt/gpc/20051104/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/opt/gpc/20051104 --enable-languages=pascal Thread model: posix gpc version 20051104, based on gcc-3.4.3 -- Chris Christopher Ferrall <http://econ.queensu.ca/%7Eferrall/> Associate Professor of Economics Department of Economics <http://www.econ.queensu.ca> Queen's University <http://www.queensu.ca> Kingston, Ontario CANADA K7L 3N6 ferrallc AT post.queensu.ca Mackintosh-Corry Rm A519 ph: 613-533-6658 fx: 613-533-6668

3 4

[RFH] adding gdb.pascal subdir
by Pierre Muller 11 Apr '07

11 Apr '07

I discussed a while ago with Daniel Jacobowitz the possibility of adding some basic tests for pascal language support. My main problem is that I never used anything like expect of autoconf before. The first step is to add a new directory called gdb.pascal in gdb/testsuite directory. But I am already lost here: I saw in the sources that I should add reference to this directory in configure.ac but if I run autoconf after the configure script is changed a lot. I read in the Contribute file that we do not need to commit the regenerated configure file, but if we want to check the effect before committing, the fact that the regenerated configure is different from the one automatically regenerated on the CVS repository might lead to unnoticed problems. The second point is that there are mainly two free pascal compiler: GNU pascal, (gpc executable) and Free Pascal, (fpc executable) The pascal testsuite will probably need to be handled a little bit differently depending on which pascal compiler is used (the command line options are completely different for the two compilers). Furthermore, none of these two compilers are included by default on all platform, as can be expected for GCC. This means that we need to find a way to check for the presence of a valid pascal compiler. There might be some equivalent code for fortran or ada compilers, but these seem to be special switches of gcc whereas both gpc and fpc. So the main question is where should I include code to test for the presence of a valid pascal compiler and how to only run the tests in gdb.pascal if a valid compiler was found. Pierre Muller Maintainer of GDB pascal language support. PS1: RFH in the message title stands for 'Request for help', I am not sure it is standard, but hope it is OK. PS2: specifically for gpc mailinglist: is there a unified and version independent symbol name for the main procedure in the main program? Using 'break main' stops at some <implicit code> The main procedure seems to be called _p__M0_main_program but this is for gpc 20060325 based on gcc 3.4.6 for Ubuntu Is this symbol still valid? Is it supposed to stay unchanged in future releases? To be able to break at the first line of the main procedure seems like a minimal requirement that is not met for GPC and GDB right now.

1 0

[RFH] adding gdb.pascal subdir
by Pierre Muller 10 Apr '07

10 Apr '07

RFH stands for 'Request for help'; I discussed a while ago with Daniel Jacobowitz the possibility of adding some basic tests for pascal language support. My main problem is that I never used anything like expect of autoconf before. The first step is to add a new directory called gdb.pascal in gdb/testsuite directory. But I am already lost here: I saw in the sources that I should add reference to this directory in configure.ac but if I run autoconf after the configure script is changed a lot. I read in the Contribute file that we do not need to commit the regenerated configure file, but if we want to check the effect before committing, the fact that the regenerated configure is different from the one automatically regenerated on the CVS repository might lead to unnoticed problems. The second point is that there are mainly two free pascal compiler: GNU pascal, (gpc executable) and Free Pascal, (fpc executable) The pascal testsuite will probably need to be handled a little bit differently depending on which pascal compiler is used (the command line options are completely different for the two compilers). Furthermore, none of these two compilers are included by default on all platform, as can be expected for GCC. This means that we need to find a way to check for the presence of a valid pascal compiler. There might be some equivalent code for fortran or ada compilers, but these seem to be special switches of gcc whereas both gpc and fpc. So the main question is where should I include code to test for the presence of a valid pascal compiler and how to only run the tests in gdb.pascal if a valid compiler was found. Pierre Muller Maintainer of GDB pascal language support. PS, specifically for gpc mailinglist: is there a unified and version independent symbol name for the main procedure in the main program? Using 'break main' stops at some <implicit code> The main procedure seems to be called _p__M0_main_program but this is for gpc 20060325 based on gcc 3.4.6 for Ubuntu Is this symbol still valid? Is it supposed to stay unchanged in future releases? To be able to break at the first line of the main procedure seems like a minimal requirement that is not met for GPC and GDB right now.

2 1

A pascal reference reader
by Russ Whitaker 20 Mar '07

20 Mar '07

Hi Attached are two bz2 files: When unziped, #1 is a plain text file. #2 is a pascal source for a command-line reader of #1. Before compiling, you should change line 10 so it can find where you want to leave #1. Am interested in feedback. a) Do you like it? b) What would you like added the most? If there's enough interest will work on it some more. Russ

1 0

Undefined local symbol error with gpc20060325 on gcc-4.0.3
by Peter Schorn 18 Mar '07

18 Mar '07

I have built gpc20060325 with gcc-4.0.3 on OS X (PowerPC) basically just from the available sources (gcc-core-4.0.3.tar.bz2 and gpc-20060325.tar.bz2). The only patch I applied was related to building a shared library (see the modified gcc-4.0.3/gcc/p/rts/Makefile.in in the attachment). Compiling the attached program "test.pas" yields an assembler error: peter% /Developer/Pascal/gpc403/bin/gpc --version gpc 20060325, based on gcc-4.0.3 ... peter% /Developer/Pascal/gpc403/bin/gpc -mdynamic-no-pic -Os -save-temps --nonlocal-exit -c test.pas test.s:unknown:Undefined local symbol L2 In this particular case this seems to be due to the combination of -Os and --nonlocal-exit but I have seen the same error message also for -O0 (together with --nonlocal-exit) for more complex programs. Can anyone shed light on this problem? Best regards, Peter Schorn

2 2

Compatible versions of gpc and gdb ?
by Ian Thurlbeck 15 Mar '07

15 Mar '07

Dear All A user is trying to get kdevelop+gdb working with gpc. I have installed gpc-20060325 + gcc-3.4.4 on Fedora Core 6 which has gdb-6.5 installed. However, the usual gpc -g -o hello hello.p produces under gdb: (gdb) list 1 <implicit code>: No such file or directory. in <implicit code> I tried -ggdb and -gstabs+ as well... Can anyone recommend a combination of gpc/gdb which works well? Many thanks Ian -- Ian Thurlbeck http://www.stams.strath.ac.uk/ Statistics and Modelling Science, University of Strathclyde Livingstone Tower, 26 Richmond Street, Glasgow, UK, G1 1XH Tel: +44 (0)141 548 3667 Fax: +44 (0)141 552 2079

3 2

GPC unit can't be found
by Silvio a Beccara 12 Mar '07

12 Mar '07

Dear friends, I tried to compile a programme of mine using this version of gpc, I compiled together with gcc: [abeccara@sm1 pi]$ gpc -v Reading specs from /home/abeccara/progs/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ./configure --enable-languages=pascal --prefix=/home/abeccara/progs/gcc-3.4.3 Thread model: posix gpc version 20050331, based on gcc-3.4.3 This is the command line: gpc -O3 -w --automake \ --ignore-function-results \ -foptimize-sibling-calls \ --implicit-result \ --unit-path=./units \ --unit-destination-path=unit-obj \ -L$MPICH \ -L. pimb.pas -o pimb but I constantly get this error: error: `gpc.gpi' must be recompiled I never got it before. I tried to set GPC_EXEC_PREFIX as follows: [abeccara@sm1 pi]$ echo $GPC_EXEC_PREFIX /home/abeccara/progs/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/ and also to copy all units from /home/abeccara/progs/gcc-3.4.3/lib/gcc/i686-pc-linux-gnu/3.4.3/units into my units directory but nothing changes. Can you help me? Kind regards Silvio a Beccara -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Problemi di Liquidità? Con Logos Finanziaria 30.000 in 24 ore a dipendenti e lavoratori autonomi con rimborsi fino a 120 mesi clicca qui * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2907&d=12-3

1 0

Re: Warum geht es nicht mit einer
by Frank Heckenbach 11 Mar '07

11 Mar '07

In the German list, Roland Goretzki found a GPC bug (roland2). I've made a fix for older GPC versions (such as 20040516 he's using), which is attached. However, in Waldek's newer GPC versions, the respective code is "#if 0"d, with the comment: "/* save_expr would cause problems */". Unfortunately this comment is not very informative to me. I've built gpc-20060325 with the code back in ("#if 1") on i586-pc-linux-gnu (Debian 3.1) with gcc-3.4.4, and all tests passed (except roland2, of course). So I suppose the problems only affect gcc-4.x or other platforms, is this right? Then I've applied my patch and all test passed, including roland2. Anyway, the point is that in the original code, save_expr is only applied to the string length (which is used twice). However, the whole string expression may contain side-effects (as in roland2.pas), and is accessed for the length (once using save_expr, twice otherwise) and for the chars. So we need to save this. This is what my patch does, removing the (now useless) save_expr for the length. Waldek's code still saves the length, in different way, so the problem still exists. Perhaps save_expr_string works with gcc-4/other platforms, so we don't need the new code. If not, can you change your code to save the whole string, or change save_expr_string if necessary (as you probably know what you'll have to test then; I don't). Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

3 3

Re: cctools-590.36 for Mac OS X (was: Indirect jmp redux)
by Adriaan van Os 08 Mar '07

08 Mar '07

Frederick Karl Kepner DuPuy wrote: > Hi. Regarding gpc for Mac OS X on Intel, I found a thread in the > archives (see below) from October 2006 concerning an error message a > user (Nestor Aguilera) got in compiling even the simplest programs. > Unless I'm misreading the thread, no final conclusion was reached. Is > anything further known now? > > Here's the thread: > http://www.gnu-pascal.de/crystal/gpc/en/mail13854.html > And the gist of the error messages: indirect jmp without `*' > > I'm having the same issue he had: programs which used to compile and > execute happily with the gpc for PPC compiler are less happy with the > gpc for Intel compiler--- they're still compiling, but issuing this > error message repeatedly as they do so. > > I believe the output executes OK; but you can see why this is > unsettling. So: is this a problem, or just an annoyance to be lived > with? And is it happening to everybody trying to use gpc for Mac on > Intel? (If so I'm curious as to why it hasn't been discussed since > October.) > > (Please pardon my near-complete ignorance, by the way.) Sorry for the lack of response on the mentioned thread so far. I have been extremely busy. It might help to download and install the right assembler and linker Binary installer <http://www.microbizz.nl/cctools-590.36.dmg> Sources <http://www.microbizz.nl/cctools-590.36.tar.bz2> Let me know if this solves the problem. Regards, Adriaan van Os

2 1

make for GPC on Solaris and quad processing
by Bernd Rehling 28 Feb '07

28 Feb '07

Hello, these are my first trials with GPC: The compilation with GNU-make failed on Solaris 10 in context with 'quad processing'. I guess this stands for long floating point data types. The 'gmake' command fails with: ../.././xgpc -B../.././ -L../.. -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/home/paspro/Compiler/gcc-3.2.3/gcc/p/rts --unit-path=/home/paspro/Compiler/gcc-3.2.3/gcc/p/units "/home/paspro/Compiler/gcc-3.2.3/gcc/p/utils/binobj.pas" Undefined first referenced symbol in file _Q_itoq ../../libgpc.a(files.o) (symbol scope specifies local binding) _Q_qtou ../../libgcc.a(_fixunstfdi.oS) (symbol scope specifies local binding) _Q_add ../../libgpc.a(files.o) (symbol scope specifies local binding) _Q_flt ../../libgpc.a(files.o) (symbol scope specifies local binding) _Q_mul ../../libgpc.a(files.o) (symbol scope specifies local binding) _Q_sub ../../libgpc.a(files.o) (symbol scope specifies local binding) ld: fatal: Symbol referencing errors. No output written to ./binobj On the internet I found hints, that Solaris in general has different 128bit processing: " Sparc 64bit ABI requires different syntax of the quad floating point software emulation (_Qp_* routines) than what is common in gcc. 128bit long doubles are passed by reference to these functions and if it returns a long double, they take the first argument as a pointer to that long double. ... " I couldn't find a solution. The make works with the languages C,C++ and Fortran, but not with Pascal. Can somebody working on Solaris help how to compile GPC or where I can get binaries ? Best Regards Bernd -- Bernd Rehling Hermann-Rodewald-Str.3 Raum 411 Tel.: (0431) 880-4475 Institut für Informatik der Christian-Albrechts-Universität zu Kiel

1 0

Runner script
by Mirsad Todorovac 27 Feb '07

27 Feb '07

Mr. Waldek, Could you please publish your runner script so I could run properly test suite despite the presence of PAX process killer on my Linux kernel? IMHO these half-done tests are of no use to anybody, so please if you would be so kind to grant my request. Regards, Mirsad "Be conservative in what you do, be liberal in what you accept from others." -- Jon Postel

2 2

CRT unit and UTF-8 displays
by Andreas K. Foerster 18 Feb '07

18 Feb '07

Hello, there is some trouble when the display is set to UTF-8 and my program uses the CRT unit. Some characters are just shown as several spaces or even scramble the display. For example I cannot use the german letter sharp s #$C3#$9F (U+00DF) or german quotation marks #$E2#$80#$9E ... #$E2#$80#$9C (U+201E ... U+201C). It works fine without the CRT unit. Also when I use FreePascal it is all right. I've tried to use the command "SetPCCharset(false);", but that didn't help. Is there anything else I could try? -- AKFoerster

2 5

Test results gpc-20060325 on gcc-4.1.1
by Mirsad Todorovac 17 Feb '07

17 Feb '07

Here are the test results on my box. Test Run By mtodorov on 2007-02-13 22:15:43 Native configuration is i686-pc-linux-gnu (domac) gpc 20060325, based on gcc-4.1.1, flags: -g -O3 -W -Wall -Wno-unused TEST agettext2test.pas: SKIPPED: could not set locale `de_DE' TEST aregextest.pas: SKIPPED: librx not installed TEST backtracerr.pas: 14c14,71 < ./test_run: line 339: 20465 Killed ./"$A_OUT" "$1" --- > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > c: about to a(yy) > a: about to xx() > d: > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > a: back from xx() > c: back from a(yy) > b: back from yy > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > b: back from b(c) > program: back from b( d ) failed TEST fay.pas: 1c1,12 < ./test_run: line 339: 420 Killed ./"$A_OUT" "$1" --- > stacking 1 > Doing successors of 1 > stacking 2 > Doing successors of 2 > Now checking if 2 is an SCC root > Now checking if 1 is an SCC root > 1 is an SCC root; SP= 2 T= 1 > Yield SCC should pass 1 out to TakeUSCC > YieldUSCC passes 1 to TakeUSCC > TakeUSCC receives V= 1 from YieldUSCC > The SCC's constituents are: > 2 1 failed TEST fjf165a.pas: SKIPPED: German locale not installed TEST fjf206c.pas: failed: ./fjf206c.pas:2: error: arithmetical overflow ./fjf206c.pas:2: error: constant overflow in expression TEST fjf322.pas: 'result_0.length./fjf322.pas: In function `o': gpc1: warnings being treated as errors ./fjf322.pas:8: warning: ' is used uninitialized in this function failed TEST fjf35.pas: ./test_run: line 339: 16467 Killed ./"$A_OUT" "$1" TEST fjf395a.pas: a Value 2 TEST fjf395b.pas: a Value -128 TEST fjf403b.pas: failed: failed TEST fjf563e.pas: failed: failed TEST fjf587b.pas: 'concat_0._p_Schema_[3]{lb: 1 sz: 1}./fjf587b.pas: In procedure `Foo': gpc1: warnings being treated as errors ./fjf587b.pas:5: warning: ' is used uninitialized in this function failed TEST fjf779a.pas: failed: TEST fjf779b.pas: failed: TEST fjf779e.pas: failed: TEST fjf779f.pas: failed: TEST fjf779g.pas: failed: TEST fproc.pas: 4c4,11 < Stack frame: 0 formal print =./test_run: line 339: 1897 Killed ./"$A_OUT" "$1" --- > Stack frame: 0 formal print = 4 formal routine = 4 > Stack frame: 1 formal print = 4 formal routine = 4 > Stack frame: 2 formal print = 4 formal routine = 4 > Stack frame: 3 formal print = 4 formal routine = 4 > Stack frame: 4 formal print = non-local jump > Stack frame: 8 formal print = -1 formal routine = -1 > Stack frame: 9 formal print = -1 formal routine = -1 > Stack frame: 10 formal print = -1 formal routine = -1 failed TEST gmptest.pas: SKIPPED: libgmp (>=3.x) not installed TEST knuth1.pas: ./test_run: line 339: 175 Killed ./"$A_OUT" "$1" TEST nicola4c.pas: failed: TEST nlgpp.pas: ./test_run: line 339: 21147 Killed ./"$A_OUT" "$1" TEST nlgpp2.pas: 13c13,30 < ./test_run: line 339: 12038 Killed ./"$A_OUT" "$1" --- > DoGoto 3 True > OK > Recursive end 3 True > Recursive before goto 4 True > Recursive end 4 True > Recursive before goto 5 True > Recursive end 5 True > Recursive before goto 6 True > Recursive end 6 True > Recursive before goto 7 True > Recursive end 7 True > Recursive before goto 8 True > Recursive end 8 True > Recursive before goto 9 True > Recursive end 9 True > Recursive before goto 10 True > Recursive end 10 True > Main end failed TEST t6334-2.pas: ./test_run: line 339: 27049 Killed ./"$A_OUT" "$1" TEST t6p6p3p4.pas: ./test_run: line 339: 7676 Killed ./"$A_OUT" "$1" # of tests 5070 # of expected passes 5044 # of unexpected failures 22 # of unsupported tests 4 Mirsad "Be conservative in what you do, be liberal in what you accept from others." -- Jon Postel

3 6

gcc-4.1.2
by Russ Whitaker 14 Feb '07

14 Feb '07

hi The gcc home page has announced gcc-4.1.2 is released. Should I try it with the existing gpc or wait for the next one? russ

1 0

GPC 20060325 @ gcc-4.1.1 build problems
by Mirsad Todorovac 13 Feb '07

13 Feb '07

I used the patch gcc-4.1-5.diff on gcc-4.1.1, and a simple gpc-build % ../gcc-4.1.1/configure --enable-languages=pascal gpc-build % make ... on Linux Debian sarge box. It breaks like this. Rerunning make gives this: mtodorov@domac:~/pascal/gpc20060325@gcc-4.1.1-build$ make make[1]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/libiberty' make[3]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/libiberty/testsuite' make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/libiberty' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/fixincludes' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/fixincludes' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/intl' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/intl' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/build-i686-pc-linux-gnu/libiberty' make[3]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/build-i686-pc-linux-gnu/libiberty/testsuite' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/build-i686-pc-linux-gnu/libiberty/testsuite' make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/build-i686-pc-linux-gnu/libiberty' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/build-i686-pc-linux-gnu/fixincludes' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/build-i686-pc-linux-gnu/fixincludes' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/libcpp' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/libcpp' make[2]: Entering directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/gcc' gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition-Wmissing-format-attribute -DHAVE_CONFIG_H -o xgpc p/gpc.o prefix.o version.o \ ../libcpp/libcpp.a ../libiberty/libiberty.a p/gpc.o(.text+0xab30): In function `main': ../../gcc-4.1.1/gcc/p/gpc.c:6941: undefined reference to `gcc_init_libintl' collect2: ld returned 1 exit status make[2]: *** [xgpc] Error 1 make[2]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/admin/mtodorov/pascal/gpc20060325(a)gcc-4.1.1-build' make: *** [all] Error 2 mtodorov@domac:~/pascal/gpc20060325@gcc-4.1.1-build$ Any advice? Thanks. Regards, Mirsad "Be conservative in what you do, be liberal in what you accept from others." -- Jon Postel

3 5

Full pathnames for units
by Prof A Olowofoyeku (The African Chief) 06 Feb '07

06 Feb '07

Hi (this is probably FAO Frank/Waldek) When building a program and there is an error in one of the units used by the program, gpc gives an error in this format: "timing.pas: In function `GetTimingCounter': timing.pas:123: error: function call used as a statement timing.pas: In main program: timing.pas:160: error: function call used as a statement gpc1.exe: gpc exited with status 1" Would it be possible to provide the full path name to the source file in which the error occurred? - e.g., "/pas/units/timing.pas: In function `GetTimingCounter': /pas/units/timing.pas:123: error: function call used as a statement /pas/units/timing.pas: In main program: /pas/units/timing.pas:160: error: function call used as a statement gpc1.exe: gpc exited with status 1" This would be very helpful for those developing IDEs (e.g., me) so that the source file can be opened into the IDE, and the cursor placed on the first line containing the error. If this is possible, a patch would be fine at this point. Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

2 2

Proper directory for included C code
by Harmonious Botch 05 Feb '07

05 Feb '07

I'm writing a rather simple program to include c code in gnu pascal. When the compiler encounters the following line of pascal code: {$L cnp.c} it generates the following error: file `cnp.c' not found Yet the c source code and the pascal source code are in the same directory. I tried working around this by using the full file descriptor, like this: {$L /home/hb/pas/cnp.c } but gpc removes the forward slashes, and gives me this error message: file `homehbpascnp.c' not found So, my question is: where does gpc expect to find the c code? Or, a different angle on the same issue: how do I tell it where to find the c code? Thanks -- View this message in context: http://www.nabble.com/Proper-directory-for-included-C-code-tf3175523.html#a… Sent from the Gpc mailing list archive at Nabble.com.

2 3

gpc Vs. gcc
by Andrew Ball 02 Feb '07

02 Feb '07

Hello, Is it likely that I can compile gpc with this...? gcc (GCC) 4.1.2 20070110 prerelease (NetBSD nb1 20070110) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - Andy Ball.

1 0

Re: GCC-4.1.1
by Maurice Lombardi 01 Feb '07

01 Feb '07

CBFalconer a écrit: > Mirsad Todorovac wrote: > >>On Fri, 12 Jan 2007, Russ Whitaker wrote: >> > > ... snip ... > >>>p.s. According to the gcc site, gcc-4.1.2 should be out soon. >>>( days? weeks? ) >> >>These are very good news. >> >>Thank you, Mr. Whitaker. > > > gcc 4.1.0 is available for DJGPP, but I cannot find a port of gpc > to this version. even gcc 4.1.1 is available on the Pavenis Web Site at http://ap1.pp.fi/djgpp/gcc/4.1.1/gcc411.html With it I have built last summer gpc20060325 for djgpp v2.03p2, using the patches gpc-4.1-5f.diff.gz gcc-4.1-5f.diff.gz found on the Waldek Hebisch web site http://www.math.uni.wroc.pl/~hebisch/gpc I had not uploaded it to the gpc web site because running the gpc test suite gives (rerun today): /djgpp/b/gnu/gcc-4.11/gcc/p/script/mkdir-p p/test { \ echo "# Automatically generated from /djgpp/b/gnu/gcc-4.11/gcc/p/test/Makefile."; \ echo "# Don't change manually."; \ echo ""; \ sed -e "s,^srcdir *=.*,srcdir=`cd /djgpp/b/gnu/gcc-4.11/gcc/p/test && pwd`,; \ s,^PC *=.*,PC=`pwd`/xgpc -B`pwd`/,; \ s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --no-unit-path --unit-path=`cd /djgpp/b/gnu/gcc-4.11/gcc/p/units && pwd`," \ /djgpp/b/gnu/gcc-4.11/gcc/p/test/Makefile; \ } > p/test/Makefile || { rm -f p/test/Makefile; false; } echo timestamp > "p/stamp-test-Makefile" cd ./p/test && c:/djgpp/bin/make.exe MASK="" EXTRA_TEST_PFLAGS=" -gstabs" TEST_RUN_FLAGS="" "pascal.check-dejagnu" make.exe[1]: Entering directory `c:/djgpp/b/gnu/build.gcc/gcc/p/test' rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core GP= PC="c:/djgpp/b/gnu/build.gcc/gcc/xgpc -Bc:/djgpp/b/gnu/build.gcc/gcc/" PFLAGS="-I ../rts --no-unit-path --unit-path=c:/djgpp/b/gnu/gcc-4.11/gcc/p/units --autobuild -g -O3 -W -Wall -Wno-unused -gstabs" PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused -gstabs" SRCDIR="c:/djgpp/b/gnu/gcc-4.11/gcc/p/test" TEST_MAKE_FLAG=test-make-flag "c:/djgpp/b/gnu/gcc-4.11/gcc/p/test/test_run" | tee test_log | "c:/djgpp/b/gnu/gcc-4.11/gcc/p/test/test_sum" -d Test Run By dosuser on 2007-01-30 13:41:18 Native configuration is djgpp (KNAUTIE) === gpc tests === Running target any Running testsuite ... UNSUPPORTED: fjf165a.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas UNSUPPORTED: longr2.pas FAIL: nicola4c.pas FAIL: y2k.pas === gpc Summary === # of tests 5070 # of expected passes 5055 # of unexpected failures 13 # of unsupported tests 2 c:/djgpp/b/gnu/build.gcc/gcc/xgpc version 20060325, based on gcc-4.1.1 (The y2K FAIL is erratic and spurious, related not to gpc, but to peculiarities of the clock when running in a DOS box under W98se) whereas there is NO error with gcc-3.4.4 I am always afraid that a beginner downloads the latest version, stump on a bug and concludes that gpc is not a good compiler. Since you seem interested I just downloaded it in the usual place http://www.gnu-pascal.de/contrib/maurice/gpc-20060325-gcc-411.i586-pc-msdos… and flagged it with a large ALPHA !!! I hope this will warn enough beginners. Maurice -- 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 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

3 3

GCC-4.1.1
by Mirsad Todorovac 29 Jan '07

29 Jan '07

Hi, and Happy New Year [with delay]! Best wishes for your health and progress in work on project and in life for New Year! BTW, I've been checking the archives, and last message Re: GCC-4.1.1 was from Jul 21 2006. The thread says the GCC-4.1.1 port is in alpha stage. How far did the progress go, and when it could be considered beta or "release"? Regards, Mirsad "Be conservative in what you do, be liberal in what you accept from others." -- Jon Postel

4 4

Gnu pascal and gtk
by Harmonious Botch 29 Jan '07

29 Jan '07

I recently installed gnu pascal on fedora. I have assumed that I installed it correctly because the tradional 'hello world' compiles and runs fine. I then installed gtk. I then tried a gtk version of hello world, as follows: (************************ program begins here *************) program hw( output ); {$include "gtk.inc"} begin GtkInit; Window := GtkWindowNew(GTK_WINDOW_TOPLEVEL); GtkWidgetShow(Window); GtkMain; end. (************************ program ends here ****************) I try to compile with: gpc -Wall -v -c hw.pas -o hw and I get the following error: /urs/local/i686-pc-linux-gnu/include/gtk.inc:9: module/unit `glib' could not be imported If I try to compile with: gpc --automake -Wall -v -c hw.pas -o hw I get this error: /urs/local/i686-pc-linux-gnu/include/gtk.inc:9: module/unit `glib' could not be compiled Glib is referenced in gtk.inc, as follows: (************ code snippet starts here*************) { Glib and Gdk standard units. } uses Glib, GModule, Gdk, GdkTypes; (************ code snippet ends here*************) So, I have 2 questions: 1) What do these errors mean? I am assuming that they mean that I have some file in the wrong directory. 2)What are the proper paths for the installation of the gtk libs? ( Absolute, or relative to the working directory ) Answers to those, or any general advice on how to install & use gtk will be much appreciated. Thanks HB -- View this message in context: http://www.nabble.com/Gnu-pascal-and-gtk-tf3133597.html#a8682964 Sent from the Gpc mailing list archive at Nabble.com.

1 0

compile problem on hp-ux 11.23
by Stoyan Angelov 16 Jan '07

16 Jan '07

hello all, i am trying to compile gpc-20060325 with the gcc-3.4.4 core on hp-ux 11.23 (PA-RISC) but i get the following error when the compilation process reaches the rts directory: gmake[2]: Entering directory `/home/aduritz/truetrue/gnu-pascal/gpc-build/gcc/p/rts' echo '{ rts-config.inc. Generated automatically from rts-config.h. }' > rts-config.inc sed -e 's,/\*,{,g;s,\*/,},g;s,^[ \t]*#$.*$,{$\1},' rts-config.h >> rts-config.inc /home/aduritz/truetrue/gnu-pascal/gpc-build/gcc/xgcc -B/home/aduritz/truetrue/gnu-pascal/gpc-build/gcc/ -B/opt/gpc/hppa2.0w-hp-hpux11.23/bin/ -B/opt/gpc/hppa2.0w-hp-hpux11.23/lib/ -isystem /opt/gpc/hppa2.0w-hp-hpux11.23/include -isystem /opt/gpc/hppa2.0w-hp-hpux11.23/sys-include -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 -Wpointer-arith -Wwrite-strings "/home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c" /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:1: warning: -g is only supported when using GAS on this processor, /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:1: warning: -g option disabled /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:660: error: conflicting types for 'open64' /usr/include/sys/fcntl.h:246: error: previous declaration of 'open64' was here /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:660: error: conflicting types for 'open64' /usr/include/sys/fcntl.h:246: error: previous declaration of 'open64' was here /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:663:1: warning: "open" redefined In file included from /usr/include/fcntl.h:9, from /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:89: /usr/include/sys/fcntl.h:259:1: warning: this is the location of the previous definition /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:691: error: conflicting types for 'usleep' /home/aduritz/truetrue/gnu-pascal/gpc-build/gcc/include/sys/unistd.h:413: error: previous declaration of 'usleep' was here /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:691: error: conflicting types for 'usleep' /home/aduritz/truetrue/gnu-pascal/gpc-build/gcc/include/sys/unistd.h:413: error: previous declaration of 'usleep' was here /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c: In function `_p_Sleep': /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:1084: warning: implicit declaration of function `_sleep' /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c: In function `_p_CStringStrSignal': /home/aduritz/truetrue/gnu-pascal/gcc-3.4.4/gcc/p/rts/rts.c:2446: warning: empty body in an if-statement gmake[2]: *** [rts.o] Error 1 gmake[2]: Leaving directory `/home/aduritz/truetrue/gnu-pascal/gpc-build/gcc/p/rts' gmake[1]: *** [pascal.rts] Error 2 gmake[1]: Leaving directory `/home/aduritz/truetrue/gnu-pascal/gpc-build/gcc' gmake: *** [all-gcc] Error 2 i was able to resolve the "usleep" by removing the definition from rts.c and leaving the one in unistd.h. any help will be greatly appreciated. greetings, Stoyan Angelov

1 0

Creating a DLL in MingW32
by Glenn Howes 08 Jan '07

08 Jan '07

Hi, Well, I need to create a Windows version of the library I previously created on the Mac. I've installed MingW32 and MYSYS on my PC. GPC automakes my Pascal source files and creates .o and .gpi files. And at this point I'm completely at sea. I need to create a DLL which is loadable from a Visual Studio C++ application. By analogy with the gcc command given in the MingW32 FAQ (http:// www.mingw.org/mingwfaq.shtml), I tried: $ gpc -c --automake MySource.p -shared -o MySource.DLL -Wl, --ouput- def, MySource.def, --out-implib, MySource.a -lgpc and the output is: gpc.exe: --output-def: linker input file unused because linking not done gpc.exe: MySource.def: linker input file unused because linking not done gpc.exe: --out-implib: linker input file unused because linking not done gpc.exe: MySource.a: linker input file unused because linking not done gpc.exe: -lgpc: linker input file unused because linking not done And even if this had worked, I'm not quite sure what the next step would have been, so it'd be nice if I could get all the voodoo and not just the next step. I could use, and appreciate some hand holding here. $gpc --version gpc.exe 20051116, based on gcc-3.2.3 (mingw special 20030504-1) $ gcc --version gcc.exe (GCC) 3.2.3 (mingw special 20030504-1) --glenn

3 3

How to set the thirtysecond bit?
by Bastiaan Veelo 29 Dec '06

29 Dec '06

Dear list. I would have expected to be able to set the thirtysecond bit of an integer type, but I cannot. Does anybody know why? Thanks, Bastiaan. program thirtysecond; const thirtyfirst = 2#01000000000000000000000000000000; thirtysecond = 2#10000000000000000000000000000000; var i_thirtyfirst : integer value thirtyfirst; i_thirtysecond : integer value thirtysecond; {constant out of range, initial value is of wrong type} i_minus_zero : integer value 2#10000000000000000000000000000000; {idem} i_minint : integer value 2#11111111111111111111111111111111; {idem} i_thirtysecond2 : integer value 1 shl 31; {idem} begin end.

4 5

Linux 64 bit versions of GPC?
by Mike Reid 22 Dec '06

22 Dec '06

I've been using an ancient 1999 version of GPC since, well, 1999, because it worked fine, came as an RPM, and did what I wanted. However, I've now got a laptop that is running the 64 bit version of Mandriva Linux. Compiled 32-bit code seems to run OK, but the packaged versions of the compiler fail at the assembly stage. I.e. I can use my old versions of GPC to produce assembler, but the assembler gives error messages even on a "hello world" program. Is there any simple work-around, or a binary distribution that should work on my system? Or do I have no option other than compiling from scratch? Mike Reid -- Dr Michael F Reid Department of Physics and Astronomy University of Canterbury Christchurch, New Zealand Ph: + 64 3 364 2548 Fax: + 64 3 364 2469 Email: mike.reid(a)canterbury.ac.nz

2 2

Bug: copy
by Andreas K. Foerster 28 Nov '06

28 Nov '06

Hello, I came across a strange thing in gpc. My programs compile well with old versions of gpc, but when someone tried to compile the program with his version, it broke. It made me look very bad. :-( The function "copy" doesn't seem to accept the result of a function anymore. I consider that as a bug. --------------------------------------------------------------- program akf1; uses GPC; function mytext: TString; begin mytext := 'something ...' end; begin WriteLn(copy(mytext, 1, 9)) end. --------------------------------------------------------------- -- AKFoerster

1 0

break bug report
by Russ Whitaker 26 Nov '06

26 Nov '06

Hi Got careless and used "break" where I should use "exit" and got this: try.pas: In main program: try.pas:7: internal compiler error: in plant_exit_loop, at p/plant.c:651 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. from this: program bug; uses gpc; begin if FileExists( Paramstr( ParamCount ) ) then begin writeln('Quitting: output file "', Paramstr( ParamCount ), '" exists'); break; end; end. gpc version 20060325, based on gcc-4.1.1 Russ

1 0

more on gp
by Frank McCormick 16 Nov '06

16 Nov '06

On Tue, 14 Nov 2006 22:58:17 +0100 Frank Heckenbach <ih8mj(a)fjf.gnu.de> wrote: > > > Frank McCormick wrote: > > > > > > > gp: Pascal and C compilers specified seem to be for different > > > > platforms gp: (`i686-pc-linux-gnu' and `i486-linux-gnu') > > > > > > GP by default compares the versions of GPC and GCC very strictly to > > > avoid subtle errors that could result on mismatch. If you know the > > > mismatch is harmless (e.g., as above, just a different labeling of > > > targets), you can add "--no-check-platform" to skip this check. > > > > I tried putting --no-check-platform into a .gp config file in my > > home directory and it works...but only sometimes. Seems to depend on whether I am in an > > IDE (Anjuta/Peng/Geany) or at the cli. Does GP always check ~.gp ? > > No, GP doesn't currently read any config file itself (this is > planned in the future, though). Soon ? > This seems to be a feature of your > IDE. (Though for PENG, which I wrote, I'm not aware of such a > feature. ;-) However, PENG allows doing such things in user-defined > tools, so perhaps this was done in your setup.) > > To make it work on the command line, too, you can use the usual > means of a shell alias or a tiny wrapper script to add this option. Alias seems to work well. Thanks -- Cheers Frank

2 1

Works sometimes.
by fmccormick＠videotron.ca 14 Nov '06

14 Nov '06

On Sun, 12 Nov 2006 19:23:21 +0100 Frank Heckenbach <ih8mj(a)fjf.gnu.de> wrote: > Frank McCormick wrote: > > > > > gp: Pascal and C compilers specified seem to be for different > > platforms gp: (`i686-pc-linux-gnu' and `i486-linux-gnu') > > > > GP by default compares the versions of GPC and GCC very strictly to > avoid subtle errors that could result on mismatch. If you know the > mismatch is harmless (e.g., as above, just a different labeling of > targets), you can add "--no-check-platform" to skip this check. I tried putting --no-check-platform into a .gp config file in my home directory and it works...but only sometimes. Seems to depend on whether I am in an IDE (Anjuta/Peng/Geany) or at the cli. Does GP always check ~.gp ? ---Frank McCormick--- ------Montreal--------

2 1

error message
by Frank McCormick 12 Nov '06

12 Nov '06

Something must have changed on my system because now I am getting this error message once in a while: gp: Pascal and C compilers specified seem to be for different platforms gp: (`i686-pc-linux-gnu' and `i486-linux-gnu') I usually happens when I use gp instead of gpc. Any ideas ? Thanks

2 1

GPC is falling out of the mainstream
by CBFalconer 08 Nov '06

08 Nov '06

GPC is falling out of the mainstream, due to the failure to integrate it with gcc. It seems to me this should take priority. -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net>

4 3

Incorrect scoping of object/class field and method formal parameter identifiers
by Gale Paeper 08 Nov '06

08 Nov '06

While assisting in porting MacPascal Object Pascal code to GPC, I encountered a bug in GPC's scope rules implementation for object field and method formal parameter identifiers. The same bug also exists with the OOE objects implementation. The follow examples (one for mac-objects and one for ooe-objects) along with the respective GPC compilation error demonstrate the bug: {$ooe-objects} program ClassScopeBug(output); type Tclass = class x: integer; procedure y(x: real); { Should be legal} end; procedure Tclass.y(x: real); begin end; begin writeln('OK'); end. ClassScopeBug.pas:8: error: formal parameter `x' of method `y' conflicts with field or method {$mac-objects} program ObjectScopeBug(output); type Tobj = object x: integer; procedure y(x: real); { Should be legal} end; procedure Tobj.y(x: real); begin end; begin writeln('OK'); end. ObjectScopeBug.pas:8: error: formal parameter `x' of method `y' conflicts with field or method Both the MacPascal Object Pascal object and the Object-Oriented Extensions for Pascal class have the same 6.2.2 Scopes requirements extensions in this area. Although stated informally; implied through syntax extensions; and informal behavioral descriptions, the formal-parameter-list of a method heading is a separate scope region for which 6.2.2.5 scope exclusion requirements apply. The "Object-Oriented Extensions for Pascal" Technical Report in paragraph 6.5.4 "Implicit References" also states in part: "...Therefore, a parameter identifier or a local variable with the same spelling as a name brought in will hide the name brought in. A name so hidden can be accessed by explicit use of the class name and qualification." Therefore, there is no conflict between formal parameter `x' of method `y' and object/class field `x' since object/class field `x' is excluded from the scope of method `y' 's formal-parameter-list and method body. Since there is no violation of either object models' requirements, GPC should compile both of the example programs without any errors. The GPC I'm using is built from Adriaan's Mac OX X GPC sources distribution which I've upgraded to use Waldek's gpc-20060325 snapshot GPC sources. The specs are: Reading specs from /Developer/Pascal/gpc345u2d1/lib/gcc/powerpc-apple-darwin8/3.4.5/specs Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2d1 Thread model: posix gpc version 20060325, based on gcc-3.4.5 Gale Paeper gpaeper(a)empirenet.com

1 0

Re: Internal compiler error with non-matching method signatures
by Waldek Hebisch 08 Nov '06

08 Nov '06

Gale Paeper wrote: > Since the 20051116 workaround for the bug is to use the legal code > construct needed for a successful compile anyway, I don't have a presing > need for a 20051116 fix. Just reporting a bug to ensure it got fixed if > it hadn't already been taken care of in one of the later snapshots. > Thanks for the report. As I wrote it should be fixed in newer versions (unless the testcase hits two bugs and one is Mac specific). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 1

Bit setting operations
by Contestcen＠aol.com 07 Nov '06

07 Nov '06

And I'm curious wheteher there are bitsetting operations ... Thanks - Thurs, The Pascal Macro Compiler has a full set of bit operations. You compile first with the Macro Compiler, and then compile the generated Pascal code with whatever Pascal compiler you customarily use. The bit operations are described on the Master Software website at pasbit.htm with an example at pasbit2.htm Frank Rubin

1 0

Using gpc and the Dev-Pas IDE in cygwin
by Brian Keener 03 Nov '06

03 Nov '06

Well the subject sort of says it all. I wonder if this is possible. I tried the Dev-Cpp IDE for C++ in Cygwin and it appears that it works and is smart enought to deal with the Windows path and of the file name and compiler program and still act like it wasd running in a Unix environment but... If I try the same thing in Dev-Pas in Cygwin and gpc when I try to compile the tetris example it seems the it finds windres properly but the file name for input gets jumbled because of windows slashes vs unix slashes: Compile lo tab Building resource file... C:\cygwin\bin\windres -i C:\dev-pascal\examples\tetris\rsrc.rc -o c:\dev-pa~1\examples\tetris\rsrc.o Resource Tab gcc: C:dev-pascalexamplestetrisrsrc.rc: No such file or directory gcc: warning: `-x c' after last input file has no effect gcc: no input files /usr/bin/windres: no resources This is probably OT for this group but I thought maybe since the Chief is involved in both I might sneak through. Any suggestion on this will be greatly appreciated. bk

2 1

SDL and GNU Pascal
by Andreas K. Foerster 01 Nov '06

01 Nov '06

Hello sdl4fp-users, As some of you might remember, I wanted to use the SDL also with GNU Pascal in my project AKFQuiz. I tried to fiddle with the source code of SDL4Freepascal. But there was too much code to change just to find out how it works... So I decided to leave SDL4fp away and implement the few things I need from scratch. My project now is fully functional with GPC and SDL. It is not yet in the released version, but you can check out the CVS as described on the homepage (see link at the end of this mail). Now I want to share my findings with you, so probably you can use it for SDL4Freepascal... First of all, the types for variables are very different. SDL4fp uses "LongInt" for what is "int" in C - because LongInt happens to be 32Bit wide in FPC. But in GPC a LongInt is "at least" :-) 64bit wide! So it doesn't fit. Older versions of GPC intentionally kept the variable types compatible to their counterparts in C. Newer versions broke with that and introduced speacial types, like CInteger or CLongInt. Another difference to FPC is, that in GPC you have a more fine grained access to determine attributes, so you have really control about the size of variables. Here is the code snipplet for the types (from my "qsys.pas"): ----------------------------------------------------------------------- {$IfDef __GPC__} type Uint8 = Cardinal attribute (Size = 8); Uint16 = Cardinal attribute (Size = 16); Sint16 = Integer attribute (Size = 16); Uint32 = Cardinal attribute (Size = 32); Sint32 = Integer attribute (Size = 32); pByte = ^Uint8; {$if __GPC_RELEASE__ < 20041218} type CInteger = Integer; {$EndIf} { __GPC_RELEASE__ } {$Else} { not __GPC__ } type CInteger = LongInt; { @@@ for 32-Bit systems } CString = PChar; Uint8 = byte; Uint16 = word; Sint16 = SmallInt; Uint32 = cardinal; Sint32 = LongInt; pByte = ^Uint8; {$EndIf} { not __GPC__ } ----------------------------------------------------------------------- Note that you have to change "LongInt" to "CInteger" and "PChar" to "CString" in SDL4fp. SDL4fp links to the library by using the name 'SDL' after the "external" modifier. This doesn't work in GPC (yet). In GPC you have to use the compiler directive "{$L SDL}". In FPC there's also a possability to use it in a similar way with "{$LinkLib SDL}"... well it works, but not in every situation. So I decided to keep the name after the external clause, but with "IfDef"s around it. GPC compiles it without the IfDef, but there are lot of warning messages then. In FPC you must use the modifier "cdecl". In GPC that is the default, so you don't need it there. You can however declare it with "attribute(cdecl)", so you can simply write a macro to modify the "cdecl": "{$Define cdecl attribute(cdecl)}". C is case sensitive, while Pascal is not. So in GPC all Pascal identifiers are converted to lowercase at an early stage, this includes the procedure names. So you have a problem when your C identifiers need uppercase letters. This can only be solved by using an attribute which mentions the name again with its capitalisation: "name 'Example'". This name isn't converted to lower case, since it's a string-constant. FPC doesn't need that, but it doesn't harm there either. putting everything together it looks like in this example: procedure SDL_WM_SetCaption(title, icon: CString); cdecl; external {$IfDef FPC}'SDL'{$EndIf} name 'SDL_WM_SetCaption'; Well I still have a problem with CString parameters. FPC needs a type cast, while GPC doesn't accept a type cast here. I "solved" it again with "IfDef"s. Does anybody know a better solution? Please have a look at my source code for more information: http://cvs.sv.nongnu.org/viewcvs/akfquiz/srcbin/?root=akfquiz The relevant units are "sdlgrph.pas" and "sdlsnd.pas". The type definitions are in "qsys.pas". If you use my findings in SDL4fp, it would be nice, if you would mention me there as "AKFoerster". Related Links: GNU Pascal: http://www.gnu-pascal.de/ Free Pascal: http://www.freepascal.org/ SDL: http://www.libsdl.org/ SDL4Freepascal: http://sdl4fp.sourceforge.net/ AKFQuiz: http://akfquiz.nongnu.org/ -- AKFoerster

4 15

Problems after install
by Frank McCormick 30 Oct '06

30 Oct '06

Hello I am back trying my hand at Pascal again after a couple of years absence...and am relatively new to Linux so please bear with me. Just installed GPC with the built-in 3.3.3 GCC...but I can't compile any of the units in the units directory. I am using the commandline "gpc --automake crt.pas" I keep getting errors like this: /usr/lib/crt1.o: In function `_start': (.text+0x18): undefined reference to `main' /tmp/ccOU5D50.o: In function `Textmode': crt.pas:(.text+0x125): undefined reference to `crt_Check_WinChanged' crt.pas:(.text+0x1a3): undefined reference to `crt_SetMonochrome' crt.pas:(.text+0x1b5): undefined reference to `crt_SetScreenSize' crt.pas:(.text+0x1e0): undefined reference to `crt_Window' crt.pas:(.text+0x1e5): undefined reference to `crt_ClrScr' /tmp/ccOU5D50.o: In function `crt_GetScreenSize': crt.pas:(.text+0x201): undefined reference to `crt_Check_WinChanged' //snip// What am I doing wrong ??? Thanks Cheers Frank in Montreal

2 2

Internal compiler error with non-matching method signatures
by Gale Paeper 27 Oct '06

27 Oct '06

While helping someone port a MacPascal Object Pascal program to GPC, an internal compiler error was encountered when an object method heading signature type declaration didn't match the method implementation's heading signature. A distilled down test program that reproduces the internal compiler error: {$mac-objects} program MethodParameterMismatchBug; type UInt8 = Byte; Str255 = record sLength: UInt8; sChars: packed array[1..255] of char; end; xButton = object procedure SetUp (name: Str255); end; procedure xButton.Setup(name: string); {WRONG} begin end; begin end. When you compile it with "gpc -c MethodParameterMismatchBug.pas", you get: MethodParameterMismatchBug.pas:17: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. The GPC used for compiling is the Mac OS X GPC that Adriaan is distributing from his web site. The specs are: Reading specs from /Developer/Pascal/gpc345u2/lib/gcc/powerpc-apple-darwin8/3.4.5/specs Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2 Thread model: posix gpc version 20051116, based on gcc-3.4.5 It is obvious in this test program's small context that the parameter types are different between the declared method heading and the implementation method heading so the compiler should find an error since the two signatures don't match exactly. However, the error shouldn't be an internal compiler error. I'll mention there was a duplication of that parameter type mismatch with another object type's method heading in a larger code context that resulted in an error message something like the compiler was too confused to continue. However, I can't reproduce it with a small test program. Gale Paeper gpaeper(a)empirenet.com

2 1

Reading strings for old Pascal implementations
by Glenn Howes 27 Oct '06

27 Oct '06

if you had a Type like the following: ====================== Type TString12 = String[12]; ======================= and you had some old (PowerPC) code which read one in from a file as in: ====================== Procedure ReadStrings(FromFile:String); Var fToFile:Text; dataToRead: TString12; begin Open(fTextAbout, FromFile); ReadBytes:=ByteRead(fTextAbout, dataToRead,SizeOf (TString12)); ===================== Then how would you read it in using code that will work on both PowerPC and x86 processors? I looked at the data file, and it appears to be mainly text separated by null characters and occasionally null+linefeeds. Thanks. --glenn

1 1

gpc (MinGW) fails to compile
by Frank Kelly 20 Oct '06

20 Oct '06

Hi there, On attempting to compile Pascal code with gpc I get this message: >> gpc -v -c my_alg_boolv2.p Using built-in specs. Configured with: ../configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=pascal --disable-win32-registry --disable-shared --enable-sjlj-exceptions --without-x --enable-interpreter --enable-hash-synchronization Thread model: win32 gpc version 20051116, based on gcc-3.4.4 (mingw special) gpc1 -v -iprefix c:/mingw/bin/mingw32/3.4.4/ my_alg_boolv2.p -quiet -dumpbase my_alg_boolv2.p -famtmpfile=C:\Temp/cckFaaaa.gpa -version -o C:\Temp/ccuabaaa.s gpc: installation problem, cannot exec `gpc1': No such file or directory --------------------------------- I have these installed: gpc 20051116, based on gcc-3.4.4 (mingw special) gcc (GCC) 3.4.4 (mingw special) I had thought that these two were meant to be compatible with each other?!! Have checked and the actual path for gpc1.exe is C:\mingw\libexec\gcc\mingw32\3.4.4 Is there any way to fix this? Thanks in advance. -Frank

3 3

mingw - module/unit `gpc' could not be compiled
by Andreas Wirooks 20 Oct '06

20 Oct '06

Hello, i'm a beginner at MinGW and Pascal and i've downloaded and searched through the archived mailbox fo a long time but i found no solution. And generally i find no useful information for setting up mingw and gpc. I wanted to use the latest gpc snapshop and so downloaded the corresponding mingw files. I used the candidate ones that the MinGW 5.0.2 installation program because these are the only ones wich have gcc 3.4.4 wich is the latest gpc snapshot is based. So the files i installed in C:\MinGW are these: These were downloaded by MinGW 5.0.2 installation program mingw-runtime-3.8.tar.gz w32api-3.5.tar.gz binutils-2.16.91-20050827-1.tar.gz gcc-core-3.4.4-20050522-1.tar.gz gcc-g++-3.4.4-20050522-1.tar.gz gcc-g77-3.4.4-20050522-1.tar.gz gcc-ada-3.4.4-20050522-1.tar.gz gcc-java-3.4.4-20050522-1.tar.gz gcc-objc-3.4.4-20050522-1.tar.gz mingw32-make-3.80.0-3.tar.gz Theses i downloaded from MinGW.org download page in the current section: gdb-5.2.1-1.exe mingw-utils-0.3.tar.gz These from gnu-pascal.de: gpc-20051116.i386-pc-mingw32.tar.gz pdcurs24.beta-i386-pc-mingw32.zip gmp-2.0.2-i386-pc-mingw32.zip rx-1.5-i386-pc-mingw32.zip I found no other MinGW setupinformation than putting C:\MinGW\bin to the path. I already know that with the --automake --autobuild options because without these i got the "module/unit interface `GPC' could not be imported" error. But with one of these options i get the error listed in the subject line. Here is the output for "gpc -v --autobuild statfsdemo.pas -o statfsdemo.exe" wich is a demo program from the doc\gpc\demos directory: C:\MinGW\doc\gpc\demos>gpc -v --autobuild statfsdemo.pas -o statfsdemo.exe Reading specs from C:/MINGW/BIN/../lib/gcc/mingw32/3.4.4/specs Configured with: ../configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=pascal --disable-win32-registry --disable-shared --enable-sjlj-exceptions --without-x --enable-interpreter --enable-hash-synchronization Thread model: win32 gpc version 20051116, based on gcc-3.4.4 (mingw special) C:/MINGW/BIN/../libexec/gcc/mingw32/3.4.4/gpc1.exe -quiet -v -iprefix C:\MINGW\BIN\../lib/gcc/mingw32/3.4.4/ statfsdemo.pas -quiet -dumpbase statfsdemo.pas -auxbase statfsdemo -famtmpfile=C:\WINDOWS\TEMP/ccbxkigb.gpa -fautobuild -version -o C:\WINDOWS\TEMP/ccWldggb.s GNU Pascal version 20051116, based on gcc-3.4.4 (mingw special) (mingw32) compiled by GNU C version 3.4.4 (mingw special). GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32543 GNU Pascal Compiler PreProcessor version 20051116, based on gcc-3.4.4 (mingw special) statfsdemo.pas:30: error: module/unit `gpc' could not be compiled I've searched and experienced for ours. I remember, when i tried to learn c years ago (i tried to learn pascal with turbo pascal 6.0 12 years ago), that for emx (yes, the os/2 box is still lying around here) i had to setup many environment variables for the include and library pathes so that i was able to run it. I now compiled gpc.pas by hand and copied all files (.o, .gpi etc.) in the demos directory and it worked doing the commandline above. Can some hacker point me to the solution? I don't think that i have an broken installation. Befor this constellation i used different mingw's with nearly all gpc incarnations from gnu-pascal and mingw but this with this one i came at least to an exe file. Alles Gute and Thanks, Andy _________________________________________________________________ Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu! http://desktop.msn.de/ Jetzt gratis downloaden!

4 4

static linking of libgpc
by Peter Norton 18 Oct '06

18 Oct '06

Hello, A few years ago I was managed to create dynamically linked executables with statically linked libgpc (or even only some objects from the lib the program used). Now I have needs to make it again but unfortunately I cann't recall the process :-( The only things I remember - the program was compilled as object first and then linked with ld to executable. I still have system.o and gpc.o in that program's folder and beleive they was involved in process somehow. Could anyone help me with ideas? Thanks in advance, Peter __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 4

Re: indirect jmp
by Nestor Aguilera 17 Oct '06

17 Oct '06

Hi, coming back from my trip, I can now go to Gale's suggestions: > Nestor, could you check the versions of as (the assembler), ld (the > linker), and Xcode and report back? > > The coomand lines for as and ld version checking are: > > as -v Apple Computer, Inc. version cctools-622.3.obj~2, GNU assembler version 1.38 > > (You'll need a control c to get back to the command line) > > ld -v Apple Computer, Inc. version cctools-622.3.obj~2 > For Xcode, from the Xcode menu select About Xcode and you'll get a > info > window with line like: > > Xcode Version: 2.4 > Component versions Xcode IDE: 759.0 Xcode Core: 757.0 ToolSupport: 733.0 > If you could fill in the question mark information, that might help > figure out a things. Hope it helps, and thanks for the concern. Nestor

1 0

Re: [GPC]: daily digest (#942)
by Ken G. Brown 10 Oct '06

10 Oct '06

><> >Date: Sat, 07 Oct 2006 17:59:41 -0700 >From: Gale Paeper <gpaeper(a)empirenet.com> <> ><> > > > In NumberFormatting.p >> > procedure NumToString(theNum: SInt32; var theString: Str255); external name '_NumToString'; > >You're using the wrong set of Mac OS X Pascal Interfaces here. Your >cite is from FPC's FPCPInterfaces Mac OS X Pascal Interfaces. Only >GPC's GPCPInterfaces Mac OS X Pascal Interfaces work correctly for GPC compiling. I was in fact using the correct ones, but had both open in BBEdit and copied the wrong one for the email > > > What do I need to do in this case? >> > >> > > First, when you ask for help you should post a complete example. I agree and I intend to do better next time. >Since this is really a Mac OS X Pascal Interfaces type problem, it would >probably be better to seek help for questions like this on the MacPascal >mailing list instead of this mailing list. You have a much better >chance of getting faster help with Mac OS X interfacing problems and the >reponders will be tailoring their help to a Mac OS X Pascal context. >snip> Ok, shall do. Thx for the help everyone. Got it compiling now and am sorting through the String manipulation issues keeping the GPCStrings as much as possible. Ken >same maximum character capacity as the fake "string" record type has. >The StringXX types are declared in the GPCStrings unit's interface. > >Gale Paeper >gpaeper(a)empirenet.com

1 0

Re: indirect jmp
by Nestor Aguilera 08 Oct '06

08 Oct '06

Dear Gale, I will be out of town and away from the Intel Mac for a week or so. I will come back by October 17, and then I will check the things you are asking for. Sorry for the delay and thank you very much for your concern. Nestor ======================================================================= On 6 Oct, 2006, at 22:58, Gale Paeper wrote: >>>> I am running Mac OS X 10.4.8 on a MacBook Intel 2Ghz Core Duo, using >>>> gpc installed from gpc345u2-intel.dmg (downloaded from http:// >>>> www.microbizz.nl/gpc.html). >>>> >>>> When compiling I get errors involving "indirect jmp without `*'" >>>> as in [snip] >>> That looks like versioning problem: I suspect that this version >>> of gpc is incompatible with the assembler you have. In detail: >>> gpc translates Pascal program into assembly and then invokes >>> assembler to translate it into machine code. Assembly files are >>> text file where each line denotes a single machine instruction. >>> Exact form of assembly instructions depends on assembler in >>> use (gpc on Mac OS X uses assembler provided by Apple). Some >>> time ago may Intel assemblers decided that they want extra >>> stars in jump instructions. AFAIK Apple did not want stars. >>> I suspect that in Mac OS X 10.4.8 Apple changed the assembler >>> to require stars in jump instructions. > > Before Apple put out Xcode version 2.2, Adriaan had to build and > distribute newer versions of as and ld because the gpc345u2 compilers > had problems with the older versions. But that was before there was an > Intel Mac the general public could buy. Perhaps, I shouldn't but I'm > assuming any Intel Mac would have at least Xcode 2.2 or later. [snip] >> Compiling the equivalent "helloworld.c" with gcc doesn't bring up any >> error messages. The gcc I have installed is "gcc version 4.0.1 (Apple >> Computer, Inc. build 5363)", and the gpc is "gpc version 20051116, >> based on gcc-3.4.5", so indeed there is a mismatch between the gcc's. > > Nestor, could you check the versions of as (the assembler), ld (the > linker), and Xcode and report back? > > The coomand lines for as and ld version checking are: > > as -v > > (You'll need a control c to get back to the command line) > > ld -v > > For Xcode, from the Xcode menu select About Xcode and you'll get a info > window with line like: > > Xcode > Version: ?? > > Component versions > Xcode IDE: ?? > Xcode Core: ?? > ToolSupport: ?? > > If you could fill in the question mark information, that might help > figure out a things.

1 0

type mismatch in argument 2 of `NumToString'
by Ken G. Brown 08 Oct '06

08 Oct '06

Thx a lot for your long explanation of Strings. Here is another one that has me baffled. My code in a procedure: procedure doHeader (pageNum, numPages : Integer); var pageNumStr, numPagesStr : Str255; the call: NumToString(pageNum,pageNumStr); I get compile error: error: type mismatch in argument 2 of `NumToString' In NumberFormatting.p procedure NumToString(theNum: SInt32; var theString: Str255); external name '_NumToString'; What do I need to do in this case? Thx Ken

3 2

Why Syntax error in function declaration?
by Ken G. Brown 07 Oct '06

07 Oct '06

Mac OS X 10.4.8, gpc 35u2 This is driving me crazy. Why does this snippet give a compile error in the function declaration? error: syntax error before `(' program PrtTst2; uses GPCStringsAll; // from the gpc.pdf manual this is the way a function should look // // function function_identifier (parameter list): result type ; // declaration part // begin // statement part // end; function fixDateYear(thisDate : String(255)) : String(255); begin end; begin {main} end. Thx for any help, Ken

3 2

indirect jmp
by Nestor Aguilera 06 Oct '06

06 Oct '06

Hi, I am running Mac OS X 10.4.8 on a MacBook Intel 2Ghz Core Duo, using gpc installed from gpc345u2-intel.dmg (downloaded from http:// www.microbizz.nl/gpc.html). When compiling I get errors involving "indirect jmp without `*'" as in $ gpc helloworld.p /var/tmp//ccz2cAa1.s:110:indirect jmp without `*' /var/tmp//ccz2cAa1.s:127:indirect jmp without `*' /var/tmp//ccz2cAa1.s:144:indirect jmp without `*' /var/tmp//ccz2cAa1.s:161:indirect jmp without `*' /var/tmp//ccz2cAa1.s:178:indirect jmp without `*' /var/tmp//ccz2cAa1.s:195:indirect jmp without `*' /var/tmp//ccz2cAa1.s:212:indirect jmp without `*' where helloworld.p is program helloworld(input, output); begin writeln('Hello world') end. Do you know what the problem is? Thanks, Nestor Aguilera

3 6

Re: compiling static library + gpc runtime
by Frank Heckenbach 06 Oct '06

06 Oct '06

Forwarded from: marcov(a)stack.nl (Marco van de Voort) In gmane.comp.compilers.gpc, you wrote: > I don't know details about those, but the historical reasons I > mentioned refer specifically to Dos, not to x86. In fact, Linux on > x86 doesn't have the underscore. IIRC, Linux/BSD lost the underscore in the ELF transition, IOW linux/x86-a.out had it.

1 0

Serial Out Example?
by Ken G. Brown 04 Oct '06

04 Oct '06

I need to support a legacy custom printer driver app in Pascal which used to directly access the old style serial ports on Mac OS 9. I need to get it running from OS X since it is used for point of sale invoice printing. The computers have been upgraded. I have the Keyspan USA28x USB to 8 pin mini din adapter, and have their test program working but now I need to either call their C routines somehow, or rewrite something similar in Pascal. I also have most of the legacy Pascal code compiling, except for the serial stuff. Can anyone point me to appropriate examples on how to do serial drive using Xcode and gpc? Thx for any pointers. Ken

1 0

gpc20060325 says "new style GCC `-H' output detected" and doesn't want to build
by Igor Marnat 03 Oct '06

03 Oct '06

Hello List! I've built two toolchains (native for i386-linux and cross for ppc-linux target) based on gpc 20060325 and gcc 4.0.3. I have the units that use {$L file.c} directive. Native compiler build them just fine but cross compiler of the same version gives an error "new style GCC `-H' output detected" and stops build. I couldn't find any information in Google and GPC mailing lists. Please, any ideas? Native compiler version: [igor@marnat2 main_program]$ gpc -v Using built-in specs. Configured with: ../gcc-4.0.3/configure --enable-languages=c,pascal --enable-threads=posix --prefix=/home/igor/src-big/tools Thread model: posix gpc version 20060325, based on gcc-4.0.3 Cross compiler version: [igor@marnat2 main_program]$ ppc-linux-gpc -v Using built-in specs. Configured with: ../configure --prefix=/home/igor/src-big/ELDK4.0/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libgcj --target=ppc-linux --with-newlib --enable-languages=c,pascal --enable-multilib=no --disable-multilib Thread model: posix gpc version 20060325, based on gcc-4.0.3 (DENX ELDK custom version 4.0.3-1) Best regards, Igor Marnat mailto:marny@rambler.ru

3 16

packed array size
by Jonas Maebe 03 Oct '06

03 Oct '06

Hello, What is the size of this packed array in gpc on 64 bit systems: type ta = 0..$7fffffff; tb = packed array[0..799] of ta; Is it 3100 or 3104 bytes? On a related note, can someone explain me how to build gpc for Mac OS X/ppc64? powerpc64-apple-darwin8 doesn't seem to be a supported target, but maybe it's called differently? Thanks, Jonas

5 13

import gpc
by Bastiaan Veelo 26 Sep '06

26 Sep '06

Hi there, Is it correct that gpc does not look in its own units directory by default? If I have a main.pas that does import gpc, I have to build with something like (on windows): @gpc --print-file-name=units > temp.tmp @SET /p GPC_UNITS=<temp.tmp DEL temp.tmp gpc --unit-path="%GPC_UNITS%" --automake main.pas Can this not be done more straightforward? gpc.exe 20051116, based on gcc-3.2.3 (mingw special 20030504-1) Best regards, Bastiaan.

3 4

Strange up-to-date check failure.
by Bastiaan Veelo 26 Sep '06

26 Sep '06

Hi, I finally reproduced an unjust "`somfile.gpi' must be recompiled" message with a minimal example. This is the tree: \ywin.pas \testy.pas \contrib\gpc.o \contrib\gpc.gpi gpc.* are compiled from gps.pas as supplied with the compiler. ywin.pas and testy.pas are as follows ============== ywin.pas START =================== MODULE ywin; EXPORT ywin = (dummy); IMPORT gpc only (PCStrings, CParamCount, CParameters); procedure dummy; end; procedure dummy; begin end; { dummy } end. ============= ywin.pas END ===================== ============= testy.pas START ==================== program testy; import ywin; begin end. ============= testy.pas END ====================== ============ Compile log START ================ >gpc -c -g --unit-path=contrib ywin.pas >gpc testy.pas testy4.pas:3: `ywin.gpi' must be recompiled ============= Compile log END =================== If ywin.pas and testy.pas live in the same directory you can get around this problem by making testy.pas with --automake, but if they live in different directories that does not work. The problem goes away if gpc.* are put together with ywin.pas. I have not tested whether this is a particular problem of gpc.pas or whether it happens with any unit interface. Best regards, Bastiaan.

2 1

clreol, wherex, etc how?
by Toby Ewing 15 Sep '06

15 Sep '06

Hi, all I'm running gpc-20041218, based on gcc 3.3.3, on a pc running RH Enterprise. I have several programs that use basic cursor controls -- wherex, wherey, clreol, and so on -- which I used to grab as externals: Procedure clreol; C; Procedure gotoxy (x : integer; y : integer ); C; Function wherey : integer; C; I have been unable to get the externals to "take" on this version of gpc, though I've tried about 20 variants -- external, asm_name, just about anything I could find in the docs and demos. It seemed logical to just "use crt" instead. Unfortunately, the CRT unit has resisted all my attempts at compilation. Specifically: * crt.pas won't compile unless crtc.c has been compiled first * "gcc -c crtc.c" fails because ncurses.h, panel.h, and term.h are missing. (In fact, panel.h and term.h are in the units directory, but presumably gcc wants them somewhere else.) My system claims to have ncurses 5.4-13 installed, but apparently that is not sufficient. I tried Willett's ncurses.gpc 20060207, but configure failed loudly because it couldn't find ncurses.h (WHICH ncurses.h, and where does it want it?). I tried the PDCurses-2.6 on the GPC libraries page, and here again configure failed (couldn't find Intrinsic.h). I am stumped. What can I do to get simple cursor control in my programs? many thanks, Toby

3 2

internal compiler error when trying to use record variable declared using "absolute" keyword
by Igor Marnat 04 Sep '06

04 Sep '06

Hello, List! Trying to build the program below using gpc 20060325 based on gcc 4.0.3 I've got "Internal compiler error". Sorry for a bit complicated test program but it's the simplest one I could produce to reproduce the bug. Error message: [igor@marnat2 internal_compiler_error]$ make gpc --automake test.pas <var_decl 0x401910d8 Eepromstor.155419 type <pointer_type 0x4018ec3c type <pointer_type 0x4018ea8c Eepromptr type <record_type 0x4018e510 Eepromtype> unsigned SI size <integer_cst 0x40139888 constant invariant 32> unit size <integer_cst 0x401398a0 constant invariant 4> align 32 symtab 0 alias set -1 main_variant <pointer_type 0x4018ea8c Eepromptr> pointer_to_this <pointer_type 0x4018ec3c>> unsigned SI size <integer_cst 0x40139888 32> unit size <integer_cst 0x401398a0 4> align 32 symtab 0 alias set -1 main_variant <pointer_type 0x4018ec3c>> used unsigned ignored SI file test.pas line 26 size <integer_cst 0x40139888 32> unit size <integer_cst 0x401398a0 4> align 32 context <function_decl 0x4018ee58 Eep> (reg/f:SI 0 ax [orig:63 Eepromstor.155419 ] [63]) chain <var_decl 0x40191144 D.606>> test.pas: In function `EAdvLineInfo': test.pas:31: internal compiler error: in expand_expr_real_1, at expr.c:6800 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. make: *** [all] Error 1 Offending program: program test; type LinesInfoPtr = ^LinesInfoType; LinesInfoType = array [0..99] of word; type EEPROMType = record LinesInfo: word; end; type StoragePtr = ^StorageType; StorageType = array [0..99] of byte; type EEPROMPtr = ^EEPROMType; var EEPROMStor: StoragePtr; EEPROMData: EEPROMPtr absolute EEPromStor; function EEP ( W: word): pointer; begin EEP := pointer (word (EEPromData) + W) end; function EAdvLineInfo (Line: ShortWord): word; begin EAdvLineInfo := LinesInfoPtr (EEP (EEPROMData^.LinesInfo))^ [Line]; end; begin writeln (integer (EAdvLineInfo (1))); end. ~ -- Best regards, Igor mailto:marny@rambler.ru

2 2

GCC front-end for IBM XL Pascal/6000 VS Mode
by Shirley Goldrei 01 Sep '06

01 Sep '06

Is anyone aware of a front-end for gcc that understands IBM XL Pascal/ 6000 VS Mode Pascal dialect? Failing that, has anyone had experience in porting or automatically translating (i.e. "transforming") XL Pascal (VS Mode) to GPC? Many thanks, Shirley Shirley Goldrei PhD Student Computing Department Macquarie University

2 1

GPC, CGI units, and program size
by Prof. A Olowofoyeku (The African Chief) 30 Aug '06

30 Aug '06

Hi I have downloaded Frank's cgiprogs package, for the purpose of building a cgi program for an adsl router (running MontaVista Linux on a mipsfple processor). First, hats off to Frank. The program compiled and runs fine on the router. The problem is the size of the compiled program (320kb when statically linked with libgpc.a, and 250kb when linked to libgpc.so, which itself is 320kb). This is a significant amount of space for a single program to take on a router. My question (and probably only Frank can answer this) is, how can one reduce the size of this program? The program uses the gpc and cgi units only. From the GPC unit it calls "Execute" and "GetTempDirectory", and from the cgi unit it calls: GetVar IsCGI CGIInitVars If it is not possible to reduce the program size, then I guess that would have to be it - I just thought I'd ask anyway :) Perhaps there is a C cgi library? Thanks. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.greatchief.plus.com/

3 12

results of cross compilation gpc20060325 for ppc-linux target on i386-linux platform
by Igor Marnat 29 Aug '06

29 Aug '06

Hello List. I've cross built gpc20060325 for ppc-linux target. In order to do that I've made the changes attached. The second and the third changes were needed because otherwise compilation process called xgpc (cross-compiler just built) with native CFLAGS (-O2 -g -march=i386 -mcpu=i686) which it didn't want to accept. The first change allowed me to install the result compiler as ppc-linux-gpc instead of ppc-linuxppc-linux-gpc as it wanted to do first. Perhaps some changes are to be made in sources. diff -urN gpc-20060325/p/Make-lang.in gpc-20060325-ppc/p/Make-lang.in --- gpc-20060325/p/Make-lang.in 2006-03-25 06:33:50.000000000 +0300 +++ gpc-20060325-ppc/p/Make-lang.in 2006-08-29 19:04:08.057019832 +0400 @@ -179,7 +179,8 @@ # Actual names to use when installing a cross-compiler. GPC_CROSS_NAME_=`t='$(program_transform_cross_name)'; echo gpc | sed $$t` -GPC_CROSS_NAME_34=$(target_noncanonical)`t='$(program_transform_name)'; echo gpc | sed $$t` +#GPC_CROSS_NAME_34=$(target_noncanonical)`t='$(program_transform_name)'; echo gpc | sed $$t` +GPC_CROSS_NAME_34=`t='$(program_transform_name)'; echo gpc | sed $$t` GPC_CROSS_NAME=$(GPC_CROSS_NAME_$(GPC_GCC_34_)) # The GPC to use for compiling libgpc.a @@ -228,8 +229,8 @@ RTS_FLAGS_TO_PASS_ALL=\ GCC_VERSION="$(GPC_GCC_VERSION)" \ SHELL="$(SHELL)" \ - CFLAGS="$(CFLAGS)" \ - PFLAGS="$(PFLAGS)" \ + CFLAGS="-O2 -g -mcpu=405" \ + PFLAGS="-O2 -g -mcpu=405" \ AR_FLAGS="$(AR_FLAGS)" \ RTSFLAGS="$(RTSFLAGS)" \ DESTDIR="../.." @@ -778,7 +779,7 @@ $(srcdir)/p/script/mkdir-p p/rts src=`cd $(srcdir) && pwd` && \ cd ./p/rts && \ - $(RTS_COMPILERS) CONFIG_SITE=nonexisting-file \ + $(RTS_COMPILERS) $(RTS_FLAGS_TO_PASS) 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` Best regards, Igor Marnat mailto:marny@rambler.ru

1 0

test results for gpc 20060325
by Igor Marnat 28 Aug '06

28 Aug '06

Hello List! Here are the results of building test suite on my machine. Results: rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core GP= PC="gpc" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log | "./test_sum" -d Test Run By igor on 2006-08-28 19:22:41 Native configuration is i686-pc-linux-gnu (marnat2) === gpc tests === Running target any Running testsuite ... UNSUPPORTED: aregextest.pas FAIL: fjf322.pas FAIL: fjf403b.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: goto8.pas FAIL: nicola4c.pas === gpc Summary === # of tests 5070 # of expected passes 5059 # of unexpected failures 10 # of unsupported tests 1 gpc version 20060325, based on gcc-4.0.3 Machine configuration: RedHat Linux, CPU: Intel 32-bit Kernel: 2.6.7, -- Best regards, Igor Marnat mailto:marny@rambler.ru

1 0

Bug with packed arrays
by Jonas Maebe 27 Aug '06

27 Aug '06

Hello, While working on packed array support for FPC and verifying against GPC, I discovered a bug in GPC's packed array support. The following program prints 0 as second line instead of 1540222835 *** type ta = packed 0..$7fffffff; tb = packed array[0..40] of ta; function test(i: longint): integer; var b: tb; begin b[1] := $5BCDEF73; test := b[i]; end; begin writeln(sizeof(tb)); writeln(test(1)); end. *** Jonas

5 10

GPC @ 64 bit
by Silvio a Beccara 24 Aug '06

24 Aug '06

Good morning, which flags should I use to compile 64-bit applications on a 64-bit machine with GPC? Thanks Silvio a Beccara -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Vinci 100 giorni di Sheba: In palio tanti set di prodotti Sheba per la gioia del tuo gatto! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5267&d=8-8

2 1

Problem with --enable-keyword and --enable-predefined-identifier
by J. David Bryan 17 Aug '06

17 Aug '06

Running gpc-20060325 on i486-pc-mingw32 (gcc-3.4.6), I wish to use an "asm" statement and the predefined identifiers "Cardinal" and "ParamCount" in an Extended Pascal program. However, the following program fails to compile: {$ extended-pascal } {$ enable-keyword asm } {$ enable-predefined-identifier Cardinal } {$ enable-predefined-identifier ParamCount } program Predefs; var C : Cardinal; I : integer; begin asm ('nop'); I := ParamCount; C := 1 end. With "gpc -c predefs.pas", I get: predefs.pas:1: warning: compiler directives are a UCSD Pascal extension predefs.pas: In main program: predefs.pas:12: error: `asm' is an extension of Borland Pascal, traditional predefs.pas:12: error: Macintosh Pascal predefs.pas:13: error: `ParamCount' is an extension of Borland Pascal Note from the above that "Cardinal" is being enabled by the directives, whereas "ParamCount" and "asm" are not. I get the same results if I specify the compiler switches on the command line (e.g., "--enable-keyword=asm", etc.) instead of within the program. I see the same behavior with gpc-20051116. Is this a compiler bug, or am I doing something wrong? -- Dave

3 14

which is faster: inc(x) 'or' x:=x+1 ?
by wangtj＠Safe-mail.net 17 Aug '06

17 Aug '06

as title thanks.

3 2

broken links(?)
by wangtj＠Safe-mail.net 13 Aug '06

13 Aug '06

these days i was trying to enter some page of gpc: http://www.gnu-pascal.de/djgpp/ http://www.gnu-pascal.de/contrib/chief/ i tried different method but still couldnt get in. i keep got messages like that one below: Forbidden You don't have permission to access /djgpp/ on this server. after i checked the mailing list i found nobody mention this problem and i think it'll be ok though nobody has ever gave me "permission" to download an open source ware which i used for a long time. so,i thought it to be broken links and hope it can be fixed, if i was wrong please point it out. BTW, i'm wondering if gpc has stopped development since i saw the alpha version has a date of 2005? whether there's newer version? Thanks.

3 2

gdb, sets, big endian and 64 bit machines
by Jonas Maebe 06 Aug '06

06 Aug '06

Hello, gdb currently displays the contents of set variables wrongly on big endian machines for at least GPC and FPC. The reason is that it treats a set as a linear array of bits, while both GPC and FPC treat it as an array of ordinals in which bits are set using "1 shl (elementnr mod sizeof(ordinal))". The problem with creating a patch is that in FPC the size of this ordinal is always 32 bit, while on GPC it is MedCard (which is 64 bit on 64 bit architectures). The main reasons for FPC to always use 32 bits are a) binary compatibility b) performance (even on 64 bit machines, loading/storing a 32 bit value from/to memory is often faster) I have found several mails in the archives of this list noting that people should not rely on GPC sets having a particular format, so I wonder whether this could be changed in GPC? Regardless of those warnings, I guess it will still cause problems (the same binary compatibility mentioned above, for people who created data files containing sets on 64 bit machines with GPC), but it will also have advantages (making files containing sets compatible with both 32 and 64 bit apps compiled by GPC). If someone sees a way to automatically detect the used set format inside gdb itself, that would be great as well of course. What do you think? Jonas PS: I've attached a patch to gdb which fixes the problem for big endian FPC and 32 bit GPC apps. I think it may still have to be changed to not treat bitstrings differently from sets, because the stabs docs (http://www.cygwin.com/stabs.html) state: --- S Indicate that this type is a string instead of an array of characters, or a bitstring instead of a set. It doesn't change the layout of the data being represented, but does enable the debugger to know which type it is. --- What are "bitstrings" in Pascal anyway? gdb displays them as B'1..3,5,7' (sets are printed as [1..3,5,7]) so they don't seem to be the same as a bit-packed array of boolean or so. PS2: the patch was created against Apple's gdb-477. However it applies cleanly to plain GNU gdb (cvs version) as well (with a few line offset differences)

4 12

Dev+GNU Pascal: unrecognised escape sequence
by Bastiaan Veelo 06 Aug '06

06 Aug '06

Also, when I load an example project, e.g., C:\dev_gpc\examples\WinHello\Windows Hello.dp and try to build, I get this error three times: c:/dev_gpc/Examples/WinHello/rsrc.rc:1: unrecognised escape sequence and this line is highlighted: 500 ICON MOVEABLE PURE LOADONCALL DISCARDABLE "C:\dev_gpc\Icon\Mainicon.ico" Any ideas why? Bastiaan.

2 1

Repost
by Adriaan van Os 05 Aug '06

05 Aug '06

(previous post was refused) Jonas Maebe wrote: > Hello, > > While working on packed array support for FPC and verifying against GPC, I discovered a bug in GPC's packed array support. The following program prints 0 as second line instead of 1540222835 > > *** > type > ta = packed 0..$7fffffff; > tb = packed array[0..40] of ta; > > function test(i: longint): integer; > var > b: tb; > begin > b[1] := $5BCDEF73; > test := b[i]; > end; > > begin > writeln(sizeof(tb)); > writeln(test(1)); > end. > *** Thanks for the testprogram. On Mac OS X, I get [P17:~/gpc/testgpc/adriaan] adriaan% gp packing.p PC=gpc-ppc [P17:~/gpc/testgpc/adriaan] adriaan% ./packing 160 0 [P17:~/gpc/testgpc/adriaan] adriaan% gp packing.p PC=gpc-i386 [P17:~/gpc/testgpc/adriaan] adriaan% ./packing 160 126835 [P17:~/gpc/testgpc/adriaan] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc345u2/lib/gcc/i386-apple-darwin8/3.4.5/specs Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=i386-apple-darwin8 --host=i386-apple-darwin8 --build=i386-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2 --with-arch=pentium-m --with-tune=prescott Thread model: posix gpc version 20051116, based on gcc-3.4.5 Regards, Adriaan van Os

1 0

When is InvalidObjectError called?
by Peter N Lewis 03 Aug '06

03 Aug '06

Who calls InvalidObjectError and why (other than the obvious!). I searched the code but couldn't find any enlightening references as to who actually detects an invalid object and calls this...? Thanks, Peter. -- Check out Interarchy 8.1.1, just released, now with Amazon S3 support. <http://www.stairways.com/> <http://download.stairways.com/>

3 4

Bug: string cannot be given an initial value
by Bastiaan Veelo 03 Aug '06

03 Aug '06

Hi, Thank you for providing GNU Pascal! In the process of migrating from Prospero Pascal to GNU Pascal, it seems I found a bug in the latter. Given the following program: program stringtest; type record_with_empty_string = record empty_string : string(127) {VALUE ''}; end; some_records_with_empty_string(length : integer) = array[1..length] of record_with_empty_string; five_records_with_empty_string = some_records_with_empty_string(5); begin end. This program compiles. But if you uncomment the initial value of empty_string, GPC complains with "initial value of discriminated schema type is of wrong type". Things like this used to work with Prospero. Is there a workaround? Thanks, Bastiaan Veelo.

5 7

Re: Can Assert report the file name and line number?
by Bastiaan Veelo 03 Aug '06

03 Aug '06

Peter N Lewis wrote: >> I have a lot of assertions. If one of them fails, GPC only reports >> something like "assertion failed (error #306 at 40dd45)". How can I >> find out the exact assertion that failed? > > > Rather than use the built in assertions, we use our own assertions, > that way it allows us to compile them out of the later beta/final > builds (a requirement for over-asserting as recommended by Writing > Solid Code which should be essential reading for any programmer). > > The code we use is basically: > > Prefix file: > > {$definec do_debug true} > > {$ifc do_debug} > {$definec Assert(b) AssertCode((b), __FILE__, __LINE__)} > {$definec AssertNoErr(err) AssertNoErrCode((err), __FILE__, __LINE__)} > {$definec InitAssertions(name, version) InitAssertionsCode(name, > version)} > {$elsec} > {$definec Assert(b)} > {$definec AssertNoErr(err)} > {$definec InitAssertions(name, version)} > {$endc} > > > Assertions unit: > > unit MyAssertions; > > interface > > {$ifc do_debug} > procedure AssertCode( b: Boolean; const sourceFileName: String; > sourceFileLine: Integer ); > procedure AssertNoErrCode( err: OSStatus; const sourceFileName: > String; sourceFileLine: Integer ); > procedure InitAssertionsCode( const name: String; const version: > String ); > {$endc} > > implementation > > {$ifc do_debug} > > var > gAppName: String255; > gAppVersion: String255; > > procedure InitAssertionsCode( const name: String; const version: > String ); > begin > gAppName := name; > gAppVersion := version; > end; > > procedure AssertCode( b: Boolean; const sourceFileName: String; > sourceFileLine: Integer ); > begin > if not b then begin > WriteLn( 'Assert: ' + gAppName + ' ' + gAppVersion + ' - ' > + sourceFileName + ':' + NumToStr( sourceFileLine ) ); > end; > end; > > procedure AssertNoErrCode( err: OSStatus; const sourceFileName: > String; sourceFileLine: Integer ); > begin > if err <> noErr then begin > WriteLn( 'Assert: Error=' + NumToStr(err) + ' ' + gAppName > + ' ' + gAppVersion + ' - ' + sourceFileName + ':' + NumToStr( > sourceFileLine ) ); > end; > end; > > {$endc} > > > Obviously this can easily be extended to implement assertions any way > you desire. > > Please be aware that if you intend to compile out assertions (as you > should for at least some assertions), then you must never include real > code in your assert statement, eg: > > Assert( (open( ... )) == 0 ); > > Rather you need to do > > err = open( ... ); > Assert( err == 0 ); > > Why do you have to compile out some assertions? Because you should be > doing things like: > > Assert( ValidDataStructure( complex_structure ) ); > > Where ValidDataStructure is walking through your complex structure > ensuring it is all internally self consistent, which could be a > significantly time consuming task. But that does not matter as it > will be compiled out when you are performance tuning and in the > shipping version. > > The alternative is you would have to be very light weight with what > you assert, or have two different classes of assertions (perhaps by > using something like) > > {$ifc do_heavy_debug} > Assert( ValidDataStructure( complex_structure ) ); > {$endc} > > Enjoy, > Peter. > Thank you for this detailed solution. Bastiaan.

3 3

Common OpenMP syntax?
by Florian Klaempfl 03 Aug '06

03 Aug '06

I'am currently thinking about implementing OpenMP support in FPC. However, there is currently (to my knowledge) no pascal syntax defined for OpenMp support. Do you think we can find a common syntax to simplify things for users? I've some ideas how it be done, but I want to hear other ideas first so they are maybe better if they aren't influenced by my ideas :) I started also a wiki page about it http://www.freepascal.org/wiki/index.php/OpenMP_support where ideas can be written down and shared.

4 3

Pointer to video memory, standalone runtime
by James Buchanan 02 Aug '06

02 Aug '06

Hi there, It looks like it's not possible to declare a pointer to char and initialise it to the video memory, e.g. type VideoMemory: ^char; var VideoMemory := 0x80000; Excuse the syntax if its wrong, I'm new to Pascal. :-) I'd like to know if it's not possible to get a pointer to the video memory region on PCs will I need to modify the compiler to allow it? Or would it be easier to just write a helper routine in C or assembler and link to it instead? Also what is the calling convention used and what does the procedure activation record look like? Is it fairly easy to use an alternative standalone runtime library with GNU Pascal? I'd like to use GCC's -fstandalone and -nostdinc -nostdlib (IIRC) options to link to my own standalone runtime so I can use Pascal for low level system programming. Thanks very much. James

3 8

Dev+GNU Pascal: internal option '--amtmpfile' not given
by Bastiaan Veelo 28 Jul '06

28 Jul '06

Hi, I am checking out Dev+GNU Pascal on Windows XP, and am having trouble compiling and linking. The problem is that when I follow the tutorial and start a GUI project, compilation halts with this error message: gpc: Internal GPC problem: internal option `--amtmpfile' not given. The project was started in a directory with a short name in C:/, to work around this other problem: I tried to compile one of the examples that get loaded upon the initial start of Dev+GNU Pascal, C:\dev_gpc\examples\projects\GrClock.pas, but compilation halted with the message c:/dev_gpc/lib/gcc-lib/ming32/3.2.3/collect2.exe: C:/Program: No such file: No such file or directory So gpc seems to try and link a file from "C:/Program Files/..." but chockes on the space in the directory name. I installed Dev+GNU Pascal from the file http://gnu-pascal.de/contrib/chief/win32/dev_gnu_pascal-1.9.4.8.exe. I followed the instructions in the Readme, and built the file build_units.pas. No compiler errors occurred, seemed to compile fine, and as far as I can see, no executable was produced (despite the warnings in the readme). What can I do to get this thing to work? Best regards, Bastiaan.

1 0

Schema parameters
by J. David Bryan 27 Jul '06

27 Jul '06

Running gpc-20060325 on i486-pc-mingw32, this program: program params (output); procedure p1 (s1 : string; s2 : string); begin writeln ('in p1') end; procedure p2 (s1, s2 : string); begin writeln ('in p2') end; begin p1 ('l', 'hello'); p2 ('l', 'hello') end. ...produces this output when compiled with --gnu-pascal: in p1 in p2 ...but this output when compiled with --extended-pascal: in p1 params: actual schema discriminants do not match (error #308 at 401426) Is this correct? -- Dave

2 3

64 bit
by Silvio a Beccara 25 Jul '06

25 Jul '06

Dear friends, if I run GPC on a 64 bit machine (an AMD Athlon 64 X2 ), it is supposed to produce 64-bit code, is it right? But what are then the sizes of the various integer types available in GPC? If I let this code program sizes; begin writeln ('# size of integer is = ', sizeof (integer) ); writeln ('# size of medint is = ', sizeof (medint) ); writeln ('# size of longint is = ', sizeof (longint) ); end. print them out, I get these results: # size of integer is = 8 # size of medint is = 8 # size of longint is = 8 is that right? Shouldn't it be like 4,8,16? Thanks, regards Silvio a Beccara -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Chatta con chi preferisci Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5489&d=25-7

2 1

Re: GCC-4.1.1
by Waldek Hebisch 21 Jul '06

21 Jul '06

I have prepared a new 4.1.x diffs: http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-4.1-5f.diff.gz http://www.math.uni.wroc.pl/~hebisch/gpc/gcc-4.1-5f.diff.gz Since I spent a lot of time out of the town I may be slow to answer questions. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

3 2

Change in packing between compiler versions
by Martin Liddle 20 Jul '06

20 Jul '06

I am continuing to struggle with some code that compiles and runs as intended using gpc-20020502 based on gcc 2.95.2 that I am now trying to get it running with gpc-20060325 based on gcc-3.4.4. It appears the packing of records has changed. The following test program produces different answers with the different compilers Program mltest06; Const MaxName=49; MaxClas=40; MaxChel=120; Type TCompr=Packed Record Name:String(Maxname); Class:1..Maxclas; Awel:Set of 1..MaxChel; Rlate,Rtime:Integer; RetirementControl:Integer; PerformanceIndex:Integer; END; Var Compr:TCompr; Begin Writeln('Size of Compr =',Sizeof(Compr)); Writeln('Size of Compr.Name =',BitSizeof(Compr.Name)); Writeln('Size of Compr.Class =',BitSizeof(Compr.Class)); Writeln('Size of Compr.Awel =',BitSizeof(Compr.awel)); Writeln('Size of Compr.Rlate =',BitSizeof(Compr.Rlate)); Writeln('Size of Compr.Rtime =',BitSizeof(Compr.Rtime)); Writeln('Size of Compr.RetirementControl=',BitSizeof(Compr.RetirementControl)); Writeln('Size of Compr.PerformanceIndex =',BitSizeof(Compr.PerformanceIndex)); End. 20020502 20060325 Size of Compr =91 96 Size of Compr.Name =464 480 Size of Compr.Class =6 6 Size of Compr.Awel =128 128 Size of Compr.Rlate =32 32 Size of Compr.Rtime =32 32 Size of Compr.RetirementControl=32 32 Size of Compr.PerformanceIndex =32 32 Is there a command line option for gpc to obtain the previous behaviour with the newer version? -- Martin Liddle, Tynemouth Computer Services, 3 Kentmere Way, Staveley, Chesterfield, Derbyshire, S43 3TW. Web site: <http://www.tynecomp.co.uk>.

2 1

Correct way to access Errno
by Martin Liddle 20 Jul '06

20 Jul '06

We have some code that compiles and runs as intended using gpc-20020502 based on gcc 2.95.2. I am now trying to get it running with gpc-20060325 based on gcc-3.4.4. As a demonstration the program Program Test_err; Var errno:integer; external name 'errno'; Begin Writeln(@Error number is ',Errno); End; Compiles but fails to link with 20060325 : "/usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section .tbss mismatches non-TLS reference in /tmp/ccae8f7a.o" The same program runs correctly with 20020522 when external name is replaced by the older syntax asmname. A bit of googling suggests this is a common problem and not limited to gpc but I can't find how I am now supposed to access errno. Any suggestions? -- Martin Liddle, Tynemouth Computer Services, 3 Kentmere Way, Staveley, Chesterfield, Derbyshire, S43 3TW. Web site: <http://www.tynecomp.co.uk>.

2 2

gpc runtime error on sparc
by vanam srihari kumar 20 Jul '06

20 Jul '06

Dear All I have loaded gpc and gcc on sun solaris10 sparc platform. Version Info :gpc version 20050331, based on gcc-3.4.3 I could compile and link the pascal programs but when I try to run in solaris debugger I am getting the below error. ******************************************************* Running: HelloWorld process id 4176 Reading libc-psr.so.1 reading en-us.is088859-15.503 singnal segv(no maping at fault address) in _p-rts-error-s34- finisherrormessage at 0x196e8 0x000196e8: -p-rts error-s34-finisherrormessage+0x0048 (st %12 %sp+64) dbx: READ of 4 bytes at address ff3fff9f8 filled error ******************************************************* By running directly it is giving segmentation fault(coredump) Where as C executables built with gcc are working fine Please suggest me, what to do? Please suggest me, what to do? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 3

Getting an error while compiling GPC-20060325 on solaris10 intelplatform
by prasad svr 20 Jul '06

20 Jul '06

I am trying to compile GPC-20060325 on solaris10 intel platform Using gcc-3.4.3.While compiling Iam getting an error like bellow. /usr/local/i386-pc-solaris2.10/bin/ld:libgcc/./libgcc.map: file format not recognized; treating as linker script /usr/local/i386-pc-solaris2.10/bin/ld:libgcc/./libgcc.map:1: parse error collect2: ld returned 1 exit status make[2]: *** [libgcc_s.so] Error 1 make[2]: Leaving directory `/home/prasad/gpc-build/gcc' make[1]: *** [libgcc.a] Error 2 make[1]: Leaving directory `/home/prasad/gpc-build/gcc' make: *** [all-gcc] Error 2 Please help how to solve the above problem. regards prasad -- _______________________________________________ Search for businesses by name, location, or phone number. -Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as…

2 1

Can Assert report the file name and line number?
by Bastiaan Veelo 19 Jul '06

19 Jul '06

Hi, I have a lot of assertions. If one of them fails, GPC only reports something like "assertion failed (error #306 at 40dd45)". How can I find out the exact assertion that failed? Thanks, Bastiaan.

2 2

Re: GCC-4.1.1
by Waldek Hebisch 15 Jul '06

15 Jul '06

> > > On Thu, 13 Jul 2006, Waldek Hebisch wrote: > > > > > Concerning gcc-4.1.1: basically, it should work the same as gcc-4.1.0. > > For both you need gpc-20060325 + patches: > > > > http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20060325.tar.bz2 > > http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-4.1-4.diff.gz > > http://www.math.uni.wroc.pl/~hebisch/gpc/gcc-4.1-4.diff.gz > > > Starting with clean copies of above, > Only hunk failure: gcc/tree-ssa-loop-niter.c > bison version: 2.2 > gcc version: 4.1.1 > make bootstrap got this far: > > make[3]: Nothing to be done for `generated-files'. > make[3]: Leaving directory `/home/russ/src/gcc_collection/gpc-20060325-4.1.1/gpc-20060325/p/rts' > cd ../../gcc-4.1.1/gcc/p && bison -o parse.c parse.y > parse.y: conflicts: 62 shift/reduce, 25 reduce/reduce > parse.y: expected 24 reduce/reduce conflicts > make[2]: *** [../../gcc-4.1.1/gcc/p/parse.h] Error 1 > make[2]: Leaving directory `/home/russ/src/gcc_collection/gpc-20060325-4.1.1/build/gcc' > make[1]: *** [stage1_build] Error 2 > make[1]: Leaving directory `/home/russ/src/gcc_collection/gpc-20060325-4.1.1/build/gcc' > make: *** [bootstrap] Error 2 > This is due to change in bison-2.[23] (I used patched 2.1). Frank attached a patch correcting this problem to: http://www.gnu-pascal.de/crystal/gpc/en/mail13607.html BTW: there is no reason to run bison -- if you touch parse.[ch] before build then you will use the version included in the patch. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

GCC-4.1.1
by Bruno Moreira Guedes 13 Jul '06

13 Jul '06

Hi! I would like to know if I use mkdiff to create diff-file to gcc-4.1.1 can gpc work. If can, how I use mkdiff? I've been tried to do it, but I've been get many errors(no such file or directory). What can I do? Thanks, Bruno

3 4

Fwd: Short Strings
by Frank Heckenbach 06 Jul '06

06 Jul '06

Forwarded from: marcov(a)stack.nl (Marco van de Voort) In gmane.comp.compilers.gpc, you wrote: >> FPC is a like Delphi, but since it supports the TP libs (Delphi doesn't), >> there is some use, also in the textmode IDE. Also the compiler and utils >> itself originally used shortstrings. However we are moving away from that >> for some time now (already since 2000). > > Well, I used BP myself long time ago, ......... > was nothing much to be changed (except for sometimes declaring a > bigger maximum size :-). I had similar experiences with my own codebases, because they were already abstracted for string usage since they were ported back from Modula2 before. However in my experience, there only is a small fraction of existing codebases that is that clean. See e.g. the average level of filth in SWAG. >> In time, only the core compiler >> itself (symbol tables etc) will be the only non legacy code using >> shortstrings. This because the size limit is no problem for >> identifiers/tokens etc, and it is quite a bit faster. >> >> This could be because the static nature allocates them together with the >> objects, while dynamic strings would be an allocation extra, > > I suppose you're talking about Delphi's string variant which is only > dynamic AFAIR. Correct, and specifically inside the FPC compiler core. The FPC compiler is speedwise mostly dependant on the memory manager and lexing. In plain Delphi (and FPC in de delphi mode), "String" means ansistring. While in TP and (FPC in TP modes) the identifier "String" means shortstring. This makes switching easy, provided the shortstring code is cleaned up (no write beyond the range 1..length(s) and no s[0] use). > However, Extended Pascal's strings can be static or (explicitly) dynamic, > just like other types, so you can use them mostly the same way as short > strings, and there is no extra overhead, except for a few bytes more to > store the bigger length field and the capacity. If the statical variant is instantiated with the class/object, yes then it would. But as said, there is no real reason to clean shortstring out of the compiler core. Maybe except if we switch to unicode (or UTF8) mangled names and identifiers, that will be a major rewrite anyway. > I think for some cases, limited strings are still useful, for other > cases, unlimited strings are preferable. Correct. However EP now has this static type. And FPC also has one, reasonably transparant. The point is more that it is not worth to invest in a second one unless there are very good reasons (and the current mac pascal discussion is one for GPC IMHO) >> Correct. And it is not just the interfaces, but also demoes, documentation >> and a nearly all Pascal code available on the Mac. > > As I said WRT BP above, I think such code, as long as it doesn't use > external short-string interfaces, can probably convert to (EP) long > strings with minimal effort. It is a barrier. And to a programmer that comes from a all-hands-held commercial compiler, it is yet another one over the already existing ones (the change of IDE, project system, misc units and language changes). That's what Peter tries to point out. For a new developer everything is new, and _every_ change that forces him to inspect every line in the whole source is a major pain and a risk. Even if every change for itself is negiable. I learned this the hard way during FPC Delphi compability convergence. You quickly port and fix heaps of all those little issues, and then when it finalyl compiles it turns out the program doesn't work anymore. The littler the changes the less chance on such scenario. However you and me and probably the rest on this list can handle decent debuggers and if necessary probably even GDB down to assembler level if we have to. Most of the Apple newbies can't though. >> In practice this means auto conversion by assignment and passing to value >> parameters. FPC/Delphi do this already. > > We do that for CStrings, so most of the time we can avoid using > CStrings in Pascal code this way. An automatic back-conversion > (e.g., for function results) also seems possible, though we don't do > that yet. Real reference parameters would be a problem, both they > are rarely needed (I suppose, also WRT short strings in Mac OS). Similarly with FPC/Delphi and ansistrings <->pchars. Btw, function results are handled by the conversion? > So this might indeed be an option for short strings (i.e., no direct > support, but automatic conversions). It will certainly be easier to > implement, but it lacks some features (such as bianry > compatibility), so I might go for the full support anyway, if it > doesn't present unsurmountable problems ... I meant these conversions as additional to the BP featureset, to interoperate with your own string type. And afaik they already have some workarounds like that using the records and some operator overloading? (Peter?) I don't think you can do without full support. Specially the "open array" string compat is too important to leave out (more important than the ref thing), because this is the main way to have generic shortstring string routines. >> The shortstring implementation is simply something >> like >> >> procedure setlength(var s:shortstring;x:integer); >> >> begin >> if x>255 then x:=255; >> s[0]:=chr(x); >> end; > > This only works for strings of capacity 255. Correct, my shortstringese is a bit rusty. Subst 255 with high(s) for a general TP compatible solution. >> This is not a problem in general. A hybrid system always has penalties, and >> people _choose_ to use it. Mostly subsystems are internally one string type, >> and only the interfaces between the subsystems aren't. > > I hope so. OTOH, I've seen in the past a lot of BP programmers use > CStrings (i.e., "PChar") throughout in their Pascal code, after they > were added to BP (version 6 or 7), probably also because of > Borland's marketing them as the next big thing. I think more that it was the only way to get around the size limits. Also the TP/BP windows compat was directer on the API than the VCL based Delphi. But there certainly was a bit of a myth in TP times that pchars were faster, partially also because they were from "C". There was some truth in that (shortstrings copy too much), and carefully crafted code could be better, but the speed advantage was vastly exagerated, specially compared with the fact that it was way easier to do anything wrong with pchars, and complex string code was way more work. The problems were that the emerging 32-bit C compilers BP was compared to were simply faster because they optimized and were 32-bit (using a 32-bit move() routine for their copies), and BP was a codegenerator from yesteryear. > (I admit I almost fell for it myself, but when I saw the drawbacks, I > converted back to short strings what I had changed to CStrings already, > fortunately, so I could easily convert the code to EP strings with GPC > later.) I mostly used shortstrings in that time and pchars only to break that limit if needed. However when that really got important, because the path sizes exploded, I was already using FPC and ansistrings were stable. >> Copying conversions are required for literals anyway, but they can't be >> avoided, since shortstrings are not lazily assigned. > > I'm not sure if that's required. We could probably also emit the > literals as short strings when needed (like we do with literals used > as CStrings). We'll see which will be easier in the end. I meant the following situation: procedure x; var s : string; begin s:='bolalalallala'; end; On the assignment some copy must follow from where the const is stored to the stack.

1 1

Fwd: Re: Short Strings
by Frank Heckenbach 04 Jul '06

04 Jul '06

Forwarded from: marcov(a)stack.nl (Marco van de Voort) In gmane.comp.compilers.gpc, you wrote: (a summary from a Mac outsider. Peter, Adriaan, feel free to correct) >> ... snip ... >> > >> > So basically, I'm just saying that the lack of short strings is >> > seriously hindering GPC adoption on the Mac, and that that should >> > probably be taken in to account when pondering the priority of their >> > implementation. > > I see. When I have more than a few days to work at GPC (currently, > I'm stilly busy with other work, you know, the paying kind ...), > I'll see if I can do it. Unless Waldek beats me to it ... (Besides Mac it also helps TP/Delphi compat a bit, though I can't quickly remember a single place where Delphi uses them. In 32-bit Delphi it is nearly fully legacy) FPC is a like Delphi, but since it supports the TP libs (Delphi doesn't), there is some use, also in the textmode IDE. Also the compiler and utils itself originally used shortstrings. However we are moving away from that for some time now (already since 2000). In time, only the core compiler itself (symbol tables etc) will be the only non legacy code using shortstrings. This because the size limit is no problem for identifiers/tokens etc, and it is quite a bit faster. This could be because the static nature allocates them together with the objects, while dynamic strings would be an allocation extra, but IIRC the compiler uses pointers to shortstring. > On a tangent, what do you think is the future of short strings > anyway? Dodo. Note that FPC also advises to use the ansistring type as much as possible. Dynamic string types are the future, static types with larger boundaries will perish also. This because more and more libraries (under influence of GNU policy) specify their maximal string sizes quite high. Putting very large strings on the stack will gigantically inflate stack size. Also more and more OSes allow really deep dir structures and long dir names. We already have had complaints about a forgotten 1024 char limitation in filenames in some routine. > Does Mac OS support those at all, with a different interface, or what? The base libs under OS X are so *nix that we pretty much use the *BSD rtl also for Darwin. Carbon has shortstrings mostly (and not just [255] afaik), and Cocoa is objective C. > Secondly, charsets. When 16-bit charsets (i.e., Unicode) become common (or > are already), will/should there be a 16-bit "short" string (i.e., max. > 65535 characters)? Don't think so. Don't bother, unless there is something that needs them. Shortstrings are Carbon and TP. Nearly all of that code is not unicode safe anyway, and if there is a major investment that will go in the direction of dynamic strings. > Or else, if the interfaces will/do use UTF-8, we'll > need conversions (automatic and/or manual) between Unicode and UTF-8 > anyway? Yes. > (As discussed before, UTF-8 doesn't make for a string type in > Pascal.) _some_ routines must be adapted for UTF-8. However most routines keep on working, due to the properties of the encoding. > Just to figure out if supporting short strings will only be a > short-lived solution and more work in this area will be required soon > anyway ... As far as I see it the problem is that Apple expected more Cocoa uptake (keep in mind that Apple comes with Java as major subsystem). However that system is not very friendly for external use, at least from our viewpoint. While a Cocoa capable GPC would be cool, this will probably be significant amount of work, and because you'd be the first pascal compiler to do so to my knowledge, that would mean a slow process, lots of additional work (converting demo programs etc, document GPC/Pascal specific workarounds etc) So for now and for some time to come, Pascal on Mac is Carbon, mainly because the barrier to use Cocoa on a large scale is probably very significant. > This is true on a high-level, when no external interfaces are a > concern. When it comes to binary file formats (as you mentioned), or > network protocols, or external binary interfaces (libraries or, like > here, the OS), things such as storage size, alignment and byte order > matter, and those are not described in Pascal. Correct. And it is not just the interfaces, but also demoes, documentation and a nearly all Pascal code available on the Mac. > BTW, in the case of short strings, they're better described as an > array, starting from 0, with the Ord of the 0'th element > representing the length, as e.g. BP does explicitly. A record would > need an Integer field for the length, and, apart from alignment > etc., it's not at all certain this is of the same size as a Char, > even if declared as a subrange (e.g., in GPC it wouldn't be -- > except for a packed record, which in turn wouldn't e.g. allow > passing the elements by reference which e.g. BP short strings do > allow). Also keep in mind that for BP (and the Mac Pascal compilers) the UCSD type was pretty much the only one. While BP had a few pchar helper kludges, these were mostly standalone. However FPC and GPC have other automated first tier stringtypes. This means that besides the stuff that TP can do, additional conversions to the native stringtypes are at least an option. This makes the interface between Carbon UI code or TP legacy code to other parts that use native strings easier. (and avoids that people stick with shortstrings for the rest of their app because of legacy) In practice this means auto conversion by assignment and passing to value parameters. FPC/Delphi do this already. I believe I mentioned this before, but for FPC/Delphi compat it would be absolutely great btw if setlength(stringtype,newlength) was implemented for all string types as opposite of length(). This allows to keep new string code somewhat type (and compiler) independant. The shortstring implementation is simply something like procedure setlength(var s:shortstring;x:integer); begin if x>255 then x:=255; s[0]:=chr(x); end; > -- don't know if that's required). This would generally require > copying the whole string. This is not a problem in general. A hybrid system always has penalties, and people _choose_ to use it. Mostly subsystems are internally one string type, and only the interfaces between the subsystems aren't. Copying conversions are required for literals anyway, but they can't be avoided, since shortstrings are not lazily assigned. > Ironically, converting to C-Strings (input parameters only, as long as the > strings do not contain Chr (0)) is easier, since one can keep the string > in place and only has to add a Chr (0) if space is reserved in advance (as > GPC does). That's why we have less of such problems with C-string based OS > interfaces (POSIX, Dos, Windows, ...), as most strings parameters are > input, and extra work is only required for the few other cases. Delphi/FPC Ansistring does the same. But I believe I described it into detail before already.

3 5

Short Strings
by Peter N Lewis 04 Jul '06

04 Jul '06

Hi all, I know short strings (255 character limit, 0 index containing the length) have been discussed to death, and I'm not going to discuss them further, but I did want to point out for those of you not on the MacPascal mailing list that everyone asking "Which should I use, FPC or GPC?" is basically ending up with FPC primarily because of lack of short string support. I have nothing against FPC, and indeed the developers have been great at supporting Mac compatibility and so forth. But since I use GPC, and since GPC has lots of really cool other features (like long Strings for example ;-), I'd love to encourage people to use GPC. I personally believe the little extra work required to use wrappers for when short strings are needed is no big deal, but it's hard to argue that "its just a little more work" to a developer who is already faced with making a big change in their environment and code. So basically, I'm just saying that the lack of short strings is seriously hindering GPC adoption on the Mac, and that that should probably be taken in to account when pondering the priority of their implementation. Thanks, Peter. -- Check out Interarchy 8.1, just released, now with Amazon S3 support. <http://www.stairways.com/> <http://download.stairways.com/>

3 4

Short String Support
by Joseph Ayers 04 Jul '06

04 Jul '06

> >>May I put in a vote for short (UCSD Pascal) string support. I'm >>trying to revive several legacy programs based on the Think Pascal, >>Codewarrior development environments. See: > >http://rsb.info.nih.gov/nih-image/ for an example. > >Based on my experience so far, I'd say that 80% of the conversion >effort has been dealing with lack of short string support. Concat >being a prime culprit with variable argument lists requiring major >hand coded efforts.. The legacy code base in these environments is >legion in the academic arena. > >Joseph Ayers > >>(BCC to "Jon" who asked basically the same in PM, perhaps related. >>BCC as I don't know if you want your address publicly known, but >>this way you won't get further replies, unless you subscribe to the >>list or read the archives.) >> >>CBFalconer wrote: >> >>> Peter N Lewis wrote: >>> > >>> ... snip ... >>> > >>> > So basically, I'm just saying that the lack of short strings is >>> > seriously hindering GPC adoption on the Mac, and that that should >>> > probably be taken in to account when pondering the priority of their >>> > implementation. >> >>I see. When I have more than a few days to work at GPC (currently, >>I'm stilly busy with other work, you know, the paying kind ...), >>I'll see if I can do it. Unless Waldek beats me to it ... >> >>On a tangent, what do you think is the future of short strings >>anyway? For one, there's the 255 chars limitation. While still >>enough for many purposes, it might not be for some, e.g. file names >>with several long directories etc. could get longer. Does Mac OS >>support those at all, with a different interface, or what? Secondly, >>charsets. When 16-bit charsets (i.e., Unicode) become common (or are >>already), will/should there be a 16-bit "short" string (i.e., max. >>65535 characters)? Or else, if the interfaces will/do use UTF-8, >>we'll need conversions (automatic and/or manual) between Unicode and >>UTF-8 anyway? (As discussed before, UTF-8 doesn't make for a string >>type in Pascal.) Just to figure out if supporting short strings will >>only be a short-lived solution and more work in this area will be >>required soon anyway ... >> >>> You should be using the standard functions for access to the length >>> parameter, after which you don't care how strings are implemented. >>> The so-called short strings are implementable as records if >>> compatibility with existing binaries or files is required. >>> >>> One of the major points of Pascal is simply to eliminate machine >>> dependence, and rely on abstractions. Thus integers are fully >>> described by maxint, and smaller ranges should be typed as >>> subranges, etc. >> >>This is true on a high-level, when no external interfaces are a >>concern. When it comes to binary file formats (as you mentioned), or >>network protocols, or external binary interfaces (libraries or, like >>here, the OS), things such as storage size, alignment and byte order >>matter, and those are not described in Pascal. >> >>BTW, in the case of short strings, they're better described as an >>array, starting from 0, with the Ord of the 0'th element >>representing the length, as e.g. BP does explicitly. A record would >>need an Integer field for the length, and, apart from alignment >>etc., it's not at all certain this is of the same size as a Char, >>even if declared as a subrange (e.g., in GPC it wouldn't be -- >>except for a packed record, which in turn wouldn't e.g. allow >>passing the elements by reference which e.g. BP short strings do >>allow). >> >>AIUI, the Mac Pascal interfaces make heavy use of such short >>strings. One option would be conversion to/from them for every >>input/output parameter (wouldn't work for true reference parameters >>-- don't know if that's required). This would generally require >>copying the whole string. Ironically, converting to C-Strings (input >>parameters only, as long as the strings do not contain Chr (0)) is >>easier, since one can keep the string in place and only has to add a >>Chr (0) if space is reserved in advance (as GPC does). That's why we >>have less of such problems with C-string based OS interfaces (POSIX, >>Dos, Windows, ...), as most strings parameters are input, and extra >>work is only required for the few other cases. >> >>Frank >> >>-- >>Frank Heckenbach, f.heckenbach(a)fh-soft.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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8 >>(BCC to "Jon" who asked basically the same in PM, perhaps related. >>BCC as I don't know if you want your address publicly known, but >>this way you won't get further replies, unless you subscribe to the >>list or read the archives.) >> >>CBFalconer wrote: >> >>> Peter N Lewis wrote: >>> > >>> ... snip ... >>> > >>> > So basically, I'm just saying that the lack of short strings is >>> > seriously hindering GPC adoption on the Mac, and that that should >>> > probably be taken in to account when pondering the priority of their >>> > implementation. >> >>I see. When I have more than a few days to work at GPC (currently, >>I'm stilly busy with other work, you know, the paying kind ...), >>I'll see if I can do it. Unless Waldek beats me to it ... >> >>On a tangent, what do you think is the future of short strings >>anyway? For one, there's the 255 chars limitation. While still >>enough for many purposes, it might not be for some, e.g. file names >>with several long directories etc. could get longer. Does Mac OS >>support those at all, with a different interface, or what? Secondly, >>charsets. When 16-bit charsets (i.e., Unicode) become common (or are >>already), will/should there be a 16-bit "short" string (i.e., max. >>65535 characters)? Or else, if the interfaces will/do use UTF-8, >>we'll need conversions (automatic and/or manual) between Unicode and >>UTF-8 anyway? (As discussed before, UTF-8 doesn't make for a string >>type in Pascal.) Just to figure out if supporting short strings will >>only be a short-lived solution and more work in this area will be >>required soon anyway ... >> >>> You should be using the standard functions for access to the length >>> parameter, after which you don't care how strings are implemented. >>> The so-called short strings are implementable as records if >>> compatibility with existing binaries or files is required. >>> >>> One of the major points of Pascal is simply to eliminate machine >>> dependence, and rely on abstractions. Thus integers are fully >>> described by maxint, and smaller ranges should be typed as >>> subranges, etc. >> >>This is true on a high-level, when no external interfaces are a >>concern. When it comes to binary file formats (as you mentioned), or >>network protocols, or external binary interfaces (libraries or, like >>here, the OS), things such as storage size, alignment and byte order >>matter, and those are not described in Pascal. >> >>BTW, in the case of short strings, they're better described as an >>array, starting from 0, with the Ord of the 0'th element >>representing the length, as e.g. BP does explicitly. A record would >>need an Integer field for the length, and, apart from alignment >>etc., it's not at all certain this is of the same size as a Char, >>even if declared as a subrange (e.g., in GPC it wouldn't be -- >>except for a packed record, which in turn wouldn't e.g. allow >>passing the elements by reference which e.g. BP short strings do >>allow). >> >>AIUI, the Mac Pascal interfaces make heavy use of such short >>strings. One option would be conversion to/from them for every >>input/output parameter (wouldn't work for true reference parameters >>-- don't know if that's required). This would generally require >>copying the whole string. Ironically, converting to C-Strings (input >>parameters only, as long as the strings do not contain Chr (0)) is >>easier, since one can keep the string in place and only has to add a >>Chr (0) if space is reserved in advance (as GPC does). That's why we >>have less of such problems with C-string based OS interfaces (POSIX, >>Dos, Windows, ...), as most strings parameters are input, and extra >>work is only required for the few other cases. >> >>Frank >> >>-- >>Frank Heckenbach, f.heckenbach(a)fh-soft.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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8 > > -- Joseph Ayers, Department of Biology and Marine Science Center Northeastern University East Point, Nahant, MA 01908 Phone (781) 581-7370 x309(office), x335(lab) Cellular (617) 755-7523, FAX: (781) 581-6076 eMail: lobster(a)neu.edu AIM: roboplasm SKYPE: cyberplasm http://www.neurotechnology.neu.edu/ http://inls.ucsd.edu/neurobots.html

1 0

Re: Hacking "method variables"
by Frank Heckenbach 21 Jun '06

21 Jun '06

Forwarded from marcov(a)stack.nl (Marco van de Voort): In gmane.comp.compilers.gpc, you wrote: >> Forwarded from marcov(a)stack.nl (Marco van de Voort): >> >> A slight advantage of the delphi method is that it requires dirty syntax to >> do dirty things. That could be seen as a deterrent. > > As a general principle, I agree -- though some (optional) warnings > would also be fine. However, AIUI, what Markus want to do isn't > actually dirty stuff, i.e. all type-safe. One could argue that this leads to partial initialisation(method inited, instantiation not). However that is just a detail. I'd have doubts because I don't think it really is worth inventing new syntax that is marginally cleaner (typesafe), since this form of usage is probably rare, and usually limited to the innerworkings of frameworks anyway. (at least that is the only place I have ever seen such code in Delphi, e.g. central dispatch routines deep in the classes framework) >> Not this moment. But IMHO it should, though we would probably call it a >> "hint" (something that is not _always_ wrong). > > Doesn't this apply to most warnings? No. E.g. portability warnings are not a problem if you are writing a non-portable app. But the compiler doesn't know this intention. Solution, put it on a different level. Also compiletime warnings about possible range problems (e.g. assigning integer to byte) can be very handy to track if you have problems, but generate a lot of noise. All old hat probably, since I assume GPC has a deep warning system? So my remark was more a musing where I would put it in our three level warning system (the three types have names; warnings, hints, notes). IIRC the difference between them, is likeliness of being correct, and frequency, but I noticed that the manual misses a formal description of these levels, I'll make a note about that.

1 1

Compiling GCC+GPC on 64 bit Athlon
by Silvio a Beccara 20 Jun '06

20 Jun '06

Dear list friends, I think this might have been asked already, but I can't find the correct answer in the archives. How does one go about compiling GCC 3.4.3 together with GCC on a 64 bit dual-core Athlon? Here's my cpuinfo information: processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 35 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping : 2 cpu MHz : 2211.354 cache size : 1024 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext f xsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy bogomips : 4430.51 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp I already tried, but without success, this configure setting: ./configure --enable-languages=pascal --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --enable-shared and I can attach, if needed, the make logfile. I hope you can help me. Kind regards Silvio a Beccara -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Refill s.r.l. - Cartucce compatibili e kit di ricarica per tutti i modelli di stampante. Acquista al telefono o online: consegna in tutta Italia in 48 ore! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5190&d=20-6

2 1

Free Pascal Meeting
by Adriaan van Os 19 Jun '06

19 Jun '06

This weekend, I attended an international meeting of the Free Pascal Development team, hosted by Marco van de Voort in Eindhoven, which happens to be just a few miles from my home. This was an informal meeting with barbecue et al (and Marco trying hard to set his house and garden on fire). A topic that I should mention here, is the many units that FPC has to interface with external packages. For many packages, there are no GPC alternatives being actively maintained. For Mac OS X however, a common set of Pascal interfaces to system software is maintained by a small team, from which interfaces are auto-generated for GPC, FPC and MW Pascal. So, in general, I think working together with the FPC team is a good idea (and for Mac OS X, we already do so actively). Anyway, the FPC team accepts {$ifdef __GPC__} patches to their interfaces and are open to discussions on other solutions. I don't have much time now to look into this, but this may change in say two or three months. Of course, volunteers are welcome. Regards, Adriaan van Os

1 0

Internal compiler error when building on AIX
by Marcus Wirth 16 Jun '06

16 Jun '06

Hi, I'm trying to build GPC (using the sources gpc-20050331.tar.bz2 and gcc-core-3.4.4.tar.bz2) on AIX 5.3. After working for a while the compiler crashes with an "Internal compiler error" (see below). Did anyone succeed building GPC on AIX using the recent sources? Thanks for your help! Marcus /opt/db2/db2bavpi/gpc/build/gcc/xgcc -B/opt/db2/db2bavpi/gpc/build/gcc/ -B/opt/d b2/db2bavpi/powerpc-ibm-aix5.3.0.0/bin/ -B/opt/db2/db2bavpi/powerpc-ibm-aix5.3.0 .0/lib/ -isystem /opt/db2/db2bavpi/powerpc-ibm-aix5.3.0.0/include -isystem /opt/ db2/db2bavpi/powerpc-ibm-aix5.3.0.0/sys-include -O2 -DIN_GCC -W -Wall -Wwrit e-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isys tem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I . -I. -I../../gcc-3.4.3/gcc -I../../gcc-3.4.3/gcc/. -I../../gcc-3.4.3/gcc/../inc lude -I../intl -DL_fixunsdfsi -c ../../gcc-3.4.3/gcc/libgcc2.c -o libgcc/./_fix unsdfsi.o ../../gcc-3.4.3/gcc/libgcc2.c: In function `__fixunsdfsi': ../../gcc-3.4.3/gcc/libgcc2.c:1384: error: unrecognizable insn: (insn:HI 11 10 12 0 ../../gcc-3.4.3/gcc/libgcc2.c:1381 (set (reg:CCEQ 122) (compare:CCEQ (ior:SI (gt:SI (reg:CCFP 121) (const_int 0 [0x0])) (eq:SI (reg:CCFP 121) (const_int 0 [0x0]))) (const_int 1 [0x1]))) -1 (insn_list 10 (nil)) (expr_list:REG_DEAD (reg:CCFP 121) (nil))) ../../gcc-3.4.3/gcc/libgcc2.c:1384: internal compiler error: in extract_insn, at recog.c:2083 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. gmake[2]: *** [libgcc/./_fixunsdfsi.o] Error 1 gmake[2]: Leaving directory `/opt/db2/db2bavpi/gpc/build/gcc' gmake[1]: *** [libgcc.a] Error 2 gmake[1]: Leaving directory `/opt/db2/db2bavpi/gpc/build/gcc' gmake: *** [all-gcc] Error 2

2 1

Error building GPC on MinGW
by Markus Gerwinski 14 Jun '06

14 Jun '06

Hi Folks, I'm trying to build gpc-20050331 (with the patch from 20050411) in a MinGW/MSys environment on Windows XP. I'm doing ./configure --enable-languages=pascal make ... and `make' then aborts with the error message below. What am I doing wrong? Regards, Markus -- LOG -- make[2]: Entering directory `/mysoftware/gcc-3.4.3/gcc/p/rts' make[2]: Nothing to be done for `generated-files'. make[2]: Leaving directory `/mysoftware/gcc-3.4.3/gcc/p/rts' rm -rf p/docdemos ./p/script/mkdir-p p/docdemos ./p/script/extract-doc-demos -o p/docdemos ./p/doc/*.texi ./p/doc/generated/*.texi ./p/doc/en/*.texi echo timestamp > "p/stamp-docdemos" make[1]: Circular libgcc.a <- pascal dependency dropped. if [ -f specs.ready ] ; then \ true; \ else \ echo timestamp > specs.ready; \ fi (MAKE="make"; srcdir=`cd ./fixinc && ${PWDCMD-pwd}` ; \ CC="gcc"; CFLAGS=" -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE"; LDFLAGS=""; \ WARN_CFLAGS="-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-error"; LIBERTY=`${PWDCMD-pwd}`/"../libiberty/libiberty.a"; \ export MAKE srcdir CC CFLAGS LDFLAGS WARN_CFLAGS LIBERTY; \ cd ./fixinc && \ /bin/sh ${srcdir}/mkfixinc.sh i686-pc-mingw32 i686-pc-mingw32) constructing ../fixinc.sh for i686-pc-mingw32 to run on i686-pc-mingw32 The directory that should contain system headers does not exist: /usr/include make[1]: *** [stmp-fixinc] Error 1 make[1]: Leaving directory `/mysoftware/gcc-3.4.3/gcc' make: *** [all-gcc] Error 2

3 4

Re: Hacking "method variables"
by Frank Heckenbach 13 Jun '06

13 Jun '06

Forwarded from marcov(a)stack.nl (Marco van de Voort): In gmane.comp.compilers.gpc, you wrote: >> It works though with >> uninitialised objects too as long as you don't actually "use" (dereference) >> self: > > I see. But I suppose Markus also wants to call the method via the > procedural variable later and apply it to a certain object instance > (selected at call time), something like (depending on the syntax > chosen): Not possible directly, however messing with the internals (via the tmethod record typecast) is "supported". IOW, people expect it to work on Delphi. procedure test; var localx : somemethodvar; begin localx:=globalmethodvarref; // local copy, avoid global mod of complex constant. tmethod(localx).data:=otherinstance; // maybe typecast to pointer end; the problem is of course that the assignment is not safe. However usually code that messes with instances of procvars is typically framework internal, and not in normal user code, so I don't have a particular problem with it. (at least not enough to invent new syntax) A slight advantage of the delphi method is that it requires dirty syntax to do dirty things. That could be seen as a deterrent. > Of course, that can be a problem -- as always if not carefully used. > BTW, do you warn if taking the address (@) of a normal (non-object) > variable on the stack? Not this moment. But IMHO it should, though we would probably call it a "hint" (something that is not _always_ wrong).

2 2

Re: Hacking "method variables"
by Frank Heckenbach 13 Jun '06

13 Jun '06

Forwarded from marcov(a)stack.nl (Marco van de Voort): In gmane.comp.compilers.gpc, you wrote: > Frank Heckenbach wrote: >> >> begin >> bla:=xx.methodname; >> end; > > So IIUC, the difference to Markus' way is that here the procedural > variable also contains the object, while there it only points to the > method, and can be applied to any object (of matching type), right? Yes, though object-instance might be a better phrasing. It works though with uninitialised objects too as long as you don't actually "use" (dereference) self: {$mode delphi} type tmyobject = class function bla ( x: integer):integer; end; tmethodvar = function (x:integer):Integer of object; function tmyobject.bla(x:integer):Integer; begin writeln(x, ' ', PtrInt(self)); // ptrint is guaranteed pointer size compat end; var x : TMyobject; y : tMethodVar; begin x:=nil; // if you can detect uninitialised vars, this is not necessary. y:=x.bla; y(5); end. will write 5 0 I'm a bit worried that this syntax is a bit focused on object types that are already (implicitely) a pointer, like Delphi. If this is possible with (one of ) your object models, better warn if you try to assign a methodvar to a method of an object that is on the stack instead of on the heap.

2 4

Re: Hacking "method variables"
by Frank Heckenbach 09 Jun '06

09 Jun '06

Markus Gerwinski wrote: > I just did a little experiment. The full source code is attached, but what I'm > doing is, in brief, the following: > > - Declaring an object type tTestObj with a method `foo', > - giving this method an attribute name, > - declaring (in the same source!) an external-declared function with the same > attribute name and a pointer (for the object) as an additional parameter, > - assigning this method to a procedure variable, > - calling the variable with a pTestObj as a parameter. > > Result: It works! :-) The method is executed as if it was "correctly" called > via tTestObj.foo, including access to private fields of the object. > > Question: Is this supposed to work? I.e. can I rely on this feature remaining > in GPC? Or is it rather looked upon as a bug, so I have to expect it'll be > removed some day? I'd consider it perhaps a misfeature, but I think it will keep working, as long as you use explicit linker names (as you do), and take care of the parameter list ("Self" last, in contrast to BP where it's first, no difference in the example). However, actually "Self" is a reference parameter of object type, not a value parameter ob object pointer type. Though both are implemented the same, and this is also unlikely to change, the example can easily be changed to avoid depending on this. > I'd like to use it as a feature, since it provides me with a way to assign > methods to procedure/function variables, something I've been missing in GPC so > far. OTOH, I would, of course, even prefer to have real, "syntax-approved" Yes, the first problem is to define a syntax. I think there might have been some suggestions before, but nothing concrete so far AFAIR. Do other dialects have something like that, if so which syntax? > method variables that also take into account polymorphy and the fact that > methods might be overridden. Here's an alternative: gFoo:= tFooFunc (@tTestObj.foo); This avoids the linker name tricks, but requires a type-cast. It has the advantage that it works with (non-)overridden methods, i.e. you can put in a derived type of tTestObj, whether in inherits tTestObj.foo or defines its own foo. For a compiler-implemented solution, this issue would also be easily solved. For polymorphy (i.e., virtual) methods, the problem is that a procedural variable needs a constant address. One way to solve it is to write a wrapper routine that does the actual virtual call. This solution (see below) doesn't even require a type-cast or other dirty stuff. It also works for non-virtual methods, of course, if you're willing to accept the small wrapper overhead (which seems inevitable for virtual methods, but can be avoided for non-virtual methods, as in your example). For a compiler-implemented solution, polymorphy would also be an issue, and AFAICS, the compiler would need to emit such a wrapper routine automatically then. That might not be too difficult per se (just some work to do ...), but the important question is, when and where to emit such wrappers (looks a bit like the C++ template problems). We could emit one on each usage, at the danger of emitting the same one several times (might even be in different units). Or emit one for each virtual method, at the danger of emitting some (often many) that aren't used at all. Of course, it's not a huge issue (just a few bytes per routine), but since a manual solution is available, I'd first wonder if the effort is justified for a feature that might not be used all that often ... Program Test; type pTestObj = ^tTestObj; tTestObj = object public Constructor init ( aBar: integer ); Procedure foo; virtual; private fBar: integer; end (* tTestObj *); p2 = ^t2; t2 = object (tTestObj) Procedure foo; virtual; end (* tTestObj *); tFooFunc = Procedure ( var obj: tTestObj ); var g1, g2: pTestObj; gFoo: tFooFunc; Constructor tTestObj.init ( aBar: integer ); begin (* tTestObj.init *) fBar:= aBar; end (* tTestObj.init *); Procedure tTestObj.foo; begin (* tTestObj.foo *) writeln ( 'I''m one.' ); end (* tTestObj.foo *); Procedure t2.foo; begin (* tTestObj.foo *) writeln ( 'Me two.' ); end (* tTestObj.foo *); Procedure FooWrapper ( var obj: tTestObj ); begin obj.foo end; begin g1 := new ( pTestObj, init ( 42 ) ); g2 := new ( p2, init ( 42 ) ); gFoo:= FooWrapper; gFoo ( g1^ ); gFoo ( g2^ ); end. 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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

3 3

Re: Hacking "method variables"
by Markus Gerwinski 09 Jun '06

09 Jun '06

Peter N Lewis wrote: > >OTOH, I would, of course, even prefer to have real, "syntax-approved" > >method variables that also take into account polymorphy and the fact that > >methods might be overridden. > > I'm afraid I can't understand the point of this, why not just use an > indirecting procedure: > > Remove the attribute names, and define > > Procedure testObjFoo ( obj: pointer ); > begin > pTestObj(obj)^.foo; > end; That's basically what I've been doing for a couple of years now, and as far as only my own code is affected, I find it a bit annoying, but acceptable. However... well, see below. > No need to rely on the compiler implementation of anything. > > Sure there is a negligible drop in efficiency, and you have to write > a duplicate for any method you want to use a a procedural variable, > but these hardly seem like big problems unless you have very specific > requirements that make them big problems...? The point is: I'm writing an API where I'd like to give the application developer the possibility to pass a method as an initialization parameter to the constructors of some objects. For example to an intermediate wrapper that turns rows of an SQL result set into objects and vice versa.

1 0

Re: Hacking "method variables"
by Frank Heckenbach 09 Jun '06

09 Jun '06

Forwarded from marcov(a)stack.nl (Marco van de Voort): In gmane.comp.compilers.gpc, you wrote: > Yes, the first problem is to define a syntax. I think there might > have been some suggestions before, but nothing concrete so far > AFAIR. Do other dialects have something like that, if so which > syntax? Delphi syntax type tbla = procedure bla(param1,param2,param3:integer) of object; Only allowed to assign methods. (classes model) Internally such beast is a record ("TMethod") with two fields. "code" and "data". Code contains a ptr to the function, data self or nil. (the latter in case of "class" (static) methods) Assignment is simple var bla: tbla; begin bla:=xx.methodname; end;

1 1

Bison-2.2
by Frank Heckenbach 07 Jun '06

07 Jun '06

Bison version 2.2 has been released. To make GPC work with it requires some minor changes. Patch attached, details in the ChangeLog entry. Bison 2.2 also has a new feature: : * %require "VERSION" : This specifies that the grammar file depends on features implemented : in Bison version VERSION or higher. Since we actively use some newer (2.0 and/or 2.1) features of Bison, we actually should use this check, to avoid users even trying with older Bisons which cannot work. OTOH, since the check is new in 2.2, we can't "%require 2.1", so by using this check we would needlessly (ATM) require Bison 2.2. What should we do? Perhaps wait until 2.2 is more widespread, then require it? 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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

3 5

Re: gpc installation using Xcode
by Adriaan van Os 31 May '06

31 May '06

Forwarding the private reply: Hi Adriaan, Thanks so much for your help - the program now works fine. I tried installing the compiler a long time ago, before the Xcode environment existed, and could never get anywhere with it, but it looks absolutely great now it works with Xcode - easy enough for me to use! Thanks again, Graham > Graham Carter wrote: > >> Examples/SillyBalls/Sources/MainProgram.pas >> gpc1: error: invalid option `dynamic-no-pic' > > I still have to update the GPC Xcode Kit, but you can apply the > following change to make it work. For IntelMac, please double-click > on the "Debug" Target. Then, in the Build Settings pane, change > > GPC_CODESTYLE = -mdynamic-no-pic > > to > > GPC_CODESTYLE = > > The -mdynamic-no-pic option is not (yet) supported for IntelMac. > Same procedure for the "Deploy" Target. > > The best place to ask Xcode specific questions is really the > MacPascal mailing list <http://www.pascal-central.com/maillist.html>. > > Regards, > > Adriaan van Os >

1 0

gpc installation using Xcode
by Graham Carter 31 May '06

31 May '06

Hi, I've just installed gpc, the associated Pascal interfaces and the Xcode software on my Intel Mac. I've configured Xcode in the way suggested and just tried to compile one of the sample programs. It compiles ok but falls over with this error: Building target “Debug” of project “SillyBalls” with configuration “Default” — (1 error) [lots of stuff deleted] 1.1/Examples/GUI Examples/SillyBalls/build/Debug/Objects/ -I . -I / Developer/Pascal/gpc345u2/lib/gcc/i386-apple-darwin8/3.4.5/units -I / Developer/Pascal/GPC Xcode Kit 1.1/Examples/GUI Examples/SillyBalls/ Sources/ --unit-path=/Developer/Pascal/GPC Xcode Kit 1.1/Examples/GUI Examples/SillyBalls/Sources/ -E -H /Developer/Pascal/GPC Xcode Kit 1.1/Examples/GUI Examples/SillyBalls/Sources/MainProgram.pas gpc1: error: invalid option `dynamic-no-pic' make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 make: *** [compile_tool] Error 1 Build failed (1 error) Can anyone more knowledgeable than me (that would be most people!) suggest what I might need to do? Sorry to be a pain, I know the answer is probably obvious to everyone on this group but this is my first step into programming a Mac (or using a unix-like environment). Thanks in advance, Graham Carter

2 1

Xcode 2.3
by lanceboyle＠qwest.net 26 May '06

26 May '06

Should GPC folks upgrade to Xcode 2.3? What are the issues, if any? Jerry

2 3

modules and scope
by Ram Seshadri 18 May '06

18 May '06

Further to my previous e-mail I have a question relating to the use of modules and scope of variables declared in module being 'seen' by other modules. The thing is I have variables in one module that I want to be able to seen by other modules. I thought as long as I export the variables from the module it should be fine but it seems not to work all that well as on compiling I get undefined reference errors. I am a newbie to pascal so don't fully understand the inner workings so help would be appreciated.

2 1

.var files and include files
by Ram Seshadri 16 May '06

16 May '06

Does the latest version of the GNU compiler support the use of include files to declare procedures and functions. When i put them in include files I get compiler errors of multiple declarations. Help would be much appreciated. Ram

2 1

OS X 10.3 missing symbol ___powidf2 ?
by Glenn Howes 09 May '06

09 May '06

As you may recall, I have a large C++ application which calls a smallish library written in Pascal. I have compiled and linked that library as a universal binary which is intended to run under Mac OS X 10.3 and up on PowerPC, and Mac OS X 10.4 and up under i386. I had been running the application on Mac OS X 10.4 and up only, but have been going through the trouble of extending support to 10.3. But there is a symbol, apparently referenced from my Pascal library, which is missing. ___powidf2. I think this might be a math function of the form: float = pow(float, int); but am not sure. I've linked in libgpc, libgcc, and the darwin-fpsave libraries. Does anyone know how I should go about getting this to link? Googling and searching on this mailing list have not gotten be anywhere. --glenn

3 2

Range checking problem
by Adriaan van Os 05 May '06

05 May '06

The following was initially discovered by Gale Paeper. [g5:~/gpc/testgpc/adriaan] adriaan% cat rangecheck1.p program rangecheck1; var i: 1..5; begin i:= 5; {$local R-} i:= i+1; {$endlocal} i:= 4; i:= i+2; writeln( 'i = ', i); end. [g5:~/gpc/testgpc/adriaan] adriaan% gpc41 rangecheck1.p --range-checking [g5:~/gpc/testgpc/adriaan] adriaan% ./a.out i = 6 [g5:~/gpc/testgpc/adriaan] adriaan% cat rangecheck2.p {$R+} program rangecheck2; var i: 1..5; begin i:= 5; {$local R-} i:= i+1; {$endlocal} i:= 4; i:= i+2; writeln( 'i = ', i); end. [g5:~/gpc/testgpc/adriaan] adriaan% gpc41 rangecheck2.p --range-checking [g5:~/gpc/testgpc/adriaan] adriaan% ./a.out ./a.out: value out of range (error #300 at 2487) [g5:~/gpc/testgpc/adriaan] adriaan% cat rangecheck3.p {$R+} program rangecheck3; var i: 1..5; begin i:= 5; {$local R-} i:= i+1; {$endlocal} writeln( 'i = ', i); end. [g5:~/gpc/testgpc/adriaan] adriaan% gpc41 rangecheck3.p --range-checking [g5:~/gpc/testgpc/adriaan] adriaan% ./a.out i = 6 [g5:~/gpc/testgpc/adriaan] adriaan% cat rangecheck4.p {$R+} program rangecheck4; var i: 1..5; begin i:= 4; i:= i+2; writeln( 'i = ', i); end. [g5:~/gpc/testgpc/adriaan] adriaan% gpc41 rangecheck4.p --range-checking [g5:~/gpc/testgpc/adriaan] adriaan% ./a.out ./a.out: value out of range (error #300 at 2477) [g5:~/gpc/testgpc/adriaan] adriaan% gpc41 -v Using built-in specs. Configured with: ../gcc-4.1.0/configure --enable-languages=c,pascal --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc410d1 Thread model: posix gpc version 20060325, based on gcc-4.1.0 In other words, {$local R-} disables range-checking for the rest of the file when using --range-checking as a command-line option, not when using {$R+}. I can hardly imagine this is intended behaviour. Regards, Adriaan van Os

2 1

"Frame size too large..."
by lanceboyle＠qwest.net 26 Apr '06

26 Apr '06

I'm getting the following warning when compiling a main program on OS X using the Xcode kit. The whole project includes a number of units too. This reminds me of the days when I would have to make more pointers to arrays and the like and/or increase the stack size in other Mac Pascals. Is there something that I can do to make the messages go away? Is this affecting debugging? warning: frame size too large for reliable stack checking warning: try reducing the number of local variables Jerry

2 1

Re: No run-time check of restricted types
by Dan N 25 Apr '06

25 Apr '06

--- Frank Heckenbach <ih8mj(a)fjf.gnu.de> wrote: > Dan N wrote: > > > The following program runs without any run-time > errors > > or warnings. How to make it produce a (useful) > > run-time error? > > > > program prog; > > var a:1..5; > > begin > > a:=5; > > writeln(a); > > a:=a+1; {Here it should produce at least a > warning} > > writeln(a); > > end. > > Which GPC version do you use? Newer versions should > produce a > run-time error here. The latest snapshot is: > > http://www.math.uni.wroc.pl/~hebisch/gpc-20060325.tar.bz2 I have gpc 3.3.3 under Cygwin. This is the latest version avaliable. $ cat a.pas program prog; var a:1..5; begin a:=5; writeln(a); a:=a+1; writeln(a); end. $ gpc -v Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir= /etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --ena ble-languages=c,ada,c++,d,f77,java,objc,pascal --enable-nls --without-included-gettext --enable-libg cj --with-system-zlib --enable-interpreter --enable-threads=posix --enable-java-gc=boehm --enable-sj lj-exceptions --disable-version-specific-runtime-libs --disable-win32-registry Thread model: posix gpc version 20040516, based on gcc-3.3.3 (cygwin special) $ gpc -o aa a.pas $ ./aa.exe 5 6 $ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

No run-time check of restricted types
by Dan N 25 Apr '06

25 Apr '06

The following program runs without any run-time errors or warnings. How to make it produce a (useful) run-time error? program prog; var a:1..5; begin a:=5; writeln(a); a:=a+1; {Here it should produce at least a warning} writeln(a); end. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

out of range error
by vanam srihari kumar 21 Apr '06

21 Apr '06

Hi While running a pascal program on Intel Solaris platform, getting below runtime error /home/kvsspl/deb/solaris/tcp: value out of range (error #300 at 81a473c) Program exited with code 052. Eventhough I am running the program in the debugger, unable to find out the line in the code where it is going. Please suugest me as how to get rid of this error. Regards Hari __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

Problem with Copy in gpc-20060325
by Peter Schorn 20 Apr '06

20 Apr '06

The following program does not compile with gpc-20060325 (but was ok with gpc-20051116). program cpt; type String255 = String(255); function flux: String255; begin flux := 'Flux' end; begin writeln(Copy(flux, 2, 3)) { error: reference expected, value given } end. -- Peter Schorn mailto:peter.schorn@acm.org

1 0

GPC and CodeWarrior Object Pascal
by Peter Schorn 20 Apr '06

20 Apr '06

Dear all, while porting from CodeWarrior Object Pascal to GPC I noticed the following differences which might be worthwhile to address in GPC. 1) Mutual recursive object type declaration program prog1; { compile with gpc --mac-pascal prog1.pas } type t1 = object function f: t2; { error: unknown identifier `t2' } { above works in CodeWarrior Object Pascal as objects are always references } end; t2 = object function g: t1; end; function t1.f: t2; begin f := nil; end; function t2.g: t1; begin g := nil; end; begin end. As a workaround this can be solved by introducing a common super class and subsequent casting. 2) Procedure type assignment compatibility with specialized parameters program prog2; { compile with gpc --mac-pascal prog2.pas } type baseType = object end; derivedType = object(baseType) end; procedure p1(x: baseType); begin end; procedure p2(x: derivedType); begin end; var pv: procedure(x: baseType); begin pv := p1; pv := p2; { error: incompatible types in assignment } end. A workaround is to declare the x in p2 as baseType and perform a cast in the body of p2. 3) Cast in with statement program prog3; { compile with gpc --mac-pascal prog3.pas } type baseType = object end; derivedType = object(baseType) procedure f; end; procedure derivedType.f; begin end; var a: baseType; b: derivedType; begin new(b); a := b; derivedType(a).f; { ok } with derivedType(a) do { warning: `with' element is not a constant or an lvalue } f; { error: invalid lvalue in method call } { error: function call used as a statement } end. A workaround is to use a temporary variable for the with statement.

4 7

Re: Experimental 4.1 port
by Adriaan van Os 20 Apr '06

20 Apr '06

Waldek Hebisch wrote: > I have now "almost ready" experimental gcc-4.1.0 port. There are some minor problems but > basically 4.1.0 port should be now as good (or as bad...) as 4.0.3 port. I would > like to fix some > extra problems (most of them not related to port) and add some feature before I make a new > snapshot, so ATM I have made port available as patches: For inclusion into a new snapshot, may I suggest the following ? 1. <http://www.gnu-pascal.de/crystal/gpc/en/mail13049.html> 2. <http://www.gnu-pascal.de/crystal/gpc/en/mail13046.html> 3. <http://www.gnu-pascal.de/crystal/gpc/en/mail12165.html>, diff attached 4. <http://www.gnu-pascal.de/crystal/gpc/en/mail13557.html> Regards, Adriaan van Os

1 0

-m64 on powerpc-apple-darwin8
by Adriaan van Os 20 Apr '06

20 Apr '06

Now that gpc has preliminary support for gcc-4 (thanks!) I am trying to build a 64-bit libgpc.a for use with -m64 on powerpc-apple- darwin8. This results in an ICE in fname.pas. ../.././xgpc -B../.././ -c -I. -W -Wall -Wmissing-prototypes - Wmissing-declarations -g -O2 -m64 --unit-path=/Users/adriaan/gnu/ gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts --automake - DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc/gpc-20060325/gcc-4/ gcc-4.0.3/gcc/p/rts/rts-version`'" -DGCC_VERSION="'4.0.3'" "/Users/ adriaan/gnu/gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts/random.pas" ../.././xgpc -B../.././ -c -I. -W -Wall -Wmissing-prototypes - Wmissing-declarations -g -O2 -m64 --unit-path=/Users/adriaan/gnu/ gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts --automake - DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc/gpc-20060325/gcc-4/ gcc-4.0.3/gcc/p/rts/rts-version`'" -DGCC_VERSION="'4.0.3'" "/Users/ adriaan/gnu/gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts/fname.pas" /Users/adriaan/gnu/gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts/ fname.pas: In function `InternalFSearch': /Users/adriaan/gnu/gpc/gpc-20060325/gcc-4/gcc-4.0.3/gcc/p/rts/ fname.pas:705: internal compiler error: in output_constant, at varasm.c:3929 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. make[2]: *** [fname.o] Error 1 make[1]: *** [pascal.rts] Error 2 make: *** [all-gcc] Error 2 It would be nice to have a 64-bit darwin compiler available for download at some point, but it is not urgent. Regards, Adriaan van Os

4 15

IEEE 754 in GPC
by lanceboyle＠qwest.net 19 Apr '06

19 Apr '06

What is the relationship between GPC and IEEE 754 floating point? THINK and CW (both Mac dialects) allowed e.g. a := Inf; a := -Inf; a := NaN; but these are rejected by GPC as undeclared identifiers. I can get the same effect by e.g. a := MaxReal * 2.0; {inf} a := 0.0 / 0.0; {nan} but this seems like a hack. Also, the old SANE (Apple's most excellent 754 implementation from way back--I think the guru Kaplan was involved, as he was with the also-most-excellent HP-15c pocket calculator) allowed returning specific numeric codes to allow determining what caused a NaN. I remember writing an arctan2 function and in the case of arctan2(0.0, 0.0), I assigned a returm value of something like NaN(85), which was somehow a NaN even though the construct looks like a function. I _think_ I could then query that particular NaN to get a clue about where it arose. I lost this when porting to CW, however. Anyway, just wondering. Jerry

3 2

StringOf empty string
by Peter Schorn 18 Apr '06

18 Apr '06

Dear all, is the following a bug or might I have made a mistake in building gpc 20060325? program strof; begin writeln(StringOf('')); end. compiles but execution terminates with invalid subrange size (error #301 at 1992b) Trace/BPT trap Best regards, Peter

3 2

Re: Dropping gcc-3.2.x (was: -m64 on powerpc-apple-darwin8)
by cbfalconer＠att.net 18 Apr '06

18 Apr '06

Frank Heckenbach <ih8mj(a)fjf.gnu.de> wrote: > ... snip ... > > I'm still testing with 3.2.3 too, but I also thought about dropping > it recently. Since the external preprocessor was the last obstacle > in adopting 3.3 and 3.4, I think we can drop 3.2.x officially (i.e., > remove the 3.2.x diffs in the next release). Objections anyone? > (If 3.3 turns out problematic, I wouldn't mind dropping it also.) The problem with that is that DJGPP available issues are rather limited. I have no objections as long as whatever is supported is also available for djgpp. I have asked several times for things to be sent to me at: cbfalconer(a)maineline.net with no response whatsoever. This periodic web access is not good. -- Chuck F (cbfalconer@yahoo.com)(cbfalconer@maineline.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE maineline address!

4 3

Experimental 4.1 port
by Waldek Hebisch 16 Apr '06

16 Apr '06

I have now "almost ready" experimental gcc-4.1.0 port. There are some minor problems but basically 4.1.0 port should be now as good (or as bad...) as 4.0.3 port. I would like to fix some extra problems (most of them not related to port) and add some feature before I make a new snapshot, so ATM I have made port available as patches: http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-4.1-4.diff.gz and http://www.math.uni.wroc.pl/~hebisch/gpc/gcc-4.1-4.diff.gz The patches are relative to gpc-20060325. gpc diff contains parser diffs. To avoid needless regeneration of parser file touch p/parse.[ch] after patching. The port should build without problems. There are extra test failures (compared to 3.4.6): asmtest.pas, fjf395[ab].pas -- test programs expect to much fjf1102.pas -- unimplemented feature (but works with older older backends) fjf403b.pas, fjf779[abefg].pas, nicola4c.pas -- port does not detect error/unused variables fjf395[ab].pas -- wrong tests fjf322.pas, fjf587b.pas -- spurious warnings -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

3 2

Re: Experimental 4.1 port
by Adriaan van Os 12 Apr '06

12 Apr '06

Waldek Hebisch wrote: > The port should build without problems. There are extra test failures > (compared to 3.4.6): > > asmtest.pas, fjf395[ab].pas -- test programs expect to much > > fjf1102.pas -- unimplemented feature (but works with older older backends) > > fjf403b.pas, fjf779[abefg].pas, nicola4c.pas -- port does not detect > error/unused variables > > fjf395[ab].pas -- wrong tests > > fjf322.pas, fjf587b.pas -- spurious warnings === gpc tests === Running target any Running testsuite ... UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas UNSUPPORTED: fjf165a.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf998r.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: longr2.pas FAIL: nicola4c.pas FAIL: prep2p.pas FAIL: systemtest.pas === gpc Summary === # of tests 5070 # of expected passes 5048 # of unexpected failures 15 # of unsupported tests 7 gpc version 20060325, based on gcc-4.1.0 Miraculously, fjf1062[a-c].pas no longer fail, although the C testprogram still does (<http://gnu-pascal.de/crystal/gpc/en/mail13495.html>). The failure of fjf563e.pas is new. It doesn't fail at -O0. Various outputs are: [g5:gcc/p/test] adriaan% gpc fjf563e.pas -O3 fjf563e.pas:7: warning: constructing limited integer set `0 .. 255'; fjf563e.pas:7: warning: use `--setlimit=NUMBER' to change the size limit at compile time. [g5:gcc/p/test] adriaan% gpc fjf563e.pas -O0 fjf563e.pas:7: warning: constructing limited integer set `0 .. 255'; fjf563e.pas:7: warning: use `--setlimit=NUMBER' to change the size limit at compile time. <tree_list 0x42471860 purpose <integer_cst 0x42471880 type <integer_type 0x4241f460 Integer> constant invariant tree_5 10000> value <integer_cst 0x424718a0 type <integer_type 0x4241f460 Integer> constant invariant tree_5 20000>> fjf563e.pas:7: error: invalid initializer for set <tree_list 0x42471860 purpose <integer_cst 0x42471880 type <integer_type 0x4241f460 Integer> constant invariant tree_5 10000> value <integer_cst 0x424718a0 type <integer_type 0x4241f460 Integer> constant invariant tree_5 20000>> fjf563e.pas:7: error: invalid initializer for set <tree_list 0x42471860 purpose <integer_cst 0x42471880 type <integer_type 0x4241f460 Integer> constant invariant tree_5 10000> value <integer_cst 0x424718a0 type <integer_type 0x4241f460 Integer> constant invariant tree_5 20000>> fjf563e.pas:7: error: invalid initializer for set [g5:gcc/p/test] adriaan% gpc fjf563e.pas -O1 fjf563e.pas:7: warning: constructing limited integer set `0 .. 255'; fjf563e.pas:7: warning: use `--setlimit=NUMBER' to change the size limit at compile time. Ah, I think this was because of the temporary patch to locate the invalid initializer set problem ! All in all, experimental gcc-4.1 support looks quite good. Regards, Adriaan van Os

2 1

Re: Experimental 4.1 port
by Adriaan van Os 12 Apr '06

12 Apr '06

Waldek Hebisch wrote: > I have now "almost ready" experimental gcc-4.1.0 port. There are some minor problems but basically 4.1.0 port should be now as good (or as bad...) as 4.0.3 port. I would > like to fix some extra problems (most of them not related to port) and add some feature before I make a new snapshot, so ATM I have made port available as patches: Thanks for the new diffs for gcc-4.1.0 ! I tried them, but the build dies with: ../.././xgpc -B../.././ -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -DHAVE_DESIGNATED_INITIALIZERS=0 -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING --unit-path=/Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts --automake -DRTS_RELEASE_STRING="'`cat /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/rts-version`'" -DGCC_VERSION="''" "/Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas" /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas: In function `CanRead': /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas:1878: error: invalid initializer for set /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas:1878: error: invalid initializer for set /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas: In function `CanWrite': /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas:1884: error: invalid initializer for set /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas:1884: error: invalid initializer for set /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas: In procedure `GPC_BlockRead': /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas:1894: error: invalid initializer for set /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas:1893: error: invalid initializer for set make[3]: *** [files.o] Error 1 make[2]: *** [pascal.rts] Error 2 make[1]: *** [stage1_build] Error 2 make: *** [bootstrap] Error 2 Regards, Adriaan van Os

2 4

Re: Out of range values in
by Bart van den Broek 09 Apr '06

09 Apr '06

----- Original Message ----- From: "Frank Heckenbach" <ih8mj(a)fjf.gnu.de> To: <gpc(a)gnu.de> Sent: Thursday, April 06, 2006 18:25 Subject: Re: Out of range values in > Bart van den Broek wrote: > >> >> > > If I (as an inactive observer) may comment / make a suggestion; >> > > when a constant of ByteBoole, WordBoole or LongBoole is evaluated, >> > > presumably at compile time, convert it to a value of type Boolean. >> > > As a consequence: >> > > type VeryTrue = ByteBool (10) .. ByteBool (42); >> > > means >> > > type VeryTrue = True..True; >> > > Also, in the test program fjf1102, (Ord (a) = 1) and (Ord (b) = 1) >> > > and >> >(Ord >> > > (c) = 1) holds, and more specifically Ord( ByteBool(42) ) = 1. >> > >> >Interesting idea, but if done only for constants (as I understand >> >your suggestion), it would also lead to strange effects: >> > >> >program foo; >> > >> >var >> > n: Integer = 42; >> > >> >begin >> > WriteLn (ByteBool (n) = ByteBool (42)) { => False } >> >end. >> >> Since the Borland Delphi 3 Object Pascal Language Guide mentions: >> "....Whenever a ByteBool, WordBool or LongBool value is used in a >> context >> where a Boolean value is expected, the compiler will automatically >> generate >> code that converts any nonzero value to the value True." >> If i interpret the expression ByteBool(n) = ByteBool(42) as "a context >> where >> a Boolean value is expected" then it is equivalent to (ByteBool(n) <> 0) >> = >> (ByteBool(42) <> 0), or (ByteBool(n) <> 0) = True, and foo would print >> True. > > I don't think so (BTW, what does Delphi do?). The context here is > `=' Since ByteBool is an ordinal type, and `=' allows the same > ordinal type (among others) on both sides, ByteBool is valid. I.e., > it's a context where Boolean is allowed, but not required. Contexts > that require Boolean include the conditions in if, while, until, or > assignments to Boolean variables, or Boolean value parameters. > >> >Besides, it probably wouldn't be 100% Delphi compatible, as Delphi >> >documentation (as quoted by Adriaan) states that Ord of "True" of >> >such types can be any value <> 0. >> >> Well, 1 is such a value <> 0, so how do u think it is incompatible? > > OK, but if it were always 1, then they'd probably say so, and not > write: > > : Boolean ByteBool, WordBool, LongBool > : Ord( True) = 1 Ord( True) = any non-zero value > >> I dont have Delphi available right now, but i vaguely remember Delphi >> does >> the following: >> ByteBool(True) = $FF >> WordBool(True) = $FFFF >> LongBool(True) = $FFFFFF >> If so (will check later) then this means my suggestion is different and >> maybe incompatible. > > I don't either, but someone who does might want to check this (and > the behaviour of my program above under Delphi). If really > ByteBool(True) = $FF (I assume you mean Ord (ByteBool (True)) = $FF, > or can you compare ByteBool and integers in Delphi?) that would > complicate things, as normally (in BP and GPC) value type casts > preserve ordinal values ... > > 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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 > E5E8 > > Indeed I meant Ord(ByteBool(True)) = $FF and so on. When I run this program in Delphi v7.1 (7.0 + patch) program Project1; {$APPTYPE CONSOLE} procedure RunTest; var n : Integer; m : Integer; begin n := 42; m := 43; Writeln(ByteBool(n) = ByteBool(m)); Writeln(ByteBool(n) = ByteBool(42)); Writeln(ByteBool(n) = True); Writeln(Ord(ByteBool(True))); Writeln(WordBool(n) = WordBool(m)); Writeln(WordBool(n) = WordBool(42)); Writeln(WordBool(n) = True); Writeln(Ord(WordBool(True))); Writeln(LongBool(n) = LongBool(m)); Writeln(LongBool(n) = LongBool(42)); Writeln(LongBool(n) = True); Writeln(Ord(LongBool(True))); Writeln(Pred(Boolean(False))); Writeln(Pred(ByteBool(False))); Writeln(Pred(WordBool(False))); Writeln(Pred(LongBool(False))); end; begin RunTest; end. I get this output (ignore extra empty lines i put in): TRUE TRUE TRUE 255 TRUE TRUE TRUE 65535 TRUE TRUE TRUE -1 <gibberish> <gibberish> TRUE TRUE Note the signedness of the Ord(LongBool(True)), probably due to the fact that Ord function is 32 bits integer. I guess being completely compatible here is not simple. Bart

3 2

Re: [MacPascal] GPC: // comments and line endings
by Adriaan van Os 09 Apr '06

09 Apr '06

Forwarding from the MacPascal mailing list: Erling Johansen wrote: > Adriaan van Os wrote: > >> Erling Johansen wrote: >> >>> GPC rejects code with // comments when the source has Macintosh line >>> endings, but not when the source has Unix or DOS line endings. >>> >>> Is this a bug or a feature? >> A bug. To be reported on the gpc mailing list (but I can do that if >> you are not suscribed). > > I'm not subscribed, so please report it. Regards, Adriaan van Os

1 0

Re: Out of range values in
by Frank Heckenbach 06 Apr '06

06 Apr '06

Waldek wrote (in private mail, but I hope you don't mind me forwarding it to the list, as it concerns the current discussion about bitsizes): > I have noticed that fjf395[ab].pas expects to be able to compute > on out of range values. Both of them fail with 4.1 backend. > According to recent discussion on GCC list using out of range > values is illegal (if we consider such values legal the type should > have bigger bounds). > > I would prefer to declare fjf395[ab].pas illegal and remove them from > the testsuite. And say that user programs expecting such behaviour > should be fixed. Yes, the test programs are currently wrong as they put ordinal values > 1 in `Boolean attribute (Size = n)' variables. I wrote them at a time when semantics of `Boolean (n)' (as they were called back then) were not very clearly defined ... > The other solution is "double accounting", when we have types > with loose bounds for backend use, but we separatly track ranges > in the front end. I'd prefer to avoid this, as it'd surely add quite some effort for probably little gain. In fact, as integer ranges can be freely declared, and we don't (yet) support bitsizes for types other than integers and Booleans, it seems to affect only Booleans with specified bitsize, which is a very special case. So we have the choice either to leave the range at False {0} .. True {1}, and forbid other values, and change the test programs, or to really declare the range according to the bitsize (e.g. False {0} and 255 values of True for an 8 bit type). The former would seem more Pascalish. OTOH, such types are probably often used for C interfaces, and what will happen if C routines put values > 1 in them? Probably undefined stuff (e.g., the backend would be free to check only bit 0 or byte 0), so we'd have to declare this invalid, which limits the use of these types. With the latter, we'd get some strange semantics (such as `Ord (High (...))' of such types not yielding 1) -- or rather, we'd retain them, as some strange semantics are already there: program Foo; type t = Boolean attribute (Size = 8); var a, b: t; begin a := t (5); b := t (2); WriteLn (a); WriteLn (b); WriteLn (a = b) end. Says: True True False And contrary to Adriaan's previous suggestion we'd actually need a pseudo-schema then, as `Boolean attribute (BitSize = 8)' according to his proposal would yield a 0 .. 1 range. But still, the latter seems the lesser evil to me ATM, as otherwise these types might not be very useful at all ... Or can/should we drop them altogether? Are they needed for Delphi compatibility? Or does someone seriously need them (where they can't just be replaced with bitsize-Integers, adding `<> 0' and `Ord' where necessary)? Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

4 11

An other gdb useful patch
by Pascal Viandier 05 Apr '06

05 Apr '06

When debugging gpc programs, I often get a gdb coredump when printing the value of string which is not -yet- initialized. This happens even more often when using ddd on top of gdb since the value is displayed as soon as you move the mouse pointer over the variable name. This problem occurs because gdb uses the value of the 'length' field of the string type schema to print the string contents. If the string is not initialized, this field may contain any value -even negative- so it crashes gdb. I solved this bug (IMHO this is one) by getting the Capacity field too. This field is always initialized for gpc strings - this is an assumption -. When printing a string, I compare the value of the actual length and the value of the capacity of the string. If the length is either negative or greater than the capacity, the capacity is used to print out the value. This modification has no impact on other Pascal string types (BP, etc). I put the patches (4) for gdb 6.4 in attachment. If someone estimates these patches are interesting enough to transmit them to the gdb maintainers, feel free to do so. I am not a member of the gdb mailing list and I do not know how to submit patches to them. Hope this will help someone. Kind regards Pascal

3 9

Integer Of
by Contestcen＠aol.com 05 Apr '06

05 Apr '06

<< I feel we should use consistent terminology. The SizeOf function returns a number of bytes, the BitSizeOf function returns a number of bits. Using just "size" when the requested parameter is a number of bits, introduces sloppy terminology, which - in general - is a source of programming errors. With IntegerOf(n), one can (implicitely) read IntegerOf(bits), so I think that is OK. Regards, Adriaan van Os >> If you want to be grammatical and consistent, then consider IntegerOfBitSize(n). For my taste, however, this is just too long. Frank Rubin

1 0

(no subject)
by Contestcen＠aol.com 04 Apr '06

04 Apr '06

In a message dated 4/2/2006 10:51:12 AM Eastern Standard Time, ih8mj(a)fjf.gnu.de writes: << BTW, native speakers, with formulation is better, "integer with/of N bits"? >> The description "Integer of N bits" is better. For the declaration, both IntegerOfBits(n) and IntegerWithBits(n) seem awkward. I would prefer the shorter IntegerOf (n) or possibly IntegerOfSize (n). Frank Rubin

3 2

gdb 6.4 patch
by Pascal Viandier 03 Apr '06

03 Apr '06

I installed gdb 6.4 on my Debian x86 box and made the patch for gpc in it. To who may be interested, here it is :-) --- gdb-6.4/gdb/dwarf2read.c 2005-11-03 21:58:31.000000000 -0500 +++ gdb-6.4.new/gdb/dwarf2read.c 2006-03-31 14:15:52.000000000 -0500 @@ -911,6 +911,8 @@ static void read_enumeration_type (struct die_info *, struct dwarf2_cu *); +static void read_set_type (struct die_info *, struct dwarf2_cu *); + static void process_enumeration_scope (struct die_info *, struct dwarf2_cu *); static struct type *dwarf_base_type (int, int, struct dwarf2_cu *); @@ -2648,6 +2650,9 @@ read_enumeration_type (die, cu); process_enumeration_scope (die, cu); break; + case DW_TAG_set_type: + read_set_type (die, cu); + break; /* FIXME drow/2004-03-14: These initialize die->type, but do not create a symbol or process any children. Therefore it doesn't do anything @@ -4031,6 +4036,24 @@ return new_prefix; } +static void +read_set_type (struct die_info * die, struct dwarf2_cu *cu) +{ + struct type *domain_type; + + /* Return if we've already decoded this type. */ + if (die->type) + { + return; + } + + domain_type = die_type (die, cu); + + die->type = create_set_type (NULL, domain_type); + +} + + /* Given a pointer to a die which begins an enumeration, process all the dies that define the members of the enumeration, and create the symbol for the enumeration type. @@ -6113,9 +6136,11 @@ case DW_LANG_Ada95: cu->language = language_ada; break; + case DW_LANG_Pascal83: + cu->language = language_pascal; + break; case DW_LANG_Cobol74: case DW_LANG_Cobol85: - case DW_LANG_Pascal83: case DW_LANG_Modula2: default: cu->language = language_minimal; @@ -6904,6 +6929,7 @@ case DW_TAG_structure_type: case DW_TAG_union_type: case DW_TAG_enumeration_type: + case DW_TAG_set_type: SYMBOL_CLASS (sym) = LOC_TYPEDEF; SYMBOL_DOMAIN (sym) = STRUCT_DOMAIN; @@ -7225,6 +7251,9 @@ case DW_TAG_enumeration_type: read_enumeration_type (die, cu); break; + case DW_TAG_set_type: + read_set_type (die, cu); + break; case DW_TAG_subprogram: case DW_TAG_subroutine_type: read_subroutine_type (die, cu); @@ -7282,7 +7311,8 @@ struct die_info *parent; if (cu->language != language_cplus - && cu->language != language_java) + && cu->language != language_java + && cu->language != language_pascal) return NULL; parent = die->parent;

1 0

Re: Redeclarations of predefined ordinal
by willett 03 Apr '06

03 Apr '06

On 2 Apr 2006, at 10:46, Frank Heckenbach wrote: >> 1. Predefine 2 pseudo-schema types to define signed and unsigned >> integral types: >> >> IntegerWithBits (n) >> CardinalWIthBits (n) >> >> where n is a compile-time constant expression. >> > > BTW, native speakers, with formulation is better, "integer with/of N > bits"? > By my intuition (native speakers vary), clearest would be "Integer of N Bits". Given that the parameter cannot appear in the middle of the predefined identifier, perhaps "IntegerOfBitsize(n)". Others, including (my second choice) "IntegerOfBits(n)" are to me less clear--it suggests that other integers are not made up of bits. Ålso, "of" is more consistent with Pascal use in declarations, "with" has different Pascal semantics. IMHO Willett Kempton

1 0

Re: New (gpc-20060325)
by Adriaan van Os 03 Apr '06

03 Apr '06

>> Waldek Hebisch wrote: >> >>> Adriaan van Os wrote: >>>> Waldek Hebisch wrote: >>>>> BTW: if the same happens with standalone program (without >>>>> modules) >>>>> I should be able to reproduce it. >>>> >>>> Sorry, not clear to me what you mean. >>> >>> I have build a cross-compiler targetting Mac OSX. However, I do not >>> have the complete toolchain (only bare compiler). Without full >>> toolchain I can not compile RTS (the problem really is >>> configure) and >>> also I can not compile anything using GPC module. >>> >>> If you have a testcase which does not use GPC module (directy or >>> indirectly) I should be able to compile it. In fact, if a >>> program uses >>> no extra modules (units) at all debugging becomes easier. >>> >>> I have tried the cross-compiler on various test programs and ATM it >>> happily produced stabs debug info. >> >> OK, I understand, I will look for a testcase (or try to isolate the >> problem). > > Some observations: > > 1. the problem does not occur when running gpc directly rather than > with make, even when passing the same compiler switches (this > sounds like random behaviour and makes me think there is an > uninitialized variable somewhere in the compiler source code) > > 2. the problems disappears when I remove Turbo3 from the USES > clause in aturbo3test.pas > > 3. the problem persists when I reduce the Turbo3 unit to nothing but > > import > > System (MemAvail => System_MemAvail, > MaxAvail => System_MaxAvail); > > Will try to further narrow this down in units/System.pas. The problem disappears when I change type PMemList = ^PMemList; to type PMemList = ^Pointer; in the function MemAvail in units/system.pas. I think that explains it. Apparently the stabs symbol generator doesn't like the type PMemList = ^PMemList declaration. Regards, Adriaan van Os

3 3

Redeclarations of predefined ordinal data types
by Adriaan van Os 02 Apr '06

02 Apr '06

The following two programs are rejected by gpc program redeclare1; type Int16 = Integer attribute( size = 16); Integer = Int16; {error: identifier `Integer' redeclared in a scope where an outer value was used} begin end. program redeclare2; type Integer = Integer attribute( size = 16); {error: identifier `Integer' redeclared in a scope where an outer value was used} begin end. The following program is accepted: program redeclare3; type Integer = ShortInt; begin writeln( 'SizeOf( Integer) = ', SizeOf( Integer)) end. GPC has been accepting the above first two programs. Gale Paper reminded me that this was (probably) changed in gpc-20050325 with bug fix 20050325: check identifier scopes stricter (az25.pas, fjf1059*.pas). However, I would argue that a type definition like int_nn = Integer attribute( size = nn); does not "use" the Integer type as such in a strict sense. Thus, it can be treated as a special case, accepting the above two programs again. Same for the other predefined ordinal types that accept attribute( size = nn), like Word, Cardinal and Boolean. Regards, Adriaan van Os

4 10

Preprocessor conditional expression support bug
by Gale Paeper 02 Apr '06

02 Apr '06

While working on a MacPascal dialect to GPC porting project, I was surprised to encounter preprocessor errors in conditional compilation directives where the conditional expression directly or indirectly (i.e., a macro expansion) contained $ hex constants. A short example (thanks Afriaan): program dollars; {$definec dollars $1} {$ifc dollars = 1} {$endc} begin end. Compiling yields the error: dollars.pas:3: conditional expression: parse error If one changes {$definec dollars $1} to {$definec dollars 1}, it compiles with no problem. After some futher testing and digging into the gpcpp.c source code, it looks like the preprocessor doesn't support $ hex constants in conditional expressions for conditional compilation directives. Since $ hex constant usage in preprocessor expressions (including conditional compilation directives) has been supported in MacPascal dialect compilers for well over two decades and it has been a long standing "standard" to use hex nibble formatting convensions for things such as conditional compilation version testing, the lack of GPC preprocessor support for $ hex constants in preprocessor conditional expressions creates MacPascal to GPC code porting problems. (Note: I'm not sure how much further back $ hex constant usage in preprocessor expression has been supported in Apple's USCD Pascal derived compilers. The support was in the first MPW Pascal compiler and may have been supported in the predecessor Lisa Pascal and Apple II compilers but I don't have anything (e.g., documentation) to verify it in the predecessors.) If for no other reason than to facilitate porting of MacPascal dialect codee to GPC, the preprocessor conditional expression support needs to be fixed to allow usage of $ hex constants. Compiler used was Adriaan's pre-built GPC Mac OS X version with specs: Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2 Thread model: posix gpc version 20051116, based on gcc-3.4.5 Gale Paeper gpaeper(a)empirenet.com

3 3

Re: New (gpc-20060325)
by Adriaan van Os 01 Apr '06

01 Apr '06

> Waldek Hebisch wrote: > >> Adriaan van Os wrote: >>> Waldek Hebisch wrote: >>>> BTW: if the same happens with standalone program (without modules) >>>> I should be able to reproduce it. >>> >>> Sorry, not clear to me what you mean. >> >> I have build a cross-compiler targetting Mac OSX. However, I do not >> have the complete toolchain (only bare compiler). Without full >> toolchain I can not compile RTS (the problem really is configure) >> and >> also I can not compile anything using GPC module. >> >> If you have a testcase which does not use GPC module (directy or >> indirectly) I should be able to compile it. In fact, if a program >> uses >> no extra modules (units) at all debugging becomes easier. >> >> I have tried the cross-compiler on various test programs and ATM it >> happily produced stabs debug info. > > OK, I understand, I will look for a testcase (or try to isolate the > problem). Some observations: 1. the problem does not occur when running gpc directly rather than with make, even when passing the same compiler switches (this sounds like random behaviour and makes me think there is an uninitialized variable somewhere in the compiler source code) 2. the problems disappears when I remove Turbo3 from the USES clause in aturbo3test.pas 3. the problem persists when I reduce the Turbo3 unit to nothing but import System (MemAvail => System_MemAvail, MaxAvail => System_MaxAvail); Will try to further narrow this down in units/System.pas. Regards, Adriaan van Os

3 5

gcc-3.4.6
by Russell Whitaker 27 Mar '06

27 Mar '06

Hi Built gpc using just released gcc-3.4.6 and gpc-20060215: passed: 5054 unsuported: aregextest.pas fail: fjf9321.pas, fjf932b.pas both failures got an ICE at the line "with v do" Russ

5 11

Re: the loss of SET_TYPE
by Adriaan van Os 26 Mar '06

26 Mar '06

Forwarding from the gcc-patches mailing list > Gaius Mulley wrote: >> I'm trying to port bring the GNU Modula-2 front end up to gcc-4.1.0 >> and have found out that SET_TYPE has been removed :-) >> >> I see the patch from Dec 2004: >> >> http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00670.html >> >> and understand the reason (no front ends in gcc tree use SET_TYPE >> etc). I suppose I'd just like to flag that Modula-2 utilises this type >> during the generation of BITSET types and also large sets (built >> internally from multiple int length SET_TYPEs). But I totally >> understand it might be difficult to justify code which is never run >> (and difficult to test) in the main gcc tree.. >> >> Pragmatically I guess it is best for me to maintain a reversed patch >> which can be applied to a gcc-4.1.0 tar ball which reintroduces this >> TYPE. Any thoughts? > > Many of the front-ends use langauge-specific tree codes to manipulate > types and/or operators specific to their needs. I suspect that > treating the SET_TYPE as a front-end tree is your best bet, and > lowering > it to the appropriate C-like representation (array, struct or integer) > during gimplification is the best way to go. > > Even if SET_TYPE is resurected, I suspect that the lack of constant > folding transformations on these expressions/trees, makes it > unnecessary > to expose their semantics to the early middle-end (and thereby all > other > front-ends), but perhaps there are dwarf2 or similar issues that don't > yet have the necessary hooks, that require this be a "common" tree > code? > > > [As a one-time Modula-2 programmer myself, I'd support Eric's > suggestion. > Wasn't James Morrison investigating issues of GNU pascal integration?] > > Roger Regards, Adriaan van Os

1 0

New (20060325) snapshot
by Waldek Hebisch 25 Mar '06

25 Mar '06

Extra info about 4.0 port: Expect some test failures. Known problems are: - sometimes gpc thinks that variables are used when in fact they are not. This causes spurious warnings about using uninitialized variables and missings warnings about unised variables - some invalid constructs are accepted - line number info is even less acurate then it was -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

1 0

Cross-compiler for mipsle platform
by Prof A Olowofoyeku (The African Chief) 24 Mar '06

24 Mar '06

Hi A quick report. I have been able to produce a Linux-based GPC cross- compiler (gcc-2.95.4 back end) targetting the "mipsle" platform. This is the platform for the Texas Instruments AR7-based ADSL modem routers (there are a whole load of them - e.g., Linksys WAG54GV2, Safecom SWAMR-54108/SWART-54125, Netgear DG834G, Aztech DSL 600EW, Netcomm NB5, Actiontec GT701-WG, D-Link DSL-G604T, and more). The routers' firmwares are based on Montavista Linux and uClibc - this is the output of "uname -a": "Linux 2.4.17_mvl21-malta-mips_fp_le #24 Wed Feb 8 15:58:57 CST 2006 mips unknown". There have been gcc cross-compilers for some time (based on gcc- 2.95.x), which I have been using to produce some mods. I didn't believe that producing a Pascal cross-compiler would be a trivial exercise, but it was in the end not as hard as I had imagined. It was a bit of a kludgy process, and I had to build the RTS separately (in the same way in which I would build any program or library for the platform), and patch the gpc compiler driver to search for libraries in some other places, but I got there in the end. My preliminary tests indicate that the compiler is working well, and is producing good binaries that run well on the router. I also produced a shared version of libgpc.a, so that the binaries will be as small as possible (space is limited in the flash and ram disks, although "memavail" tells me that I have 99mb memory to play with (I seriously doubt it!)). So, another GPC success story :-) Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

1 0

[OFF] European Community Patent Consultation
by Adriaan van Os 24 Mar '06

24 Mar '06

From <http://consultation.ffii.org/> "In January 2006, the European Commission started a consultation on a project that, if it goes according to current plans, will result in the legalization of software patents, which are known to be devastating to the software industry. The project is the Community Patent. While the essential idea, having EU-wide patents, is a good one, the current Commission proposal would transfer EU and member state legislative and judicial power to the European Patent Office, which would effectively legalize their hitherto illegal practice of granting software patents. The Commission asks any interested party to fill-in a questionnaire with their views. The Foundation for a Free Information Infrastructure (FFII) questions the validity of the procedure, based on the serious lack of accessibility, which means that a majority of EU businesses are completely excluded from answering. However, we also recommend participation to those businesses that are able to do so, since this will demonstrate to what extent businesses are affected." Those on the list that live in Europe (excluding Switzerland), please participate <http://consultation.ffii.org/How_to_Answer>. Regards, Adriaan van Os

1 0

gpc and OpenMP
by Alexander Todorov 24 Mar '06

24 Mar '06

Hello to all, are there any parallel code developers in the list? I will have to work on a mixed mode parallel project using MPI and OpenMP. There are some bindings in pascal for the MPI library which is ok. Does gpc support OpenMP compiler directives? Is there a known pascal compiler that supports OpenMP? here are some links : Message Passing Interface http://www.open-mpi.org/ http://www.lam-mpi.org/ http://www.mpi-forum.org/ http://www-unix.mcs.anl.gov/mpi/ OpenMP : http://www.openmp.org TIA.

3 2

Fwd: Re: RTS and thread safety
by Frank Heckenbach 22 Mar '06

22 Mar '06

Forwarded from: marcov(a)stack.nl (Marco van de Voort) (Sorry, it's a bit late. I had overlooked it.) On 2006-02-25, Frank Heckenbach <ih8mj(a)fjf.gnu.de> wrote: > However, as I've said > before, I'm skeptical about Input etc. Do we really want a > per-thread Input, each with its own buffer (which means, if several > of them are acutally used, it becomes hard to foretell in which one > each sequence of input bytes ends up)? Similar for Output. For > StdErr, one could argue that it shouldn't buffer at all (which GPC's > in fact doesn't, and so does stderr in C by default AFAIK). This is a possible problem, buffering also complicates initialisation of a new thread, because it requires more than a shallow copy of the threadvar segment. (buffer is duplicated, stuff in output is thus twice in buffer, not to speak about what if you use pointers in the filedescriptor record etc). There are bugreports about problems with threadsafe input/output in FPC bugrepository, mostly in combination with unit crt. >> There's a few more in TP-compatibility units (like doserror in the >> Dos unit and some crt things) > > Well, for CRT, just making the internal state per-thread wouldn't > really help much AFAICS. E.g., if each threads has its own screen > buffer, and updates the real screen from it, this would probably > result in chaos. IOW, as there's only one physical screen (unless > multi-headed), I think one probably needs some common data across > threads. Or you leave it up to the user -- as, e.g., ncurses > recommends doing all curses I/O within one thread. The latter thing is a typical thing for UIs. E.g. Delphi also specifies the VCL (GUI classes) as non-threadsafe. It provides a synchronization mechanism though to schedule basic code in the mainthread. >> Since our RTL is under a slightly modified LGPL (allows static >> linking as long as you make the modifications to the FPC-RTL-licensed >> code available), license-wise I don't think there is any problem for >> you to reuse things. If there is, we could dual-license it under the >> regular LGPL as well I suppose (the main reason for the static >> linking exception is that some OS'es, like Dos, simply do not support >> dynamic linking, and support for creating dynamic libraries was not >> available for all OS'es in our compiler from the start either). > > BTW, standard LGPL allows static linking as well. You just have to > distribute object files of the non-free parts, so users can relink. > But I suppose for some reason that's not desired? No. I think we simply didn't think of that, and the GNU site didn't spell it out either. It is a good point for the license FAQ though.

2 6

Variable number of parameters
by Pascal Viandier 19 Mar '06

19 Mar '06

Is there a mechanism in GPC to pass a variable number of parameters to a Pascal procedure (and to know how many they are?). I would like to implement something like the C "sprintf()" in Pascal. Any clue would be welcome. Regards Pascal Viandier

2 13

Re: Changing source code
by cbfalconer＠att.net 16 Mar '06

16 Mar '06

"Prof A Olowofoyeku (The African Chief)" <chiefsoft(a)bigfoot.com> wrote: > > This isn't strictly a GPC question, but it is related, so I'll ask > anyway :| > > Is there an easy way to change a string in all source files to > another string? > > For example, if I want to change all occurrences of "Type foo = > Object (bar)" to "Type Tfoo = Class (Tbar)" in all ".pas" and > ".pp" files in a directory tree, is there an easy way to do it, > using standard GNU tools? I could of course write a program to > do it, but I figured there could be an easier way. Thanks. The standard tool sed comes to mind. Another item that may be useful is id2id-20, available in standard C source at: <http://cbfalconer.home.att.net/download/id2id-20.zip> -- Chuck F (cbfalconer@yahoo.com)(cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!

1 0

Re: Redeclarations of predefined ordinal data types
by cbfalconer＠att.net 16 Mar '06

16 Mar '06

Adriaan van Os <gpc(a)microbizz.nl> wrote: > > The following two programs are rejected by gpc > > program redeclare1; > type > Int16 = Integer attribute( size = 16); > Integer = Int16; {error: identifier `Integer' redeclared in a scope > where an outer value was used} > begin > end. > > program redeclare2; > type > Integer = Integer attribute( size = 16); {error: identifier `Integer' > redeclared in a scope where an outer value was used} > begin > end. > > The following program is accepted: > > program redeclare3; > type > Integer = ShortInt; > begin > writeln( 'SizeOf( Integer) = ', SizeOf( Integer)) > end. All right and proper in my view. Once an identifier from an outer scope is used in an inner scope it can no longer be redeclared in that inner scope. Usage has extended its scope. The proper way to create a restricted integer type is: const maxint = 32767; /* for example */ type integer = -maxint .. maxint; which is why these items are predeclared at level 0, rather than reserved words. -- Chuck F (cbfalconer@yahoo.com)(cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!

1 0

export vs static
by Pascal Viandier 15 Mar '06

15 Mar '06

I would like to submit a case on which I spent some time. It occurred with sources converted to GPC from SUN Pascal with an automated script. In the interface section of a module, the following statements: Export MyModule = (A); .... Var A : Integer = 4; attribute(static); .... This module compiles with no complaint. However for all modules importing MyModule -AND- using A, gpc issues the <error undefined reference to 'A'>. The problem is: SUN Pascal understands the "static" directive as in C, so the statements above are correct and work - as in C -, but not for GPC. I know the difference between the two "static" flavours but it would have been of great help if gpc had issued at least a warning when compiling MyModule. Something like: "Cannot export a static variable" had saved me some difficult hours. I did not found any reference to the directive "static" in the 7185 or 10206 standards and the GPC documentation about this is not as clear as it could be. Since I cannot determine if I hit a bug or if it is something one should not bother with, I let you make your own opinion. Kind regards Pascal Viandier

2 5

Strings and standard Pascal
by Waldek Hebisch 14 Mar '06

14 Mar '06

Consider the following program: program fstr(output); type sat = packed array [1..16] of 'K'..'O'; var sa : sat; begin sa := 'OK'; writeln('Sizeof(sa) = ', Sizeof(sa)); writeln(sa) end . ATM it "works". However, it seems that this program is illegal. Namely ISO says: : Each value of a string-type shall be structured as a one-to-one : mapping from an index-domain to a set of components possessing : the char-type And later it again speaks about `the char-type'. So it seems that subranges of char type are _not_ allowed as component types of strings. Form implementation point of view subranges can be packed more tightly then char type, so such restriction make some sense. Now, the question is what shall we do? And do you agree with my reading of the standard? Shall we disallow the program above. Or maybe accept it as an extension, but report an error in standard mode. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

4 7

Non-local exit out of method
by Peter Schorn 10 Mar '06

10 Mar '06

Dear all, are there any plans to make non-local exits out of a method legal? This works in CodeWarrior Pascal and looks somehow better than a goto. The following program illustrates the issue: I could not find a way to make a non-local exit out of q using the exit statement. program exittest; { compile with gp --nonlocal-exit exittest.pas } type o = object procedure p; end; procedure o.p; procedure q; begin exit(p); { error: invalid argument `p' to `Exit' } exit(o.p); { error: syntax error before `.' } end; begin { o.p } end; begin { exittest } end. Best regards, Peter

5 11

Changing source code
by Prof A Olowofoyeku (The African Chief) 08 Mar '06

08 Mar '06

Hi This isn't strictly a GPC question, but it is related, so I'll ask anyway :| Is there an easy way to change a string in all source files to another string? For example, if I want to change all occurrences of "Type foo = Object (bar)" to "Type Tfoo = Class (Tbar)" in all ".pas" and ".pp" files in a directory tree, is there an easy way to do it, using standard GNU tools? I could of course write a program to do it, but I figured there could be an easier way. Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

5 6

Re: Changing source code
by Garth Fletcher 08 Mar '06

08 Mar '06

Prof A Olowofoyeku (The African Chief) wrote: > Hi > > This isn't strictly a GPC question, but it is related, so I'll ask > anyway :| > > Is there an easy way to change a string in all source files to another > string? > > For example, if I want to change all occurrences of "Type foo = Object > (bar)" to "Type Tfoo = Class (Tbar)" in all ".pas" and ".pp" files in a > directory tree, is there an easy way to do it, using standard GNU > tools? I could of course write a program to do it, but I figured there > could be an easier way. Thanks. > > Best regards, The Chief > -------- > Prof. Abimbola A. Olowofoyeku (The African Chief) > web: http://www.greatchief.plus.com/ > TextWrangler (the FREE little brother of BBEdit) can be downloaded from <http://www.barebones.com/support/textwrangler/updates.shtml> And it will do multi-file GREP based searches. -- Garth Fletcher

1 0

Re: potential buffer overflow in gpc lexer
by Waldek Hebisch 04 Mar '06

04 Mar '06

Martin Pitt wrote: > Frank Heckenbach [2006-03-02 18:37 +0100]: > > > not sure, if that's actually a problem resulting in the worst > > > scenario, > > > > It might if someone runs the compiler in a server-like scenario. > > (I doubt whether anyone does, and if so, there'd be other security > > questions to consider.) When using the compiler normally, to build > > and then run a program, it's probably less harmful, since "arbitrary > > code execution with crafted pascal source files" is really the > > purpose of a compiler. ;-) > > Not really. You do not want to execute arbitrary code by merely > *compiling* source code. Think of autobuilders of Linux distributions, > etc. Every nontrivial package contains a makefile or a build script, so it executes arbitrary code anyway. The only semi-realistic threat is when somebody sets a teaching site, where anybody can submit a program for syntax checking. > > > anyway regeneration with flex-2.5.33 does fix this bug. > > > > > > * SECURITY UPDATE: Fix arbitrary code execution with crafted > > > pascal source files. > > > * Rebuild gcc/p/pascal-lex.c with the current flex, which fixes a > > > buffer overflow in generated flex scanners. > > > * CVE-2006-0459 > > > > Do I see this right that the bug is in flex, not in GPC itself? > > To be exact, it was in the scanner generated by flex. > > > (I suppose > > https://launchpad.net/distros/ubuntu/+source/flex/+bug/30940 > > but I've always got a 500 on this page so far.) > > Right, it was marked as private so far, but now the bug is public. > > > Is the problem also present in flex-2.5.27? > > I didn't check, but it's highly probable. > Looking at the description I see that the problem is due to line: *YY_G(yy_state_ptr)++ = yy_current_state; similar line is present in flex scanners generated with older flex versions, but only if the scanner uses reject rules. AFAICS GPC scanner do not have this problem: `pascal-lex.c' do not contain `yy_state_ptr'. > > I've now built and tested GPC with flex-2.5.33 as well. No > > regressions apart from a few harmless prototype warnings. So I > > suggest we offically require 2.5.33 from now on. > ATM I see no need. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 1

Reading source past end of block
by Pascal Viandier 04 Mar '06

04 Mar '06

I encountered an unexpected error with GPC when compiling a Pascal source that contains "some text" (not Pascal code) after the final "End." of the program. GPC tries to compile this extra text and finds syntax errors in it. Although I did not see any reference to this in ISO 10206, I think it could be a nice feature for GPC to ignore everything after the final "End." in a program or a unit since nothing useful for it should be there. I am using gpc 20050331 under Debian Linux X86 and gpc 20051116 on Sparc Solaris 2.6. Kind Regards Pascal Viandier

6 11

GPC with GCC 4?
by Silvio a Beccara 03 Mar '06

03 Mar '06

Dear friends, I haven't been following the list very closely lately, so I'd have a question: is there a version of GPC which is based on GCC 4? I'm asking because I've been told that GCC 4 is much faster than its predecessors, so there could be a significant gain in performances. Thank you, regards Silvio a Beccara Trieste - Italy -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: I migliori giochi Jamba! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=4844&d=3-3

2 2

Re: Expressions with subrange operands
by cbfalconer＠att.net 03 Mar '06

03 Mar '06

Ernst-Ludwig Bohnen <bohnen(a)mail.desy.de> wrote: > ... snip ... > > Simplifying your program I observe the same problem: > > PROGRAM testsubrange; > var > i: ShortInt; {signed 16 bit integer} > j: SizeType; {unsigned 32 bit word} > point : record x,y: real end; {takes 16 bytes} > begin > i:= 3658; > j:= 16; > writeln ('result1 = ', i*j); {58528, OK} > writeln ('result2 = ', i*SizeOf(point)); {-7008, wrong} > end. > > My suspicion is that for calculating the second expression > the compiler uses wrong operand size (16? bit) instead > of 32 (function SizeOf returns a value of SizeType). > BTW: -7008+2^16 = 58528 I believe you are simply caught in the silly C value preserving promotion. C does not preserve unsignedness during integer promotion. This is built into the C standard, and means you will be getting signed values in unexpected places. -- Chuck F (cbfalconer@yahoo.com)(cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!

2 1

Expressions with subrange operands
by Adriaan van Os 02 Mar '06

02 Mar '06

[G5:gpc/testgpc/adriaan] adriaan% cat testsubrange.p program testsubrange; type int16 = integer attribute( size = 16); int32 = integer attribute( size = 32); point = record x,y: real end; var i: int16; procedure P( size: int32); begin writeln( 'size = ', size) end; begin i:= 3658; P( i * SizeOf( point)); end. [G5:gpc/testgpc/adriaan] adriaan% gp testsubrange.p [G5:gpc/testgpc/adriaan] adriaan% ./testsubrange size = -7008 Any comments ? Regards, Adriaan van Os

5 16

Unit name same as exported procedure name not allowed
by lanceboyle＠qwest.net 01 Mar '06

01 Mar '06

I have a unit named Head which exports a single procedure also named Head. In the calling program, the compiler (20050331) generates an error, "statement used as expression." The docs don't seem to say anything about a name limitation. Have my previous two Pascals let me get away with something naughty? Of course, renaming either the unit or the procedure fixes the problem. Jerry

4 4

Re: Debugger problems OS X
by lanceboyle＠qwest.net 01 Mar '06

01 Mar '06

On Feb 27, 2006, at 10:48 PM, lanceboyle(a)qwest.net wrote: > my program doesn't call anything like readline Oops--sorry. It indeed does call a readline. However, that problem notwithstanding, the debugger continues to behave oddly. After the debugger loads, my program takes about 10 seconds before anything appears to happen with it. Then, stepping in/out/over is unreliable, with the "program counter" (the red arrow that indicates which line is about to be executed) pointing to the wrong line. Jerry

2 2

Building gpc-20051104 on i686-apple-darwin8
by Adriaan van Os 28 Feb '06

28 Feb '06

> [Darwin:gcc/p/test] adriaan% gpc -v > Reading specs from > /Developer/Pascal/gpc344x1/lib/gcc/i686-apple-darwin8/3.4.4/specs > Configured with: ../gcc-3.4.4/configure --enable-languages=c,pascal > --enable-threads=posix --target=i686-apple-darwin8 > --host=i686-apple-darwin8 --build=i686-apple-darwin8 > --prefix=/Developer/Pascal/gpc344x1 > Thread model: posix > gpc version 20051104, based on gcc-3.4.4 > > (more about the testsuite in the next message) Because of <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22099> I ran the testsuite with --no-pic, so I had to tell the darwin linker to shut up complaining about that. [Darwin:gcc/p/test] adriaan% make EXTRA_PFLAGS="--no-pic -Wl,-read_only_relocs,suppress" rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core GP= PC="gpc" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused --no-pic -Wl,-read_only_relocs,suppress " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused --no-pic -Wl,-read_only_relocs,suppress " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log | "./test_sum" -d Test Run By adriaan on 2005-11-14 00:37:07 Native configuration is i686-apple-darwin8 (Darwin.local) === gpc tests === Running target any Running testsuite ... UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas ^[[FAIL: backtracerr.pas ^R FAIL: bo4-19.pas FAIL: bprealtest.pas FAIL: emptyrec.pas FAIL: fay.pas UNSUPPORTED: fjf165a.pas FAIL: fjf35.pas FAIL: fjf464c.pas FAIL: fjf464e.pas FAIL: fjf908.pas FAIL: fproc.pas UNSUPPORTED: gmptest.pas FAIL: gpcu_c_u.pas FAIL: knuth1.pas FAIL: nicola4d.pas FAIL: nlgpp.pas FAIL: nlgpp2.pas FAIL: robert1a.pas FAIL: robert1b.pas FAIL: systemtest.pas FAIL: t6334-2.pas FAIL: t6p6p3p4.pas FAIL: waldek1.pas === gpc Summary === # of tests 4965 # of expected passes 4939 # of unexpected failures 21 # of unsupported tests 5 gpc version 20051104, based on gcc-3.4.4 Innocent ------- * systemtest failure is caused by a Max OS X bug * bo4-19.pas fails because of the linker option passed to the testsuite gpc: -read_only_relocs: linker input file unused because linking not done gpc: suppress: linker input file unused because linking not done, * emptyrec.pas, same * gpcu_c_u.pas, same * waldek1.pas, same Serious ------ * bprealtest.pas, segmentation fault Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000041 Thread 0 Crashed: 0 dyld 0x8fe03d1b dyld::bindLazySymbol(mach_header const*, unsigned long*) + 119 1 dyld 0x8fe135cf stub_binding_helper_interface + 61 2 a.out 0x00001000 0x1000 + 0 3 a.out 0x000020c6 _p__M6_System_S63_Realtobpreal + 102 (system.pas:425) 4 a.out 0x0000305e _p__M0_main_program + 142 (bprealtest.pas:25) 5 a.out 0x000033ba main + 58 (<implicit code>:36) 6 a.out 0x00001cfe _start + 228 (crt.c:272) 7 a.out 0x00001c19 start + 41 ? maybe floating point exception * fay.pas, bus error Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0xbffff6d0 Thread 0 Crashed: 0 <<00000000>> 0xbffff6d0 0 + -1073744176 1 a.out 0x00002da8 Q.5 + 168 (fay.pas:92) 2 a.out 0x00002dbd _p__M0_S6_Outer + 13 (fay.pas:90) 3 a.out 0x00002e2a main + 58 (<implicit code>:134) 4 a.out 0x0000211e _start + 228 (crt.c:272) 5 a.out 0x00002039 start + 41 ? procedural parameter and local procedure problems (? trampolines ?) the following test failures look the same: * backtraceerr.pas * fjf35.pas * fjf464c.pas * fjf464e.pas * fproc.pas, same * knuth1.pas, same * nicola4d.pas, same * nlgpp.pas * nlgpp2.pas * t6334-2.pas * t6p6p3p4.pas * fjf908.pas failed 89 1.000000000000000e+00 2.500000000000000e-01 * robert1a.pas x ** y = NaN trunc( x ** y) = 0 * robert1b.pas 10.0 ** y = NaN trunc( 10.0 ** y) = 0 Anything I can do to investigate this further and report it to gcc bugzilla ? Regards, Adriaan van Os

5 17

gpidump with Debian X86
by Pascal Viandier 28 Feb '06

28 Feb '06

Hi, I just tried gpidump under Debian Linux X86 and it just does not work on any gpi file. I get the following message: gpidump accodbc.gpi accodbc.gpi: valid GPI file header Chunk `invalid chunk'gpidump: cannot read all the data from file `accodbc.gpi' in `BlockRead' (error #415 at 805884f) gpidump --version gpidump for GPC 20050331 based on GCC 3.4.5 20050821 (prerelease) (Debian 3.4.4-8) Copyright (C) 2002-2005 Free Software Foundation, Inc. Report bugs to <gpc(a)gnu.de>. Is this a known bug or is there a newer version? Regards Pascal Viandier

2 1

Debugger problems OS X
by lanceboyle＠qwest.net 28 Feb '06

28 Feb '06

What would cause this kind of output from the debugger? All of the files that are said to be unable to have their symbols read [bottom paste] seem to be in the right place on my disk. When I run under the graphical debugger on OS X, breakpoints in the main program are ignored and the call stack is all blank lines except for level 7 which is denoted as ?? (two question marks). When I try a backtrace in the regular debugger (noob alert), I get, among others, #4 $000420c8 in _p_Read_Line (F=$1df000) at /Users/adriaan/gnu/gpc/ gpc344d2/gcc-3.4.4/gcc/p/rts/files.pas:2297 which is indicated as being called from my program, except that my program doesn't call anything like readline and why is there an indication that there is something interesting at /Users/adriann/ ? My program sort of hangs at this point, but indeed it continues if I press Return. Here's the intial debugger output: [Session started at 2006-02-27 22:03:49 -0700.] GNU gdb 2003-01-28-cvs (Tue Jan 6 00:06:50 GMT 2004) Loading program into debugger… Copyright 2003 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 "powerpc-apple-darwin7.2.0". tty /dev/ttyp2 warning: Unable to read symbols from "/usr/lib/libSystem.B.dylib". warning: Unable to read symbols from "/usr/lib/libSystem.B.dylib"; skipping. Program loaded. run [Switching to process 20707 local thread 0xf03] Running… warning: Unable to read symbols from "/System/Library/Frameworks/ Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ A/vecLib". warning: Unable to read symbols from "/System/Library/Frameworks/ Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ A/vecLib"; skipping. warning: Unable to read symbols from "/System/Library/Frameworks/ Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ A/libvMisc.dylib". warning: Unable to read symbols from "/System/Library/Frameworks/ Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ A/libvMisc.dylib"; skipping. warning: Unable to read symbols from "/usr/lib/libstdc++.6.dylib". warning: Unable to read symbols from "/usr/lib/libstdc++.6.dylib"; skipping. Jerry

2 1

Re: New (20060215) snapshot
by Waldek Hebisch 27 Feb '06

27 Feb '06

Investigating Chief's report I have found that GPC parser may crash due to undetected parser stack overflow. To avoid the problem you can either apply the following patch to `parse.c' or patch `parse.y' and `glr.c' from bison distribution. The second way is "better", but requires you to have bison-2.1 and to patch its installotion. If you do not want to mess with bison patch to `parse.c' should be enough to avoid problems with GPC. Patches to `parse.y' and `glr.c' are in attachement. Both patches increase size of GPC parser stack. --- ../../../rr/gpc/p/parse.c 2006-02-15 03:05:20.000000000 +0100 +++ parse.c 2006-02-25 14:06:37.639531864 +0100 @@ -287,6 +287,7 @@ /* Copy the first part of user declarations. */ #line 63 "parse.y" +#define YYMAXDEPTH 200000 #include "gpc.h" /* A few keywords of some dialects can be parsed as regular identifiers @@ -8277,7 +8278,7 @@ size_t yysize, yynewSize; size_t yyn; yysize = yystack->yynextFree - yystack->yyitems; - if (YYMAXDEPTH <= yysize) + if (YYMAXDEPTH < yysize + YYHEADROOM) yyMemoryExhausted (yystack); yynewSize = 2*yysize; if (YYMAXDEPTH < yynewSize) -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

3 4

RTS and thread safety
by Peter N Lewis 25 Feb '06

25 Feb '06

This issue came up on the MacPascal list, but since I recently ran across an RTS thread safety issue, I thought I'd post it here too, at least for reference if not for anything else. >There is a multi-platform multi-threading unit for gpc, see ><http://www.gnu-pascal.de/crystal/gpc/en/mail10658.html> (but also read ><http://www.gnu-pascal.de/crystal/gpc/en/thread10512.html>). One thing I didn't see mentioned in the thread, but I discovered recently is that the routines like ReadStr/WriteStr are not thread safe. In particular they use a global variable (LastReadWriteStrFDR) for the file handle internally (to avoid re-allocating it each time), which is not MP thread safe. Also, they use an IOResult global variable (InOutRes variable). To properly handle MP threading, the RTS would, at the least, require everything to have a returned error result, rather than using IOResult, which would be a big change (although this would be desirable for New as well). This change would be incompatible with existing RTS routines, although it could possible be accomplished by placing a thread safe layer underneath the thread-unsafe standard RTS API, for example (very loose pseudo code) : procedure WriteStr( xxx ) var error: yyy; begin fh := GetReadWriteStrFDR; error := WriteStrSafe( fh, xxx ) InOutRes := error; conditionally exit with a runtime error end; It would also likely require additions/changes to the way the compiler interacted with the RTS. Any way you slice it, it'd be a fair amount of work to be entirely thread safe. Enjoy, Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

6 18

New (20060215) snapshot
by Waldek Hebisch 25 Feb '06

25 Feb '06

I have put a new gpc snapshot at: http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20060215.tar.bz2 It consists mostly of bugfixes (many related to ISO compliance), but there also some new features. Main change is to argument handling. In particular, `const' discriminated strings are now passed by reference and there is new `const var' mode, which forces passing argument by reference. For more detail see: http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20060215 and http://www.math.uni.wroc.pl/~hebisch/gpc/Fixed-20060215 -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

4 19

What causes "error: label `nonlocal_exit_18' not set"
by lanceboyle＠qwest.net 24 Feb '06

24 Feb '06

What causes this? error: label `nonlocal_exit_18' not set It's happening right after the declaration of a procedure in a unit. Jerry

4 8

Question Re: predef.h
by Mirsad Todorovac 21 Feb '06

21 Feb '06

Hi, all! As for our last discussion re buffure overflows, I had to take time to think and do homework, after which I feel more sympathetic to what you have said - stack execution protection truly isn't all. NOW; I was asked from GCC team whether the RotateLeft/RotateRight bug is still present in their middle-end/back-end, and I am unable to tell without trying to recompile implementation attempt in PASCAL with newest backend (3.4.5, as it seem that GPC still does not support 4.0.2 :-( However, it appears that predef.h is missing from gpc-yyyymmdd/p subtree. On surface, it appears to be replaced by predef.def. I am not sure if the mechanism of definition of primitives is the same as the previous one in predef.h, so I am asking because you of course know more. Thank you very much in forward. Best regards, Mirsad "Tvrdim da bi se napetost izmedju znanosti i vjere trebala rijesiti njihovom sintezom, a ne odbacivanjem ili podvojenoscu." Pierre Teilhard de Chardin (1881-1955)

2 3

Development status & GNU Pascal on QNX
by Michael Müller 21 Feb '06

21 Feb '06

Hi, we are developing a console application under Delphi. The main task is to run it on Windows. But in some situations we need to run it on the realtime OS QNX. For this we currently use FreePascal. But several years ago (when they switched to version 2.x) the removed the QNX support but FPC 1.0.x lacks many interesting features like dynamic arrays. Searching for alternatives we found GNU Pascal. But going through the project pages I'm a little bit confused about the current development status. The download page which offers alpha test versions shows a version that is nearly one year old. The community is still active and from browsing through the mail archive I found some up-to-date but personal releases. So my main question is what the development status of GNU Pascal is. Before we would switch to it which would need some changes in the code I would like to know if the work on GNU Pascal is coordinated. Additionally I thought that GNU Pascal is bundled with GNU C so that with every GNU C release there is a GNU Pascal release. But this seems to be a big misunderstanding from my side. Only Fortan and Java seems to be bundled. And related to our real need: Does anybody here use GNU Pascal on QNX? Regards Michael

2 3

Re: New (20060215) snapshot
by cbfalconer＠att.net 20 Feb '06

20 Feb '06

<Maurice.Lombardi(a)ujf-grenoble.fr> wrote: > Waldek Hebisch a écrit: > >> I have put a new gpc snapshot at: >> >> http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20060215.tar.bz2 > > Compiled with DJGPP and gcc 3.4.4 > Only one failure for a new test (y2k has no meaning) When can we hope to see a gpc to go with gcc 4.0.1 under DJGPP, which seems to be the latest available. It is awkward not to be able to update gcc. -- Chuck F (cbfalconer@yahoo.com)(cbfalconer@maineline.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE maineline address!

3 2

Changing access
by cbfalconer＠att.net 19 Feb '06

19 Feb '06

I sent the following message from my maineline address some time ago, and no change has been made to my access. Maybe it just disappeared? Darned if I know how to set this up. Please change my access so that mail is delivered to: cbfalconer(a)maineline.net and accepted from there and worldnet.att.net, att.net, or yahoo.com (all user cbfalconer). I would still like a reply-to gpc... to appear in the list messages sent to me. -- Chuck F (cbfalconer@yahoo.com)(cbfalconer@maineline.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE maineline address!

1 0

Range checking for constants
by Adriaan van Os 15 Feb '06

15 Feb '06

> * 20060130: In ISO modes report out of range constants only at > runtime (range1.pas) > > {$W-} > {$classic-pascal} > program range(Output); > var v : 1..2; > begin > if true then > writeln('OK') > else > v := 0 > end. I welcome the change, but it implies that no checking is done when --range-checking is off (but currently it does). {$W-} {$classic-pascal} program range2(Output); var v : 1..2; begin {$local R-} v := 0; {$endlocal} writeln('OK') end. I suggest this behaviour for --mac-pascal (also). Regards, Adriaan van Os

2 2

ICE on unimplemented operators
by Adriaan van Os 14 Feb '06

14 Feb '06

The following testprogram causes an ICE in the compiler. [G5:~/gpc/testgpc/adriaan] adriaan% cat ice4.pas program ice4; type Str9 = record sLength: Byte; sChars: packed array[ 1.. 9] of char end; Str255 = record sLength: Byte; sChars: packed array[ 1..255] of char end; operator + ( const s1: Str9; const s2: Str255 ) = theResult : Str255; operator + ( const s1: Str9; const s2: Str255 ) = theResult : Str9; procedure P; var s1: Str9; s2: Str255; begin s1:= s1 + s2 end; begin end. [G5:~/gpc/testgpc/adriaan] adriaan% gpc ice4.pas ice4.pas: In operator `+ (Str9, Str255)': ice4.pas:19: error: syntax error before `.' ice4.pas:8: confused by earlier errors, bailing out Date/Time: 2006-02-14 17:52:23 +0100 OS Version: 10.3.9 (Build 7W98) Report Version: 2 Command: gpc1 Path: /Developer/Pascal/gpc345u2/libexec/gcc/powerpc-apple-darwin7/3.4.5/gpc1 Version: ??? (???) PID: 3239 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000010 Thread 0 Crashed: 0 gpc1 0x000a7724 all_blocks + 0x2c 1 gpc1 0x000a7758 all_blocks + 0x60 2 gpc1 0x000a7758 all_blocks + 0x60 3 gpc1 0x000a7758 all_blocks + 0x60 4 gpc1 0x000a77a8 get_block_vector + 0x20 5 gpc1 0x000a7818 identify_blocks + 0x3c 6 gpc1 0x000c05f0 rest_of_compilation + 0x2d0 7 gpc1 0x000ae950 output_inline_function + 0xa8 8 gpc1 0x00012680 poplevel + 0xd0 9 gpc1 0x001357f4 lhd_clear_binding_stack + 0x2c 10 gpc1 0x000c30d0 toplev_main + 0x84c 11 gpc1 0x00002468 _start + 0x188 12 dyld 0x8fe1a278 _dyld_start + 0x64 PPC Thread State: srr0: 0x000a7724 srr1: 0x0000f930 vrsave: 0x00000000 cr: 0x42002224 xer: 0x00000000 lr: 0x000a7758 ctr: 0x0013561c r0: 0x000a7758 r1: 0xbfffedc0 r2: 0x00000000 r3: 0x00000008 r4: 0x00000000 r5: 0x00000000 r6: 0x404e7530 r7: 0x00000001 r8: 0x0000001e r9: 0x405ec300 r10: 0x405ed000 r11: 0x00000001 r12: 0x42002224 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0x404e72d4 r23: 0x404e7618 r24: 0x0045f0ec r25: 0x0048e8b0 r26: 0x0046714c r27: 0x00000000 r28: 0x00000000 r29: 0x00000000 r30: 0x00000008 r31: 0x000a77e4 Binary Images Description: 0x1000 - 0x457fff gpc1 /Developer/Pascal/gpc345u2/libexec/gcc/powerpc-apple-darwin7/3.4.5/ gpc1 0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld 0x93a50000 - 0x93a54fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x95f30000 - 0x9601efff libiconv.2.dylib /usr/lib/libiconv.2.dylib 0x98d8e000 - 0x98eddfff libSystem.B.dylib /usr/lib/libSystem.B.dylib [G5:~/gpc/testgpc/adriaan] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc345u2/lib/gcc/powerpc-apple-darwin7/3.4.5/specs Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 --build=powerpc-apple-darwin7 --prefix=/Developer/Pascal/gpc345u2 Thread model: posix gpc version 20051116, based on gcc-3.4.5 Regards, Adriaan van Os

3 2

ICE on bad forward declaration
by Adriaan van Os 14 Feb '06

14 Feb '06

The following testprogram causes an ICE in the compiler. [G5:~/gpc/testgpc/adriaan] adriaan% cat ice3.pas program ice3; type Str44 = record sLength: Byte; sChars: packed array[ 1..44] of char end; procedure P (s: str44); forward; procedure P (const s: str44); begin end; begin end. [G5:~/gpc/testgpc/adriaan] adriaan% gpc ice3.pas ice3.pas:9: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. [G5:~/gpc/testgpc/adriaan] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc345u2/lib/gcc/powerpc-apple-darwin7/3.4.5/specs Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 --build=powerpc-apple-darwin7 --prefix=/Developer/Pascal/gpc345u2 Thread model: posix gpc version 20051116, based on gcc-3.4.5 Date/Time: 2006-02-14 15:06:50 +0100 OS Version: 10.3.9 (Build 7W98) Report Version: 2 Command: gpc1 Path: /Developer/Pascal/gpc345u2/libexec/gcc/powerpc-apple-darwin7/3.4.5/gpc1 Version: ??? (???) PID: 21604 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000008 Thread 0 Crashed: 0 gpc1 0x00017198 check_routine_decl + 0x1f8 1 gpc1 0x0001ac5c start_routine + 0x644 2 gpc1 0x0000ad84 yyuserAction + 0x7714 3 gpc1 0x00011560 main_yyparse + 0x888 4 gpc1 0x000c30c4 toplev_main + 0x840 5 gpc1 0x00002468 _start + 0x188 6 dyld 0x8fe1a278 _dyld_start + 0x64 PPC Thread State: srr0: 0x00017198 srr1: 0x0200f930 vrsave: 0x00000000 cr: 0x44022222 xer: 0x20000000 lr: 0x00017060 ctr: 0x000c3ccc r0: 0x0000000f r1: 0xbfffe7f0 r2: 0x14080000 r3: 0x405eb680 r4: 0x405eb180 r5: 0x00000000 r6: 0x00000000 r7: 0x00000000 r8: 0x00000000 r9: 0x405eb580 r10: 0x00000000 r11: 0x00000000 r12: 0x24024242 r13: 0x00000000 r14: 0x00000000 r15: 0x00000000 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000000 r21: 0x00000000 r22: 0x00000000 r23: 0x00000000 r24: 0x405e8840 r25: 0x405e8828 r26: 0x405ea1c0 r27: 0x00000000 r28: 0x405eb700 r29: 0x405eb380 r30: 0x405eb480 r31: 0x00016fb8 Binary Images Description: 0x1000 - 0x457fff gpc1 /Developer/Pascal/gpc345u2/libexec/gcc/powerpc-apple-darwin7/3.4.5/ gpc1 0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld 0x93a50000 - 0x93a54fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x95f30000 - 0x9601efff libiconv.2.dylib /usr/lib/libiconv.2.dylib 0x98d8e000 - 0x98eddfff libSystem.B.dylib /usr/lib/libSystem.B.dylib The same happens with the implicit forward declaration in a unit's interface. Regards, Adriaan van Os

3 2

Typo in manual
by Adriaan van Os 13 Feb '06

13 Feb '06

The GPC manual for PtrInt reads > PtrInt > (Under construction.) > Synopsis > type > PtrCard = Integer attribute (Size = BitSizeOf (Pointer)); > Description > A signed integer type of the same size as a pointer. > Conforming to > ‘PtrInt’ is a GNU Pascal extension. This should obviously be PtrInt = Integer attribute (Size = BitSizeOf (Pointer)); By the way, I didn't manage to build the html version of the manual, because the entry for 'Index' creates an index.html file, which conflicts with the usual index.html file. Regards, Adriaan van Os

3 6

traceback
by willett 12 Feb '06

12 Feb '06

I'm using gpc version 20051116, based on gcc-3.4.5. Impressive update! It is very nice to have the runtime error detection. But of course it means some new errors have to be dealt with, one way or another. An old program of mine is now getting... out of range (error #300 at 2c57) Trace/BPT trap Trying to get a less cryptic error report, maybe one with the procedure stack at point of error, I compile as: gp -mtraceback=full progname But this does not add anything to the information in the out of range error. Also, it would be nice to have a list of error messages, so that error #300 could be looked up. Any thought on how to access more information for runtime errors? (like a simple traceback of procedure calls).. Thanks, Willett Kempton

5 12

Re: Getting an error while compiling GPC-20051116 on HP-UX11i v2
by prasad svr 11 Feb '06

11 Feb '06

Hi, After igave `-mlp64' flag iam getting an error like this make[2]: Entering directory `/gcc/gpcbuild/gcc/p/rts' /gcc/gpcbuild/gcc/xgcc -B/gcc/gpcbuild/gcc/ -B/usr/local/ia64-hp-hpux11.23/bin/ -B/usr/local/ia64-hp-hpux11.23/lib/ -isystem /usr/local/ia64-hp-hpux11.23/includ e -isystem /usr/local/ia64-hp-hpux11.23/sys-include -c -I. -W -Wall -Wmissing-p rototypes -Wmissing-declarations -mlp64 -Wpointer-arith -Wwrite-strings "/gcc/ gcc-3.4.3/gcc/p/rts/rts.c" /gcc/gcc-3.4.3/gcc/p/rts/rts.c: In function `_p_CStringStrSignal': /gcc/gcc-3.4.3/gcc/p/rts/rts.c:2446: warning: empty body in an if-statement ../.././xgpc -B../.././ -c -g -I. -W -Wall -Wmissing-prototypes -Wmissing-decla rations -mlp64 --unit-path=/gcc/gcc-3.4.3/gcc/p/rts --automake `cat needed-opt ions` -DRTS_RELEASE_STRING="'`cat /gcc/gcc-3.4.3/gcc/p/rts/rts-version`'" -DGCC_ VERSION="'3.4.3'" "/gcc/gcc-3.4.3/gcc/p/rts/rtsc.pas" ../.././xgpc -B../.././ -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarat ions -mlp64 --unit-path=/gcc/gcc-3.4.3/gcc/p/rts --automake `cat needed-option s` -DRTS_RELEASE_STRING="'`cat /gcc/gcc-3.4.3/gcc/p/rts/rts-version`'" -DGCC_VER SION="'3.4.3'" "/gcc/gcc-3.4.3/gcc/p/rts/string1.pas" ../.././xgpc -B../.././ -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarat ions -mlp64 --unit-path=/gcc/gcc-3.4.3/gcc/p/rts --automake `cat needed-option s` -DRTS_RELEASE_STRING="'`cat /gcc/gcc-3.4.3/gcc/p/rts/rts-version`'" -DGCC_VER SION="'3.4.3'" --interface-only "/gcc/gcc-3.4.3/gcc/p/rts/error.pas" /gcc/gcc-3.4.3/gcc/p/rts/error.pas:267: error: module/unit interface `Heap' coul d not be imported make[2]: *** [stamp-error-gpi] Error 1 make[2]: Leaving directory `/gcc/gpcbuild/gcc/p/rts' make[1]: *** [pascal.rts] Error 2 make[1]: Leaving directory `/gcc/gpcbuild/gcc' make: *** [all-gcc] Error 2 # can any one help on this. Regards Prasad > ----- Original Message ----- > From: "Waldek Hebisch" <hebisch(a)math.uni.wroc.pl> > To: gpc(a)gnu.de > Subject: Re: Getting an error while compiling GPC-20051116 on HP-UX11i v2 > Date: Wed, 8 Feb 2006 01:57:55 +0100 (CET) > > > Russell Whitaker wrote: > > On Tue, 7 Feb 2006, Waldek Hebisch wrote: > > > > > prasad svr wrote: > <snip> > > >> /gcc/gpcbuild/gcc/xgcc -B/gcc/gpcbuild/gcc/ > > -B/usr/local/ia64-hp-hpux11.23/bin/ > > >> -B/usr/local/ia64-hp-hpux11.23/lib/ -isystem > > /usr/local/ia64-hp-hpux11.23/includ > > >> e -isystem /usr/local/ia64-hp-hpux11.23/sys-include -c -I. -W > > -Wall -Wmissing-p > > >> rototypes -Wmissing-declarations -g -O2 -Wpointer-arith > > -Wwrite-strings "/gcc/ > > >> gcc-3.4.3/gcc/p/rts/rts.c" > > >> /gcc/gcc-3.4.3/gcc/p/rts/rts.c:663:1: warning: "open" redefined > > >> In file included from /usr/include/fcntl.h:9, > > >> from /gcc/gcc-3.4.3/gcc/p/rts/rts.c:89: > > >> /usr/include/sys/fcntl.h:259:1: warning: this is the location > > of the previous de > > >> finition > > >> /gcc/gcc-3.4.3/gcc/p/rts/rts.c: In function `_p_CStringStrSignal': > > >> /gcc/gcc-3.4.3/gcc/p/rts/rts.c:2446: warning: empty body in an > > if-statement > > >> /gcc/gcc-3.4.3/gcc/p/rts/rts.c: In function `_p_SqRt': > > >> /gcc/gcc-3.4.3/gcc/p/rts/rts.c:831: internal compiler error: > > in emit_move_insn, > > >> at expr.c:2812 > > >> Please submit a full bug report, > > >> with preprocessed source if appropriate. > > >> See <URL:http://gcc.gnu.org/bugs.html> for instructions. > > >> make[2]: *** [rts.o] Error 1 > > >> make[2]: Leaving directory `/gcc/gpcbuild/gcc/p/rts' > > >> make[1]: *** [pascal.rts] Error 2 > > >> make[1]: Leaving directory `/gcc/gpcbuild/gcc' > > >> make: *** [all-gcc] Error 2 > > >> # > > >> > > >> > > >> can any one help on this. > > >> > > > > <snip> > > > It looks that the problem is fixed in gcc-4.0, but ATM gpc do not work > > > with this version of gcc. > > > > tried it with gcc-3.4.5 -c and got a .o result > > > > linux i686 > > > > The problem affects ia64 (Itanium) running HPUX. In fact, it seems that > only 32-bit mode is affected. Unfortunatly, 32-bit mode is a default on > HPUX. > > To Prasad: it seems that you have succesfully built the compiler proper. > The problem is with building the 32-bit runtime. You may try building > 64-bit runtime. > > Some hints how to do this are in a message by Peter Keenan: > > http://www.gnu-pascal.de/crystal/gpc/en/mail11264.html > > (however, to get 64-bit mode use `-mlp64' flag). > > -- > Waldek Hebisch > hebisch(a)math.uni.wroc.pl > -- _______________________________________________ Search for businesses by name, location, or phone number. -Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as…

2 1

Fw: checking out gpc source
by Bart van den Broek 11 Feb '06

11 Feb '06

Hello, I would like to look into the gpc source code, first step is to compile the gpc+gcc. Can you please tell me what is a recent fairly stable snapshot / release? I ask this because on the website, the " source code of the current GNU Pascal release " points to the alpha snapshots, that has 20050331, but the binary/cygwin has "gpc-20051116, based on gcc-3.4.4". I am using Cygwin. Kind regards, Bart van den Broek.

2 1

Imported XCode/GPC
by Joseph Ayers 10 Feb '06

10 Feb '06

I find using GPC in XCode to present a conundrum. When I create a New Project and select a Carbon Pascal application or use one of the sample examples, They both work. If I Import a previous CodeWarrior project into XCode, I find no way to tell it that it is a Pascal Project. Inspection of the make file generated by the NewProject command indicates that it does that, but a search of the XCode User Manual for the words "Make File" returns nothing. More amazing, when I select "Edit active target" from the "Project" menu I get a different window for a project created with New Project as opposed to Import. How do I tell XCode to execute a make file for an imported project? Is there anyway to copy stuff from a pascal project created with NewProject to an Imported Codewarrior Pascal project. Thanks, -- Joseph Ayers, Department of Biology and Marine Science Center Northeastern University East Point, Nahant, MA 01908 Phone (781) 581-7370 x309(office), x335(lab) Cellular (617) 755-7523, FAX: (781) 581-6076 eMail: lobster(a)neu.edu AIM: roboplasm http://www.neurotechnology.neu.edu/ http://inls.ucsd.edu/neurobots.html

2 1

Re: Getting an error while compiling GPC-20051116 on HP-UX11i v2
by prasad svr 08 Feb '06

08 Feb '06

Hi, I am trying to install gpc-20051116 on HP-UX11i v2(Itanium) with gcc-3.4.3.Intially igot "make[2]: *** [needed-options] Error 1", itried with "touch /gcc/gpcbuild/gcc/p/rts/needed-options".After that iam geeting an error like make[2]: Leaving directory `/gcc/gpcbuild/gcc' cd ./p/rts && make CC="`echo /gcc/gpcbuild/gcc/xgcc -B/gcc/gpcbuild/gcc/ -B/usr/ local/ia64-hp-hpux11.23/bin/ -B/usr/local/ia64-hp-hpux11.23/lib/ -isystem /usr/l ocal/ia64-hp-hpux11.23/include -isystem /usr/local/ia64-hp-hpux11.23/sys-include ' ' | sed -e 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[^/][^:]*/$,../../\1,'` " PC="`echo ./xgpc -B./' ' | sed -e 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[ ^/][^:]*/$,../../\1,'`" GCC_VERSION="3.4.3" SHELL="/bin/sh" CFLAGS="-g -O2" PFL AGS="" AR_FLAGS="rc" RTSFLAGS="" DESTDIR="../.." AR="ar" RANLIB="ranlib" RANLIB_ TEST="" all make[2]: Entering directory `/gcc/gpcbuild/gcc/p/rts' /gcc/gpcbuild/gcc/xgcc -B/gcc/gpcbuild/gcc/ -B/usr/local/ia64-hp-hpux11.23/bin/ -B/usr/local/ia64-hp-hpux11.23/lib/ -isystem /usr/local/ia64-hp-hpux11.23/includ e -isystem /usr/local/ia64-hp-hpux11.23/sys-include -c -I. -W -Wall -Wmissing-p rototypes -Wmissing-declarations -g -O2 -Wpointer-arith -Wwrite-strings "/gcc/ gcc-3.4.3/gcc/p/rts/rts.c" /gcc/gcc-3.4.3/gcc/p/rts/rts.c:663:1: warning: "open" redefined In file included from /usr/include/fcntl.h:9, from /gcc/gcc-3.4.3/gcc/p/rts/rts.c:89: /usr/include/sys/fcntl.h:259:1: warning: this is the location of the previous de finition /gcc/gcc-3.4.3/gcc/p/rts/rts.c: In function `_p_CStringStrSignal': /gcc/gcc-3.4.3/gcc/p/rts/rts.c:2446: warning: empty body in an if-statement /gcc/gcc-3.4.3/gcc/p/rts/rts.c: In function `_p_SqRt': /gcc/gcc-3.4.3/gcc/p/rts/rts.c:831: internal compiler error: in emit_move_insn, at expr.c:2812 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [rts.o] Error 1 make[2]: Leaving directory `/gcc/gpcbuild/gcc/p/rts' make[1]: *** [pascal.rts] Error 2 make[1]: Leaving directory `/gcc/gpcbuild/gcc' make: *** [all-gcc] Error 2 # can any one help on this. Regards Prasad > ----- Original Message ----- > From: "Waldek Hebisch" <hebisch(a)math.uni.wroc.pl> > To: gpc(a)gnu.de > Subject: Re: Getting an error while compiling GPC-20050331 on HP-UX11i v2 (Itanium > Date: Thu, 2 Feb 2006 02:00:49 +0100 (CET) > > > prasad svr wrote: > > > I tried with gpc-20051116 on HP-UX11i v2 (Itanium),i am geeting > > an error like > > > > > > ocal/ia64-hp-hpux11.23/include -isystem > > /usr/local/ia64-hp-hpux11.23/sys-include' ' | sed -e > > 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[^/][^:]*/$,../../\1,'`" > > PC="`echo ./xgpc -B./' ' | sed -e > > 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[^/][^:]*/$,../../\1,'`" > > GCC_VERSION="3.4.3" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" > > AR_FLAGS="rc" RTSFLAGS="" DESTDIR="../.." AR="ar" RANLIB="ranlib" > > RANLIB_TEST="" all > > make[2]: Entering directory `/gcc/gpcbuild/gcc/p/rts' > > echo '{ rts-config.inc. Generated automatically from > > rts-config.h. }' > rts-config.inc > > sed -e 's,/\*,{,g;s,\*/,},g;s,^[ \t]*#$.*$,{$\1},' rts-config.h > > >> rts-config.inc > > ../.././xgpc -B../.././ -I. -W -Wall -Wmissing-prototypes > > -Wmissing-declarations -g -O2 > > --unit-path=/gcc/gcc-3.4.3/gcc/p/rts --automake > > --print-needed-options "/gcc/gcc-3.4.3/gcc/p/rts/endian.pas" 2> > > "needed-options" || true > > if grep '^[^-]' "needed-options" > /dev/null; then echo > > "needed-options: `cat "needed-options"`" >&2; rm -f > > "needed-options"; false; else true; fi > > needed-options: /gcc/gcc-3.4.3/gcc/p/rts/endian.pas:37: error: > > module/unit interface `Error' could not be imported > > make[2]: *** [needed-options] Error 1 > > make[2]: Leaving directory `/gcc/gpcbuild/gcc/p/rts' > > make[1]: *** [pascal.rts] Error 2 > > make[1]: Leaving directory `/gcc/gpcbuild/gcc' > > make: *** [all-gcc] Error 2 > > > > can any one help on this. > > > > Just few remarks: > > 1) "needed-options" for gpc-20051116 is na empty file, so you may try > to do > > touch /gcc/gpcbuild/gcc/p/rts/needed-options > > to create the file and restart the build. > > 2) gpc is trying to compile "endian.pas". However "--print-needed-options" > should disable normal compilation, so something is wrong with command > line processing. > > 3) Similar problem was already reported for HP-UX (ATM with no resolution): > > http://www.gnu-pascal.de/crystal/gpc/en/mail13084.html > > > -- > Waldek Hebisch > hebisch(a)math.uni.wroc.pl > -- _______________________________________________ Search for businesses by name, location, or phone number. -Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as…

3 3

Possible bug in `ReadStr'/`Val'
by Frank Heckenbach 07 Feb '06

07 Feb '06

I noticed an incorrect handling of string parameters in a few RTS routines which might cause incorrect results when reading from strings where the actual parameters are expressions (not simple variables). `ReadStr' and `Val' might be affected, though I haven't been able to reproduce an actual problem. The rarely used `StringTFDD_Reset' is affected, that's where I found the problem. (fjf1099.pas) The attached patch fixes the bugs. For `StringTFDD_Reset', this results in an interface change, though for most uses it should be compatible (string -> conformant array of char), as long as the actual parameter is not an empty string. You'll have to rebuild the RTS and your units. You can do `make pascal.update-release' in the build gcc subdirectory before making GPC, to force GPC to recompile things. (I'm not including a version change in the patch, as the patch might be useable against several releases this way, though I've tested it only against one.) Waldek, you told me you're going to release a new snapshot soon. Please test this patch with your current code and include it if possible. 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: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 6

External directives
by Prof A Olowofoyeku (The African Chief) 04 Feb '06

04 Feb '06

Hi If you have something like this: function foo : integer; external 'bar' name 'foo'; you get a warning that the library name in 'external' is ignored. Is it possible, instead of ignoring the library name, to generate an implicit call to link it? For example, the example above would resolve to an implicit '-lbar' (i.e., it would be the equivalent of '{$l bar}'). Is this feasible, and is there any reason why it would be a bad idea? BTW: this causes a compiler error: const barlib = 'bar'; function foo : integer; external barlib name 'foo'; Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

3 3

crt & ncurses
by Russell Whitaker 04 Feb '06

04 Feb '06

Hi Some time ago I complained about getting grafic characters instead of f thru z, etc., when ncurses updated from 5.3 to 5.4 Since then I discovered if I insert SetPCCharSet( false ) before the first write the problem goes away. The following program illistrates it: program ncur; uses CRT; begin if( GetPCCharSet ) then begin writeln("true"); SetPCCharSet( false ); writeln("true"); end else writeln("false"); end. Russ

3 4

Ada calling Pascal (not working)
by lanceboyle＠qwest.net 03 Feb '06

03 Feb '06

(This post is related to two earlier posts by me, "Linking Ada to Pascal" and 'Where is documentation for "new argument to _p_initialize (@)" PCStrings.') I have not been able to solve the problem when calling _p_initialize from Ada. I still get the Ada compiler telling me, "too many arguments in call." I suspect that I might be passing the wrong _kinds_ of arguments but not the wrong number. Here are the three relevant files: <file adacallspascal.adb> with Ada.Text_IO; use Ada.Text_IO; with Ada.Command_Line; use Ada.Command_Line; with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; procedure adacallspascal is procedure mypascalprocedure; pragma Import(Convention => C, Entity => mypascalprocedure); procedure init_pascal_main_program; pragma Import(Convention => C, Entity => init_pascal_main_program, External_Name => "_p__M0_init"); procedure p_initialize; pragma Import(Convention => C, Entity => p_initialize, External_Name => "_p_initialize"); procedure p_finalize; pragma Import(Convention => C, Entity => p_finalize, External_Name => "_p_finalize"); Argument_Count_Plus_1 : integer := Argument_Count + 1; Command_Name_String : string := Command_Name; C_Command_Name_String : aliased string := Command_Name_String & ASCII.NUL; begin Put_Line ("Hello from adacallspascal."); Put(Argument_Count_Plus_1); New_Line; Put_Line(Command_Name_String); -- Initialize the Pascal RTS. p_initialize (Argument_Count_Plus_1, C_Command_Name_String'access, null, 0); -- Line 29 init_pascal_main_program; mypascalprocedure; p_finalize; Put_Line ("Goodbye from adacallspascal."); end adacallspascal; <file mypascalprogram.pas> program mypascalprogram(input, output); {$gpc-main=dummy} procedure mypascalprocedure; attribute( name = 'mypascalprocedure'); begin writeln('Hello from mypascalprocedure.'); end; begin {When exported to Ada, this part should not be called.} writeln('In mypascalprogram; error if calling from Ada.'); end. <The commands> gpc -c mypascalprogram.pas gnatmake adacallspascal.adb -gnatf -largs mypascalprogram.o / Developer/Pascal/gpc344d2/lib/gcc/powerpc-apple-darwin8/3.4.4/libgpc.a <Output from attempting to compile> gcc -c -gnatf adacallspascal.adb adacallspascal.adb:29:05: too many arguments in call gnatmake: "adacallspascal.adb" compilation error Jerry

4 4

Incompatible types error detection bug
by Gale Paeper 02 Feb '06

02 Feb '06

GPC fails to detect incompatible type errors between two or more new-pointer-type defined types where the same domain-type is used in new-type type-denoters. An example demonstrating the bug: {$extended-pascal} program grp12(output); type t1 = ^integer; t2 = ^integer; var x: t2; procedure foo(p: t1); begin end; begin foo(x); {WRONG - incompatible types} writeln('FAIL'); end. Although both t1 and t2's new-pointer-type type-denoter have the same domain-type, t1 and t2 are distinctly different types. Therefore, t1 and t2 aren't assignment-compatible types (per ISO 10206 paragraph 6.4.6) and the foo(x) call is illegal since the actual-parameter type (t2) isn't assignment-compatible with the formal-paramter type (t1) as required by ISO 10206 paragraph 6.7.3.2. The compiler I used was the latest version of Mac OS X GPC that Adriaan built and made available for downloading. The specs: Reading specs from /Developer/Pascal/gpc345u2/lib/gcc/powerpc-apple-darwin8/3.4.5/specs Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2 Thread model: posix gpc version 20051116, based on gcc-3.4.5 P.S. This bug was originally found by Mike Hore and discussed on the MacPascal mailing list. The above example is a distilled version of the problem he found while working with Mac OS X GPC and the Mac OS X GPCPInterfaces. Gale Paeper gpaeper(a)empirenet.com

3 2

Re: Getting an error while compiling GPC-20050331 on HP-UX11i v2
by prasad svr 02 Feb '06

02 Feb '06

Hi, I tried with gpc-20051116 on HP-UX11i v2 (Itanium),i am geeting an error like ocal/ia64-hp-hpux11.23/include -isystem /usr/local/ia64-hp-hpux11.23/sys-include' ' | sed -e 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[^/][^:]*/$,../../\1,'`" PC="`echo ./xgpc -B./' ' | sed -e 's,$-[BI]$$[^/][^:]$,\1../../\2,g;s,^$[^/][^:]*/$,../../\1,'`" GCC_VERSION="3.4.3" SHELL="/bin/sh" CFLAGS="-g -O2" PFLAGS="" AR_FLAGS="rc" RTSFLAGS="" DESTDIR="../.." AR="ar" RANLIB="ranlib" RANLIB_TEST="" all make[2]: Entering directory `/gcc/gpcbuild/gcc/p/rts' echo '{ rts-config.inc. Generated automatically from rts-config.h. }' > rts-config.inc sed -e 's,/\*,{,g;s,\*/,},g;s,^[ \t]*#$.*$,{$\1},' rts-config.h >> rts-config.inc ../.././xgpc -B../.././ -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/gcc/gcc-3.4.3/gcc/p/rts --automake --print-needed-options "/gcc/gcc-3.4.3/gcc/p/rts/endian.pas" 2> "needed-options" || true if grep '^[^-]' "needed-options" > /dev/null; then echo "needed-options: `cat "needed-options"`" >&2; rm -f "needed-options"; false; else true; fi needed-options: /gcc/gcc-3.4.3/gcc/p/rts/endian.pas:37: error: module/unit interface `Error' could not be imported make[2]: *** [needed-options] Error 1 make[2]: Leaving directory `/gcc/gpcbuild/gcc/p/rts' make[1]: *** [pascal.rts] Error 2 make[1]: Leaving directory `/gcc/gpcbuild/gcc' make: *** [all-gcc] Error 2 can any one help on this. Regards Prasad > ----- Original Message ----- > From: "Waldek Hebisch" <hebisch(a)math.uni.wroc.pl> > To: gpc(a)gnu.de > Subject: Re: Getting an error while compiling GPC-20050331 on HP-UX11i v2 (Itanium > Date: Fri, 27 Jan 2006 15:53:27 +0100 (CET) > > > prasad svr wrote: > > I am trying to compile GPC-20050331 on HP-UX11i v2 (Itanium 64 > > bit) Using gcc-3.4.3.While compiling Iam getting an error like > > bellow. > > > > > > gcc ?c -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC -W -Wall > > -Wwrite-string -Wstrict-prototypes -Wmissing -Prototypes > > -pedantic -Wno-long-long -DHAVE_CONFIG_H > > -DGENERATOT_FILE -I. ?I. > > > > -I/gcc/gcc-3.4.3/gcc -I/gcc/gcc-3.4.3/gcc/. > > ?I/gcc/gcc-3.4.3/gcc/../include -I ../intl > > /gcc/gcc-3.4.3/gcc/gcov-iov.c -o gcov-iov.o > > > > In file included from /gcc/gcc-3.4.3/gcc/gcov-iov.c: 27: > > > > /gcc/gcc-3.4.3/gcc/version.c: 8 error: Conflicting type for `version string' > > /gcc/gcc-3.4.3/gcc/version.h: 3 error: previous declaration of > > `version string' was here > > /gcc/gcc-3.4.3/gcc/version.c: 8 error: conflicting types for `version string' > > /gcc/gcc-3.4.3/gcc/version.h: 3 error: previous declaration of > > `version string' was here > > > > First suspect is incorrectly patched backend: gpc contains a patch which > modifies both `version.c' and `version.h'. If only one of them is patched > you will get errors as above. > > gpc-20050331 is likely to have problems on IA-64, but the above is _not_ > one of expected problems. To avoid other problems I would suggerst > to use gpc-20051116 version from: > > http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-20051116.tar.bz2 > > or search the mailing list archives for patches. > > -- > Waldek Hebisch > hebisch(a)math.uni.wroc.pl > -- _______________________________________________ Search for businesses by name, location, or phone number. -Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as…

2 1

Buffer Overrun Prevention in GPC
by Mirsad Todorovac 30 Jan '06

30 Jan '06

Hi, all! I have recently studied several forms of viruses and security holes in software. Many if not 90% of recent exploits depend on holes introduced through buffer overruns, such as this C example: printbuffer() { char buffer[100]; gets (buffer); /* oops!*/ fp = fopen("LPT1:", "w"); fputs (buffer, fp); } Is Pascal and namely GNU Pascal safer re: buffer overruns? How much does runtime range checking help and to what extent can we depend on it? Is it acceptable to write setuid root programs in GPC and what are the cautions? Thanks for answers. Mirsad "Tvrdim da bi se napetost izmedju znanosti i vjere trebala rijesiti njihovom sintezom, a ne odbacivanjem ili podvojenoscu." Pierre Teilhard de Chardin (1881-1955)

3 18

Internal compiler error with readstring
by Peter Schorn 28 Jan '06

28 Jan '06

The following program crashes the compiler (gpc345u2 on Mac OS 10.4.4): program rs; { compile with gpc rs.pas } var a: integer; begin readstring(a); { internal compiler error: Bus error } end. Best regards, Peter

5 8

Getting an error while compiling GPC-20050331 on HP-UX11i v2 (Itanium 64 bit) using gcc-3.4.3.
by prasad svr 27 Jan '06

27 Jan '06

Hi, I am trying to compile GPC-20050331 on HP-UX11i v2 (Itanium 64 bit) Using gcc-3.4.3.While compiling Iam getting an error like bellow. gcc c -DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC -W -Wall -Wwrite-string -Wstrict-prototypes -Wmissing -Prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H -DGENERATOT_FILE -I. I. -I/gcc/gcc-3.4.3/gcc -I/gcc/gcc-3.4.3/gcc/. I/gcc/gcc-3.4.3/gcc/../include -I ../intl /gcc/gcc-3.4.3/gcc/gcov-iov.c -o gcov-iov.o In file included from /gcc/gcc-3.4.3/gcc/gcov-iov.c: 27: /gcc/gcc-3.4.3/gcc/version.c: 8 error: Conflicting type for `version string' /gcc/gcc-3.4.3/gcc/version.h: 3 error: previous declaration of `version string' was here /gcc/gcc-3.4.3/gcc/version.c: 8 error: conflicting types for `version string' /gcc/gcc-3.4.3/gcc/version.h: 3 error: previous declaration of `version string' was here make[1]: *** [gcov-iov.o] Error 1 make[1]: Leaving directory `/gcc/gpcbuild/gcc' make: *** [all-gcc] Error 2 any one can help on this problem. Regards Prasad -- _______________________________________________ Search for businesses by name, location, or phone number. -Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as…

3 2

MinGW -mwindows -mconsole
by Adriaan van Os 25 Jan '06

25 Jan '06

Has somebody worked with gpc on MinGW passing both -mwindows and -mconsole to create both a console box and GUI stuff ? Is a different thread needed for the GUI ? Regards, Adriaan van Os

3 5

Question about -Widentifier-case
by Peter Schorn 24 Jan '06

24 Jan '06

I have a question on the meaning of the identifier-case warning in gpc (gpc345u2 on Mac OS 10.4.4). Compiling the program below I get three warnings but I'd expect none since in all three cases the two referenced variables are different. Is my expectation wrong? Best regards, Peter { 1} program cap; { 2} { compile with gpc -o cap -Widentifier-case cap.pas } { 3} { 4} procedure p(A: integer); { 5} { 6} procedure q(a: integer); { cap.pas:6: warning: capitalisation of identifier `a' doesn't match } { 8} { cap.pas:4: warning: previous capitalisation `A' } { 9} begin {10} a := 1; {11} end; {12} {13} begin { p } {14} A := 0; { cap.pas:14: warning: capitalisation of identifier `A' doesn't match } {16} { cap.pas:6: warning: previous capitalisation `a' } {17} end; {18} {19} procedure r(a: integer); { cap.pas:19: warning: capitalisation of identifier `a' doesn't match } {21} { cap.pas:14: warning: previous capitalisation `A' } {22} begin {23} a := 1; {24} end; {25} {26} begin {27} end.

3 2

Creating Universal static library called from XCode 2.2.1 Carbon Application
by Glenn Howes 23 Jan '06

23 Jan '06

I have a legacy static library written in Pascal which I need to call from a C++ application targeting both PowerPC and x86 processors on the Mac OS X platform ( a so-called universal binary). After compiling and linking everything together, I'm having trouble calling the Pascal runtime libraries: i.e. I crash. Software used: glenn% gpc -v Reading specs from /Developer/Pascal/gpc345u2/lib/gcc/powerpc-apple- darwin8/3.4.5/specs Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c -- enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc- apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/ Pascal/gpc345u2 Thread model: posix gpc version 20051116, based on gcc-3.4.5 gpc-i386 -vReading specs from /Developer/Pascal/gpc345u2/lib/gcc/i386- apple-darwin8/3.4.5/specs Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c -- enable-threads=posix --target=i386-apple-darwin8 --host=powerpc-apple- darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/ gpc345u2 --with-sysroot=/Developer/SDKs/MacOSX10.4u.sdk/ --with- arch=pentium-m --with-tune=prescott Thread model: posix gpc version 20051116, based on gcc-3.4.5 Mac OS X 10.4.4 XCode 2.2.1 Source: 34 files of legacy Pascal which I've gone through and fixed all of the compiler errorss and most of the warnings. Steps I've taken. 1) Compiled and packaged using gpc, libtool, and lipo: gpc -c --automake -Wl,-framework,Carbon -funit-path=/Developer/Pascal/ GPCPInterfaces/ MySrc.p libtool -static *.o -o MyLibPPC.a rm *.gpi rm *.o gpc-i386 -c --automake -Wl,-framework,Carbon -funit-path=/Developer/ Pascal/GPCPInterfaces/ MySrc.p libtool -static *.o -o MyLibx86.a lipo *.a -create -output MyLib.a 2) Made a universal version of the gpc.a library lipo /Developer/Pascal/gpc345u2/lib/gcc/i386-apple-darwin8/3.4.5/ libgpc.a /Developer/Pascal/gpc345u2/lib/gcc/powerpc-apple- darwin8/3.4.5/libgpc.a -create -output gpc.a 3) Added both libraries to my XCode 2.2.1 C++ application 4) Compile and Links without running, crashes as soon as it tries to call WriteLn, if I remove the WriteLn, it crashes later in a call to the file routine Assign, which might be the first runtime library call. I declare the entry in C++ as: extern "C" short MyEntry(const char *path); In Pascal, I declare it as const MaxPointerChars = 20000; Type PAPointerChar=^APointerChar; APointerChar = Packed Array [0..MaxPointerChars] of Char; Int16 = Integer attribute ( size = 16); ... function MyEntry(DllPathC:PAPointerChar):Int16; attribute (name = 'MyEntry'); ... function MyEntry(aCString:PAPointerChar):Int16; var DLLPath:String2048; pathLength:Int32; i:Int32; begin pathLength := StrLen(aCString); if pathLength > 2048 then pathLength := 2048; DLLPath := ''; for i := 1 to pathLength do begin DLLPath := DLLPath + aCString^[i-1]; end; WriteLn(DLLPath); { crashes here} ... gdb gives me the following console output: Running… Program received signal: "EXC_BAD_ACCESS". Unable to disassemble _p_Write_Init. 5) I've written a little test application in Pascal to debug the libraries code (when it is not packaged as a library but compiled directly into the application) and the code works perfectly well in that environment. The debugging was done with XCode 2.1 as I believe there is a problem with gpc and XCode 2.2. So how do I fix this?

2 4

GPC 20051116 on Sparc Solaris
by Pascal Viandier 22 Jan '06

22 Jan '06

I ran the test suite against gpc 20051116 on SUN Sparc Solaris with the following results: Test Run By pascal on 2006-01-16 13:41:36 Native configuration is sparc-sun-solaris2.6 (perfdev) === gpc tests === Running target any Running testsuite ... UNSUPPORTED: agettext2test.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas UNSUPPORTED: crttest.pas UNSUPPORTED: fjf165a.pas FAIL: fjf980a.pas FAIL: fjf980b.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: longr2.pas === gpc Summary === # of tests 4969 # of expected passes 4960 # of unexpected failures 2 # of unsupported tests 7 gpc version 20051116, based on gcc-3.4.4 In the two failing tests there is a "packed array [1 .. 1] of Boolean". If I run the tests by hand I get bus error. If I remove the "packed" in the array declaration, both tests work as expected. Is this a Sparc Solaris - specific bug? Regards Pascal Viandier pascal(a)accovia.com

2 1

Program parameters with ISO 7185
by Brian Wichmann 20 Jan '06

20 Jan '06

I was a co-author of an algorithm written in Pascal (ISO 7185) which read: PROGRAM stvpas(datafile, output); {This program counts the votes in a Single Transferable Vote election, using Meek's method, and reports the results} ... The datafile was reread on every iteration of the algorithm. Am I correct in stating that that the program cannot be run with gpc without making a change to the program to assign datafile to an external file? Brian.

3 5

Changing access:
by CBFalconer 20 Jan '06

20 Jan '06

Darned if I know how to set this up. Please change my access so that mail is delivered to: cbfalconer(a)maineline.net and accepted from there and worldnet.att.net, att.net, or yahoo.com (all user cbfalconer). I would still like a reply-to gpc... to appear in the list messages sent to me. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: <http://cfaj.freeshell.org/google/>

1 0

Re: Dynamic arrays dimensions
by Silvio a Beccara 19 Jan '06

19 Jan '06

> This version doesn't do any range checking. This means the code may > have worked incorrectly, unnoticed. Too bad... anyway now I'm using the latest one. > Are you using a 64 bit platform? This array would have a size of > 6.4 GB which is not possible on 32 bit. From your question I understand that the maximum limit coincides with the physical memory (which is limited to 4 GB on a 32-bit machine). I'm using a 32 bit machine, so I adjusted the dimensioning of that array (and the size of the calculation) to fit my memory. Thanks Silvio a Beccara -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Trova la tua anima gemella con Meetic. Iscriviti subito gratis: potrai trovare migliaia di single in linea e chattare con loro! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid@48&d-1

3 2

Re: GPC on i686-apple-darwin
by Waldek Hebisch 19 Jan '06

19 Jan '06

Adriaan van Os wrote: > You were quite right about -fPIC. All the failures, except emil9.pas > disappear with -fno-pic. However, many of the other tests fail with > -fno-pic, because the option disables dynamic linking on Mac OS X. The > PPC back-end has a workaround (-mdynamic-no-pic) but that doesn't seem > to work for i686-apple-darwin. > I have just realized that Darwin PIC problem have nothing to do with Linux PIC problems: Darwin does not use the binutils feature (ELF GOT relocations) that Linux uses. > Updating the linker and assembler to odcctools-20050327 had no effect > on testsuite results. > > So, I must either > - find a backport of i686-apple-darwin PIC fixes > - find a solution for gcc-3.4 bootstrap problems > - wait for gcc-4.0 support. > > Still, I am glad with the results so far. > Well, I was able build 3.3.6 based cross-compiler for i686-apple-darwin target, and I can see duplicate labels in the assembler output. It seems that 3.4.3 has changed the parts responsible for generating those labels. I have found that 3.4.[34] contain blatant bug with easy fix: --- gcc-3.4.4/gcc/config/i386/darwin.h.orig Thu Jun 16 01:10:29 2005 +++ gcc-3.4.4/gcc/config/i386/darwin.h Thu Jun 16 01:10:32 2005 @@ -43,7 +43,7 @@ /* Use the following macro for any Darwin/x86-specific command-line option translation. */ -#define SUBTARGET_OPTION_TRANSLATE_TABLE +#define SUBTARGET_OPTION_TRANSLATE_TABLE { 0, 0 } #define ASM_SPEC "-arch i386 \ %{Zforce_cpusubtype_ALL:-force_cpusubtype_ALL} \ After that I can build the compiler proper. However I get ICE when building gcc runtime. Trying gpc on knuth3.pas (to get assembler output) give me ICE. Both ICE-s seem related to generting labels needed in PIC code... So, it seems that nobody tried gcc-3.4.x for i686-darwin for almost a year (ChangeLog entry for SUBTARGET_OPTION_TRANSLATE_TABLE change is from 2004-08-23) -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 9

Pascal calling Ada (works)
by lanceboyle＠qwest.net 19 Jan '06

19 Jan '06

(This post is related to two earlier posts by me, "Linking Ada to Pascal" and 'Where is documentation for "new argument to _p_initialize (@)" PCStrings.') I've had some success here. The following two files (Pascal main program) and compile commands work. <file pascalcallsada.pas> program pascalcallsada (input, output); procedure youradapackagesubroutine; external name 'myadapackagesubroutine'; procedure adainit; external name 'adainit'; procedure adafinal; external name 'adafinal'; begin adainit; writeln('Hello from pascalcallsada.'); youradapackagesubroutine; writeln('Goodbye from Pascal main program.'); adafinal; end. <file myadapackage.ads> package myadapackage is procedure myadapackagesubroutine; pragma Export(Convention => C, Entity => myadapackagesubroutine, External_Name => "myadapackagesubroutine"); end myadapackage; <file myadapackage.adb> with Ada.Text_IO; use Ada.Text_IO; package body myadapackage is procedure myadapackagesubroutine is begin Put_Line("Hello from myadapackagesubroutine."); end myadapackagesubroutine; begin Put_Line("Initializing myadapackage."); end myadapackage; <Compile commands> gpc -c pascalcallsada.pas gnatmake -c myadapackage.adb gnatmake -c myadaprogram.adb gnatbind -n myadapackage.ali myadaprogram.ali gnatlink myadaprogram.ali pascalcallsada.o `gpc -print-file- name=libgpc.a` \ -o mypascalprogram <Out from running> Initializing myadapackage. Hello from pascalcallsada. Hello from myadapackagesubroutine. Goodbye from Pascal main program. Jerry

2 3

Crash with sets under Solaris
by Pascal Viandier 16 Jan '06

16 Jan '06

Hi all, I am sorry to be back on this subject after a so long time, but I just hit the problem with a real-life program. I applied the patch you suggested and ran the gpc test suite again. It gives worse results than previously with 97 unexpected failures. If I run some programs under gdb I get Segmentation faults in various places in sets.pas. For example SetCopy (line 286) adam3g adam3h assumptions awindte2 awindtes dostest SetEqual (line 215) adam3k adam3l adam3m adam3n WordNumber (line 113) adam3q adam3r ancestor2 Test fail with no core dump az44 chief41 couper10 couper8 gpc gives: warning: `absolute' declaration increases required alignment and test fail chris4 chris5 Is there a patch to solve this problem? If you need more information, I will do my best to give it. Regards Pascal Viandier pascal(a)accovia.com -----Message d'origine----- De : gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] De la part de Waldek Hebisch Envoyé : May 25, 2005 16:33 À : gpc(a)gnu.de Objet : Re: RE : bigsetdemo strange result Pascal Viandier wrote: > Hi, > > At your suggestion, I ran the gpc test suite. > Here is the summary result: > > Test Run By pascal on 2005-05-25 10:45:41 > Native configuration is sparc-sun-solaris2.6 (perfdev) > gpc 20050331, based on gcc-3.4.3, flags: -g -O3 -W -Wall -Wno-unused > > Nuber of tests: 4947 > Number of Ok: 4828 > Number of tests skipped: 7 > Number of failures: 56 (includes internal compiler error and some > coredumps) > Number of coredumps: 47 > Number of compiler errors: 2 > > > Should I worry? > Something is really broken. At first glance all failures involve sets, so it may be just a single problem. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 6

Re: Dynamic arrays dimensions
by Maurice Lombardi 16 Jan '06

16 Jan '06

Silvio a Beccara a écrit: > I think you are right, I calculated the size, too and it is actually more than > my physical memory. Is the maximum heap space as big as the physical RAM, or > it is less? It depends on your system, linux mingw djgpp or other. I use DJGPP (dos based). There it can be somewhat higher, by using virtual memory obtained by swapping to disk. But this is at the expense of a considerable slow-down of the programs, so usually I make every effort _not_ to use this "facility". Maurice -- 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 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

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