Hello, folks!
We are approaching a version of GPC that will (a) compile with gcc-2.95.x and (b) only need minimal patches to the GCC backend.
With the next version of the GNU Compiler Collection (GCC), we want to publish the long-expected gpc-2.1 as a fully integrated frontend. We expect this next GCC release (2.9x or 3.0) to happen within the next two months or so.
It is not realistic to fix all bugs and to implement all wanted features listed in the GPC TODO list (http://fjf.gnu.de/gpc-todo_toc.html) within this time schedule. However, most of the bugs listed there are not really relevant to real-world praxis. So we are planning to re-sort the TODO list and to focus on the most important bugs and feature requests.
Please tell us which bugs and/or missing features on the TODO list, section "Urgent", you consider the most urgent.
And of course, your help to fix those bugs is welcome.
Peter
We are approaching a version of GPC that will (a) compile with gcc-2.95.x and (b) only need minimal patches to the GCC backend.
That is great.
Two days ago I started work on a port for the FreeBSD 4.0-current ports collection.
The tricky thing is matching the gcc used in the system, which itself is patched and a moving target.
So far I used the beta which has some problems (got C and Pascal frontends, but no libgpc yet).
Would you suggest to experiment with your more recent stuff?
Regards, Marc
Hallo, Marc!
Two days ago I started work on a port for the FreeBSD 4.0-current ports collection. [...] Would you suggest to experiment with your more recent stuff?
Yes. I am currently finishing up some tests under a bigendian machine (Sun/Solaris) and will announce a new Alpha release Real Soon Now[tm].
Peter
Two days ago I started work on a port for the FreeBSD 4.0-current ports collection.
Ok, I just managed to compile gpc beta by patching it similiar to how the existing gcc 2.8.1 port for FreeBSD does, plus one additional change:
marc@oranje$ gpc -v Reading specs from /usr/ports/lang/gcc28/work/local/lib/gcc-lib/i386-unknown-freebsd4.0/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 marc@oranje$
My first test example worked:
marc@oranje$ gpc -Wall -o u2a1 u2a1.pas marc@oranje$ ./u2a1 Wert für feld[1]? 10 Wert für feld[2]? 20 Wert für feld[3]? 25 Wert für feld[4]? 33 Wert für feld[5]? 0 Das Maximum ist: 33 marc@oranje$
The second however did not:
marc@oranje$ gpc -Wall -o u3a4 u3a4.pas u3a4.pas: In function `Listeeinlesen': u3a4.pas:144: warning: missing string capacity - assuming 255 marc@oranje$ ./u3a4 Bitte geben Sie die zu sortierenden Zahlen ein. Beenden Sie Ihre Eingabe mit einer Leerzeile. 10 4 5 29 0
Segmentation fault (core dumped) marc@oranje$
Nice to see you support familiar gcc options (I have no clue yet about gpc):
marc@oranje$ gpc -Wall -pedantic -o u3a4 u3a4.pas u3a4.pas: In function `Listeeinlesen': u3a4.pas:144: warning: missing string capacity - assuming 255 u3a4.pas:151: warning: ISO Pascal does not allow reading of strings from textfiles u3a4.pas:152: warning: ISO Pascal does not define `Val' u3a4.pas:156: warning: ISO Pascal does not allow reading of strings from textfiles u3a4.pas:157: warning: ISO Pascal does not define `Val' u3a4.pas: At top level: u3a4.pas:180: warning: third argument of `main' is deprecated
Strange Warning, does C shine through somehow?
Testing if gdb works:
marc@oranje$ gpc -g -o u3a4 u3a4.pas u3a4.pas: In function `Listeeinlesen': u3a4.pas:144: warning: missing string capacity - assuming 255 marc@oranje$ gdb u3a4 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... (gdb) l 171 begin 172 writeln (Zeiger^.info); 173 Zeiger := Zeiger^.next; 174 end; { while } 175 end; { GibListeAus } 176 begin 177 ListeEinlesen (RefListe); 178 SortiereListe (RefListe); 179 GibListeAus (RefListe) 180 end. { TesteSortiereListe } (gdb) r Starting program: /home/marc/research/hagen/kip/u3a4 Bitte geben Sie die zu sortierenden Zahlen ein. Beenden Sie Ihre Eingabe mit einer Leerzeile. 2 4 5
Program received signal SIGSEGV, Segmentation fault. 0x80545fd in Strlen (Src=0x416) at gstrings.pas:309 309 while Temp^ <> #0 do Inc (Temp); (gdb) p Temp^ (gdb) p Temp^ Undefined command: "". Try "help". (gdb) p Temp $1 = (Char *) 0x416 (gdb) bt #0 0x80545fd in Strlen (Src=0x416) at gstrings.pas:309 #1 0x8050208 in _p_get_file_name (File=0xbfbfd564) at file.c:1334 #2 0x804f0fa in _p_ok_EOF (File=0xbfbfd564) at file.c:754 #3 0x804a7a8 in _p_direct_getc_checkeof (File=0xbfbfd564) at read.c:80 #4 0x804a84a in _p_readi_check (File=0xbfbfd564, check=NoRangeCheck, min=0, max=0) at read.c:128 #5 0x804b0cf in _p_readi (File=0xbfbfd564) at read.c:237 #6 0x804d1e6 in _p_val_integer_nocheck (string=0xbfbfd9ec "5", maxchars=0, flags=0, var=0xbfbfd9e0) at read.c:697 #7 0x8049437 in Listeeinlesen (Outliste=@0x80647a4) at u3a4.pas:157 #8 0x80494ad in program_Testesortiereliste () at u3a4.pas:177 #9 0x8049518 in main (argc=1, argv=0xbfbfdb30, envp=0xbfbfdb38) at u3a4.pas:180 (gdb) quit The program is running. Exit anyway? (y or n) y marc@oranje$
Not bad. This will give some fun. :)
Yes. I am currently finishing up some tests under a bigendian machine (Sun/Solaris) and will announce a new Alpha release Real Soon Now[tm].
No hurry.
An experimental port (= the BSD package system) is working.
I have just barely enough time in October to research how to make it a nice one, integrating it correctly into the FreeBSD framework. When this issue is solved I go for bug hunting and will gladly help to smoothen things next month.
Regards, Marc
Dear Pascalers
I'm having difficulty characterising a bug in the gpc-19990813 release with egcs-1.1.2. Note that the program runs fine under gpc-19990118.
I have ~300 lines of legacy code which basically reads double values from a file (using fopen(), fread(), I might add), converts them to strings using a complicated set of routines to format the strings, etc and writes them to another file (actually I've taken the writes out now).
On files with more than about 72000 double values my program crashes:
... 72085 72086 72087 72088
Program received signal SIGSEGV, Segmentation fault. Integertostring (I=131083, S=@0xbf800210) at mxtx.p:103 103 VAR Cs:STRING; Negative:BOOLEAN; Fig:INTEGER; (gdb) where #0 Integertostring (I=131083, S=@0xbf800210) at mxtx.p:103 #1 0x804a647 in Makefigstring (R=1310825.1112762, Sf=6, Expval=6, S=@0xbf8007a8) at mxtx.p:158 #2 0x804b070 in Realtostring (R=1310825.1112762, Sf=6, S=@0xbffffbd4) at mxtx.p:194 #3 0x804c2ac in Convert (Fid=@0x8065080, Rowsinfile=13693, Colsinfile=6, Sigfig=6) at mxtx.p:248 #4 0x804c532 in program_Mxtx () at mxtx.p:262 #5 0x804c598 in main (argc=1, argv=0xbffffd10, envp=0xbffffd18) at mxtx.p:264
STRING is typed as string(250); and the program does *lots* of string manipulation, maybe this is bad?
Trapping the conversion that causes the problem gives this trace:
(gdb) 158 IntegerToString(MantVal1,MS1); (gdb) s Integertostring (I=470428, S=@0xbf800228) at mxtx.p:103 103 VAR Cs:STRING; Negative:BOOLEAN; Fig:INTEGER; (gdb) n
Program received signal SIGSEGV, Segmentation fault. Integertostring (I=470428, S=@0xbf800228) at mxtx.p:103
This seems to be in the initialisation of the local variables. Is this right ? Any ideas for further progression ?
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