Gpc June 2006

gpc@gnu.de

11 participants
14 discussions

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

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

Short Strings
by Peter N Lewis 04 Jul '06

04 Jul '06

Hi all, I know short strings (255 character limit, 0 index containing the length) have been discussed to death, and I'm not going to discuss them further, but I did want to point out for those of you not on the MacPascal mailing list that everyone asking "Which should I use, FPC or GPC?" is basically ending up with FPC primarily because of lack of short string support. I have nothing against FPC, and indeed the developers have been great at supporting Mac compatibility and so forth. But since I use GPC, and since GPC has lots of really cool other features (like long Strings for example ;-), I'd love to encourage people to use GPC. I personally believe the little extra work required to use wrappers for when short strings are needed is no big deal, but it's hard to argue that "its just a little more work" to a developer who is already faced with making a big change in their environment and code. So basically, I'm just saying that the lack of short strings is seriously hindering GPC adoption on the Mac, and that that should probably be taken in to account when pondering the priority of their implementation. Thanks, Peter. -- Check out Interarchy 8.1, just released, now with Amazon S3 support. <http://www.stairways.com/> <http://download.stairways.com/>

3 4

Re: Hacking "method variables"
by Frank Heckenbach 21 Jun '06

21 Jun '06

Forwarded from marcov(a)stack.nl (Marco van de Voort): In gmane.comp.compilers.gpc, you wrote: >> Forwarded from marcov(a)stack.nl (Marco van de Voort): >> >> A slight advantage of the delphi method is that it requires dirty syntax to >> do dirty things. That could be seen as a deterrent. > > As a general principle, I agree -- though some (optional) warnings > would also be fine. However, AIUI, what Markus want to do isn't > actually dirty stuff, i.e. all type-safe. One could argue that this leads to partial initialisation(method inited, instantiation not). However that is just a detail. I'd have doubts because I don't think it really is worth inventing new syntax that is marginally cleaner (typesafe), since this form of usage is probably rare, and usually limited to the innerworkings of frameworks anyway. (at least that is the only place I have ever seen such code in Delphi, e.g. central dispatch routines deep in the classes framework) >> Not this moment. But IMHO it should, though we would probably call it a >> "hint" (something that is not _always_ wrong). > > Doesn't this apply to most warnings? No. E.g. portability warnings are not a problem if you are writing a non-portable app. But the compiler doesn't know this intention. Solution, put it on a different level. Also compiletime warnings about possible range problems (e.g. assigning integer to byte) can be very handy to track if you have problems, but generate a lot of noise. All old hat probably, since I assume GPC has a deep warning system? So my remark was more a musing where I would put it in our three level warning system (the three types have names; warnings, hints, notes). IIRC the difference between them, is likeliness of being correct, and frequency, but I noticed that the manual misses a formal description of these levels, I'll make a note about that.

1 1

Compiling GCC+GPC on 64 bit Athlon
by Silvio a Beccara 20 Jun '06

20 Jun '06

Dear list friends, I think this might have been asked already, but I can't find the correct answer in the archives. How does one go about compiling GCC 3.4.3 together with GCC on a 64 bit dual-core Athlon? Here's my cpuinfo information: processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 35 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping : 2 cpu MHz : 2211.354 cache size : 1024 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext f xsr_opt lm 3dnowext 3dnow pni lahf_lm cmp_legacy bogomips : 4430.51 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp I already tried, but without success, this configure setting: ./configure --enable-languages=pascal --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --enable-shared and I can attach, if needed, the make logfile. I hope you can help me. Kind regards Silvio a Beccara -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Refill s.r.l. - Cartucce compatibili e kit di ricarica per tutti i modelli di stampante. Acquista al telefono o online: consegna in tutta Italia in 48 ore! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5190&d=20-6

2 1

Free Pascal Meeting
by Adriaan van Os 19 Jun '06

19 Jun '06

This weekend, I attended an international meeting of the Free Pascal Development team, hosted by Marco van de Voort in Eindhoven, which happens to be just a few miles from my home. This was an informal meeting with barbecue et al (and Marco trying hard to set his house and garden on fire). A topic that I should mention here, is the many units that FPC has to interface with external packages. For many packages, there are no GPC alternatives being actively maintained. For Mac OS X however, a common set of Pascal interfaces to system software is maintained by a small team, from which interfaces are auto-generated for GPC, FPC and MW Pascal. So, in general, I think working together with the FPC team is a good idea (and for Mac OS X, we already do so actively). Anyway, the FPC team accepts {$ifdef __GPC__} patches to their interfaces and are open to discussions on other solutions. I don't have much time now to look into this, but this may change in say two or three months. Of course, volunteers are welcome. Regards, Adriaan van Os

1 0

Internal compiler error when building on AIX
by Marcus Wirth 16 Jun '06

16 Jun '06

Hi, I'm trying to build GPC (using the sources gpc-20050331.tar.bz2 and gcc-core-3.4.4.tar.bz2) on AIX 5.3. After working for a while the compiler crashes with an "Internal compiler error" (see below). Did anyone succeed building GPC on AIX using the recent sources? Thanks for your help! Marcus /opt/db2/db2bavpi/gpc/build/gcc/xgcc -B/opt/db2/db2bavpi/gpc/build/gcc/ -B/opt/d b2/db2bavpi/powerpc-ibm-aix5.3.0.0/bin/ -B/opt/db2/db2bavpi/powerpc-ibm-aix5.3.0 .0/lib/ -isystem /opt/db2/db2bavpi/powerpc-ibm-aix5.3.0.0/include -isystem /opt/ db2/db2bavpi/powerpc-ibm-aix5.3.0.0/sys-include -O2 -DIN_GCC -W -Wall -Wwrit e-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isys tem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I . -I. -I../../gcc-3.4.3/gcc -I../../gcc-3.4.3/gcc/. -I../../gcc-3.4.3/gcc/../inc lude -I../intl -DL_fixunsdfsi -c ../../gcc-3.4.3/gcc/libgcc2.c -o libgcc/./_fix unsdfsi.o ../../gcc-3.4.3/gcc/libgcc2.c: In function `__fixunsdfsi': ../../gcc-3.4.3/gcc/libgcc2.c:1384: error: unrecognizable insn: (insn:HI 11 10 12 0 ../../gcc-3.4.3/gcc/libgcc2.c:1381 (set (reg:CCEQ 122) (compare:CCEQ (ior:SI (gt:SI (reg:CCFP 121) (const_int 0 [0x0])) (eq:SI (reg:CCFP 121) (const_int 0 [0x0]))) (const_int 1 [0x1]))) -1 (insn_list 10 (nil)) (expr_list:REG_DEAD (reg:CCFP 121) (nil))) ../../gcc-3.4.3/gcc/libgcc2.c:1384: internal compiler error: in extract_insn, at recog.c:2083 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. gmake[2]: *** [libgcc/./_fixunsdfsi.o] Error 1 gmake[2]: Leaving directory `/opt/db2/db2bavpi/gpc/build/gcc' gmake[1]: *** [libgcc.a] Error 2 gmake[1]: Leaving directory `/opt/db2/db2bavpi/gpc/build/gcc' gmake: *** [all-gcc] Error 2

2 1

Error building GPC on MinGW
by Markus Gerwinski 14 Jun '06

14 Jun '06

Hi Folks, I'm trying to build gpc-20050331 (with the patch from 20050411) in a MinGW/MSys environment on Windows XP. I'm doing ./configure --enable-languages=pascal make ... and `make' then aborts with the error message below. What am I doing wrong? Regards, Markus -- LOG -- make[2]: Entering directory `/mysoftware/gcc-3.4.3/gcc/p/rts' make[2]: Nothing to be done for `generated-files'. make[2]: Leaving directory `/mysoftware/gcc-3.4.3/gcc/p/rts' rm -rf p/docdemos ./p/script/mkdir-p p/docdemos ./p/script/extract-doc-demos -o p/docdemos ./p/doc/*.texi ./p/doc/generated/*.texi ./p/doc/en/*.texi echo timestamp > "p/stamp-docdemos" make[1]: Circular libgcc.a <- pascal dependency dropped. if [ -f specs.ready ] ; then \ true; \ else \ echo timestamp > specs.ready; \ fi (MAKE="make"; srcdir=`cd ./fixinc && ${PWDCMD-pwd}` ; \ CC="gcc"; CFLAGS=" -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE"; LDFLAGS=""; \ WARN_CFLAGS="-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-error"; LIBERTY=`${PWDCMD-pwd}`/"../libiberty/libiberty.a"; \ export MAKE srcdir CC CFLAGS LDFLAGS WARN_CFLAGS LIBERTY; \ cd ./fixinc && \ /bin/sh ${srcdir}/mkfixinc.sh i686-pc-mingw32 i686-pc-mingw32) constructing ../fixinc.sh for i686-pc-mingw32 to run on i686-pc-mingw32 The directory that should contain system headers does not exist: /usr/include make[1]: *** [stmp-fixinc] Error 1 make[1]: Leaving directory `/mysoftware/gcc-3.4.3/gcc' make: *** [all-gcc] Error 2

3 4

Re: Hacking "method variables"
by Frank Heckenbach 13 Jun '06

13 Jun '06

Forwarded from marcov(a)stack.nl (Marco van de Voort): In gmane.comp.compilers.gpc, you wrote: >> It works though with >> uninitialised objects too as long as you don't actually "use" (dereference) >> self: > > I see. But I suppose Markus also wants to call the method via the > procedural variable later and apply it to a certain object instance > (selected at call time), something like (depending on the syntax > chosen): Not possible directly, however messing with the internals (via the tmethod record typecast) is "supported". IOW, people expect it to work on Delphi. procedure test; var localx : somemethodvar; begin localx:=globalmethodvarref; // local copy, avoid global mod of complex constant. tmethod(localx).data:=otherinstance; // maybe typecast to pointer end; the problem is of course that the assignment is not safe. However usually code that messes with instances of procvars is typically framework internal, and not in normal user code, so I don't have a particular problem with it. (at least not enough to invent new syntax) A slight advantage of the delphi method is that it requires dirty syntax to do dirty things. That could be seen as a deterrent. > Of course, that can be a problem -- as always if not carefully used. > BTW, do you warn if taking the address (@) of a normal (non-object) > variable on the stack? Not this moment. But IMHO it should, though we would probably call it a "hint" (something that is not _always_ wrong).

2 2

Re: Hacking "method variables"
by Frank Heckenbach 13 Jun '06

13 Jun '06

Forwarded from marcov(a)stack.nl (Marco van de Voort): In gmane.comp.compilers.gpc, you wrote: > Frank Heckenbach wrote: >> >> begin >> bla:=xx.methodname; >> end; > > So IIUC, the difference to Markus' way is that here the procedural > variable also contains the object, while there it only points to the > method, and can be applied to any object (of matching type), right? Yes, though object-instance might be a better phrasing. It works though with uninitialised objects too as long as you don't actually "use" (dereference) self: {$mode delphi} type tmyobject = class function bla ( x: integer):integer; end; tmethodvar = function (x:integer):Integer of object; function tmyobject.bla(x:integer):Integer; begin writeln(x, ' ', PtrInt(self)); // ptrint is guaranteed pointer size compat end; var x : TMyobject; y : tMethodVar; begin x:=nil; // if you can detect uninitialised vars, this is not necessary. y:=x.bla; y(5); end. will write 5 0 I'm a bit worried that this syntax is a bit focused on object types that are already (implicitely) a pointer, like Delphi. If this is possible with (one of ) your object models, better warn if you try to assign a methodvar to a method of an object that is on the stack instead of on the heap.

2 4

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 June 2006