February 2006 - Gpc

Inefficiency of `mod'
by Emil Jerabek 26 Oct '10

26 Oct '10

Hi, during some debugging I noticed that GPC generates very hairy code for the `mod' operator with signed arguments. A closer look revealed that the code contains a lot of branching on conditions which can be determined on compile time, and most surprisingly, the value of X mod Y is recomputed _twice_, if X is negative. (I've attached a commented assembler dump.) This may be partially a back-end problem (CSE?), but I feel there's something wrong in the relevant code in gpc-common.c (build_pascal_binary_op) as well. `exp1 mod exp2' gets translated into something like exp2 <= 0 ? error : exp1 >= 0 ? exp1 mod exp2 : ((-exp1) mod exp2) == 0 ? 0 : exp2 - (-exp1) mod exp2 This arranges that both arguments supplied to the "internal mod" are non-negative, but this information is not passed on -- the arguments are still declared as signed types, which apparently makes the back-end to produce the mess it does. I've done a little test: the following replacement for `mod', which differs from the built-in one essentially just by the type-casts to `Cardinal', inline operator xmod (X, Y: Integer) = Z: Integer; begin if Y <= 0 then RuntimeError (714); if X >= 0 then Z := Cardinal (X) mod Y else begin Z := Cardinal (-X) mod Y; if Z <> 0 then Z := Y - Z end end; indeed generates a better code, it measures about 15% faster for positive X and more than twice faster for negative X. YMMV. If this is possible in user code, it should work in the compiler internals as well :) The result type of the whole `mod' expression looks dubious too. IIUIC, `exp1 mod exp2' inherits the type of exp1. Now, the result of `mod' is guaranteed to be nonnegative and to fit in the type of exp2 (or more precisely, it is in 0 .. High (type of (exp2)) - 1), whereas it needn't have anything to do with the type of exp1: consider var X, Z: Integer; Y: LongInt; begin X := -8; Y := High (LongInt); Z := X mod Y { -> overflow } end Or am I missing something? Emil (BTW, where is fjf434c.pas?)

10 16

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

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 01 Mar '06

01 Mar '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