Gpc April 2003

gpc@gnu.de

26 participants
39 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

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

Upper/lower case in identifiers
by Frank Heckenbach 22 May '03

22 May '03

As you probably know, GPC currently converts all identifiers to first letter upper-case/rest lower-case. Since this is often not nice, I plan to change this. This would affect at least the following things: - error messages - the file name chosen with `--transparent-file-names' (makes a difference only on case-sensitive file systems, i.e. not Dos/Windows); is this ok (to those who use this option)? - the file name prompt with external files without binding While I'm at it, it might be easy to add a warning if an identifier is used with varying case (something like `var Foo: Integer; [...] WriteLn (FOO)'). - Any ideas for the name of the option? (`-Widentifier-case'?) - Default? (I suppose off, though I think I myself would prefer on.) - Should it work across units/modules? Or should it be a tri-state option (never/current file/global)? 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

8 8

Dynamic object methods
by Frank Heckenbach 15 May '03

15 May '03

One item on the to-do list are BP compatible dynamic methods. As far as I understand the BP description, they are semantically equivalent to virtual methods, only the syntax is different (an integer index added) and the implementation (which we don't have to follow, of course). Ignoring this index syntactically would be easy to do. Would this be useful, and is it really all that's required? 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

10 36

Common symbols
by Adriaan van Os 12 May '03

12 May '03

While trying to build a Mach-O dynamically linked shared library with GPC and LD, I get the following error: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_0__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_1__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_2__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_3__ (size 32) In the Mach-O Runtime Architecture docs I found: "A common symbol is a symbol that may appear in multiple intermediate object files. The static linker permits multiple common symbol definitions with the same name in input files, and copies the one with the largest size to the final product. If there is an another symbol with the same name as a common symbol, the static linker will ignore the common symbol instead. The standard C compiler generates a common symbol when it sees a tentative definition—a global variable that has no initializer and is not marked extern. The following line is an example of a tentative definition: int x; A shared library cannot have common symbols. To eliminate common symbols in an existing shared library, you must either explicitly define the symbol (with an initialized value, for example) in one of the modules of the shared library, or pass the -fno-common flag to the compiler." My questions are: 1. Is there something special about symbols for sets ? 2. Would it help to rebuild libgpc.a with the --no-common flag ? 3. Any other ideas or suggestions ? Regards, Adriaan van Os

3 6

gcc 3.2.3 successes
by Prof A Olowofoyeku (The African Chief) 05 May '03

05 May '03

Hi folks I have built gpc 20030323 with gcc-3.2.3 sources, both under Cygwin and Mingw. I used the gcc-3.2.2.diff. There were no problems with either configuring or building. I have not yet run the testsuites, but everything seems okay with my own programs. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

4 6

`Return'
by Frank Heckenbach 01 May '03

01 May '03

`Return' currently needs special syntactic handling, only because it's (optional) argument doesn't have to be enclosed in parentheses (like in C), such as `Return 42'. The only Pascal dialect (AFAIK) that also supports `Return' is Mac Pascal. Does it work without parentheses there? If not, I suggest to change it in GPC, even if it means a few (trivial) changes in existing code. 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

4 7

Book about GNU Pascal
by Marek Soobik 01 May '03

01 May '03

Hi! Can anybody recommend me a good reference book of GNU Pascal (written in English). Marek

2 1

Weird type/identifier conflicts
by Grant Jacobs 30 Apr '03

30 Apr '03

This is an *updated* version of my previous message, which I mistaken sent to gpc-doc (my apologies). (See the bits 'Addendum' for the new stuff I've added.) Excuse my being frustrated. I am trying damn hard to get GPC (2.1 (20020510), based on gcc-2.95.3 20010315 (release)) to compile a Pascal program I wrote some time ago but keep running it things I can't make sense of. Maybe I'm being unfair, but I'll give you the whole story just in case its something new. The latest issue I'm having is a run of type vs. identifier conflict errors of the form: ./GHJ_AARegions.pas:49: type name expected, identifier `Fnames' given ./GHJ_AARegions.pas:49: warning: missing type in declaration of `Infname' ./GHJ_AARegions.pas:54: warning: parameter has incomplete type My trouble was fnames *is* a type. It is *only* defined as a type. So how the heck does the compiler come away thinking that its an identifier????? I eventually resolved this by directly 'using' modules, rather than rely on the hierarchy (read on). When this error occurred the GHJ_AARegions unit uses GHJFnames. GHJFnames in turn uses GHJFiles, which is where the type fnames is defined. (Really these two levels need to be the other way around, but this is a legacy program I am porting, so I have to deal with that after the port.) Since these uses statements were within the interface section, I presumed the definitions would propagate upwards so that they form a hierarchy. Or, put another way, I assumed the interface of a unit is extended by any units it uses in its interface section. Originally, I had: unit GHJ_AARegions ; interface uses GHJStdDefs, GHJStdMaths { for inrange() }, GHJttInterface { for press_return() }, GHJStrings { for get_string8() }, {=>} GHJFnames { for get_fname() }, GHJ_AAErrors, GHJ_AAUtils, GHJ_AAGlobalUnit ; By getting GHJ_AARegions to explicitly, directly, use GHJFiles, the compiler stopped complaining. ie. I changed the above code to: unit GHJ_AARegions ; interface uses GHJStdDefs, GHJStdMaths { for inrange() }, GHJttInterface { for press_return() }, GHJStrings { for get_string8() }, {=>} GHJFiles, GHJFnames { for get_fname() }, GHJ_AAErrors, GHJ_AAUtils, GHJ_AAGlobalUnit ; {=>} points out the offending line of source. If this is truly the problem, then I presume there is no way of building a hierarchy of units in GPC at present? (In this case my safest strategy is to have every unit uses *all* the lower units directly, "just in case". Or put, another way, I might just as well use includes to make everything one big flat program. Sorry, but I *am* frustrated!) Three thoughts: 1. This is the correct behaviour?: surely I should be able to use a higher-level module and have all the lower-level modules definitions within that higher-level module "gotten" at the same time without have to explicitly duck behind the scenes and drag out each module??? Excuse me for asking this, but its not terribly clear from the docs, at least on my reading of it. Addendum: I've since seen section 6.1.8.2. The source structure of UCSD/Borland units of the docs say "A units exports everything declared in the interface section". This it doesn't appear to do if we consider things in the units imported via uses. 2. Why the heck does the compiler report the message it does? "Missing type fnames" perhaps, but since fnames is only ever defined as a type and never as an identifier, it shouldn't be able to report the message it did... 3. Is there any chance you can tell the user where the "identifier" (see the error message) is defined so that in future users might have chance of trying to second-guess just what the compiler is "thinking"? Sorry I can't provide a full code example: I am porting a largish program (approx. 60,000 lines of source in a dozen or so modules) and in any event I can't understand the problem well enough to create an example - catch-22... Looking at the known bugs for ver. 2.1 there are a couple that might be relevant, esp."Types declared in a module interface are not visible in the implementation" (but does this refer to the same module's interface section and how are units and modules related with reference to this?) While I'm writing, is there any chance you can make the compiler keep trying after one unit has failed, rather than stopping at that point? It seems that if there is even one error in a unit, the compilation is abandoned at the end of that unit. Now to try figure out how GPC claims a type-mismatch on something that is definitely the same type and the type is only defined in one place... probably the same issue, we'll see... Addendum: Nope. It proves to be a unit issue, but a different one. It seems that --automake doesn't "drill down". If you modify a lower level unit, then recompile a higher-level one that uses the lower-level unit, GPC doesn't re-compile the lower-level unit first and instead comes out with (apparently) misleading error messages. --automake in my hands isn't so auto ;-) ! Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs(a)bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents.

8 77

[admin@gmane.org: gpc added to Gmane]
by Anja Gerwinski 30 Apr '03

30 Apr '03

Hello, checking the mail for gpc-owner, I found the message below. The GPC list has been added to http://gmane.org/ which is a mail-to-news gateway. They claim they received a request for this. Does anyone know anything about this? As the gpc list archive is public, I suppose it is no problem that the list is now archived at gmane, too. However, I find it puzzling that they add a list without asking for permission first. Our list archive provided by Frank's crystal removes email addresses from the formatted view. I did not check how Gmane deals with this. The mail below says "Address encryption is off". Could someone please check what this means, and get it changed, if necessary? Best wishes, Anja ----- Forwarded message from Gmane Administrator <admin(a)gmane.org> ----- X-Gmane-Information: For more information, see http://gmane.org/ From: admin(a)gmane.org (Gmane Administrator) To: owner-gpc(a)gnu.de Subject: gpc added to Gmane Organization: GNU Mail To News -- http://gmane.org/ Date: Sun, 06 Apr 2003 16:00:29 +0200 We have received a request for adding the gpc(a)gnu.de mailing list to the Gmane mail-to-news gateway/archive. A subscription request message has been sent. If this is contrary to your wishes, please send a mail to admin(a)gmane.org saying so, and the list will be removed from Gmane. Gmane is a mail-to-news portal that never expires its messages. It therefore also functions as a mailing list archive. It's a bi-directional gateway, but Gmane verifies that its users' email addresses are valid before passing the messages through the news-to-mail gateway. (Groups can also be made "read-only", which means that Gmane won't forward any messages at all to the mailing list.) Gmane can encrypt addresses to make address harvesting difficult, and heeds X-No-Archive and related headers. If you wish to import older archives into Gmane, send a message to the Gmane administrators -- just reply to this message. The following parameters are set for this mailing list: * Newsgroup name: gmane.comp.compilers.gpc * Mailing list address: gpc(a)gnu.de * The gateway is bi-directional * Address encryption is off * Spam detection is on * The list is described as: "discussions and development of the GNU Pascal compiler" * News URL: news://news.gmane.org/gmane.comp.compilers.gpc * Web URL: http://news.gmane.org/thread.php?group=gmane.comp.compilers.gpc This newsgroup will be created when the first message from the mailing list arrives. For more information about the Gmane project, go to <URL: http://gmane.org/>. This request was handled by Tom Koelman <tkoelman(a)xs4all.nl>. ----- End forwarded message -----

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 April 2003