Gpc

gpc@gnu.de

5400 discussions

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

Jump to page:

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