June 2004 - Gpc

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

25 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

-mlong-double-128
by Adriaan van Os 13 May '05

13 May '05

The following produces an internal compiler error: [G4:~/gnu/testgpc/adriaan] adriaan% cat compare.pas program Compare; procedure R ( var r1, r2: real); begin if r1 <> r2 then r1:= r2 - 1.0 end; begin end. [G4:~/gnu/testgpc/adriaan] adriaan% gpc -o compare compare.pas -mlong-double-128 compare.pas: In procedure `R': compare.pas:6: error: unrecognizable insn: (insn 26 34 27 2 0x0 (set (reg:SI 126) (subreg:SI (reg:TF 33 f1) 0)) -1 (nil) (nil)) compare.pas:6: internal compiler error: in extract_insn, at recog.c:2175 It may be, of course, that the Darwin target doesn't properly support the -mlong-double-128 PowerPC processor option. If it's a gcc back-end bug, I can report it to Bugzilla. However, the "real" type used is 64-bit on the Darwin target, with or without -mlong-double-128 ... The option only changes the size of the "longreal" and "extended" types to 128-bit. Regards, Adriaan van Os [G4:~/gnu/testgpc/adriaan] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc33d7/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d7/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d7 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3

6 15

Environment variables on Mac OS X
by Adriaan van Os 01 Nov '04

01 Nov '04

As discussed before, shared libraries on Mac OS X can not reference the environ variable directly, where applications can. This is a show stopper on Mac OS X, because of the internals of autoconf and because the environ variable is referenced in gpc's runtime library. To solve this problem, I apply the following patch: --- gcc/p/rts/rts.c.orig Wed Apr 16 01:58:46 2003 +++ gcc/p/rts/rts.c Fri Jun 6 11:35:50 2003 @@ -195,7 +195,15 @@ extern int errno; #endif -#if defined (HAVE_ENVIRON) || defined (environ) +/* needed by Mac OS X */ +#if defined (__MACH__) && defined(__APPLE__) +#include <crt_externs.h> +#endif + +/* on Mac OS X the environ variable can not be referenced in shared libraries */ +#if defined (__MACH__) && defined(__APPLE__) +#define environ (*_NSGetEnviron()) +#elif defined (HAVE_ENVIRON) || defined (environ) #if !defined (environ) && !defined (ENVIRON_DECLARED) extern char **environ; #endif I would be grateful if this patch is merged with gpc's sources. Regards, Adriaan van Os

2 4

gpc-20040516 released
by Frank Heckenbach 22 Jul '04

22 Jul '04

I have uploaded a new beta version of GPC to <http://www.gnu-pascal.de/beta/>. This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work. Waldek Hebisch and I are currently working on some larger changes, including qualified identifiers, range checking and support for gcc-3.4.0. An alpha version with these changes, which might be less stable, will probably be released in a few weeks. BUILD NOTE: If you modify the GPC sources, you now need bison-1.875c and flex-2.5.27 (<http://lex.sourceforge.net>) to rebuild. These versions must be matched exactly. Newer flex versions, in particular 2.5.31, might work as well, but contain a known unportability, so I did not test them, and I recommend 2.5.27. (Other programs such as yacc and lex instead of bison and flex also will not do.) I have included the files generated by bison and flex in the distribution (also in the "minimal" distribution), so you should not need these tools when you only want to build GPC. NOTE: The `Pipe' unit was renamed to `Pipes' because of a name conflict. Unfortunately, this requires a small change to all programs that use this unit. New features: * arithmetic expressions now work as lower array/subrange bounds (fjf248.pas, fjf293.pas, fjf336.pas, fjf346a.pas, fjf622.pas) * records/objects with many fields are processed faster * parameters of procedural types now support Standard Pascal procedural parameters, conformant/open arrays and `type of' inquiries (fjf939*.pas) * empty parameter lists can be written as `()' (chief54*.pas, delphi6*.pas) (D) * GMP unit: `mpf_sin', `mpf_cos' * the test suite output is now by default stored in DejaGnu compatible files `gpc.log' and `gpc.sum' in the `p/test/' directory; other available test targets are `pascal.check-short' and `pascal.check-long' (@) * new options `-W[no-]dynamic-arrays' (fjf931*.pas) * new argument to `_p_initialize' (@) * new function `UMask' * new option `--no-debug-source' * new lexer (no directly user-visible difference, but should allow for better handling of lexer-based problems in the future) Fixed bugs: * `pow' and `**' are really EP conformant now (in particular `x pow y' and `x ** y' are an error if x = 0 and y <= 0) (emil27*.pas) * `protected var' parameters must only accept references (unlike `const' parameters) (gale5*.pas) * `pack' must not pack the component type of arrays (fjf940[b-e].pas) * in some circumstances packed fields were allowed as `var' parameters (fjf940a.pas) * bugs with nonlocal gotos out of routines declaring file variables (nonloc*.pas) (fix involved a change in the internal representation of file variables) * 'foo'#42 must not be rejected in `--borland-pascal' (chief53.pas) * `--implementation-only' didn't work correctly (bo4-19.pas) * messages referring to object methods now point to the method declaration rather than the end of the object type declaration * initializers for types containing nested schemata now work (fjf914*.pas) * various smaller bugs Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

11 50

Re: problem building GPC 20040516 on AIX - continued
by Gert Doering 21 Jul '04

21 Jul '04

Hi, On Wed, Jun 16, 2004 at 08:30:38PM +0200, Frank Heckenbach wrote: > Gert Doering wrote: > > > I'm trying to build the gpc-20040516 "beta" snapshopt with GCC-3.3.x on > > AIX 5.1. GCC-3.x itself supports AIX 5, I have a working version on > > the system (binary install, not compiled-it-myself). [..] > > the line 511 is this one: > > > > TARGET_CPU_CPP_BUILTINS (); > > > > ...which fully escapes me as for why it might not compile...!?? [..] > Unless you need very particular system conditionals (Pascal programs > usually don't), just insert the line > > #define rs6000_cpu_cpp_builtins(foo) > > in lang.c. Thanks for your quick reply. Unfortunately, I didn't see it before today because my spam filter didn't know about the GNU Pascal list yet (all e-mails with unknown To:/CC: headers are quarantained as "maybe spam". Stupid me.) I will try this approach over the weekend. In the meantime, I tried something else - gcc-3.2.3 with gpc-20040516, again on AIX 5.1 and additionally on AIX 5.2 (in case AIX 5.1 is broken). The effect is quite different here. It builds all of xgpc and the libgpc.a just fine, but then crashes in trying to build "binobj". The error is this: gmake[2]: Entering directory `/s1/gpc-build/gcc/p/utils' ../.././xgpc -B../.././ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" collect2: library libgpc not found gmake[2]: *** [binobj] Error 1 gmake[2]: Leaving directory `/s1/gpc-build/gcc/p/utils' gmake[1]: *** [pascal.utils] Error 2 gmake[1]: Leaving directory `/s1/gpc-build/gcc' If I change the -B invocation to use an absolute path, the library is found, but the (AIX) ld doesn't really like the result either: ../.././xgpc -B/s1/gpc-build/gcc/ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" ld: 0711-317 ERROR: Undefined symbol: Tempdirectory.1 ld: 0711-317 ERROR: Undefined symbol: Tempstr.4 ld: 0711-317 ERROR: Undefined symbol: Buffer.8 ld: 0711-317 ERROR: Undefined symbol: Zero.3 ld: 0711-317 ERROR: Undefined symbol: Epoch.6 ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status I've checked with "nm", and it looks like all the stuff should be there: gd@hilb3:/s1/gpc-build/gcc/p/utils> nm ../../libgpc.a | grep Tempdir Tempdirectory.1 U - Tempdirectory.1 d 37956 8 Tempdirectory.1.P8 d 37952 4 Tempdirectoryset.0 d 37948 4 Since I had the nagging suspicion that there might be something in the pascal libraries that the system ld doesn't understand, I tried installing the GNU binutils, ./configure'd again, and rebuilt. Built bombed in libgcc (gcc created stuff that gas didn't like). Removed gas, ./configure'd again, rebuilt. Same error as above (collect2 not finding libgpc). Trying again with absolute paths and GNU ld linked into the "-B" directory as "real-ld" led to a new error: ../.././xgpc -B/gnulocal/src/gcc-3.2.3/gcc/ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/gnulocal/src/gcc-3.2.3/gcc/p/rts --unit-path=/gnulocal/src/gcc-3.2.3/gcc/p/units `cat needed-options` "binobj.pas" /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempdirectory.1' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempstr.4' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Buffer.8' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Zero.3' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Epoch.6' collect2: ld returned 1 exit status (the -B path is different from the example above, because it's a different system - the other one doesn't have the GNU binutils installed yet - but don't let that confuse you) --> so it seems that actually the library itself has unresolved symbols, and not the "binobj.pas" program it tries to link. "ranlib" doesn't help either. Any further ideas how to tackle this? The whole symbol format confuses me - being a C programmer, I'm used to errors about "_crypt" not found, but not without a "_" and neither with trailing numbers... thanks again, gert -- Gert Doering gd(a)medat.de MEDAT Muenchen Tel: 089/126808-0 Fax: -50

4 19

gpc-20040516 for AMD64 (Linux)
by Prof A Olowofoyeku (The African Chief) 12 Jul '04

12 Jul '04

Hi I have built gpc-20040516 for AMD64 (platform: Fedora Core 2, 64-bit). Binaries can be obtained here: http://gnu-pascal.de/contrib/chief/fedora-2/ Built and tested on an Athlon-64 3.2+, the testsuite ran fine, except for these: TEST asmtest.pas: SKIPPED: only for IA32 TEST az20.pas: ./test_run: line 334: 4929 Segmentation fault ./"$A_OUT" "$1" TEST confarr5.pas: ./test_run: line 334: 9516 Segmentation fault ./"$A_OUT" "$1" TEST fjf746.pas: ./test_run: line 334: 14662 Segmentation fault ./"$A_OUT" "$1" TEST fjf746.pas: ./test_run: line 334: 14662 Segmentation fault ./"$A_OUT" "$1" TEST jj5.pas: SKIPPED: `attribute (stdcall)' not available TEST martin3.pas: ./test_run: line 334: 27275 Segmentation fault ./"$A_OUT" "$1" TEST pack10.pas: ./test_run: line 334: 30277 Segmentation fault ./"$A_OUT" "$1" TEST pack5.pas: ./test_run: line 334: 30396 Segmentation fault ./"$A_OUT" "$1" One curious thing. "Writeln (sizeof (Integer))" prints "4", as does "Writeln (sizeof (Cardinal))". Shouldn't these be 64-bit? Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

6 29

Bad stabs
by Adriaan van Os 10 Jul '04

10 Jul '04

The output below from objdump suggests that stabs debugging info from gpc is broken. Does this happen on other platforms also ? Regards, Adriaan van Os ------- [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c hello.pas -g [G4:~/gnu/testgpc/adriaan] adriaan% objdump -g hello.o hello.o: file format mach-o-be Bad stab: Datevalid:(0,5)=@s8;- 16;,0,1;Timevalid:(0,5),1,1;Year:(0,1),2,32;Month:(0,6)=r(0,1);1;12;,34, 4;Day:(0,7)=r(0,1);1;31;,38,5;Dayofweek:(0,8)=r(0,1);0;6;,43,3;Hour:(0,9 )=r(0,1);0;23;,46,5;Minute:(0,10)=r(0,1);0;59;,51,6;Second:(0,11)=r(0,1) ;0;61;,57,6;Microsecond:(0,12)=r(0,1);0;999999;,63,20;Timezone:(0,1),83, 32;Dst:(0,5),115,1;Tzname1:(0,13)=s44Capacity:(0,14)=r(0,14);00000000000 00;0037777777777;,0,32;length:(0,14),32,32;_p_Schema_:(0,15)=ar(0,1);1;3 3;(0,2),64,264;;,128,352;Tzname2:(0,16)=s44Capacity:(0,14),0,32;length:( 0,14),32,32;_p_Schema_:(0,17)=ar(0,1);1;33;(0,2),64,264;;,480,352;; Last stabs entries before error: n_type n_desc n_value string SO 0 0000000000000000 /Users/adriaan/gnu/testgpc/adriaan/ SO 0 0000000000000000 hello.pas OPT 0 0000000000000000 gcc2_compiled. LSYM 0 0000000000000000 integer:t(0,1)=r(0,1);-2147483648;2147483647; LSYM 0 0000000000000000 char:t(0,2)=@s8;-20; LSYM 0 0000000000000000 Complex:t(0,3)=R4;16;0; LSYM 0 0000000000000000 Timestamp:t(0,4)=s104Datevalid:(0,5)=@s8;- 16;,0,1;Timevalid:(0,5),1,1;Year:(0,1),2,32;Month:(0,6)=r(0,1);1;12;,34, 4;Day:(0,7)=r(0,1);1;31;,38,5;Dayofweek:(0,8)=r(0,1);0;6;,43,3;Hour:(0,9 )=r(0,1);0;23;,46,5;Minute:(0,10)=r(0,1);0;59;,51,6;Second:(0,11)=r(0,1) ;0;61;,57,6;Microsecond:(0,12)=r(0,1);0;999999;,63,20;Timezone:(0,1),83, 32;Dst:(0,5),115,1;Tzname1:(0,13)=s44Capacity:(0,14)=r(0,14);00000000000 00;0037777777777;,0,32;length:(0,14),32,32;_p_Schema_:(0,15)=ar(0,1);1;3 3;(0,2),64,264;;,128,352;Tzname2:(0,16)=s44Capacity:(0,14),0,32;length:( 0,14),32,32;_p_Schema_:(0,17)=ar(0,1);1;33;(0,2),64,264;;,480,352;; [G4:~/gnu/testgpc/adriaan] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc332d1/lib/gcc-lib/powerpc-apple-darwin/3.3.2/specs Configured with: ../gpc-332d1/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc332d1 --enable-threads=posix --target=powerpc-apple-darwin Thread model: posix gpc version 20030830, based on gcc-3.3.2 [G4:~/gnu/testgpc/adriaan] adriaan% objdump -v GNU objdump 2.13.90 20030128 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty.

4 10

Re: GPC on AMD Opteron?
by Mingeborg＠aol.com 26 Jun '04

26 Jun '04

Thanks for the help! - Inga In a message dated 6/26/2004 2:33:39 AM Eastern Daylight Time, chiefsoft(a)bigfoot.com writes: > > On 25 Jun 2004 at 19:06, Mingeborg(a)aol.com wrote: > > > Does GPC compile on AMD Opteron processors (64 bit, GNU/Linux)? > > > > I saw in the archives that it's been done for Athlon processors, > > presumably that means, "yes"? Are there any caveats? > > I easily built a version for Fedora Core 2 for AMD64. There > is nothing > to it. No caveats whatsoever. The binaries are here: > http://gnu-pascal.de/contrib/chief/fedora-2/ > > Best regards, The Chief > -------- > Prof. Abimbola A. Olowofoyeku (The African Chief) > web: http://www.greatchief.plus.com/ > > > > >

1 0

GPC on AMD Opteron?
by Mingeborg＠aol.com 26 Jun '04

26 Jun '04

Does GPC compile on AMD Opteron processors (64 bit, GNU/Linux)? I saw in the archives that it's been done for Athlon processors, presumably that means, "yes"? Are there any caveats? Thanks, - Inga

2 1

Re: GPC on AMD Opteron?
by Mingeborg＠aol.com 25 Jun '04

25 Jun '04

Thanks a lot, - Inga In a message dated 6/25/2004 7:15:41 PM Eastern Daylight Time, georges(a)its.caltech.edu writes: > > I assume you mean native AMD64? > > Yes it does (I recently repackaged a new wersion for Gentoo and tested it on > amd64). There doesn't seem to be anything special, just follow the > instructions. You can also take a look at the ebuild, > http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-lang/gpc/gpc-20040516.ebuild > which essentially contains all the steps to build and install it.. > > George > > On Friday 25 June 2004 16:06, you wrote: > > Does GPC compile on AMD Opteron processors (64 bit, GNU/Linux)? > > > > I saw in the archives that it's been done for Athlon > processors, presumably > > that means, "yes"? Are there any caveats? > > > > Thanks, > > - Inga > > > >

1 0