March 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

New (gpc-20060325)
by Waldek Hebisch 08 Dec '09

08 Dec '09

I have put a new gpc snapshot at: http://www.math.uni.wroc.pl/~hebisch/gpc-20060325.tar.bz2 Main change is preliminary gcc-4.0.x support. The other changes are rather small. Note that for "production use" 3.4.x and 3.3.x backend are prefered. Also, using 2.8.1, 2.95.3 and 3.2.3 backend should work, but is depreciated. For more detail see: http://www.math.uni.wroc.pl/~hebisch/gpc/NEWS-20060325 and http://www.math.uni.wroc.pl/~hebisch/gpc/Fixed-20060325 -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

7 44

-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

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