January 2002 - Gpc

³Ì·s®ø®§¤½§G , ½Ð°Ñ¾\¥»«Hªþ¥ó¤§»¡©úÀÉ . 4FxlrOMtTMAD0Q4cghe9Lhszm
by 4QY4B5jehlPBMS＠gcn.net.tw 07 Jan '02

07 Jan '02

. . . . .h

1 0

recent mingw32 (windows) binary available
by Jerry van Dijk 05 Jan '02

05 Jan '02

I wanted to give GPC a testdrive, but I could not find a recent mingw32 binary version, so I was forced to build my own. As it might be useful to others, I've made it available through my webpage: http://users.ncrvnet.nl/gmvdijk/pascal As I have only limited webspace, I had to keep the binary minimal. If someone wants to move the binary to another place where it will be more accessable, that would be fine, as would be adding the documentation, test programs, etc. to it. Note that this is a native windows build, not a cross build. It includes everything (including pdcurses) that was needed to run the testsuite with gpc and mingw32. If anyone has questions, please contact me directly, as I am not a member of this list. gr. Jerry. -- -- Jerry van Dijk | email: jvandyk(a)attglobal.net -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk

2 1

GPC 2.1 RC 2 released
by Frank Heckenbach 05 Jan '02

05 Jan '02

Hi everyone, GPC version 20011222, the release candidate #2 for GPC 2.1, has been uploaded to the usual places, CVS and FTP: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/gpc-20011222.tar.gz The main changes made since RC 1 are in the searching of unit source and GPI files (thanks to a bug report by The Chief), the handling of packed arrays (thanks to a bug report by Emil Jerabek) and set constructors (due to some bugs found by myself). If you use any of these things, you might want to check if the changes didn't break any of your code. There is also one new "feature", the Intl (internationalization) unit by Eike Lange. (I know that normally one should not do major additions so short before a release, but the unit is completely separate from the rest of the compiler and run time system, so even a very unlikely fatal bug would not affect the stability of the whole system.) Again, I've tested it on some systems, test reports from other systems are welcome, and if you find new or especially important bugs, or very important missing features, please report them. Merry Xmas, Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 5

error in new gpc, not present earlier
by J.Booij＠wbmt.tudelft.nl 04 Jan '02

04 Jan '02

At the Delft University of Technology, Mechanical Engineering, Structural optimization and Computational Mechanics group we have been using gpc for quite a while for a fairly large project, a finite element package. This runs on linux. With the most recent version of gpc the compiler will not compile three of the files, the older version we have perfoms the compile without problems. Removing (by commenting out) a part of the code allowed the compiler to successfully terminate, but then the result is of course useless. I have tried to isolate the problem by including all the required information on types, variables, constants, etc with include files, but in that case the compilation is successful. One of the actual routines makes use of 17 units (with uses). I am sending this message in the hope that it will be of some use, I realize that I am providing only very scanty information, but sending all the necessary information would give much more than you would probably want. Posibly the gdb information will give some clues to where the problem arises. Please contact me if I can help by providing more information. I am working on Linux, the output of uname -a is: Linux dutw52.wbmt.tudelft.nl 2.4.7-10enterprise #1 SMP Thu Sep 6 16:48:20 EDT 2001 i686 unknown . The compilation ends with the message: #progress# ERROR/backmesh.p (428) gpc: Internal compiler error: program gpc1 got fatal signal 11 gpc1: gpc exited with status 1 gpc1: gpc exited with status 1 The new version of gpc gives (from gpc -v) Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20011222, based on 2.95.2 19991024 (release) The old one gives Reading specs from /usr/tm/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20001015, based on 2.95.2 19991024 (release) The output from gdb as suggested in your manual is: gdb /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/gpc1 core GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/gpc1 /tmp/ccd3UKqD.i -quiet -du'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x082412a2 in int_cst_lt_always (val1=0x83be324, val2=0x83b784c) at ../../../gcc-2.95.2/gcc/p/types.c:1816 1816 if ((TREE_UNSIGNED (val1) || TREE_UNSIGNED (TREE_TYPE (val1))) (gdb) backtrace #0 0x082412a2 in int_cst_lt_always (val1=0x83be324, val2=0x83b784c) at ../../../gcc-2.95.2/gcc/p/types.c:1816 #1 0x082416c9 in select_integer_type (val1=0x83b784c, val2=0x83b7890, why=LE_EXPR) at ../../../gcc-2.95.2/gcc/p/types.c:1900 #2 0x081f4af9 in build_pascal_binary_op (code=LE_EXPR, exp1=0x83b784c, exp2=0x83b7890) at ../../../gcc-2.95.2/gcc/p/gpc-common.c:2377 #3 0x0822ed32 in yyparse () at parse.y:4485 #4 0x081e3744 in compile_file (name=0xbfffeb91 "/tmp/ccd3UKqD.i") at ../../../gcc-2.95.2/gcc/p/../toplev.c:3265 #5 0x081e749b in main (argc=14, argv=0xbfffe9c4) at ../../../gcc-2.95.2/gcc/p/../toplev.c:5440 #6 0x40049507 in __libc_start_main (main=0x81e6274 <main>, argc=14, ubp_av=0xbfffe9c4, init=0x80491c8 <_init>, fini=0x8249590 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbfffe9bc) at ../sysdeps/generic/libc-start.c:129 J. Booij J.Booij(a)wbmt.tudelft.nl J.Booij(a)wbmt.tudelft.nl

1 0

Lazy I/O
by Emil Jerabek 02 Jan '02

02 Jan '02

Accordnig to both ISO standards, readln(f) should be equivalent to get(f), when eoln(f) is true. In GPC the former seems to be implemented as lazy I/O, while the latter does not. Here is an example (enter three lines of text to test it). ---------------------------- program echo3lines(input,output); procedure copyline; begin while not eoln do begin output^:=input^; get(input); put(output) end end; begin write('Enter the first line: '); copyline; readln; writeln; write('Enter the second line: '); copyline; get(input); writeln; write('Enter the last line: '); copyline; readln; writeln end. ---------------------------------------- Is this a bug or a feature? Emil Jerabek

4 15