Gpc June 2003

gpc@gnu.de

32 participants
37 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

License of the GNU Pascal documentation?
by Matthias Klose 09 Aug '03

09 Aug '03

On The debian-legal mailing list there currently is a major discussion about the "freeness" of the "GNU Free Documentation License". You may want to look at the archives yourself, one point to start is http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00307.html The problem are the "Invariant Sections" of the GFDL, which make the GFDL non-free from Debian's viewpoint. Looking at gpc's documentation, I see the GFDL-1.1 (with the short example GFDL license at the end), but in the man page I only find: COPYING Copyright (c) 1997-2003 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 version published by the Free Software Foundation. A copy of the GFDL comes as a texinfo document along with the GPC manual. In contrast with copying-fdl.texi, there is no mentioning of the "Invariant Sections": "If you have no Invariant Sections, write ``with no Invariant Sections'' instead of saying which ones are invariant. If you have no Front-Cover Texts, write ``no Front-Cover Texts'' instead of ``Front-Cover Texts being @var{list}''; likewise for Back-Cover Texts." Please clarify the copyright of the man page. I'll have to remove the info and html docs from the Debian main section (maybe somebody volunteers to repackage them to the non-free section), but to keep at least the manual pages in the package I'd like to see the license of the manual pages be clarified. Thanks, Matthias

6 16

gpc --help --v
by Adriaan van Os 13 Jul '03

13 Jul '03

gpc --help -v displays a list of available compiler options. Pascal specific options, however, are truncated to the first 23 characters, e.g. -fobject-destination-pa Path where to create ... Back-end options don't seem to be truncated, e.g. -fguess-branch-probability Enables guessing of ... The list of options is quite useful, even better in untruncated form. Regards, Adriaan van Os

5 10

range check test programs
by Francois Schoubben 12 Jul '03

12 Jul '03

For the main tests, i hope it's the end... Up to you to correct my tests... http://www.info.fundp.ac.be/~fsc/dvpt/fsc.tar.gz or, "online" http://www.info.fundp.ac.be/~fsc/dvpt/ fsc01-05 : array R/W fsc06-10 : packed array R/W fsc11 : array in a record (just one, i dont think it's usefull :) ) fsc12 : enum fsc13-14 : string (R/W) fsc15-16 : range write (integer and char) fsc 17-18 : functions and range fsc 19-25 : predefined functions (chr, fillchar, ...) fsc26-27 : conformant array R/W fsc28-30 : slice array fsc31-35 : actual schema discriminant fsc36-37 : "for loops", i'm not sure it's what you expect... For asm target, i have a problem... The only "assembler language" i know is MIX (thanks D. Knuth :-) )... And i haven't really got time to learn it before... long time i'm afraid... Can anybody help here??? For the remaining... What's missing? wrong? misunderstood? I've never played with delphi extensions, the OO language i used was java. And i'm teaching the very basics of programming so, i never used slice array and other schema discriminant before, it's possible i missed a lot of thing... Just explain me (or point me to a relatively short tutorial), i only ask to learn :) -- Francois Schoubben

3 7

object bug report
by Russell Whitaker 10 Jul '03

10 Jul '03

Hi: Took the Chief's sample, added one line, calling file obj1.pas; then: gpc -o obj obj1.pas program obj1; type a = object procedure p; end; b = object (a) procedure p; virtual; end; procedure a.p; begin writeln ('a'); end; procedure b.p; begin writeln ('b'); end; var foo : a; bar : b; begin foo.p; bar.p; end. Got this: obj1.pas:10: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. Using this: Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.2.2/specs Configured with: ../gcc-3.2.2/configure --enable-languages=pascal : (reconfigured) ../gcc-3.2.2/configure --enable-languages=pascal : (reconfigured) ../gcc-3.2.2/configure --enable-languages=pascal Thread model: posix gpc version 20030209, based on gcc-3.2.2 Russ

6 39

gpc20030507 with gcc-3.3 on Mac OS X
by Adriaan van Os 08 Jul '03

08 Jul '03

Peter N Lewis wrote, > #### > #### FDE 0x2aea4 (OB 0x13fd60, fde_end 0x2affc) has zero > length!Aborting. > #### > Abort Fixed with gcc-3.3. Geoff Keating wrote: > > Adriaan van Os writes: >> (4) compiling any .c source with -ggdb or -gdwarf-2 (instead of >> -gstabs or -g) produces the following output: >> Internal compiler error in default_no_named_section, at varasm.c:5305 > > Darwin doesn't really support dwarf2 at present. Fixed with gcc-3.3, there is now a message "unknown or unsupported -g option". Geoff Keating wrote: > > Adriaan van Os writes: > >> Does anyone know what the status is of the following problems, >> encountered with gcc-3.2.1/3.2.2 on Darwin/Mac OS X ? >> >> (1) trampolines crash (I have a patch to fix it) >> >> (2) longjumps crash (I have a patch to fix it also) >> >> (3) non-local goto's don't work, e.g. > > These are all fixed in GCC 3.3. Well, not quite. Longjump crashes and non-local goto crashes have been fixed, but trampoline crashes not. The gcc-3.2.x trampoline patch can be applied to gcc-3.3 and it fixes most trampoline crashes, but ..... ./test_run: line 193: 766 Segmentation fault "$DIFF" testmake.tmp "$xo" TEST fproc.pas: failed ... running the testuite for fproc.pas takes a long time and fails. After a while the hardddisk starts to spin continuously, which might indicate that the system is allocating lots virtual memory (on a 1.25 GB Mac). After this, gpc1 crashes when compiling ANY .pas file, until a reboot. The typical backtrace looks like this: Date/Time: 2003-05-18 03:11:07 +0200 OS Version: 10.2.4 (Build 6I32) Host: G4.local. Command: gpc1 PID: 27979 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0 Crashed: #0 0x0014ec68 in find_reloads (reload.c:4000) #1 0x0011bbe8 in reload_as_needed (reload1.c:3893) #2 0x00115388 in reload (reload1.c:1107) #3 0x001dca60 in global_alloc (global.c:583) #4 0x000991ec in rest_of_compilation (toplev.c:3304) #5 0x00007b58 in finish_routine (declarations.c:2436) #6 0x0002d27c in main_yyparse (parse.c:1739) #7 0x00097ce0 in compile_file (toplev.c:2134) #8 0x0009ce94 in do_compile (toplev.c:5370) #9 0x0009cf60 in toplev_main (toplev.c:5400) #10 0x00002700 in _start (crt.c:267) #11 0x00002580 in start Maybe, virtual memory is corrupt after the fproc.pas testrun ?? Running the testsuite for fproc.pas with --longjmp-all-nonlocal-labels, results in a compiler error message: TEST fproc.pas: /var/tmp//ccMu9pMb.s:unknown:Can't emit reloc {- symbol "LSJR11"} @ file address 800. /var/tmp//ccMu9pMb.s:unknown:Can't emit reloc {- symbol "LSJR11"} @ file address 796. /var/tmp//ccMu9pMb.s:unknown:Undefined local symbol L3$pb failed Regards, Adriaan van Os

3 8

Installation instructions
by Frank Heckenbach 02 Jul '03

02 Jul '03

The installation instructions in the manual are somewhat outdated (and have always been, at least for some years now). There are probably a number of things which are not quite accurate, missing or unnecessary (perhaps kludges that were once necessary). Also, the structure of the chapter is probably not optimal. Furthermore, there's information (partly overlapping, but also containing things not mentioned in the manual) that was once in the FAQ, but was taken out since it should be merged with the install instructions (because having two parallel, but not quite identical instructions would only add to the confusion). This merging hasn't been done, so the old FAQ information has rotted since then (probably all URLs in it are wrong now etc.), so it must be carefully updated and then merged with the install chapter. Obviously, I'm looking for people to do that. (I'm not going to, since my perspective, especially here, is a bit different from the average user's ...) Ideally, perhaps for each "essentially" different platform (i.e., DJGPP, Cygwin, Mingw, Mac OS, Unix and perhaps GNU/Linux as a special case of Unix where some things are easier, so it might be worth making it a separate section which doesn't confuse the user with details necessary for other Unices) one user should write one compact section. It should describe both compiling from sources and installing binaries. (Of course, this doesn't mean completely rewriting it -- the existing material can be used and rearranged, of course.) There should be some coordination (by one of them or someone else), so the sections will not look more different from each other than necessary, and common things need to be described only once. I'd like to not have to do this myself, but instead get the collected material from the coordinator in a new install.texi when it's ready. (I'm sending this mail to both gpc and gpc-doc, since it concerns the documentation, but also "regular" GPC users, and since the archives currently don't work, please reply to both lists. Once the volunteers have found, they can coordinate via gpc-doc only or private mail, of course ...) I've put the install chapter from the current sources as well as the old information from the FAQ at http://fjf.gnu.de/gpc-install.tar.gz 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

5 6

gdb
by Peter N Lewis 30 Jun '03

30 Jun '03

Hi, So what is the status of gdb? It seems to work with Pascal, but it does not seem to be able to display String()'s and I could not figure out how to use "call" to call CFShow (Apple says: call (void)CFShow(cf) but that just gives a syntax error). (CFShow is a debugging routine that prints out the decoded value of the input parameter). And print S gives: $1 = (&$$1 = record ) @$bffff7c0: <incomplete type> Thanks, Peter. -- <http://www.interarchy.com/> <http://documentation.interarchy.com/>

3 3

Archives working again
by Frank Heckenbach 29 Jun '03

29 Jun '03

The archives of this mailing list and the (experimental) search function on the GPC site <http://www.gnu-pascal.de/search.html> should now be working again. 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

1 0

Archives working again
by Frank Heckenbach 29 Jun '03

29 Jun '03

1 0

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 2003