Gpc February 2003

gpc@gnu.de

38 participants
76 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 (… [View More]

10 16

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 … [View More]

8 8

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 … [View More]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. [View Less]

8 77

Progress of Mac OS X port
by Adriaan van Os 20 Apr '03

20 Apr '03

Yesterday, I wrote a small test program and linked it against Apple's "Carbon framework". To my surprise, it worked. So, against all expectations, the current compiler is able to link to Apple "dylibs" and Apple "frameworks". The compiler produces ".o" code and the Apple-"ld" linker takes care of the rest. This implies, that I am loosing interest in the Apple-patched GCC compiler. Apple writes "we're not even sure what all of them [the compiler changes] are, because the existing … [View More]

6 13

Re: Conformant array curiosity
by Wood David 24 Mar '03

24 Mar '03

Frank, Thanks for your reply. I've managed to cut down the module to this very short module so I just get two errors, both - prior parameter's size depends on 'A': MODULE Test interface; export Test=(Test_proc); PROCEDURE Test_proc(List : ARRAY[a..b :INTEGER] OF DOUBLE); END. MODULE Test implementation; PROCEDURE Test_proc; BEGIN List[a]:= 2.3; List[2]:= 2.3; END; { Test_proc } END. The errors correspond to each assignment although the error line is the … [View More]

2 2

Conditional keywords
by Frank Heckenbach 17 Mar '03

17 Mar '03

GPC supports a number of keywords that do not belong to all (or any ;-) known Pascal standards/dialects. To relieve the resulting problems, there are currently 3 mechanisms: - If any dialect option (`--extended-pascal' etc.) is used, all keywords not belonging to this standard are deactivated completely. - Individual keywords can be disabled using `--disable-keyword'. - Some keywords are recognized only depending on context, so compiling a program that uses them as identifiers is still … [View More]

5 10

Re: Dynamic array sizes
by Wood David 12 Mar '03

12 Mar '03

Adriaan van Os wrote: > > (1) What about this: get a pointer to the first array element > and then > clear sizeof-array-element * array-size bytes ? > > (2) With modern risc processors, the time delay for > operations on large > data sets is typically in memory stalls, not in processor > instructions. > Are your records densely packed or unaligned on the processor's > "natural" data bounds ? Did you actually try to zero the > array in a for > … [View More]

4 7

Re: gpc-20030209
by Prof A Olowofoyeku (The African Chief) 12 Mar '03

12 Mar '03

On 12 Feb 2003 at 05:45, Frank Heckenbach wrote: > > > But it should be possible with moderate effort to implement > > > something like > > > > > > export Foo = all (FileMode => GPC_FileMode); > > > > > > so one won't have to name all interface declarations, but only the > > > re-exports and renamings explicitly. > > > > Ok. I'd rather not touch any EP stuff (e.g., modules) at all. > > However, if that is … [View More]

2 1

GPC on Solaris 9
by Cserzo Miklos 06 Mar '03

06 Mar '03

Hi Folks, we need to install GPC on Solaris 9 (64-bit sun). Compilation stops at the rts part. Most probably due to the 64-bit architecture. Is there a protocol around this? Cheers, miklos

4 8

Range Checking
by Frank Heckenbach 05 Mar '03

05 Mar '03

Hi, after some friendly requests and discussion, I'm planning to implement range checking as one of the next major things in GPC (probably in Januaray, if nothing urgent gets in between ...). Note, I'm using "range checking" in the specific meaning I explained recently, not generally for all kinds of runtime checks, and not including overflow checking of arithmetic operations etc. (that will be a separate issue). Also, as I said before, I'll do an "easy" implementation. I'm still not … [View More]

6 15

2025

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