- Gpc - gnu.de

vim indent file for pascal
by Guillaume Rousse 14 Feb '02

14 Feb '02

Hello. I just wrote a pascal indent file for vim. It is very basic, and intended for teaching purpose mainly, but if some of you want to try it, i'd be happy to have some feedback. It's located at http://lis.snv.jussieu.fr/~rousse/linux/pascal.indent.vim -- Guillaume Rousse <rousse(a)ccr.jussieu.fr> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

1 0

GPC Installation Help on Windows NT
by andrew.kelly＠us.abb.com 14 Feb '02

14 Feb '02

I recently discovered GPC and am attempting to install it on Windows NT, but cannot get it to run. So far I have done the following: * downloaded the MinGW 1.1 distribution from SourceForge.net * added C:\mingw\bin to my PATH per the MinGW 1.1 instructions at SourceForge * downloaded the gpc-19990118.i386-pc-mingw32 distribution * extracted the files to the C:\mingw folder (the GPC binary is in the same bin folder as the GCC, g77, etc. binaries) Now, working in a Command Prompt window from a different folder (i.e. my "working directory"), I get the following behavior: * Type "gpc" - works ok (I get the copyright message and a list of more details, command line options, and a command to view the online documentation) * Type "gpc --verbose" (as described in the above output) - I get a couple of lines of messages, with the last line reading "ld: cannot open crt1.o: No such file or directory", but this file is located in my "C:\mingw\lib" folder. * Type "info -f gpc invoking" (as described in the above output) - I get the standard Microsoft error message "The name specified is not recognized as an internal or external command, operable program or batch file." * Type "gpc test.pas" (test.pas is a file in my current working directory, which runs correctly under Turbo Pascal 5.5) - I get an error message "gpc: installation problem, cannot exec 'gpc-cpp': No such file or directory" There is a file "gpc-cpp.exe" located in "c:\MinGW\lib\gcc-lib\i386-mingw32\2.8.1", so I added this folder to my PATH. Now I get the following behavior: * Type "gpc test.pas" (same as above) - I get a different error message "ld: cannot open crt1.o: No such file or directory", but this file is located in my "C:\mingw\lib" folder. Can anyone help me get this installation to work? Also, it would be great to use either the PENG or RHIDE IDEs described on the GPC web page, but I noticed that both of these only work with DJGPP. Will DJGPP work under Windows NT? If so, (other than the obvious of getting the DJGPP versions of GCC, binutils, GPC etc.), are there any tricks necessary to getting the DJGPP version of GPC operable and getting PENG or RHIDE working as well? Thanks. Andrew Kelly andrew.kelly(a)us.abb.com

3 2

Re: gcc-3+
by da Silva, Joe 14 Feb '02

14 Feb '02

Again, fragmentation is a different issue. Garbage collection involves the removal of garbage - which means blocks of memory that are no longer referenced by a pointer, but which due to neglect, have not been de-allocated (ie. memory leakage). Joe. > -----Original Message----- > From: Russell Whitaker [SMTP:russ@ashlandhome.net] > Sent: Thursday, February 14, 2002 2:47 PM > To: cbfalconer(a)worldnet.att.net > Cc: gpc(a)gnu.de > Subject: Re: gcc-3+ > > > > On Wed, 13 Feb 2002, CBFalconer wrote: > > > ... Pascal should not have garbage collection. > > 1. Does the program fragment memory? > 2. If yes, what are the acceptable limits of that fragmentation? > 3. Will the program terminate before those limits are reached? > > One size doesn't fit all. > > Russ > >

1 0

Re: gcc-3+
by da Silva, Joe 13 Feb '02

13 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Russell Whitaker [SMTP:russ@ashlandhome.net] > Sent: Wednesday, February 13, 2002 3:51 PM > To: gpc(a)gnu.de > Subject: Re: gcc-3+ > > > > On Tue, 12 Feb 2002, Markus Gerwinski wrote: > > > Hi folks, > > > > Frank Heckenbach wrote (in reply to da Silva, Joe): > > > Obviously, you need pointers to represent such structures. Creating > > > them is not a problem, but how to clean up properly? You can > > > traverse all pointers in the object and clean up the objects they > > > point to recursively. But that's wrong because those objects might > > > be referred to from elsewhere. Also, with cyclic references, you'd > > > run into an endless loop. > [Joe da Silva] Yes, I seem to recall this matter being discussed in Pemberton and Martin, wrt. the P4 compiler, although I can't recall the details ( I'm trying to learn this stuff, but it's "heavy going" and spare time is scarce :-/ ). > > > > > > This is not to say it's impossible (I mentioned reference counting, > > > and there are ways to avoid the endless loop), but is this much > > > simpler than GC? In fact, if you consider the whole memory as a > > > large tree(*), the resulting algorithm wouldn't look much > > > differently from a GC algorithm ... > > > > If this > > > > inter-dependence with GCC also means that garbage > > > > collection is a requirement, then "so be it" ... > > > Practically, it does. But if you know a better solution, even if > > > only in theory, I'd be interested, just for curiosity. > > > > I'm currently working on a framework including an object type named > > "tReferenceManager". It is intended to exactly solve this problem, at > least > > for synchronization of collections (lists, hashtables etc.): For every > > pointer, you can subscribe _one_ collection it is stored in, plus an > > arbitrary number of reference collections. When the pointer is removed > from > > the store collection, it is automatically disposed, and all of the > > references are removed from the reference collections. > > > > I hope to complete the respective unit of this framework within a few > weeks. > > If anyone thinks he/she can use it, I'll announce it after this unit is > > ready. (Frank: The framework contains also the exception handling unit > we > > already talked about.) > > > > Personally, I _really_ dislike garbage collection since I had to deal > with > > it in an optimization problem in Java. ;-/ IMO, providing a language > with > > GC is just a way to encourage programmers to give up control. An > alternative > > feature I'd like to see in a language would be to split pointers into > two > > separate data types: "store" pointers and "reference" pointers. > Allocating > > and deallocating may only be done on a store pointer; setting a pointer > to > > an already existing address may only be done with a reference pointer. > When > > disposing of a store pointer, itself and all of its references are > > automatically set to nil, so you can always check whether the pointer is > > pointing to valid data. (It's the same principle I'm using in my > > tReferenceManager, and up to now I didn't find any disadvantages in it. > > Except that you are forced to think before you code.;-) > [Joe da Silva] An interesting idea - I like your approach. > > > Perhaps I'm missing something. I thought the purpose of GC was to maintain > a list of free memory. Thus GC doesn't care how you access a block, it > cares only if it is free or not. A simple GC would recognize adjacent free > blocks and combine them into a larger single block. > [Joe da Silva] Well, I though that's what "new" and "dispose" do. As I understand it, GC's purpose is to de-allocate memory blocks that no longer are referenced by pointers but that the programmer has forgotten to de-allocate himself (or herself). For example, new(apointertosomething); ..... {no dispose} new(apointertosomething); > A more complex scheme > could move already allocated blocks to make a large free block when one is > needed. This last might be implemented by adding a transparent level of > indirection. Programmer thinks his pointer p is pointing to something when > in reality it is pointing to an internal pointer pointing to the > something. Thus when the block gets moved only one pointer needs to be > changed. > > Along with GC you have the problem of do you allocate first fit or best > fit? Each has its pros and cons. > > And just how is gcc doing GC and friends? (was lazy and didn't do much > digging thru the code.) > > Just some thoughts, > Russ >

3 3

Re: gcc-3+
by da Silva, Joe 13 Feb '02

13 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Tuesday, February 12, 2002 9:29 PM > To: gpc(a)gnu.de > Subject: Re: gcc-3+ > > da Silva, Joe wrote: > > > > Excuse me, but I think that's more of a prejudice here. What the > > > compiler does internally relies heavily on tree structures. These > > > require pointers in *any* language -- though some languages hide the > > > fact. Pascal doesn't hide it, so the tree handling code and the > > > resulting memory management problems would be exactly the same if > > > GPC was written in Pascal. > > > > > > Other typical usages of pointers in C, such as for strings, are > > > relatively few in GCC/GPC, and are not the problem. > > > > > [Joe da Silva] > > > > My comments were general and relate to the excessive > > reliance of C on pointers, whereas Pascal often avoids > > them with safer alternatives, such as "var" parameters, > > etc. > > As much as I share your dislike of C in general, let's try to keep > to the point. The use of explicit pointers instead of `var' > parameters does not affect the memory management situation (if used > properly, but I think GCC does so). Memory management is used with > malloc() in C or New in Pascal, and those routines yield explicit > pointers, anyway. > [Joe da Silva] Yes, you are right. Sorry for straying a bit off-topic (no pun intended;-). Of course, memory leakage and stray pointers are two separate problems. ------ snip ------

1 0

Re: Complex_Arctan
by Maurice Lombardi 12 Feb '02

12 Feb '02

Frank Heckenbach <frank(a)g-n-u.de> a dit : > Besides, as I noted, Emil evaluates the series only in a certain > interval (|u| < 1/3, i.e. z < 1/9), so the number of terms needed to > get the required accuracy is bounded by a constant (the size of the > coefficients array). When you say "too high", do you mean this > constant is too big? Bigger than that of a Tchebiceff polynomial of same accuracy over same range. > Also, as I said, I can't see why there should > be large rounding errors. Mmm. I may have spoken too fast. Rounding errors are a plague in large degree polynomials of alternating signs, if terms (coeff * x^n) are of same order of magnitude. This should not occur for an absolutely convergent series, where the higher degree terms are small, if summed from higher to lower degree. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

gcc-3+
by Russell Whitaker 12 Feb '02

12 Feb '02

Hi found this at http://gcc.gnu.org/projects/ Miscellaneous ideas: Chill should use garbage collection. Convert the Chill front end to use garbage collection instead of obstacks, so that it can work again with current GCC. Suspect this should apply to gpc as well. Any guess how much time and effort it would take to make the change? Russ

1 0

Re: Log1P in DJGPP (was: Complex_Arctan)
by da Silva, Joe 11 Feb '02

11 Feb '02

You're right! Problem solved, silly mistake on my part - I forgot that the "asmname" stuff was case sensitive. <G> Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, February 11, 2002 3:16 PM > To: gpc(a)gnu.de > Subject: Re: Complex_Arctan > > da Silva, Joe wrote: > > > Hmmm ... Maybe I'm doing something wrong, but my installation of > > GPC (DJGPP) doesn't know what "Log1P" is, nor can I find it in the > > source code of the GPC unit, etc. Anyway, that's my problem, so I'll > > look into that further when I can. > > Emil posted a Pascal version of Log1P recently. And if the libc > contains it (DJGPP's does), an external declaration will do. > ------ snip ------

1 0

help regarding .ini file
by HARIKRISHNA Kocheralkota 11 Feb '02

11 Feb '02

Hello , Is there any implementation for initialization files (.INI). in GPC. Can you help us on creating one ? thanks hari

1 0

Re: Complex_Arctan
by Maurice Lombardi 11 Feb '02

11 Feb '02

Frank Heckenbach <frank(a)g-n-u.de> a dit : > da Silva, Joe wrote: > > As for my comment about "tweaked" coefficients (for platforms which > > don't already provide the function), the general rule is that if you > > truncate > > an infinite series, you need to "tweak" the coefficient values to provide > > optimum accuracy for the number of terms you are using. Simply > > truncating a series may produce inaccurate results, regardless of how > > many terms you apply. That is the general rule, and I remember it was > > certainly true with trigonometric functions. However, perhaps this effect > > is not so prevalent with the "log1p" coefficients? > > As I said, I'm no expert on numerics, and I haven't heard of this > tweaking. I suppose that what Joe has in mind is the replacement of a Taylor series by a Tchebychev polynomial. The drawback of a Taylor series is that to have a given accuracy you need only one term at the origin, but a number of terms which increases when you go farther away from the origin of the development. To have the accuracy you need at the farthest point of the development you need a polynomial of too high a degree, and you get in addition problems of roundoff errors when evaluating this polynomial. A Tchebycheff polynomial have a constant accuracy over the whole range of validity, and for a given accuracy over a given range it is of lower degree than any Taylor series based polynomial in the same range. Even better is the use of a rational function (ratio of two polynomials) as is used in the CEPHES library, for the log1p function in particular. However the degree and coefficients of this best polynomial depends both on the interval sought and on the accuracy needed. It is different e.g. for single, double, long double, and you cannot simply truncate a given series to different orders. The situation is even worse for a general purpose compiler like gpc which is aimed to work with different word sizes: 64 bits for real or double for most systems, but may be 128 bits for some. Checks would be needed to select the polynomial to use. It is probably better to let this done when possible by a libc library (or an other specialized library like CEPHES) which knows the particular system for which it is built and selects the order and coefficients of the polynomial accordingly. Gpc should give only a less optimized but the most generally valid solution. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

3 2

Re: Complex_Arctan
by da Silva, Joe 11 Feb '02

11 Feb '02

Hmmm ... Maybe I'm doing something wrong, but my installation of GPC (DJGPP) doesn't know what "Log1P" is, nor can I find it in the source code of the GPC unit, etc. Anyway, that's my problem, so I'll look into that further when I can. As for my comment about "tweaked" coefficients (for platforms which don't already provide the function), the general rule is that if you truncate an infinite series, you need to "tweak" the coefficient values to provide optimum accuracy for the number of terms you are using. Simply truncating a series may produce inaccurate results, regardless of how many terms you apply. That is the general rule, and I remember it was certainly true with trigonometric functions. However, perhaps this effect is not so prevalent with the "log1p" coefficients? If so, that's good - it means we don't have to go to the trouble of finding "tweaked/optimized" coefficients (or find out how to derive them). Unfortunately, I don't remember the name of the book in which I found the "tweaked" coefficients for trigonometric functions, nor whether this also had similar coefficients for other functions (it was quite a few years ago now ;-). Joe. > -----Original Message----- > From: Emil Jerabek [SMTP:ejer5183@artax.karlin.mff.cuni.cz] > Sent: Saturday, February 09, 2002 12:47 AM > To: gpc(a)gnu.de > Subject: Re: Complex_Arctan > > Joe wrote: > > > > > BTW, AFAICT, DJGPP does not have a Log1P function, > > so I wasn't able to verify the above anyway. I didn't know > > the values to use for the coefficients "Log1PCoefs[]", so > > I couldn't try the suggested Log1P code, either. Although > > ??? You don't have to guess the coefficients, they are initialized in the > code. > (If you don't want to rebuild the RTS just to test it (I didn't either), > move the > "to begin do" stuff into your main program, and import the GPC unit > (because of the > SplitReal function).) > > > Emil presented a power series which I assume represents > > these coefficients, I don't know whether these need to be > > "tweaked". If I understand this correctly, it is an infinite > > series. However, AFAIK, when you apply a finite version > > of such a series, you need to "tweak" it's values to get > > good accuracy (no, I don't know how to do this). > > > > I remember experimenting years ago with the power > > series for "sine" or "cosine" and being amazed at how > > a small finite "tweaked" power series was much more > > accurate than the "conventional" power series, no > > matter how many terms I calculated for it (after a while, > > the more terms you calculate, the greater the error > > you introduce). I presume the "log1p" power series > > also has this effect(?) > > > > Not sure what sort of "tweaking" you have in mind. Anyway, my Log1P > implementation > tries to use as few terms of the power series as possible, and it sums > them in reverse order. > I don't know if this is optimal, but it appeared to work with acceptable > precision: > the largest error I found was 2 ulp's when compiled without optimization, > and 1 ulp when > compiled with -O2, both on an i586. > > Emil >

2 1

doubt in Sets
by Anuradha 11 Feb '02

11 Feb '02

Hello, We have a small query regarding sets in GPC. Here is the problem : We have defined a set in a unit and my program is using the this defined set. But the compiler says that the identifier is undeclared. The following is my program and the unit. ========================= > program SETT; > uses > setsunit; > var > c : Myset; > begin > c:=[fs_auto]; > testSET(c); > end. > ============================ > unit setsunit; > interface > type > Myset = set of (fs_auto,fs_trans) ; > procedure testSET(x:Myset) > implementation > procedure testSET(x:myset); > begin > if x=[fs_auto] then > writeln('1'); > end; > end. > ================================= Can you kindly help us on this? Thanks and Regards Anuradha. -- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123

2 1

Re: Complex_Arctan
by da Silva, Joe 10 Feb '02

10 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, February 06, 2002 11:40 AM > To: jerabek(a)math.cas.cz; gpc(a)gnu.de > Subject: Re: Complex_Arctan > > Emil Jerabek wrote: > > > Frank Heckenbach wrote: > > > > > Emil Jerabek wrote: > > [...] > > > > Your change doesn't solve this, it just reduces the threshold > > > > to EpsReal^2 > 4 / MaxReal. (BTW, the original implementation in > math.pas also needs > > > > a similar condition.) > > > > > > > > Frank, do you _really_ think there are machines with such a small > MaxReal? > > > > > > It doesn't really matter what I think, does it? ;-) Actually, I > > > haven't looked at any non-IEEE FP implementation in detail. > > > > > > I'm applying Joe's patch (since it's certainly a little > > > improvement). If you have more ideas for improvement, let me know. > > > > > > Frank > > > > > > > So, here's another version :-) It should never overflow, AFAICS. > > > > ------------------------------- > > const Ln2 = 0.6931471805599453094172321214581765680755; > > var FunnyNumber: Real; > > > > function Complex_ArcTan (z: Complex): Complex; > > var x, y, a, b, c, d: Real; > > begin > > x := Abs (Re (z)); > > y := Abs (Im (z)); > > b := 1 - y; > > d := (1 + y) / 2; > > if b < 0 then d := -d; > > b := Abs (b); > > if x >= b then begin > > c := b / x; > > d := d * c - x / 2; > > if x <= FunnyNumber then > > b := Ln2 - Ln (4 * x * Sqrt (1 + Sqr (c)) / (1 + y)) / 2 > > else > > b := Log1P (2 * (y / x) / (b * c / 2 + x / 2)) / 4; > > c := 1; > > end else begin > > c := x / b; > > a := x * c / 2; > > d := d - a; > > if b <= FunnyNumber then > > b := Ln2 - Ln (4 * b * Sqrt (1 + Sqr (c)) / (1 + y)) / 2 > > else > > b := Log1P (2 * (y / b) / (b / 2 + a)) / 4 > > end; > > d := ArcTan2 (c, d) / 2; > > if Re (z) < 0 then d := -d; > > if Im (z) < 0 then b := -b; > > Complex_ArcTan := Cmplx (d, b) > > end; > > > > to begin do > > begin > > FunnyNumber := 2.1 / Sqrt (MaxReal); > > end; > > Well, this one is a little longer than the previous ones, so should > I use it? > [Joe da Silva] Probably. It looks more reliable than the previous version. The only concern I still have, is that the test program, emil9, does not test for accuracy with large "arctan" arguments (only up to 1e17). Since "tan" can produce huge results even with just real arguments, an "arctan" function must conversely provide accurate results with huge arguments. BTW, AFAICT, DJGPP does not have a Log1P function, so I wasn't able to verify the above anyway. I didn't know the values to use for the coefficients "Log1PCoefs[]", so I couldn't try the suggested Log1P code, either. Although Emil presented a power series which I assume represents these coefficients, I don't know whether these need to be "tweaked". If I understand this correctly, it is an infinite series. However, AFAIK, when you apply a finite version of such a series, you need to "tweak" it's values to get good accuracy (no, I don't know how to do this). I remember experimenting years ago with the power series for "sine" or "cosine" and being amazed at how a small finite "tweaked" power series was much more accurate than the "conventional" power series, no matter how many terms I calculated for it (after a while, the more terms you calculate, the greater the error you introduce). I presume the "log1p" power series also has this effect(?) ------ snip ------

3 2

Re: Complex_Arctan
by da Silva, Joe 10 Feb '02

10 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Emil Jerabek [SMTP:ejer5183@artax.karlin.mff.cuni.cz] > Sent: Friday, January 25, 2002 5:23 AM > To: gpc(a)gnu.de > Subject: Complex_Arctan > > Hi all, > > I've had a look at the complex arctangent function in the RTS. It turned > out that > > - it raises a runtime error or returns an infinite imaginary part on > arguments too close > to the singularities +/- i, for example > ArcTan (Cmplx (1e6 * MinReal, +/- 1)) > > - it often returns a real number when it should return something with a > small imaginary part > instead (example: ArcTan (Cmplx (1e17, 1e17)) on IA32, YMMV), and in > general, > the imaginary part of the result is very unreliable when |Im (z)| << > |Re (z)|^2 > (because it is essentially computed as `Ln (something close to 1)'; > example: > Im (Arctan (Cmplx (1000, 0.0001))) gives 9.999989726e-11 instead of > 9.999990000e-11, > again this is machine-dependent) > > The following patch to p/rts/math.pas solves these problems (I hope it > doesn't introduce > others). > > ------------------------------ > > function Log1P (x: Real): Real; asmname 'log1p'; > > function Complex_Arctan (z: Complex): Complex; > const Ln2 = 0.6931471805599453094172321214581765680755; > var b, c, d: Real; > begin > c := Sqr (Re (z)); > b := 1 - Abs (Im (z)); > d := ((1 + Abs (Im (z))) * b - c) / 2; > [Joe da Silva] I wonder, would it be better to use the following instead, to reduce problems with overflow for large values (magnitude) of Re(z) and/or Im(z)? : c := Re(z) * 0.5 * Re(z); b := 1 - Abs(Im(z)); d := (1 + Abs(Im(z))) * 0.5 * b - c; Also, as a general question, is division more expensive than multiplication, or does the complier's optimization take care of such matters anyway? > if Abs (b) > Abs (Re (z)) then > b := Log1P (4 * (Abs (Im (z)) / b) / (b + Re (z) * (Re (z) / b))) / 4 > else if c <= MinReal then > b := (Ln2 - Ln (Abs (Re (z)))) / 2 > else > b := Log1P (4 * (Abs (Im (z)) / Re (z)) / (b * (b / Re (z)) + Re (z))) > / 4; > if Im (z) < 0 then b := -b; > Complex_Arctan := Cmplx (ArcTan2 (Re (z), d) / 2, b) > end; > ------------------------ > > > Emil Jerabek >

3 8

How to Cross Compile ?
by gerdunne＠eircom.net 08 Feb '02

08 Feb '02

Hi Can someone please tell me how do I use 'AS' utility to cross compile a Pascal prog. to the MC68000 (S format..) I've read the html file on 'AS' and tried out the -m68000 switch but i must be doing something wrong? I'm using 'GPC. Regards Ger.

2 1

Re: Constant Expressions (was: Complex_Arctan)
by da Silva, Joe 07 Feb '02

07 Feb '02

Yes, the language in both standards is horrible! :-/ AFAICS, all that stuff about the "defining point" for functions is probably just saying that you can use predefined functions only (excluding those that don't have a constant result) and not functions that you define within your program. Joe. > -----Original Message----- > From: Emil Jerabek [SMTP:ejer5183@artax.karlin.mff.cuni.cz] > Sent: Friday, February 08, 2002 4:33 AM > To: gpc(a)gnu.de > Subject: Re: Constant Expressions (was: Complex_Arctan) > > Joe wrote: > > > Please see below ... > > > > Joe. ( Feeling a bit better :-) > > > > Good news :-) > > > > > Well, actually the ISO-10206 standard (since the topic was complex > > maths, that is the applicable standard) *does* allow function calls > > in constant expressions. See sections 6.3.1, 6.3.2, 6.8.2. :-) > > > > There are some restrictions of course, mainly to ensure that the > > constant expression is indeed constant. AFAIK, only pre-defined > > functions are allowed (although I haven't looked too closely at > > that). > > > > Example from section 6.3.2 : > > > > const > > ............... > > pi = 4 * arctan(1); > > ............... > > > > You are probably right. I got somewhat confused by the language > of the standard ;-) > > From section 6.8.2: > > "...An expression shall be designated nonvarying if it does not > contain the following > ... > c) an applied occurrence of an identifier as a function-identifier > that has a defining-point contained by the program-block or that denotes > one of the required functions eof or eoln. > ..." > > Section 6.2.2.1: > > "Each identifier or label contained by the program-block shall have > a defining-point, with the exception of the identifier > of a program-heading (see 6.12)." > > From section 6.2.2.10: > > "Required identifiers that denote the required values, types, schemata, > procedures, and functions shall be used as if their defining-points > have a region enclosing the program (see 6.1.3, 6.4.2.2, 6.4.3.4, > 6.4.3.6, 6.4.3.3.3, 6.7.5, 6.7.6, and 6.10). > ..." > > > So, do those required identifiers have a defining-point or do they not? > > > Emil Jerabek

1 0

Re: Constant Expressions (was: Complex_Arctan)
by da Silva, Joe 07 Feb '02

07 Feb '02

Please see below ... Joe. ( Feeling a bit better :-) > -----Original Message----- > From: Emil Jerabek [SMTP:ejer5183@artax.karlin.mff.cuni.cz] > Sent: Wednesday, February 06, 2002 4:39 AM > To: gpc(a)gnu.de > Subject: Re: Complex_Arctan > > Frank Heckenbach wrote: > > > Emil Jerabek wrote: > [...] > > > Your change doesn't solve this, it just reduces the threshold > > > to EpsReal^2 > 4 / MaxReal. (BTW, the original implementation in > math.pas also needs > > > a similar condition.) > > > > > > Frank, do you _really_ think there are machines with such a small > MaxReal? > > > > It doesn't really matter what I think, does it? ;-) Actually, I > > haven't looked at any non-IEEE FP implementation in detail. > > > > I'm applying Joe's patch (since it's certainly a little > > improvement). If you have more ideas for improvement, let me know. > > > > Frank > > > > So, here's another version :-) It should never overflow, AFAICS. > > ------------------------------- > const Ln2 = 0.6931471805599453094172321214581765680755; > var FunnyNumber: Real; > > function Complex_ArcTan (z: Complex): Complex; > var x, y, a, b, c, d: Real; > begin > x := Abs (Re (z)); > y := Abs (Im (z)); > b := 1 - y; > d := (1 + y) / 2; > if b < 0 then d := -d; > b := Abs (b); > if x >= b then begin > c := b / x; > d := d * c - x / 2; > if x <= FunnyNumber then > b := Ln2 - Ln (4 * x * Sqrt (1 + Sqr (c)) / (1 + y)) / 2 > else > b := Log1P (2 * (y / x) / (b * c / 2 + x / 2)) / 4; > c := 1; > end else begin > c := x / b; > a := x * c / 2; > d := d - a; > if b <= FunnyNumber then > b := Ln2 - Ln (4 * b * Sqrt (1 + Sqr (c)) / (1 + y)) / 2 > else > b := Log1P (2 * (y / b) / (b / 2 + a)) / 4 > end; > d := ArcTan2 (c, d) / 2; > if Re (z) < 0 then d := -d; > if Im (z) < 0 then b := -b; > Complex_ArcTan := Cmplx (d, b) > end; > > to begin do > begin > FunnyNumber := 2.1 / Sqrt (MaxReal); > end; > ------------------------------------ > > > I encountered a compiler bug during testing :-( > Strictly speaking, the Standard doesn't allow function calls in constant > expressions, > but I expect the compiler would reject it if it were not supposed to work. > [Joe da Silva] Well, actually the ISO-10206 standard (since the topic was complex maths, that is the applicable standard) *does* allow function calls in constant expressions. See sections 6.3.1, 6.3.2, 6.8.2. :-) There are some restrictions of course, mainly to ensure that the constant expression is indeed constant. AFAIK, only pre-defined functions are allowed (although I haven't looked too closely at that). Example from section 6.3.2 : const ............... pi = 4 * arctan(1); ............... > [pas]% cat exprconst.pas > program Foo (Output); > > const > Bar = 1 / Sqrt (16); > ------ snip ------

2 1

business marketing
by jjmkt2002160715＠yahoo.com 06 Feb '02

06 Feb '02

1 0

pre-registration instructions (5598IZYG0-776@12)
by dot-biz-registrar586805＠mail.com 06 Feb '02

06 Feb '02

PUBLIC ANNOUNCEMENT: The three new Internet domain extension formats - .NAME .BIZ .INFO . have now been introduced to the Internet. However, many users are still unfamiliar with how these names work. The following are some tips on what these names are and where you can register. ############### .NAME Extension ############### - Currently in pre-registration stage. - Designed for personal use. - 2-level registration format (eg. FirstName.LastName.name) - Used for web URL (www.FirstName.Lastname.name) or email (FirstName(a)LastName.name) - Registry accepts submissions once a week, first come first serve basis. - Where to pre-register: http://www.NamesForEveryone.com. ############## .BIZ Extension ############## - Currently operational. - Designed for business use. - No registration restrictions. - Works just like a .COM name - Where to register: http://www.DotBizToday.com ############### .INFO Extension ############### - Currently operational. - Designed for information on products / organizations - No registration restrictions - Works just like a .COM name - Where to register: http://www.InfoGrab.com Over a million names of these new extensions have already been registered. Therefore, if your name is still available, please secure it immediately to avoid possible disputes. Yours truly, Domain Administrator [6760OPhl4-370lVTF8465QSdy0-002rIlB3365Cpyv7-964F@45]

1 0

Stop paying TOO MUCH for Life Insurance!
by rww1966426287＠mailcity.com 06 Feb '02

06 Feb '02

1 0

[±¤°í] ³î¶ó¿î ¼ºÀåÈ£¸£¸óÀÇ ºñ¹Ð!!
by ¾ÆÇªÁö¸¶ 06 Feb '02

06 Feb '02

1 0

Ultimate HGH: Make you look and feel 20 YEARS YOUNGER!
by dave 06 Feb '02

06 Feb '02

[Attachment denied by the firewall. Please contact the network administrator if assistance is needed (type "(none)", filename "(none)")]

1 0

NO MORE SPEEDING TICKETS!!!
by Jimmy700607＠earthlink.net 06 Feb '02

06 Feb '02

1 0

Re: Complex_Arctan
by da Silva, Joe 06 Feb '02

06 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, February 06, 2002 12:25 PM > To: gpc(a)gnu.de > Subject: Re: Complex_Arctan > > da Silva, Joe wrote: > > > > function Complex_ArcTan (z: Complex): Complex; > > > var x, y, a, b, c, d: Real; > > > begin > > > x := Abs (Re (z)); > > > y := Abs (Im (z)); > > > b := 1 - y; > > > d := (1 + y) / 2; > > > if b < 0 then d := -d; > > > b := Abs (b); > > > if x >= b then begin > > > c := b / x; > > > d := d * c - x / 2; > > > > > [Joe da Silva] > > > > Perhaps it's impossible to avoid overflow under all conditions? > > In this case, if Im(z) is large and Re(z) is small, then "d" will > > overflow here because "c" is now large too. :-/ > > But that's the `x >= b' case. :-) > [Joe da Silva] Oops! Sorry, I missed that - I'm coming down with the 'flu, so my head isn't too clear. :-( > > > It seems that even the wheel was invented in San > > > Diego :-) > > > > > [Joe da Silva] > > > > No, it was invented in Australia! See the following! : <G> > > http://www.theage.com.au/news/state/2001/07/02/FFX0ADFPLOC.html > > Nice. I'm surprised, though, that this didn't happen in the US > first ... ;-) > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Complex_Arctan
by da Silva, Joe 06 Feb '02

06 Feb '02

Please see below ... Joe. > -----Original Message----- > From: Emil Jerabek [SMTP:ejer5183@artax.karlin.mff.cuni.cz] > Sent: Wednesday, February 06, 2002 4:39 AM > To: gpc(a)gnu.de > Subject: Re: Complex_Arctan > > Frank Heckenbach wrote: > > > Emil Jerabek wrote: > [...] > > > Your change doesn't solve this, it just reduces the threshold > > > to EpsReal^2 > 4 / MaxReal. (BTW, the original implementation in > math.pas also needs > > > a similar condition.) > > > > > > Frank, do you _really_ think there are machines with such a small > MaxReal? > > > > It doesn't really matter what I think, does it? ;-) Actually, I > > haven't looked at any non-IEEE FP implementation in detail. > > > > I'm applying Joe's patch (since it's certainly a little > > improvement). If you have more ideas for improvement, let me know. > > > > Frank > > > > So, here's another version :-) It should never overflow, AFAICS. > > ------------------------------- > const Ln2 = 0.6931471805599453094172321214581765680755; > var FunnyNumber: Real; > > function Complex_ArcTan (z: Complex): Complex; > var x, y, a, b, c, d: Real; > begin > x := Abs (Re (z)); > y := Abs (Im (z)); > b := 1 - y; > d := (1 + y) / 2; > if b < 0 then d := -d; > b := Abs (b); > if x >= b then begin > c := b / x; > d := d * c - x / 2; > [Joe da Silva] Perhaps it's impossible to avoid overflow under all conditions? In this case, if Im(z) is large and Re(z) is small, then "d" will overflow here because "c" is now large too. :-/ > if x <= FunnyNumber then > b := Ln2 - Ln (4 * x * Sqrt (1 + Sqr (c)) / (1 + y)) / 2 > else > b := Log1P (2 * (y / x) / (b * c / 2 + x / 2)) / 4; > c := 1; > end else begin > c := x / b; > a := x * c / 2; > d := d - a; > if b <= FunnyNumber then > b := Ln2 - Ln (4 * b * Sqrt (1 + Sqr (c)) / (1 + y)) / 2 > else > b := Log1P (2 * (y / b) / (b / 2 + a)) / 4 > end; > d := ArcTan2 (c, d) / 2; > if Re (z) < 0 then d := -d; > if Im (z) < 0 then b := -b; > Complex_ArcTan := Cmplx (d, b) > end; > > to begin do > begin > FunnyNumber := 2.1 / Sqrt (MaxReal); > end; > ------------------------------------ > > > I encountered a compiler bug during testing :-( > Strictly speaking, the Standard doesn't allow function calls in constant > expressions, > but I expect the compiler would reject it if it were not supposed to work. > > [pas]% cat exprconst.pas > program Foo (Output); > > const > Bar = 1 / Sqrt (16); > > var > OK: Boolean value True; > S: String (30); > > procedure Baz (X: Integer); > var > Y: Real; > E: Integer; > begin > if Odd (X) then WriteStr (S, Bar) > else WriteStr (S, Bar); > Val (S, Y, E); > if (E <> 0) or (Y <> 0.25) then begin > WriteLn ('Failed ', X, ': ', S); > OK := False > end > end; > > begin > Baz (0); > Baz (1); > Baz (2); > Baz (3); > if OK then WriteLn ('OK') > end. > [pas]% gpc exprconst.pas > [pas]% ./a.out > Failed 0: 4.609351182172047e-01 > [pas]% gpc -O2 exprconst.pas > [pas]% ./a.out > Failed 0: Inf > Failed 2: Inf > > > I also wondered if the compiler catches this as a violation of the > standard when > compiled with `--extended-pascal' or `-pedantic'. It compiled happily with > the former > (when I replaced `Val' with `ReadStr', of course), but the result with > `-pedantic' was > somewhat surprising. It seems that even the wheel was invented in San > Diego :-) > [Joe da Silva] No, it was invented in Australia! See the following! : <G> http://www.theage.com.au/news/state/2001/07/02/FFX0ADFPLOC.html > (Apart from that, shouldn't it produce warnings rather than errors?) > > > [pas]% gpc -pedantic exprconst.pas > exprconst.pas:4: `SqRt' is a UCSD Pascal extension > exprconst.pas:7: type/var initialization is an ISO 10206 Extended Pascal > extension > exprconst.pas:8: UCSD and Borland Pascal want string capacity in brackets > exprconst.pas:8: ISO 7185 Pascal does not have the `String' type > exprconst.pas: In procedure `Baz': > exprconst.pas:15: `Odd' is a UCSD Pascal extension > exprconst.pas:15: `WriteStr' is an ISO 10206 Extended Pascal extension > exprconst.pas:15: `WriteStr' is an ISO 10206 Extended Pascal extension > exprconst.pas:16: `WriteStr' is an ISO 10206 Extended Pascal extension > exprconst.pas:16: `WriteStr' is an ISO 10206 Extended Pascal extension > exprconst.pas:17: `Val' is a Borland Pascal extension > exprconst.pas:17: `Val' is a Borland Pascal extension > exprconst.pas:19: `WriteLn' is a UCSD Pascal extension > exprconst.pas: In main program: > exprconst.pas:29: `WriteLn' is a UCSD Pascal extension > [Joe da Silva] Perhaps I should consult the manual first, but what's this "-pedantic" option for? "SqRt", "Odd" and "WriteLn" are all standard identifiers in ISO 7185, so why are they listed as "UCSD extensions"? > Emil Jerabek

2 1

(no subject)
by 8HlbuD＠tpts6.seed.net.tw 05 Feb '02

05 Feb '02

±ÀÂË§AÌ€@Ó€£¿ùªººô¯ž---ŒÆŠìµø³¥ ŠUºØŒÆŠì¬ÛŸ÷ªºµû€ñ»Pºô€Íªº€¬°Ê°Qœ×,¥i¥H°µ¬°ÁÊ¶R«eªº°ÑŠÒ. ÁÙŽ£šÑ€F³\ŠhšR¬~ŒÆŠì·Ó€ùªºªù¥«€Îºô¯ž,¥Ø«e4x6€@±i¥un6€ž! §ó¯S§Oªº¬O,ÁÙŠ³°OŸÐ¥dªº¥X¯²,§Ú¹LŠ~¥X°êŽN¥ŽºâŠV¥LÌ¯²°OŸÐ¥d,ŽN€£¥Î§âNotebookŠª¥X¥h! www.dcview.com.tw

1 0

Special Opportunity
by saille55＠hotmail.com 05 Feb '02

05 Feb '02

Special Opportunity Software to Copy Any DVD's And Own Five Money Making Web Sites Software For $34.95 DOWNLOAD NOW!!!!! Order Both Instant Internet Empire Five-money-making-Sites- http://www.jlwconsulting.org DVD Software for only $34.95 (Instant Download) http://jlwconsu@64.239.47.155/copyany.htm To get this special price you must order from this page Click Here or cut and paste this link into your web browser. https://www.paypal.com/xclick/business=jlw@jlwconsulting.org&item _name=DVD+Software+&+Wealth+Empire+Sites&item_number=dvd-EW&amoun t=34.95&no_shipping=1&return=http:/jlwconsu@64.239.47.155/thankyo udvdandei.htm&cancel_return=http:/jlwconsulting You can also Order each product separately from thier web page for $24.95 each. We believe that you are someone who is looking for a way to change your life financially with a legitimate opportunity from home and are tired of internet scams. If not, please accept our apologies and send an email to remove(a)jlwconsulting.org Thank you for your co-operation

1 0

Re: GPC test suite (was: egcs-19980517 and gpc-980511)
by mike stump 05 Feb '02

05 Feb '02

> From: levi(a)localhost.nc3a.nato.int > To: levi(a)localhost.nc3a.nato.int > Date: Sat, 30 May 1998 11:19:43 +0200 (MEST) > I conclude that DejaGNU currently does not seem to be able to do all > tests necessary for testing GNU Pascal. Then you must not have understood dejagnu yet. Because you can do whatever you want within the confines of dejagnu, you are not limited in any way. This lack of any limitation translates into you can do anything you want. I think you may have meant that you cannot reuse the existing gcc or g++ testsuite framework wholesale with no changes.

2 1

gcc 2.96.2 and 3.0.3
by Guillaume Rousse 04 Feb '02

04 Feb '02

Hi all. I'm trying to compile latest gpc 20011222 snapshot for Mandrake, which ships either gcc-2.96 and gcc-3.03. Latest message on this topic (early december) says gpc is not supported on these versions. Is this still true ? -- Guillaume Rousse <rousse(a)ccr.jussieu.fr> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

6 23

SOMETHING YOU DON'T KNOW (8968oGyT7-168LDvP2317hz@22)
by beginner810042＠linux.org 04 Feb '02

04 Feb '02

Hello ! I have been receiving emails saying that I'm contributing to the "moral decay of society" by selling the Banned CD. That may be, but I feel strongly that you have a right to benefit from this hard-to-find information. So I am giving you ONE LAST CHANCE to order the Banned CD! With this powerful CD, you will be able to investigate your friends, enemies and lovers in just minutes using the Internet. You can track down old flames from college, or you can dig up some dirt on your boss to make sure you get that next promotion! Or maybe you want a fake diploma to hang on your bedroom wall. You'll find addresses for companies that make these diplomas on the Banned CD. Need to disappear fast and never look back? No problem! Using the Banned CD, you will learn how to build a completely new identity. Obviously, the Powers That Be don't want you to have the Banned CD. They have threatened me with lawsuits, fines, and even imprisonment unless I stop selling it immediately. But I feel that YOU have a Constitutional right to access this type of information, and I can't be intimidated. Uncle Sam and your creditors are horrified that I am still selling this product! There must be a price on my head! Why are they so upset? Because this CD gives you freedom. And you can't buy freedom at your local Walmart. You will have the freedom to avoid creditors, judgments, lawsuits, IRS tax collectors, criminal indictments, your greedy ex-wife or ex-husband, and MUCH more! Please Click the URL for the Detail! http://%65%72%65%35%2Evt%39%2E%63%6F%2E%75%6B or http://s%70%79s%70y.a%73%6Bu%2E%74%6F or http://%74%72%61ve%6C3%343%35%2Eg%6F%2E%74%6F You are receiving this special offer because you have provided permission to receive third party email communications regarding special online promotions or offers. We strongly oppose the use of SPAM email and do not want to send our mailings to anyone who does not wish to receive them. If you do not wish to receive any further messages from Travel Easy. To Be Removed From Our List, smart90(a)email.com [4794cUoG5-447yTLD0697vPhz4-058tLDX0109Phbt3-558@44]

1 0

Leasing Pays
by hotticket＠discountcapital.net 04 Feb '02

04 Feb '02

1 0

<±¤°í>Æ¯º¸
by ¹Ì·¡¿¡´Â 03 Feb '02

03 Feb '02

1 0

Order adult DVDs from home!!! 25254
by mellissa36712＠yahoo.com 02 Feb '02

02 Feb '02

Great Adult Video and Toy Store with over 3000+ Products online Are you looking for Vibrators, Penis Extenstions, Lingerie, Love Dolls, Movies or Dvd's, We have them all and more. 100% Discreet Shipping, and Billing. Secure Online Ordering, Fast Delivery. http://www.dvdsanddildos.com Must be 18 Years of age or older to access this site. To be removed from this list, simply hit reply and put REMOVE in the subject line

1 0

Need to Market your Service or Product?
by WeServe＠hotmail.com 02 Feb '02

02 Feb '02

1 0

Re: FREE PORN!^ jrfAhnsddnvfsxi0qgw...jrfAhpy0gg...
by marrisa69＠ed.ac.uk 02 Feb '02

02 Feb '02

FREE PORN PASSWORDS CLICK ON THE LINK BELOW NOW!! http://www.innovative-e-solutions.com/tuu ALL THE FREE PORN YOU CAN HANDLE! CHOOSE FROM 8 GREAT SITES ALL FOR FREE! http://www.innovative-e-solutions.com/tuu You have received this email because you subscribed to our newsletter if you wish to unsubscribe hit reply and you will be removed immediately!

1 0

help with CygWin & gcc 2.95.3-5
by Ken Linder (KC7RAD) 01 Feb '02

01 Feb '02

Hi All, I am trying to compile gpc-20011202 on a new cygwin install with gcc ver 2.95.3-5 Does anyone have the diffs for this code tree? Should the diffs for 2.95.3 work? I tried running mkdiff with that gcc ver but it errors out. When I try compiling gpc with 2.95.2, the patch/configure works fine but the actual compile generates a compiler error and prompts me to contact GNU and submit a bug! Would this matter if I am trying to compile 2.95.2 with the gcc2.95.3-5 that comes with cygwin? OK, I have confused everyone probably :-) Short answer... How do I run/compile gpc with cygwin with the above gcc ver? Thanks! Ken Linder KC7RAD

2 1

ADV:Hollywood dirt from internet-soap.com
by hollywood_dirt＠internet-soap.com 01 Feb '02

01 Feb '02

tinseltrash / adj / 1. a person who's achieved great wealth, fame and/or power in the field(s) of film, television and/or music, who remains unable or unwilling to improve upon the bad conduct and/or low morals imparted upon them in their youth 2. something you throw away after Christmas ------------ Hello, my name is Jeff Abugov. I have been a professional Hollywood writer for fourteen years -- you can check me out because my resume is all over the Internet. I've written for "Cheers," "Golden Girls," and "My Two Dads." I've written and produced "Roseanne," consulted on "Caroline in the City," executive-produced "Roc" and "Grace Under Fire." I wrote and directed an independent feature film called "The Mating Habits of the Earthbound Human" which you may have never seen, and you should, but that's not the point. The point is I know what I'm talking about when it comes to show business. So, I'd like to tell you a story about a good friend of mine, one of the nicest guys I know, who simply got a bum rap in the press. Yes, he deserved it, because he screwed us all, but as I see it, he had no choice. You can decide for yourself when you hear his story. Today's portion of this internet soap opera is free. If you like it, chapters 2 through 5 will be free as well. After that, all I ask is a dollar a chapter because I have to make a living the same way you do. It's just a buck, for crying out loud. But don't worry about that now. Just read, and enjoy. "TINSELTRASH" by Jeff Abugov Chapter One "The Invitation" A very good friend of mine was the biggest star on TV about ten years ago. I can't tell you his real name because the story that will follow is perverse and horrible, so to protect him and his family I'll call him "Robby Rockman." I'll say Robby is six-foot tall with a slender build, blue eyes, reddish-brown hair and freckles, but I might be making that up. Robby was the kind of guy who would pick up homeless people and then treat them to dinner at an all-night diner. With no fanfare or publicity, he'd pay their stay in a cheap motel until he found them a job, then he'd move on to his next project. Sometimes it was rescuing puppies from the pound, other times it was lending money to down-and-out actor friends, or simply coaching his little son's t-ball team. When there was a problem on his sitcom set, it was Robby who smoothed over the wounded egos and got everyone back on track. There wasn't a benefit he turned down, a charity he refused, or a secret he couldn't keep. To know this guy was to have a lifelong friend you could trust forever. Robby received several Emmy nominations for his sitcom which I'll call "School, Sweet School," of which he won two. He received four Golden Globe nominations and won one. He should've won an Oscar because his film performance was brilliant even though the movie tanked. It deserved to tank, it wasn't good, but that's not the point. You know who I'm talking about. If you're young, you grew up with him as a role model. If you're older, you watched him with your kids. He brilliantly played a nice guy, I'll call the character "Mr. Bell," the loveable teacher at "School, Sweet School," even though he didn't really play a teacher and it wasn't really a show about a high school. Everyone thought, including me, that the only reason Robby was so great at playing a nice guy was that he WAS such a nice guy. The truth is, he was a brilliant actor who could play a jerk as well as anyone. And that, my hopeful readers, is how he reached his legendary status. He didn't do it on the big screen or the little screen, but in the press, the tabloids, and in his best performances, on the nightly news. This is the downfall, the comeback, and the personal destruction of the one we'll call Robby Rockman. *** There are many places to begin Robby's story, but I'll choose the night of his agent's annual Fourth of July bash because that was the night Robby decided to alter the entire course of his life. It had been eight years since Robby taped the final episode of "School, Sweet, School." Six years since his brilliant performance in the dull-as-hell courtroom drama movie, five years since his big budget action picture flopped, four years since he worked at all, and roughly six months since his agent returned one of his phone calls. His agent, whom I'll call Artie Eichman, was five-foot-eight, with a muscular build due to a personal trainer and a full mane of sandy-brown hair due to cosmetic surgery. He signed Robby when both of them were nothing, and took him from good reviews in an Off-Broadway flop to the lead in "School, Sweet School." During the run of the show, Artie used the leverage from representing Robby to make himself one of the most powerful agents at his mammoth agency. Let's call it "the Mammoth Agency." Today, Artie is among those who run this town, and he wouldn't have had any of it without Robby's talent and loyalty, but he still sees no reason to return his calls. So when Robby got Artie's invitation out of the mail, he didn't even have to open it to know that he was on his way back. Artie had been having these parties since the third year of "School, Sweet School," and he always invited only the top people in Hollywood, and only his working clients. Robby was not working but clearly he was about to, and he had a pretty good idea of what the role would be. For weeks, Robby had been begging Artie - actually Artie's secretary because Artie wouldn't return his calls -- for an audition with a certain well-known director, let's call him Anthony dePaulo. dePaulo, you know him, too, is one of America's greatest directors. From the Spielberg-Lucas generation, his movies may never have made as much money as theirs did, but his were better. That's my opinion and nothing more, but I'd bet you agree. dePaulo had helped mediocre actors become great, and had helped great actors carve the character for which they'd be forever remembered. He had made stars out of nothing, and turned has-beens into icons. With an actor as brilliant as Robby, the sky was the limit, and everybody knew it. Robby knew that the invitation could only mean that Artie had somehow gotten him the part in dePaulo's new film. The rest was up to him, and he knew he could pull it off. Especially with a director as brilliant as dePaulo! Something you should know about Robby is that he always hated Hollywood parties. At the peak of his popularity, he couldn't stand the sycophants sucking up to him so they could tell the other sycophants he was their pal. Since his decline, these same sycophants ignored him like the plague, which Robby hated even more. Robby's wife, whom we'll call Trudy Rockman, was a beautiful yet petite waif of a woman with straight, jet black hair to her mid-back and zero streaks of red. If you ask me, it would've looked better with a little bit of red, but Trudy didn't want to "go Hollywood." Trudy was just one year younger than Robby, and they had been high school sweethearts. She had stuck by Robby through the lean years in New York, the insanity of superstardom, and the dark years that followed. Everyone who knew them agreed that their marriage was as good as one could get in Hollywood. Trudy knew how Robby felt about parties. She also knew he shouldn't go to this one because Artie never meant for him to be invited. Artie believed unemployed clients made him look bad, and Trudy could only deduce that Artie's secretary had sent out the invitation on her own. Why the secretary had done that Trudy had no idea, and I'll get to it later. Still, Trudy knew that Robby was not welcome at the party. The reason she knew this was because she was secretly having an affair with Artie. No one was aware of it at the time of course, including me. Like I said, we all thought Robby and Trudy had the perfect marriage. But after watching her husband grow sadder and sadder with each passing day for eight years of his vanishing career, Trudy finally couldn't take it anymore. The least Artie could do is return one of her husband's calls, she felt. So, a couple of months before the bash, she got into her red Cherokee and drove to the Mammoth Agency building in Beverly Hills to confront him. Artie greeted Trudy with warmth, humor, and friendliness. Instead of denying her accusations, he explained them away. "I serve him better by speaking to studio heads on his behalf than using the same time to tell him that I have nothing to tell him," was one of his defenses. "He already knows no one will hire him, but when I tell him he just gets more depressed," was another. "I'd be nothing without Robby," he'd begin my personal favorite with total sincerity. "It pains me that you'd think I'd actually give up on him." Trudy pointed out the fallacies of each of Artie's defenses, and Artie countered brilliantly. It wasn't that she believed anything he said, but the repartee, the give-and-take, the warmth and the smile was something she hadn't had for a very long time. Then Nicholson called, and Artie had to go. He had been trying to steal Nicholson for months, he explained to Trudy as if it were a good thing, then told her he wanted to continue their conversation because he wanted to make sure Robby was happy. If he was making matters worse, he went on, he wanted to know how to correct it. So he asked her out to dinner. She, naive little thing that she was, suggested it would be best if Robby didn't know about it since it would embarrass him to learn that his wife had more impact on his agent than he did. Artie made some vague comment about honesty, then quickly went along with the plan. Their first dinner was a great success and they spent the entire time talking about Robby. No true solutions were reached, but Trudy had a wonderful time with the gregarious man, once again eating in an L.A. hotspot, once again being treated like Hollywood royalty. So they had another dinner, and another. Conversations about Robby had long vanished, and Artie spent much of the time talking about how his first wife had taken half his money, and how his second wife was now trying to take the other half. The rest of the time he spent telling Trudy how absolutely beautiful she was. Trudy kind of knew what Artie was after for she wasn't THAT naive. They had known each other for a very long time by then and she had seen him talk his talk with many other women, married or not. So the fact that he was now trying to woo the wife of the man to whom he owed so much may have repelled her, but it did not surprise her. On the other hand, Artie was not an unattractive man. She had never been with a muscle-guy before, and had often secretly fantasized about being with him. Of course, she had no intention of acting on it. Until he got her drunk. Because she let him. Trudy had never been with anyone other than Robby, and Artie was very well endowed. It wasn't that he was better in bed than Robby that got her to climax. It wasn't that she loved or even liked Artie. She knew Artie for the sleaze he was, and it made it all the more exciting for her. It was raw sex, it was wrong, and as the two sweated away on the rooftop veranda of Artie's Hollywood Hills home with the L.A. skyline twinkling in her half-opened eyes, she knew she would keep coming back for more. Trudy had never done a wrong thing in her life and, in her mid-thirties, the lifelong wife of her husband -- this was the only way she could see of being her own person. The truly sad part is that for years Robby had been attracted to Artie's second wife, Adona Eichman, young, beautiful, thin with large, expensive breasts -- the trophy Artie received for representing Robby. Adona had had a crush on Robby since she was a kid, and would've given herself to him in a second. She had given him all the signals, but Robby simply wouldn't go for it. It wasn't because of Artie and it was barely because of Trudy. As far as Robby was concerned, he was a married man and that was that. So when Robby got the invitation from Artie's assistant, Trudy knew some kind of slip-up had occurred because Artie had already told her Robby wasn't on the list. But Robby was so excited thinking that he got the part in a Tony dePaulo film that Trudy didn't know what to say. "Be realistic, he wouldn't invite YOU," she knew she couldn't say. "He only invites his working clients, and you haven't worked in years," she also knew was wrong. So, instead, she dropped casual hints. "Don't you just hate these full-of-it parties?" she asked him. "Sure, but I'm in no position to turn it down," he replied. "I'm sure whatever Artie has going for you will hold if we don't go to this party." "He wants me there," Robby answered. "I'm sure he has his reasons." "Why don't you call him and find out what the reasons are? Maybe they're not as important as you think." "Even if they're not, it doesn't matter. He wants me to come and I've always been a team player. I can't change now." In the end, Trudy figured there wouldn't be any harm in attending. They'd have a bad time, Robby would grow more depressed, but in the end it wouldn't change anything. She couldn't have been more wrong. It was at that party that Robby made the very conscious, calculated decision that would ultimately cause his life to spiral completely out of control! And the drugs, sex and other scandals in which he'd be involved were nothing but a by-product of that one vice-laden decision. *** Up Next: "A Hollywood Bash" *** The main characters in this e-novel are fictional and are not intended to portray or resemble any actual individuals, whether living or dead (except for Jeff Abugov who is a real screenwriter, director and producer.) Although certain real people and companies are mentioned in this e-novel, all of the events are fictional and are not intended to portray or resemble any actual events. Copyright 2001 Tinseltrash, Inc. ------------ To receive Chapter 2, "A Hollywood Bash", for FREE, click mailto:chapter2@internet-soap.com if highlighted. AOL users may have to use the following <a href="mailto:chapter2@internet-soap.com">link</a> if the previous information is not highlighted. If none of the automatic links work send email to chapter2(a)internet-soap.com and it will be sent to you automatically. To be removed from this mailing list, send email to remove(a)internet-soap.com and this email address will be removed.

1 0

Mails
by Miklos Cserzo 01 Feb '02

01 Feb '02

Hi Folks, I am getting a huuuuuge amount of mails from the list recently. They are old stuff mostly. Is anyone around getting those too? What is this? Cheers, miklos

4 3

Files
by berend＠beard.nest.nl 01 Feb '02

01 Feb '02

* Moved (from: gpc) by Berend de Boer using timEd 1.10.b3+. Peter Gerwinski wrote in a message to Berend de Boer: PG> I tried to use Extended Pascal "binding" to assign a file PG> variable to an external -- existing -- file. I just copied PG> the "Assign" pro- cedure by Berend as published in PG> borland2ep.doc. It does not always work: I often get a PG> runtime error saying that the file did not exist. If you can repeat it, compile with another Extended Pascal compiler, for example Prospero's one. If that fails too, there is really something wrong with the code. But I suspect gpc. You're using which OS? Groetjes, Berend (-: fido: 2:281/527.23 email: berend(a)beard.nest.nl

4 3

operators pow and **
by Maurice Lombardi 01 Feb '02

01 Feb '02

Hi all, It seems that operators pow and ** cannot be redefined in gpc. Is that expected ? I work with djgpp / w98 dos box (should be irrelevant I think) Thanks Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

4 4

Re: Mingw [was GPC newbie]
by gerdunne＠eircom.net 31 Jan '02

31 Jan '02

Hi chief. I carried out all your instructions. Downloaded MinGW-1.1.tar. I got a bit further but now I have a new problem. When I 'GPC *.pas -o *.exe ' I get 'ld: cannot find -lgpc' and when I do the GPC.EXE --verbose I get the following:- C:\>gpc.exe --verbose Using builtin specs. gpc version 19990118, based on egcs-2.91.60 19981201 (egcs-1.1.1 release) ld \lib\crt1.o -L\mingw32\lib -lgpc -lcrtdll -lmingw32 -lgcc -lmoldname -lcrtdl l -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lcrtdll ld: cannot find -lgpc C:\> My autoexec.bat Path is pointing at all the directories Any help would be appreciated. Regards Ger. african_chief(a)bigfoot.com wrote: < < BTW: you can get the full Mingw release from this URL: < http://sourceforge.net/project/showfiles.php?group_id=2435 < < < Best regards, The Chief < --------- < Prof. Abimbola Olowofoyeku (The African Chief) < Email: African_Chief(a)bigfoot.com < http://www.bigfoot.com/~african_chief/ <

2 1

Re: How to Handle Variable Names in Both C and Pascal
by Gloria, Jing 30 Jan '02

30 Jan '02

Chuck F, thanks for the prompt response and for the utility that you sent. I will give it a try. I will have to FTP my files from the Solaris system to my desktop PC. Everyone, I apologize for any inconvenience that HTML in my mail may cause. I am using Microsoft Outlook and I have selected Plain Text format when composing my e-mail. I do not know why it is not turning off HTML. As I am typing out this e-mail, I see that it says "Plain Text" on the header. I hope HTML is turned off now. Regards, Jing

2 1

How to Handle Variable Names in Both C and Pascal
by Gloria, Jing 30 Jan '02

30 Jan '02

I would appreciate getting suggestions on how to approach the following situation. As mentioned in previous messages to this group, I am porting code from SPARC/Sun_OS/Sun_compilers (development and runtime) to Intel/Solaris_7/GNU_compilers (also development and runtime). Source code are in C, C++, and Pascal. One requirement is to keep the source code so that it can be built in either platforms. I have used #ifdef/#else/#endif with asmname and wrapper functions/ subroutines to handle this. My problem is with several global variables. For example, I have one called "emulator_error" and it is used in 250 files with around 100 in C and 150 in Pascal source files. Is there a way to avoid editing all 150 Pascal files to put the #ifdef/#else/#endif with asmname directive? I believe writing a script to do this will be complicated since the variable names can be declared in a line where several variables are declared. For example: Var test_val, emulator_error, sum : integer; and only emulator_error is used in both C and Pascal; test_val and sum are referenced in Pascal source code only. Regards, Jing Gloria Texas Instruments Sherman, Texas

2 1

Complex_Arctan
by Emil Jerabek 29 Jan '02

29 Jan '02

Hi all, I've had a look at the complex arctangent function in the RTS. It turned out that - it raises a runtime error or returns an infinite imaginary part on arguments too close to the singularities +/- i, for example ArcTan (Cmplx (1e6 * MinReal, +/- 1)) - it often returns a real number when it should return something with a small imaginary part instead (example: ArcTan (Cmplx (1e17, 1e17)) on IA32, YMMV), and in general, the imaginary part of the result is very unreliable when |Im (z)| << |Re (z)|^2 (because it is essentially computed as `Ln (something close to 1)'; example: Im (Arctan (Cmplx (1000, 0.0001))) gives 9.999989726e-11 instead of 9.999990000e-11, again this is machine-dependent) The following patch to p/rts/math.pas solves these problems (I hope it doesn't introduce others). ------------------------------ function Log1P (x: Real): Real; asmname 'log1p'; function Complex_Arctan (z: Complex): Complex; const Ln2 = 0.6931471805599453094172321214581765680755; var b, c, d: Real; begin c := Sqr (Re (z)); b := 1 - Abs (Im (z)); d := ((1 + Abs (Im (z))) * b - c) / 2; if Abs (b) > Abs (Re (z)) then b := Log1P (4 * (Abs (Im (z)) / b) / (b + Re (z) * (Re (z) / b))) / 4 else if c <= MinReal then b := (Ln2 - Ln (Abs (Re (z)))) / 2 else b := Log1P (4 * (Abs (Im (z)) / Re (z)) / (b * (b / Re (z)) + Re (z))) / 4; if Im (z) < 0 then b := -b; Complex_Arctan := Cmplx (ArcTan2 (Re (z), d) / 2, b) end; ------------------------ Emil Jerabek

2 4

Re: Accessing Mailing List Mail - Newbie Questions
by da Silva, Joe 29 Jan '02

29 Jan '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, January 21, 2002 2:39 AM > To: gpc(a)gnu.de > Subject: Re: Accessing Mailing List Mail - Newbie Questions > > Gloria, Jing wrote: > > > I am able to get to the mailing list archives thru my > > Web browser. I have also registered to subscribe to > > this mailing list. Pls point me to any documentation > > on how to use this system. > > There's none available. I thought it was more or less > slef-explaining. > > Or rather, as they say, the best documentation is the source which > can be found at http://fjf.gnu.de/crystal/. :-) > > > On the Web page, I can read the mail that have been > > submitted using the link from the GPC documentation. > > > > 1. How do I reply to a particular mail? There is no > > option to reply to the entry that I am reading. > > No, I haven't enabled this feature yet. It's mostly a policy > decision. We don't want anonymous replies on the list (and it might > also create another entry for spammers, though I'm not sure how many > spammers try to exploit web interfaces yet). And since the archive > (technically) independent of the list distribution, we'd have to do > a parallel user management (including passwords) for the archive. > > > 2. I sometimes see a section in the page that says > > "Reply to" with a list of previous messages. However, > > if I click on a mail entry in the list, that particular > > mail entry is displayed. > > Yes, this means as much as "The present mail is a reply to the > following mails". If you have a better idea how to name it, let me > know. > [Joe da Silva] How about "In reply to" ? > > 3. There is a login button at the end of the page for > > registered Crystal users. Do I need to register before > > I can reply to the mail in the mailing list? > > Registration is currently only used for administrators, but I don't > think it would be a problem to make it available for other users as > well. I didn't expect anyone to want to reply via this way, so I > didn't provide this options yet, but if there's some interest ... > > I'd like to know if anyone else is interested, so I can decide if I > should do the registrations manually or set up an automated system > (if there are many) ... > [Joe da Silva] I for one, only use it for reading messages. > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

GPC newbie
by gerdunne＠eircom.net 28 Jan '02

28 Jan '02

My OS = Win 95 I've installed MINGW32 and the GPC and have adjusted the Autoexec.bat parameters. I can execute the command 'GPC -v' and I get the correct responce. When I try to compile a *.pas prog. I get: - "GPC.exe: installation problem, cannot exe 'as': No such file or directory." I have downloaded the binutils. (a) The './configure make' command won't work for me. (b) I, not sure I've unziped to the right directory. (C) Do i have to configure my autoexec.bat for binutils? Any help would be greatly appreciated. Thanks Ger.

2 1

pow
by Emil Jerabek 27 Jan '02

27 Jan '02

(I'm surprised a bit that nobody noticed this before.) The complex "pow" operator gives completely bogus results with negative exponents. Example: [artax:pascal]% cat tst.pas program Foo (Output); var z: Complex; begin z := Cmplx (5, 0) pow (-1); WriteLn (Re (z) : 5 : 1, Im (z) : 5 : 1) end. [artax:pascal]% gpc tst.pas [artax:pascal]% ./a.out 1.0 0.0 The "Complex_Pow" function in rts/math.pas computes reciprocals as 1 / (x+iy) := (x-iy) / |x+iy|, which is a nonsense. Here is a patch (recycling a Maurice's idea to make it work for too big or too small arguments). ---------------------------------------- function Complex_Pow (z: Complex; y: Integer) = r: Complex; var a, b: Real; begin if y < 0 then begin if Abs (Re (z)) > Abs (Im (z)) then begin a := Im (z) / Re (z); b := Re (z) + Im (z) * a; z := Cmplx (1 / b, -a / b) end else begin if Im (z) = 0 then begin SetReturnAddress (ReturnAddress (0)); RuntimeError (706); { Executed `x pow y' when complex x is zero and y < 0 } RestoreReturnAddress end; a := Re (z) / Im (z); b := Re (z) * a + Im (z); z := Cmplx (a / b, -1 / b); end; y := - y end; r := 1; while y <> 0 do begin if Odd (y) then r := r * z; y := y shr 1; if y <> 0 then z := Sqr (z) end end; ------------------------------------- BTW, are there any serious reasons why the complex "**" operator accepts only _real_ exponents? As far as the RTS is concerned, it would suffice to change "Double" to "Complex" in the declaration of "Complex_Power", but I expect that it needs some compiler magic as well. Emil Jerabek

2 3

Accessing Mailing List Mail - Newbie Questions
by Gloria, Jing 26 Jan '02

26 Jan '02

I am able to get to the mailing list archives thru my Web browser. I have also registered to subscribe to this mailing list. Pls point me to any documentation on how to use this system. On the Web page, I can read the mail that have been submitted using the link from the GPC documentation. 1. How do I reply to a particular mail? There is no option to reply to the entry that I am reading. 2. I sometimes see a section in the page that says "Reply to" with a list of previous messages. However, if I click on a mail entry in the list, that particular mail entry is displayed. 3. There is a login button at the end of the page for registered Crystal users. Do I need to register before I can reply to the mail in the mailing list? Regards, Jing Gloria Texas Instruments Sherman, Texas

2 2

test summaries for gpc-2.1 RC2 on Linux
by Matthias Klose 25 Jan '02

25 Jan '02

Attached you find the test summaries for RC2, based on Debian's gcc-2.95.4 compiler. For alpha it looks like the newly built gpc.pas cannount be found. Note that all compilers are built with srcdir != builddir.

2 1

help: invoking Pexecute problem
by Tam Pikey 22 Jan '02

22 Jan '02

Hi We're having a problem when compiling while trying to use pexec. I'm looking for suggestions/fixes if anyone has one? The compile error is: ------------------------ [09:44:46] sdis:~/sdis >gpc sort.pas sort.pas: In function `program_Sort': sort.pas:11: undeclared identifier `Pexecute' (first use this function) sort.pas:11: (Each undeclared identifier is reported only once sort.pas:11: for each function it appears in.) sort.pas:12: undeclared identifier `Pexecute_one' (first use this function) sort.pas:12: undeclared identifier `Pexecute_search' (first use this function) sort.pas:12: undeclared identifier `Pexecute_verbose' (first use this function) [09:44:55] sdis:~/sdis > My versions are: ------------------------ [09:23:29] root:~ >gpc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 [09:23:32] root:~ >gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) [09:23:39] root:~ > Sitting on an Ultra 10 Sparc running Solaris 2.7 tam axtlp(a)uaa.alaska.edu

4 5

Re: Trouble using GPC modules
by da Silva, Joe 21 Jan '02

21 Jan '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, January 21, 2002 1:59 AM > To: gpc(a)gnu.de > Subject: Re: Trouble using GPC modules > > Nicolas Courtel wrote: > > > I'm trying to use the simple GPC modules mechanism, as described in the > Doc > > (7.1.8.1, page 85), and can't figure out how to link the provided > example, with > > module DemoMod3 and program ModDemo3. > > > > I'm using GPC 20011202 on Solaris-8; I tried several methods, for > example: > > > > % gpc --automake moddemo3.pas > > > > and always get undefined linking errors: > > > > Setfoo /var/tmp/cc2daawp1.o > > Getfoo /var/tmp/cc2daawp1.o > > > > I guess the solution is really simple, but can't find it, please help! > > > > Here's the example source code: > > Works for me. Perhaps you need to specify the `asmname's (anyway, > this will be required in the future when GPC will support qualified > identifiers, so you might as well do it now, and perhaps it will > solve your problem): > > module DemoMod3; > > type > FooType = Integer; > > var > Foo : FooType; > > procedure SetFoo (f : FooType); asmname 'setfoo'; > procedure SetFoo (f : FooType); > [Joe da Silva] OK, time for a silly question ... <g> Why does the procedure header need to be given twice? (Looks weird!)

2 1

Trouble using GPC modules
by Nicolas Courtel 20 Jan '02

20 Jan '02

Hi all, I'm trying to use the simple GPC modules mechanism, as described in the Doc (7.1.8.1, page 85), and can't figure out how to link the provided example, with module DemoMod3 and program ModDemo3. I'm using GPC 20011202 on Solaris-8; I tried several methods, for example: % gpc --automake moddemo3.pas and always get undefined linking errors: Setfoo /var/tmp/cc2daawp1.o Getfoo /var/tmp/cc2daawp1.o I guess the solution is really simple, but can't find it, please help! Here's the example source code: module DemoMod3; type FooType = Integer; var Foo : FooType; procedure SetFoo (f : FooType); begin Foo := f; end; { SetFoo } function GetFoo: Footype; begin GetFoo := Foo; end; { GetFoo } end. program ModDemo3 (Output); type FooType = Integer; procedure SetFoo (f : FooType); external; function GetFoo: FooType; external; begin SetFoo (999); Writeln (GetFoo); end. -- Nicolas

2 1

Trouble using GPC modules
by Nicolas Courtel 20 Jan '02

20 Jan '02

Hi all, I'm trying to use the simple GPC modules mechanism, as described in the Doc (7.1.8.1, page 85), and can't figure out how to link the provided example, with module DemoMod3 and program ModDemo3. I'm using GPC 20011202 on Solaris-8; I tried several methods, for example: % gpc --automake moddemo3.pas and always get undefined linking errors: Setfoo /var/tmp/cc2daawp1.o Getfoo /var/tmp/cc2daawp1.o I guess the solution is really simple, but can't find it, please help! Here's the example source code: module DemoMod3; type FooType = Integer; var Foo : FooType; procedure SetFoo (f : FooType); begin Foo := f; end; { SetFoo } function GetFoo: Footype; begin GetFoo := Foo; end; { GetFoo } end. program ModDemo3 (Output); type FooType = Integer; procedure SetFoo (f : FooType); external; function GetFoo: FooType; external; begin SetFoo (999); Writeln (GetFoo); end. -- Nicolas

1 0

Re: GPC Variable/Procedure Naming Convention
by Gloria, Jing 18 Jan '02

18 Jan '02

Frank, thanks for your inputs that I read in the mailing list archives. I was hoping there is an option to allow making the names in lowercase. Everyone, can somebody please send me information on how to change the GPC naming schema so that it will generate names that are all in lowercase? At this point I am willing to take a chance and rebuild my GPC compiler if it will generate all lowercase names. I have Pascal procedures/functions that are called by both Pascal and C modules. Global variables are used in both C and Pascal modules. There are close to 100 global variables and around sixty Pascal procedures/functions shared by both C and Pascal. All these scattered over 500 Pascal and C source files. The C modules use all lowercase for the names. So I either convert the C files to have first character uppercase names or add asmname in the Pascal files. Either way, I will need to edit hundreds of files. Regards, Jing Gloria Texas Instruments Sherman, TX

2 1

array of 24-bit cardinals?
by Toby Ewing 17 Jan '02

17 Jan '02

Hello, all I'm working with some large arrays (2^27 elements), and am about to run into memory limitations. Currently I'm using a bytecard for each element, but in expanding my program's capabilities, I want to add a second array of cardinal. This second cardinal needs to have a range larger than 2^16 (65535), but I don't have enough memory for a 2^32 cardinal. Sounds like 2^24 cardinals would be appropriate... I looked into the range-specified integers in the manual. It says: >>> 8.2.3.3 Integer Types with Specified Size In some situations you will need an integer type of a well-defined size. For this purpose, GNU Pascal provides three families of signed and unsinged integer types. The type Integer (42) is guaranteed to have a precision of 42 bits. In a realistic context, you will most often give a power of two as the number of bits, and the machine you will need it on will support variables of that size. If this is the case, the specified precision will simultaneously be the amount of storage needed for variables of this type. <<< So perhaps the 24-bit cardinal would work fine. My questions: 1) will the compiler really allocate only 24 bits, or will it align the array elements along 32-bit boundaries? 2) If the compiler does indeed make true 24-bit-aligned cardinals, how much speed will I lose in memory access? If this is an unexplored issued, please let me know, in which case I'll attempt it and report back on how it worked. regards, Toby Soil Scientist, Iowa State University

3 3

Re: Is this a bug or me being stupid?
by da Silva, Joe 17 Jan '02

17 Jan '02

What if you define your variable as -32767..32767, instead of -32768..32767? Does that work? I know that the full range of a 16 bit, two's complement integer is indeed -32768..32767, but Pascal does not assume two's complement implementation, hence the range for an integer is -maxint..maxint, not -(maxint+1)..maxint. Therefore, GPC may at least in some cases regard the need for -32768 as an integer type whose maxint is 32768 or greater, in which case 16 bits would be deemed inadequate (with 32 bits chosen instead). If the above analysis is true, then GPC has two bugs : 1. It is inconsistent about whether -32768..32767 fits within 16 bits. 2. It is allowing the "external" qualifier to circumvent checking for duplicate identifiers (as Maurice has already pointed out). Joe. > -----Original Message----- > From: Martin G C Davies [SMTP:martin.g.c.davies@ntlworld.com] > Sent: Wednesday, January 16, 2002 10:54 PM > To: gpc(a)gnu.de > Subject: Re: Is this a bug or me being stupid? > > > > > -----Original Message----- > > From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de]On Behalf Of Maurice > > Lombardi > > Sent: 16 January 2002 10:47 > > To: gpc(a)gnu.de > > Subject: Re: Is this a bug or me being stupid? > > > > > > Martin G C Davies wrote: > > > > > main: sizeof curpseudoreg=2 > > > main: alignof curpseudoreg=2 > > > main: curpseudoreg initially set to 5 > > > initregcons: sizeof curpseudoreg=4 > > > initregcons: alignof curpseudoreg=4 > > > initregcons: curpseudoreg=327680 > > > initregcons: curpseudoreg now set to 99 > > > main: curpseudoreg=0 > > > > > > So the quuestion is, why is the sizeof and alignog different in the > two > > > modules? > > > > They are not the same variable. You see that the values also of > > curpseudoreg > > are different. > > Thanks for the analysis Maurice but I don't think it's correct for three > reasons:- > > 1. If I change packed -32768..32767 to integer(16) the problem goes away > for > the example given. > > 2. I added a writlen of the addr of curpseudoreg and it is the same > address > in each module (new code below). > > 3. 327680 is hex 50000 so it just looks like the sizeof and alignof of 4 > are > what is mucking it up. > > Thus I still think this a gpc bug. > > main.pas > ======== > > program main(output) ; > > procedure initregcons ; external ; > > var > curpseudoreg : packed -32768..32767number ; external ; > > begin > writeln( 'main: addr curpseudoreg=' , integer( addr( curpseudoreg ) ) > ) > ; > writeln( 'main: sizeof curpseudoreg=' , sizeof( curpseudoreg ) ) ; > writeln( 'main: alignof curpseudoreg=' , alignof( curpseudoreg ) ) ; > curpseudoreg := 5 ; > writeln( 'main: curpseudoreg initially set to ' , curpseudoreg ) ; > initregcons ; > writeln( 'main: curpseudoreg=' , curpseudoreg ) ; > end. > > regabs.pas > ========== > > module regabs ; > > var > curpseudoreg : packed -32768..32767 ; external ; > var > curpseudoreg : packed -32768..32767 ; > > procedure initregcons ; external ; > > procedure initregcons ; > begin > writeln( 'initregcons: addr curpseudoreg=' , integer( addr( > curpseudoreg ) ) ) ; > writeln( 'initregcons: sizeof curpseudoreg=' , sizeof( curpseudoreg ) > ) > ; > writeln( 'initregcons: alignof curpseudoreg=' , alignof( > curpseudoreg ) ) ; > writeln( 'initregcons: curpseudoreg=' , curpseudoreg ) ; > curpseudoreg := 99 ; > writeln( 'initregcons: curpseudoreg now set to ' , curpseudoreg ) ; > end ; > > end. > > and the output when run is:- > > main: addr curpseudoreg=522892 > main: sizeof curpseudoreg=2 > main: alignof curpseudoreg=2 > main: curpseudoreg initially set to 5 > initregcons: addr curpseudoreg=522892 > initregcons: sizeof curpseudoreg=4 > initregcons: alignof curpseudoreg=4 > initregcons: curpseudoreg=327680 > initregcons: curpseudoreg now set to 99 > main: curpseudoreg=0 >

4 4

Is this a bug or me being stupid?
by Martin G C Davies 16 Jan '02

16 Jan '02

I have a cut down version of a bug I have found:- File 1 (main.pas) ================= program main(output) ; procedure initregcons ; external ; var curpseudoreg : packed -32768..32767 ; external ; begin writeln( 'main: sizeof curpseudoreg=' , sizeof( curpseudoreg ) ) ; writeln( 'main: alignof curpseudoreg=' , alignof( curpseudoreg ) ) ; curpseudoreg := 5 ; writeln( 'main: curpseudoreg initially set to ' , curpseudoreg ) ; initregcons ; writeln( 'main: curpseudoreg=' , curpseudoreg ) ; end. File 2 (regabs.pas) =================== module regabs ; var curpseudoreg : packed -32768..32767 ; external ; var curpseudoreg : packed -32768..32767 ; procedure initregcons ; external ; procedure initregcons ; begin writeln( 'initregcons: sizeof curpseudoreg=' , sizeof( curpseudoreg ) ) ; writeln( 'initregcons: alignof curpseudoreg=' , alignof( curpseudoreg ) ) ; writeln( 'initregcons: curpseudoreg=' , curpseudoreg ) ; curpseudoreg := 99 ; writeln( 'initregcons: curpseudoreg now set to ' , curpseudoreg ) ; end ; end. I compile them:- gpc -Wall main.pas regabs.pas and there are no warnings. By the way gpc -v gives:- Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 20010924, based on gcc-2.8.1 When I run the program I get:- main: sizeof curpseudoreg=2 main: alignof curpseudoreg=2 main: curpseudoreg initially set to 5 initregcons: sizeof curpseudoreg=4 initregcons: alignof curpseudoreg=4 initregcons: curpseudoreg=327680 initregcons: curpseudoreg now set to 99 main: curpseudoreg=0 So the quuestion is, why is the sizeof and alignog different in the two modules? Cheers, Martin P.S. I am testing using integer(16) for this example but I have other similar problems (different packed ranges).

2 3

GPC Variable/Procedure Naming Convention
by Gloria, Jing 16 Jan '02

16 Jan '02

Is there a way such that the variable names (or procedure/function names) in GPC are created so that the name is all lowercase? This would make it match C variable names which are in lowercase. I understand the GPC converts the names to uppercase for the first character and lower case for all the succeeding characters in the name. I am converting an application where some modules are in written in Pascal and others in C. They share many global variables and some procedures and functions. There are too many lines of code and too many files to change if I use asmname. Furthermore, I need to keep the source files such that I can build on either a Sun Sparc system or Intel Solaris 7 system. Since these two systems have different compilers, this GPC naming convention is requiring a lot of work. Bottomline, I want GPC and GCC to generate the same name so that I can link all the modules. Any suggestions or comments? GPC is version 19991030. based on 2.95 19990728. GCC is 2.95.2. Thanks in advance for any assistance the community provides. Regards, Jing Gloria Texas Instruments Sherman, TX

2 1

Re: gpc problems in 2.95
by Matthias Klose 16 Jan '02

16 Jan '02

[CC to gpc(a)gnu.de; the gpc version is the RC2, the gcc version 2.95.4 CVS] Philip Blundell writes: > The version of gpc in the 2001-12-23 upload doesn't seem to work on arm, > sparc, m68k or s390; they all seem to segfault somewhere during the build. > > ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings > -Wmissing-prototypes -Wmissing-declarations -g -O3 > -DRTS_RELEASE_STRING="'`cat /build/buildd/gcc-2.95-2.95.4.ds7/src-native/gcc/p/ > rts/rts-version`'" --unit-path=/build/buildd/gcc-2.95-2.95.4.ds7/src-native/gc > c/p/rts --automake `cat needed-options` /build/buildd/gcc-2.95-2.95.4.ds7/src-n > ative/gcc/p/rts/heap.pas > xgpc: Internal compiler error: program gpc1 got fatal signal 11 > make[5]: *** [heap.o] Error 1 on sparc it fails in another file: ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O3 -DRTS_RELEASE_STRING="'`cat /home/doko/2.95/gcc-2.95-2.95.4.ds7/src-native/gcc/p/rts/rts-version`'" --unit-path=/home/doko/2.95/gcc-2.95-2.95.4.ds7/src-native/gcc/p/rts --automake `cat needed-options` /home/doko/2.95/gcc-2.95-2.95.4.ds7/src-native/gcc/p/rts/endian.pas xgpc: Internal compiler error: program gpc1 got fatal signal 11 make[5]: *** [endian.o] Error 1 > > What's to be done? I'll go back to the gpc-20010924 version for these architectures, if I get no feedback from upstream.

3 6

A compiler crash with -g -O3
by Emil Jerabek 16 Jan '02

16 Jan '02

Something is bad with function inlining, when debug info is being generated: [pas]% uname -a ; gpc -v Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 unknown Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20011222, based on 2.95.2 19991024 (release) [pas]% cat crash.pas program P (Output); (* FLAG -g -O -finline-functions *) var A: Integer; procedure S; var B: 0 .. 1; begin A := B end; begin S; WriteLn ('OK') end. [pas]% gpc -g -O -finline-functions crash.pas gpc: Internal compiler error: program gpc1 got fatal signal 11 [pas]% gdb /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/gpc1 core GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `/usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/gpc1 /tmp/ccoAW9qr.i -quiet -du'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 print_int_cst_octal (c=0x8257cbc) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:1597 1597 int width = TYPE_PRECISION (TREE_TYPE (c)); (gdb) bt #0 print_int_cst_octal (c=0x8257cbc) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:1597 #1 0x08140986 in dbxout_type (type=0x8259fc0, full=0, show_arg_types=0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:1171 #2 0x0814230c in dbxout_symbol_location (decl=0x825a920, type=0x8259fc0, suffix=0x0, home=0x825a8a4) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2161 #3 0x08141ebc in dbxout_symbol (decl=0x825a920, local=1) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:1944 #4 0x0814245b in dbxout_syms (syms=0x825a920) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2230 #5 0x08142a6d in dbxout_block (block=0x825a984, depth=4, args=0x0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2585 #6 0x08142bc8 in dbxout_block (block=0x825a9cc, depth=3, args=0x0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2644 #7 0x08142bc8 in dbxout_block (block=0x8279134, depth=2, args=0x0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2644 #8 0x08142bc8 in dbxout_block (block=0x827917c, depth=1, args=0x0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2644 #9 0x08142bc8 in dbxout_block (block=0x82791ac, depth=0, args=0x0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2644 #10 0x08142d07 in dbxout_function (decl=0x82776c0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2706 #11 0x08171879 in rest_of_compilation (decl=0x82776c0) at ../../../gcc-2.95.2/gcc/p/../toplev.c:4419 #12 0x08189a28 in finish_function (nested=0) at ../../../gcc-2.95.2/gcc/p/gpc-decl.c:9708 #13 0x081a41d2 in yyparse () at parse.y:525 #14 0x0816fb91 in compile_file (name=0xbffffb69 "/tmp/ccoAW9qr.i") at ../../../gcc-2.95.2/gcc/p/../toplev.c:3265 #15 0x08172e7a in main (argc=11, argv=0xbffff9ec) at ../../../gcc-2.95.2/gcc/p/../toplev.c:5440 #16 0x40041e5e in __libc_start_main (main=0x8171ec4 <main>, argc=11, ubp_av=0xbffff9ec, init=0x8049194 <_init>, fini=0x81bcf80 <_fini>, rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffff9dc) at ../sysdeps/generic/libc-start.c:129 Emil Jerabek

2 1

#466 ???
by 320017353451-0001＠t-online.de 16 Jan '02

16 Jan '02

Where do I find errorcodes in general and this one in particular ? I had a look into /usr/share/doc/packages/gpc etc witout finding anything ... : -) Thanks Douglas P.S. It s an error which is not really reproduceable ... so I would like to know where to look closer ?!

2 1

Re: Complex_SqRt bug
by da Silva, Joe 14 Jan '02

14 Jan '02

OK, if you're happy that the code is correct ... I guess I just don't understand what the "a := Abs(Im(z)) / (2 * b)" statement does ... More accurate results are always welcome, anyway. Anyway, although you might say the Clipped_SqRt solution is a kludge, it is certainly not second-guessing. It would only be applied where the minimum theoretical argument was zero, in which case it would avoid (and eliminate) rounding errors which produced a slightly negative "zero". Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, January 10, 2002 9:30 PM > To: gpc(a)gnu.de > Subject: Re: Complex_SqRt bug > > da Silva, Joe wrote: > > > To be honest, the revised Complex_SqRt function you present > > is a bit too complicated for me. <G> > > > > So, my thinking is that, instead of re-writing the algorithm of > > Complex_SqRt and similar routines, it would be simpler and > > less error-prone in these situations, to utilize a new, alternative > > SqRt function, eg. : > > > > Function Clipped_SqRt (x : double) : double; > > {Alternative SqRt : Clips negative arguments, returning zero} > > begin {Clipped_SqRt} > > if x > 0 > > then > > Clipped_SqRt := SqRt (x) > > else > > Clipped_SqRt := 0 > > end; {Clipped_SqRt} > > > > Of course, you would only apply this alternative to SqRt when > > the argument cannot theoretically be negative ... > > I don't think so. This seems more like a kludge to me (first compute > a wrong value, and then second-guess in a subroutine what it could > really be). Besides, it would only avoid the problem in the "< 0" > case -- as Emil noted, "the patch above gives more accurate results > (even for arguments which do not trigger the bug)." > > BTW, I checked his code carefully to make sure it's mathematically > correct. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

4 3

Problems with GtkUnit
by Klaus F. Østergaard 14 Jan '02

14 Jan '02

Hi, I have a small problem with the GtkUnit. I have the unit installed, using make every thing just worked. All the tutorial programs compiled and they are ready to use. But when I try to compile the simple helloworld.pas with this: gpc -O2 -Wall --automake helloworld.pas -o ../../../pascal/bin/helloworld I get this error: In file included from helloworld.pas:5: ../units/gtk.inc:23: module/unit `gtkmarshal' could not be compiled In the helloworld I have changed the path from '../units' to '/home/klaus/temp/gtk/units' Am I missing something on the command line when I call the compiler, or is there a bug in the unit? Kind regards, Klaus F. Oestergaard

3 4

Complex_SqRt bug
by Emil Jerabek 14 Jan '02

14 Jan '02

The complex square root function crashes with a funny error message on some arguments close to the real line: [pas]% cat sqrt.pas program SqrtTest (Output); var C: Complex; begin C := Sqrt (Cmplx (4.2, 1e-8)); WriteLn ('OK') end. [pas]% uname -a ; gpc -v Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 unknown Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20011222, based on 2.95.2 19991024 (release) [pas]% gpc sqrt.pas [pas]% ./a.out ./a.out: argument to `SqRt' is < 0 (error #708 at 805d837) [pas]% The square root is computed as \sqrt{X+iY} = \sqrt{(A+X)/2} + i \sqrt{(A-X)/2} sgn(Y), where A=|X+iY|. It seems that due to inaccuracies etc., A may turn out to be _less_ than |X|, if |Y| << |X|, which means that SqRt((A+-X)/2) gets a negative argument. I suggest the following patch. --------------------------------------------------- diff -U3 orig/p/rts/math.pas p/rts/math.pas --- orig/p/rts/math.pas Mon Sep 3 12:48:15 2001 +++ p/rts/math.pas Mon Jan 7 21:34:43 2002 @@ -192,8 +192,7 @@ function Complex_SqRt (z: Complex): Complex; var - a: Double; - Sign: Integer; + a, b: Double; begin { SqRt (x + yi) = +/- (SqRt ((a + x) / 2) +/- i * SqRt ((a - x) / 2)) @@ -203,10 +202,15 @@ Principal value defined in the Extended Pascal standard: Exp (0.5 * Ln (z)), i.e. Sign (Re (SqRt (z)) := 1, Sign (Im (SqRt (z))) := Sign (Im (z)) } a := Abs (z); - if Im (z) < 0 then Sign := -1 else Sign := 1; - if a <> 0 - then Complex_SqRt := Cmplx (SqRt ((a + Re (z)) / 2), Sign * SqRt ((a - Re (z)) / 2)) - else Complex_SqRt := 0 + if a = 0 then Complex_SqRt := 0 + else begin + b := SqRt ((a + Abs (Re (z))) / 2); + if Abs (Im (z)) > Abs (Re (z)) then a := SqRt ((a - Abs (Re (z))) / 2) + else a := Abs (Im (z)) / (2 * b); + if Re (z) < 0 then begin var c: Double = a; a := b; b := c end; + if Im (z) < 0 then Complex_SqRt := Cmplx (b, -a) + else Complex_SqRt := Cmplx (b, a) + end end; function Complex_Ln (z: Complex): Complex; ---------------------------------------------------- It would also work to simply insert if Abs (Re (z)) > a then a := Abs (Re (z)); into the original version, but the patch above gives more accurate results (even for arguments which do not trigger the bug). When talking about math.pas, I also suggest a little optimization to the complex logarithm function; \log \sqrt x = (\log x)/2, but the RHS is (I guess) computed faster and more precisely: --------------------------------------------------- diff -U3 orig/p/rts/math.pas p/rts/math.pas --- orig/p/rts/math.pas Mon Sep 3 12:48:15 2001 +++ p/rts/math.pas Mon Jan 7 22:10:08 2002 @@ -211,7 +211,8 @@ function Complex_Ln (z: Complex): Complex; begin - Complex_Ln := Cmplx (Ln (Abs (z)), ArcTan2 (Im (z), Re (z))) + Complex_Ln := Cmplx (Ln (Sqr (Re (z)) + Sqr (Im (z))) /2, + ArcTan2 (Im (z), Re (z))) end; function Complex_Exp (z: Complex): Complex; ----------------------------------------------------- Emil Jerabek

4 8

packed arrays again
by Emil Jerabek 14 Jan '02

14 Jan '02

There are still some problems with packed arrays of subrange types. (1) Initializers don't work properly. [pas]% cat packed1.pas program P (Output); type T = packed array [0 .. 2] of 0 .. 1000; var A: T value (1, 2, 0); begin if (A[0] = 1) and (A[1] = 2) and (A[2] = 0) then WriteLn ('OK') else WriteLn ('Failed: ', A[0] : 4, A[1] : 4, A[2] : 4) end. [pas]% uname -a ; gpc -v Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 unknown Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20011222, based on 2.95.2 19991024 (release) [pas]% gpc packed1.pas packed1.pas:9: warning: too few initializers for array [pas]% ./a.out Failed: 1 0 0 [pas]% (2) In certain situations, assignment statements work incorrectly when the same subscribed packed array variable is accessed on both sides of the assignment. [pas]% cat packed2.pas program P (Output); var A: packed array [0 .. 2] of 0 .. 1000; function F (N: Integer): Integer; begin if N = 0 then F := 0 else begin A[N] := F (A[N]); F := A[N] + 1 end end; begin A[0] := 1; A[1] := 2; A[2] := 0; A[0] := F (A[0]); if A[0] = 2 then WriteLn ('OK') else WriteLn ('Failed: ', A[0]) end. [pas]% gpc packed2.pas [pas]% ./a.out Failed: 1 [pas]% The problem is in the statement "A[N] := F (A[N]);" in the body of F. During its execution, A[N] is _cleared_ before the function call, in particular the argument passed to F is always 0. The debugger session below illustrates this behavior. (gdb 5.0 doesn't understand packed arrays; I used a type-cast to Integer as a workaround. Integer(A)=A[0]+1024*A[1]+1048576*A[2], i.e. 2049=(1,2,0) and 1=(1,0,0).) [pas]% gpc -g packed2.pas [pas]% gdb a.out GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) break F Breakpoint 1 at 0x8049c2c: file packed2.pas, line 8. (gdb) run Starting program: /home/emil/pascal/pas/a.out Breakpoint 1, F (N=1) at packed2.pas:8 8 if N = 0 then F := 0 Current language: auto; currently pascal (gdb) watch Integer(A) Hardware watchpoint 2: (Integer) A (gdb) step 10 A[N] := F (A[N]); (gdb) step Hardware watchpoint 2: (Integer) A Old value = 2049 New value = 1 $08049cb4 in F (N=1) at packed2.pas:10 10 A[N] := F (A[N]); (gdb) bt #0 $08049cb4 in F (N=1) at packed2.pas:10 #1 $0804a1a9 in pascal_main_program () at packed2.pas:19 #2 $0804a2bb in main (argc=1, argv=$bffffacc, envp=$bffffad4) at <implicit code>:21 #3 $40064e5e in __libc_start_main (main=$804a294 <main>, argc=1, ubp_av=$bffffacc, init=$80494c8 <_init>, fini=$8066b50 <_fini>, rtld_fini=$4000d3c4 <_dl_fini>, stack_end=$bffffabc) at ../sysdeps/generic/libc-start.c:129 (gdb) step Breakpoint 1, F (N=0) at packed2.pas:8 8 if N = 0 then F := 0 (gdb) Emil Jerabek

2 1

Re: Complex_SqRt bug
by da Silva, Joe 14 Jan '02

14 Jan '02

Well, I haven't seen the computations, but if you are happy that they are "sound" and that they will be more accurate than the existing algorithm, then I agree that you should use them. The advantage of the Clipped_SqRt solution was simplicity and clarity (and certainty;-). However, it does not change the accuracy. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Friday, January 11, 2002 12:43 PM > To: gpc(a)gnu.de > Subject: Re: Complex_SqRt bug > > da Silva, Joe wrote: > > > OK, if you're happy that the code is correct ... I guess I just don't > > understand what the "a := Abs(Im(z)) / (2 * b)" statement does ... > > I could write down the computations if you like (unless Emil has > them readily available already) ... > > > Anyway, although you might say the Clipped_SqRt solution is a > > kludge, it is certainly not second-guessing. It would only be applied > > where the minimum theoretical argument was zero, in which case > > it would avoid (and eliminate) rounding errors which produced a > > slightly negative "zero". > > As I said, I'm no expert on numeric algorithms, but I think if an > algorithm can produce such wrong results, it might also be > inaccurate for other values and should be improved (such as > Complex_Sqrt). After all, normal rounding doesn't easily make a > positive value (even very close to 0) negative. So it might be > better if the programmer sees the problem clearly with an error > message. If it really turns out that an algorithm is as good as > possible (numerically) and still prone to this kind of problem, > something like Clipped_SqRt might be in order. But I guess this is > rather an exceptional situation, so Clipped_SqRt does not seem a > good candidate for a general library routine. > > But perhaps Emil can comment better on these matters ... > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

List of successful GPC ports
by Prof. A Olowofoyeku (The African Chief) 12 Jan '02

12 Jan '02

Hi all Do we have a canonical list of successful GPC builds? If not, can we try to create one please? Thanks all. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

3 4

Speading up GPC [2] ...
by Mirsad Todorovac 12 Jan '02

12 Jan '02

Hi, all, (Well, former message had a typing error in it's title as you must have noticed - which shows what quirks might occur when being eager to speed things up ;-) There's more space for speed/efficiency improvements. The second issue (I thank my friend Dvae who pointed similar issue years ago) is reading of input files. When done with open(2)/read(2) interface, it's correct, but mapping it into memory with mmap(2) is only slightly different, but much more efficient. This is because kernel does things for you. I can't give you a direct estimation about how switch to mmap(2) interface would speed-up GPC, but I remember an application (oops, I forgot to add it to my CV) when we had to read complete registry of Croatian companies in order to do a search. In this simplistic case with one big file, mmap(2)-ing it instead of open(2)/read(2)-ing it has shown _50%_drop!!!!_ in use of 'system time'. 'User time' also dropped, because interface routines didn't have to copy records to memory locations allocated with malloc - they were already mmap(2)-ed in, I only needed to re-link pointers to them. Off course, several routines had to be modified to be read-only to avoid copy-on-write overhead over input file, and to remove dependencies from '\0' trailing byte. At the time, it seemed as an acceptable price. I can't estimate the amount fo work required to attempt to implement mmap(2) interface to read files (on platforms where available) seemlesly. But from 'Internals', since parser calls lexer, mostly only lexer would have to be modified - and have two versions (one for platforms with MMAP and one for others, selected etiher with -DUSE_MMAP compile directive when compiling GPC, or even at runtime). The change would, however, significantly decrease copying overhead when dealing with large files. Also this could be applied to generating GPI files, but that area I'm not certain about yet. Please give your valuable opinions - thanks, Mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

2 1

{Max,Min,Eps}Real
by Emil Jerabek 12 Jan '02

12 Jan '02

The Extended Pascal real constants have strange values, namely MaxReal=MinReal=EpsReal=NaN. [pas]% cat const.pas program EPRealConstants (Output); uses GPC; var R : Real; OK: Boolean value True; procedure Bomb (I: Integer); begin WriteLn ('Failed ', I : 2, ': ', R); OK := False end; begin R := MinReal; if IsNotANumber (R) then Bomb (1); if IsInfinity (R) then Bomb (2); if R <= 0 then Bomb (3); { Simple `if R / 2 <> 0' doesn't work (at least on IA32), since it is internally computed with bigger precision. The same holds for tests # 8 and 13. } R := R / 2; if R <> 0 then Bomb (4); R := MaxReal; if IsNotANumber (R) then Bomb (5); if IsInfinity (R) then Bomb (6); if R <= 0 then Bomb (7); R := R + R; if not (IsInfinity (R) or (R <= MaxReal)) { `not IsInfinity (R)' alone probably can't work on non-IEEE hardware } then Bomb (8); R := EpsReal; if IsNotANumber (R) then Bomb (9); if IsInfinity (R) then Bomb (10); if R <= 0 then Bomb (11); R := R + 1; if R <= 1 then Bomb (12); R := EpsReal / 2 + 1; if R <> 1 then Bomb (13); if OK then WriteLn ('OK') end. [pas]% uname -a ; gpc -v Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 unknown Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20011222, based on 2.95.2 19991024 (release) [pas]% gpc const.pas [pas]% ./a.out Failed 1: NaN Failed 4: NaN Failed 5: NaN Failed 8: NaN Failed 9: NaN Failed 13: NaN [pas]% I'm not quite sure if the testing program above is robust enough, but it passed on my machine when I replaced manually the constants with their correct (IMHO) values (1.7976931348623157e+308, 4.9406564584124654e-324, 2.2204460492503131e-16). Emil Jerabek

2 4

boolean function return value wrong
by Martin G C Davies 12 Jan '02

12 Jan '02

Hi, gpc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 20011222, based on gcc-2.8.1 I have to use gcc-2.8.1 because later versions have a bug with goto out multiple levels (as discussed in this forum before). My new problem is with source:- program Hello ; function covers( var p1 , p2 : integer ) : boolean ; begin if ( p1 = p2 ) then begin covers := false ; writeln( 'mgcd covers returns false 1' ) ; return ; end ; covers := true ; writeln( 'mgcd covers returns true' ) ; end ; var i1, i2 : integer ; begin i1 := 1 ; i2 := 1 ; writeln( 'covers=' , covers( i1 , i2 ) ) ; end. When I run it I get:- mgcd covers returns false 1 covers=True I could not find a reference to this problem. The problem was not introduced in 20011222 because 20010924 shows the same problem. Can anyone help? Cheers, Martin.

3 5

Sppeding & speading -> speeding ...
by Mirsad Todorovac 11 Jan '02

11 Jan '02

Hi, all - me again - I don't know how I managed to misspell speeding twice, and in the title ... Apology to all. Mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

1 0

Sppeding up GPC :-) ...
by Mirsad Todorovac 11 Jan '02

11 Jan '02

Hi, all - have a nice weekend first, Since this is not a bug report, relax all! I was puzzled by 'Highlights' section of GPC manual that says how GNU Pascal compiler is substantially slower. I know of course that it uses proven GNU backend, so GPC team has little influence in making *that* part run faster. I know that reliability is more important than speed, but a question occured to me. While I was still at the college, we had an collegium called "Language Processors". It had subjects like LL-grammar, attribute grammar etc., which are mathematical background for compilers. On labs, we had a choice, whether to use code parser, or a 'finite stata automata' (FSA) driven parser. I chose the latter which made me a lot of complications; but impression of all students was that FSA parser is substantially faster. Why is this - FSA parser is very small piece of code driven by a table that represents it's wisdom and logic, which serves to approve or reject syntax. I realized GPC is using 'bison' parser as it's front end - and 'bison' (yacc successor) AFAIK uses code-driven parsing generated from attribute LALR(1) grammar, doesn't it? What is your estimate, is there a chance of leap increase of speed if switching bison to use FSA-syntax checker? So he would generate part of compiler that does the same grammar, but by different method, finite state automata (FSA). FSA parsers are known to be more compact, but harder to design. Modern machine architectures would make FSA parser run even faster, since (realtively small) table and driver code can fit into most processor's caches nowadays, making compilation fly. Besides that, grammar can be spearated from generated code, so (in some ideal case) there would be no need to recompile driver part of the compiler, only compiler table - when changing or debugging grammar. My estimation that this change could help reduce compile time by 50% to 70%; and decrease compiler binary size (parser part) by 30-60%, switching syntax (by compiler directive) would then be a switch of table, while automate driving code would remain the same. This change doesn't influence RTL generator and back-end, neither lexer front-end (but there's a room for finite-state automata strategy improvements there also). Of course, although this improvement would carry an opportunity to catch up with Borland Pascal in speed, but GNU backend's generality makes this very hard as I suspect. Now, these are only reflections, I haven't sunk that deep in 'bison' nor GPC internals - but please tell me that this line of research have a sense or not. Of course, counter-argument is always 'why touch something stable, when there's more important work to do, like catching up with standards?' - but tuning performance of code was always my weakness from college days ;-) Once again, have a nice weekend, Mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

1 0

GtkUnit
by Klaus F. Østergaard 11 Jan '02

11 Jan '02

> > Hi, > > I have downloaded the Gtkunit.=20 > On a linux box (Redhat 7.2) extracted it with tar -xvf to a temp on my = > home dir. > On my home I have installed a rather new GPC only a couple of weeks old. > When I try to run Makefile I get a error Permission denied, I have tried = > also as root, same problem. > How do I install the units? > I have assumed that this is the path to get a GUI with out programming = > all the buttons ect. by myself also the shortest path to make nice = > programs that runs under X? > > Thanks in advance for help, > > Klaus F. Oestergaard > > >

2 1

Re: Complex_SqRt bug
by da Silva, Joe 10 Jan '02

10 Jan '02

To be honest, the revised Complex_SqRt function you present is a bit too complicated for me. <G> So, my thinking is that, instead of re-writing the algorithm of Complex_SqRt and similar routines, it would be simpler and less error-prone in these situations, to utilize a new, alternative SqRt function, eg. : Function Clipped_SqRt (x : double) : double; {Alternative SqRt : Clips negative arguments, returning zero} begin {Clipped_SqRt} if x > 0 then Clipped_SqRt := SqRt (x) else Clipped_SqRt := 0 end; {Clipped_SqRt} Of course, you would only apply this alternative to SqRt when the argument cannot theoretically be negative ... Joe. > -----Original Message----- > From: Emil Jerabek [SMTP:ejer5183@artax.karlin.mff.cuni.cz] > Sent: Wednesday, January 09, 2002 3:54 AM > To: gpc(a)gnu.de > Subject: Complex_SqRt bug > > The complex square root function crashes with a funny error message > on some arguments close to the real line: > > [pas]% cat sqrt.pas > program SqrtTest (Output); > > var > C: Complex; > > begin > C := Sqrt (Cmplx (4.2, 1e-8)); > WriteLn ('OK') > end. > [pas]% uname -a ; gpc -v > Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 > unknown > Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs > gpc version 20011222, based on 2.95.2 19991024 (release) > [pas]% gpc sqrt.pas > [pas]% ./a.out > ./a.out: argument to `SqRt' is < 0 (error #708 at 805d837) > [pas]% > > > The square root is computed as > > \sqrt{X+iY} = \sqrt{(A+X)/2} + i \sqrt{(A-X)/2} sgn(Y), > > where A=|X+iY|. It seems that due to inaccuracies etc., A may > turn out to be _less_ than |X|, if |Y| << |X|, which means that > SqRt((A+-X)/2) gets a negative argument. I suggest the following patch. > > --------------------------------------------------- > diff -U3 orig/p/rts/math.pas p/rts/math.pas > --- orig/p/rts/math.pas Mon Sep 3 12:48:15 2001 > +++ p/rts/math.pas Mon Jan 7 21:34:43 2002 > @@ -192,8 +192,7 @@ > > function Complex_SqRt (z: Complex): Complex; > var > - a: Double; > - Sign: Integer; > + a, b: Double; > begin > { SqRt (x + yi) = +/- (SqRt ((a + x) / 2) +/- i * SqRt ((a - x) / 2)) > > @@ -203,10 +202,15 @@ > Principal value defined in the Extended Pascal standard: Exp (0.5 * > Ln (z)), > i.e. Sign (Re (SqRt (z)) := 1, Sign (Im (SqRt (z))) := Sign (Im (z)) > } > a := Abs (z); > - if Im (z) < 0 then Sign := -1 else Sign := 1; > - if a <> 0 > - then Complex_SqRt := Cmplx (SqRt ((a + Re (z)) / 2), Sign * SqRt ((a > - Re (z)) / 2)) > - else Complex_SqRt := 0 > + if a = 0 then Complex_SqRt := 0 > + else begin > + b := SqRt ((a + Abs (Re (z))) / 2); > + if Abs (Im (z)) > Abs (Re (z)) then a := SqRt ((a - Abs (Re (z))) / > 2) > + else a := Abs (Im (z)) / (2 * b); > + if Re (z) < 0 then begin var c: Double = a; a := b; b := c end; > + if Im (z) < 0 then Complex_SqRt := Cmplx (b, -a) > + else Complex_SqRt := Cmplx (b, a) > + end > end; > > function Complex_Ln (z: Complex): Complex; > ---------------------------------------------------- > > It would also work to simply insert > > if Abs (Re (z)) > a then a := Abs (Re (z)); > > into the original version, but the patch above gives more accurate > results (even for arguments which do not trigger the bug). > > > When talking about math.pas, I also suggest a little optimization to > the complex logarithm function; \log \sqrt x = (\log x)/2, but the RHS > is (I guess) computed faster and more precisely: > > --------------------------------------------------- > diff -U3 orig/p/rts/math.pas p/rts/math.pas > --- orig/p/rts/math.pas Mon Sep 3 12:48:15 2001 > +++ p/rts/math.pas Mon Jan 7 22:10:08 2002 > @@ -211,7 +211,8 @@ > > function Complex_Ln (z: Complex): Complex; > begin > - Complex_Ln := Cmplx (Ln (Abs (z)), ArcTan2 (Im (z), Re (z))) > + Complex_Ln := Cmplx (Ln (Sqr (Re (z)) + Sqr (Im (z))) /2, > + ArcTan2 (Im (z), Re (z))) > end; > > function Complex_Exp (z: Complex): Complex; > ----------------------------------------------------- > > > Emil Jerabek

2 1

Makeinfo & info misbehavior and like ...
by Mirsad Todorovac 08 Jan '02

08 Jan '02

Hi, all, Happy New Year to everybody!!! Best wishes for all your projects and all your areas of life! -------------------------------------------------------------------- You probably remember me having problems with iso-8859-2 (Latin 2) charset when translating GNU Pascal documentation to Croatian. If you are doing something similar to some other languages which require 8-bit (above first 127) characters, I've noticed some problems with the way GNU 'info' displays menu items that contain them - GNU 'info' shifts the "hotspots" of every menu item bellow first such character by one line, so you have to select a line bellow an item to select that item. I'm not to proud with the way I coped with this, since I had to leave those menu items in English, and translate them on the right side in description part (where 8-bit chars are treated correctly). Any better ideas? -------------------------------------------------------------------- 'makeinfo' inserts spurious line-breaks when 8-bit chars and DOS-style line-breaks are present. After figuring out to erase CTRL-M's from the file, 'makeinfo' output began to look as expected. The problematic was @table @asis ... @end @table section (others didn't show problems with or without CRTL-Ms ... I don't know whether GNU 'makeinfo' renders tables correctly under MS DOS enviroment (in this case my solution would break there)????? Thanks for help in advance? -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

2 2

³Ì·s®ø®§¤½§G , ½Ð°Ñ¾\¥»«Hªþ¥ó¤§»¡©úÀÉ . 4FxlrOMtTMAD0Q4cghe9Lhszm
by 4QY4B5jehlPBMS＠gcn.net.tw 07 Jan '02

07 Jan '02

. . . . .h

1 0

recent mingw32 (windows) binary available
by Jerry van Dijk 05 Jan '02

05 Jan '02

I wanted to give GPC a testdrive, but I could not find a recent mingw32 binary version, so I was forced to build my own. As it might be useful to others, I've made it available through my webpage: http://users.ncrvnet.nl/gmvdijk/pascal As I have only limited webspace, I had to keep the binary minimal. If someone wants to move the binary to another place where it will be more accessable, that would be fine, as would be adding the documentation, test programs, etc. to it. Note that this is a native windows build, not a cross build. It includes everything (including pdcurses) that was needed to run the testsuite with gpc and mingw32. If anyone has questions, please contact me directly, as I am not a member of this list. gr. Jerry. -- -- Jerry van Dijk | email: jvandyk(a)attglobal.net -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk

2 1

GPC 2.1 RC 2 released
by Frank Heckenbach 05 Jan '02

05 Jan '02

Hi everyone, GPC version 20011222, the release candidate #2 for GPC 2.1, has been uploaded to the usual places, CVS and FTP: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/gpc-20011222.tar.gz The main changes made since RC 1 are in the searching of unit source and GPI files (thanks to a bug report by The Chief), the handling of packed arrays (thanks to a bug report by Emil Jerabek) and set constructors (due to some bugs found by myself). If you use any of these things, you might want to check if the changes didn't break any of your code. There is also one new "feature", the Intl (internationalization) unit by Eike Lange. (I know that normally one should not do major additions so short before a release, but the unit is completely separate from the rest of the compiler and run time system, so even a very unlikely fatal bug would not affect the stability of the whole system.) Again, I've tested it on some systems, test reports from other systems are welcome, and if you find new or especially important bugs, or very important missing features, please report them. Merry Xmas, Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 5

error in new gpc, not present earlier
by J.Booij＠wbmt.tudelft.nl 04 Jan '02

04 Jan '02

At the Delft University of Technology, Mechanical Engineering, Structural optimization and Computational Mechanics group we have been using gpc for quite a while for a fairly large project, a finite element package. This runs on linux. With the most recent version of gpc the compiler will not compile three of the files, the older version we have perfoms the compile without problems. Removing (by commenting out) a part of the code allowed the compiler to successfully terminate, but then the result is of course useless. I have tried to isolate the problem by including all the required information on types, variables, constants, etc with include files, but in that case the compilation is successful. One of the actual routines makes use of 17 units (with uses). I am sending this message in the hope that it will be of some use, I realize that I am providing only very scanty information, but sending all the necessary information would give much more than you would probably want. Posibly the gdb information will give some clues to where the problem arises. Please contact me if I can help by providing more information. I am working on Linux, the output of uname -a is: Linux dutw52.wbmt.tudelft.nl 2.4.7-10enterprise #1 SMP Thu Sep 6 16:48:20 EDT 2001 i686 unknown . The compilation ends with the message: #progress# ERROR/backmesh.p (428) gpc: Internal compiler error: program gpc1 got fatal signal 11 gpc1: gpc exited with status 1 gpc1: gpc exited with status 1 The new version of gpc gives (from gpc -v) Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20011222, based on 2.95.2 19991024 (release) The old one gives Reading specs from /usr/tm/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20001015, based on 2.95.2 19991024 (release) The output from gdb as suggested in your manual is: gdb /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/gpc1 core GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/gpc1 /tmp/ccd3UKqD.i -quiet -du'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x082412a2 in int_cst_lt_always (val1=0x83be324, val2=0x83b784c) at ../../../gcc-2.95.2/gcc/p/types.c:1816 1816 if ((TREE_UNSIGNED (val1) || TREE_UNSIGNED (TREE_TYPE (val1))) (gdb) backtrace #0 0x082412a2 in int_cst_lt_always (val1=0x83be324, val2=0x83b784c) at ../../../gcc-2.95.2/gcc/p/types.c:1816 #1 0x082416c9 in select_integer_type (val1=0x83b784c, val2=0x83b7890, why=LE_EXPR) at ../../../gcc-2.95.2/gcc/p/types.c:1900 #2 0x081f4af9 in build_pascal_binary_op (code=LE_EXPR, exp1=0x83b784c, exp2=0x83b7890) at ../../../gcc-2.95.2/gcc/p/gpc-common.c:2377 #3 0x0822ed32 in yyparse () at parse.y:4485 #4 0x081e3744 in compile_file (name=0xbfffeb91 "/tmp/ccd3UKqD.i") at ../../../gcc-2.95.2/gcc/p/../toplev.c:3265 #5 0x081e749b in main (argc=14, argv=0xbfffe9c4) at ../../../gcc-2.95.2/gcc/p/../toplev.c:5440 #6 0x40049507 in __libc_start_main (main=0x81e6274 <main>, argc=14, ubp_av=0xbfffe9c4, init=0x80491c8 <_init>, fini=0x8249590 <_fini>, rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbfffe9bc) at ../sysdeps/generic/libc-start.c:129 J. Booij J.Booij(a)wbmt.tudelft.nl J.Booij(a)wbmt.tudelft.nl

1 0

Lazy I/O
by Emil Jerabek 02 Jan '02

02 Jan '02

Accordnig to both ISO standards, readln(f) should be equivalent to get(f), when eoln(f) is true. In GPC the former seems to be implemented as lazy I/O, while the latter does not. Here is an example (enter three lines of text to test it). ---------------------------- program echo3lines(input,output); procedure copyline; begin while not eoln do begin output^:=input^; get(input); put(output) end end; begin write('Enter the first line: '); copyline; readln; writeln; write('Enter the second line: '); copyline; get(input); writeln; write('Enter the last line: '); copyline; readln; writeln end. ---------------------------------------- Is this a bug or a feature? Emil Jerabek

4 15

Re: GPC 2.1 RC 1 released
by Frank Heckenbach 31 Dec '01

31 Dec '01

Hi, > sounds great! Will there be an OS/2 (emx) binary, too? I don't have the > setup for a build myself these days. Please ask on the list (gpc(a)gnu.de). I don't have an EMX setup myself, but maybe someone else does. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Random in GPC Pascal?
by A. Huici 28 Dec '01

28 Dec '01

Hello, How I can use "Random" function or another pseudo random number generator in GPC Pascal? Sincerely, a.huici(a)telia.com

3 2

Interfacing C++
by Robert.Roebling＠t-online.de 23 Dec '01

23 Dec '01

Hi, I consider writing an GNU Pascal interface to a rather large C++ library. Ideally, I would like to match Pascal objects to C++ classes, either directly or indirectly. There are already Python, Perl, Basic and Lua bindings for the same C++ library, so we are not uninformed about the work involved in writing a new language binding. My question is if there is any helper tool that makes lifer for this kind of thing easier than having to do everything by hand? Thanks for any info. Please reply to me directly as I am not subscribed to the GPC mailing list - I am subscribed to too many already. The C++ library is free and Open Source, if that matters to anyone. It is the GUI library wxWindows. Regards, Robert

1 0

[Fwd: ANNOUNCE: DJGPP V2.03 Refresh Beta]
by Maurice Lombardi 20 Dec '01

20 Dec '01

Hi gpc/djgpp users I have recompiled gpc-20011202 for the "refresh" version announced below. But I have no Windows 2000 or XP machine to test it. I have only checked that it works well with W98se. It is uploaded on agnes as ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc-20011202-gcc-2953.i586-pc-msdosdjgpp-refresh.zip When running in a W98se Dos box it gives zero error (2 tests skipped as usual) when running the test suite by going into the gcc/p/test directory and issuing simply "make": this was one of the improvements announced (Nesting will recover selectors). The dostest.bat which was designed to overcome this bug by splitting the tests in chunks of 250 will no more be necessary when/if this version will be uploaded to simtelnet. Meanwhile do not use it "as is" with this version because it triggers an other bug ... apparently the maximum length of the command line which can be passed from dostest.bat to make has been somewhat decreased: it works if the tests are split in chunks of only 128 ... The following diff will do the job: --- dostest.bat.orig Thu Jan 4 07:22:08 2001 +++ dostest.bat Thu Dec 20 18:57:44 2001 @@ -28,6 +28,6 @@ if exist make.out del make.out if exist dtlist.* del dtlist.* make msg -ls -1 *.pas | split -l 250 - dtlist. +ls -1 *.pas | split -l 128 - dtlist. for %%f in (dtlist.*) do make MASK="`cat %%f`" pascal.check-long >> make.out sh test_sum < make.out This diff can be included without harm in next gpc snapshots. Meanwhile a file gpc-test-20011202.zip (with modified dostest.bat) has been uploaded to agnes in the same directory as above for people wanting to check this version of gpc with Windows 2000 / XP. (The test suite is not included with the binaries). -------- Message d'origine -------- Objet: ANNOUNCE: DJGPP V2.03 Refresh Beta Date: Tue, 18 Dec 2001 08:47:21 -0600 (CST) De: sandmann(a)clio.rice.edu (Charles Sandmann) Répondre-A: djgpp(a)delorie.com A: djgpp-announce(a)delorie.com DJGPP release V2.03 has been available since January 2000. In that time a small number of bugs have been discovered and corrected. Windows 2000 and Windows XP were released with some bugs in their DOS support. The goal for the refreshed release was to provide complete binary compatibility and fixes for known problems that were simple and low risk to fix. The updated version works with Windows ME, Windows 2000 and Windows XP in addition to earlier platforms. Fixes included in the update distribution: Windows 2000 and XP long file name support fixes Windows 2000 and XP program nesting fixes Windows 2000 and XP debugging breakpoint fixes Windows NT, 2000 and XP sbrk address wrap fixes Windows ME fixes in rename and mkdir __dpmi_simulate_real_mode_procedure_retf_stack fix Symify fixes to prevent crashes on symbol interpretation Error message instead of crash if no selector for _dos_ds Termios read bug fix on STDIN Format fix in strftime Freopen will always reuse same handle Nesting will recover selectors (long makes should not fail) Itimer fix for usecs == 0 Long path bug fixes (to prevent being treated as /) FSEXT fixes for dup and dup2 Y2K fix in djasm More details (and html links to updated distributions) are available from: http://clio.rice.edu/djgpp/win2k/main_203.htm The files can also be retrieved using ftp from: ftp://clio.rice.edu/djgpp/v203u/ Some key GNU distributions have been rebuilt with the updated library to make installs and building other packages easier on Windows 2000 and XP. If you have a chance (or need any of the fixes mentioned) please try out the new distributions. If the distributions are an improvement over the current distributions they will replace the files on Simtel. -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

Solaris 8 binaries
by Mariusz Zynel 20 Dec '01

20 Dec '01

Hi All, Due to some inquires I had recently, have just build latest GPC (20011202) under Solaris 8 using GCC 2.95.3. Binaries are packaged with native Solaris tools and are available at: ftp://math.uwb.edu.pl/pub/solaris8 as well as: ftp://agnes.dida.physik.uni-essen.de/home/mariusz Regards -- . Mariusz Zynel University of Bialystok, Institute of Mathematics Akademicka 2, 15-267 Bialystok, Poland ----------------------------------------------------------------------- mailto:mariusz@math.uwb.edu.pl office: +48 (85) 745 7552 http://math.uwb.edu.pl/~mariusz mobile: +48 (604) 777 588

2 1

Re: bug report
by Russell Whitaker 20 Dec '01

20 Dec '01

If you take the listing and make some minor changes so it looks like: unit Buff; interface const MAXLINES = 20000; type lline = string ( 4000 ); procedure BB_AddLine( Aline: lline ); {adds to end} implementation { var cap : integer;} type ptrline = ^Line; Line = string ( ); TbbArray = array[1..MAXLINES] of ptrline; var BigBuffer : Tbbarray; {array of pointers to data} LineCount : integer = 0; procedure BB_AddLine( Aline: lline ); begin inc( LineCount ); BigBuffer[ LineCount ] := new( ptrline, length( Aline )); BigBuffer[ LineCount ]^ := Aline; end; end. Compile the above, you get: buff.pas:17: parse error before `)' buff.pas:17: missing expression buff.pas:17: warning: missing string capacity - assuming 255 buff.pas: In procedure `Bb_addline': buff.pas:28: too many arguments to `New' Now, uncomment lines 12,13 so it reads var cap: integer; And add in cap to line 17 so it reads Line = string( cap ); The unit now compiles and works as expected. (creates strings with capacity = length at runtime) Russ

3 3

starting problems ...
by Fernando Carrilho 20 Dec '01

20 Dec '01

I'm trying to start to work with gnu pascal on a solaris 2.6 platform. After installing the binary distribution 19990118, my first attempts to compile a simple program (demoproc.pas, included in the distribution) have no sucessfull at all: using gpc --automake demoproc.pas produces the output ld: fatal: file crt1.o: open failed: No cuch file or directory ld: fatal: file crti.o: open failed: No cuch file or directory ld: fatal: file crtbegin.o: open failed: No cuch file or directory ld: fatal: library -lgcc: not found ld: fatal: file crtend.o: open failed: No cuch file or directory ld: fatal: file crtn.o: open failed: No cuch file or directory It looks something is misconfigured ... I'm using GPC_EXEC_PREFIX=/usr/local/lib/gcc-lib/*/* This should be a very basic thing to solve, but .... can someone help ? Thank you, Fernando Carrilho

2 1

New GDB version 5.1 available
by Pierre Muller 19 Dec '01

19 Dec '01

This is just to inform people that GDB 5.1 was released. http://sources.redhat.com/ml/gdb-announce/2001/msg00010.html Extract of the annoucement of particular interest for gpc and fpc-pascal mailing lists : ........................ What has changed in GDB? *** Changes in GDB 5.1: ........................ * Support for debugging Pascal programs. GDB now includes support for debugging Pascal programs. The following main features are supported: - Pascal-specific data types such as sets; - automatic recognition of Pascal sources based on file-name extension; - Pascal-style display of data types, variables, and functions; - a Pascal expression parser. However, some important features are not yet supported. - Pascal string operations are not supported at all; - there are some problems with boolean types; - Pascal type hexadecimal constants are not supported because they conflict with the internal variables format; - support for Pascal objects and classes is not full yet; - unlike Pascal, GDB is case-sensitive for symbol names. >>>>>>>>>>>>>>>>>>>>>>< The pascal language support is essentially my work, but it is still far from complete and far from perfect. One of the latest patch applied should allow to get a nice representation of GPC strings. Please don't hesitate to report problems about pascal support .... Two reminders: -- if you really can't do what you used to do anymore with GDB, try simply to set the language to C with (gdb) set langugage c and try again if it works better. Don't forget that if you are in pascal language, pascal syntax must be used: so to change the value of a variable 'x' in the program, you will need to use (gdb) set x := 5 instead of (gdb) set x = 5 for older GDB version. In the hope that these changes will be useful for the pascal community. Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99

6 8

Re: bug report
by Russell Whitaker 19 Dec '01

19 Dec '01

Hi Thanks for the prompt and detailed reply. Below is a copy of program with errors removed. Noteable: 1. a var declaration is required before a type declaration. 2. later on, the varible just declared really isn't needed. in this case a "new(ptrline, length( Aline ))" works just as well. There may be several ways you could redesign gpc to remove the var requirement. One way would be to allow a dummy varible in a type declaration so new() would know there is more than one item. Russ unit Buff; interface const MAXLINES = 20000; type lline = string ( 4000 ); procedure BB_AddLine( Aline: lline ); {adds to end} implementation var cap : integer; type ptrline = ^Line; Line = string ( cap ); TbbArray = array[1..MAXLINES] of ptrline; var BigBuffer : Tbbarray; {array of pointers to data} LineCount : integer = 0; procedure BB_AddLine( Aline: lline ); begin inc( LineCount ); cap := length( Aline ); BigBuffer[ LineCount ] := new( ptrline, cap ); BigBuffer[ LineCount ]^ := Aline; end; end.

2 1

GPC 2.1 RC 1 released
by Frank Heckenbach 17 Dec '01

17 Dec '01

Hi everyone, GPC version 20011202 has been uploaded to the usual places, CVS and FTP: ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/gpc-20011202.tar.gz We consider this version the Release Candidate #1 for the upcoming GPC 2.1 release. Many things have changed since the last announced version. (Please see the `Done' section of the To-Do list and the `News' chapter in the manual or on the homepage for details.) Though many bugs have been fixed since the last version, there is still a number of known bugs left, some of which are longstanding issues that will take some time to be fixed. Therefore, according to a discussion in gpc(a)gnu.de, we have decided to make a 2.1 release now, anyway. This version has been tested successfully (i.e., the test suite ran without failures -- except martin2a.pas and fjf434c.pas on some platforms which should have been moved to knownbugs, and will be further investigated before the final release) on the following systems: i586-pc-linux-gnulibc1 (gcc-2.8.1) i586-pc-linux-gnulibc1 (gcc-2.95.3) i386-pc-msdosdjgpp (gcc-2.8.1) sparc-sun-solaris2.6 (gcc-2.95.2) mips-sgi-irix6.5 (gcc-2.95.2) alpha-dec-osf4.0b (gcc-2.95.3) Test reports from other systems are welcome. If you find new or especially important bugs, or very important missing features, let us know so we can perhaps fix them before 2.1. Any major changes, however, will not be done in the 2.1 source tree, but rather in the next alpha versions leading to 2.2. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

4 4

"set_words_big_endian"
by Sven Jauring 17 Dec '01

17 Dec '01

Hi all A couple of months ago, I someone could tell me whether it was possible to have record variants of sets lesser than 32 members to be aligned. Frank Heckenbach told me to make GPC use 8 bits as the smallest size for a set, by changing TSelElement in p/rts/sets.pas and set_word_size and set_alignment in p/util.c. That worked great, had it not been for the fact that the code depended on reversed ordering of those bytes! (Actually, what I need is the elements in the set to represent the binary bits in a consecutive order) In the following code, I need BIT0 to be represented by the most significant bit of USRINT, and BIT15 by the least significant. *********************************** TYPE INT16 = INTEGER(16); INT8 = packed -128..127; INT0_65535 = packed 0..65535; B_TYPE = (B1, B2, B3, B4, B5, B6, B7, B8); BITS = (BIT0, BIT1, BIT2, BIT3, BIT4, BIT5, BIT6, BIT7, BIT8, BIT9, BIT10, BIT11, BIT12, BIT13, BIT14, BIT15); B_TYPE_SET = set of B_TYPE; BIT_SET = set of BITS; VAR OUT_REC = record case INT16 of 0 : (BSLB : B_TYPE_SET; BSHB : B_TYPE_SET); 1 : (USRINT : INT0_65535); 2 : (BT : BIT_SET); end; ************************************ I tried to change set_words_big_endian to "1", in p/util.c! That made the bit representation work, but when I tried running p/test/setest.pas, I got the following result: "The set opcodes work : [] False mul plus minus in and rel False" Is there a way to get sets to use "set_words_big_endian", or am I on a totally hopeless mission, all together? It would really save my day if this would be possible! Best Regards and Merry Christmas Sven Jauring

1 0

bug report
by Russell Whitaker 15 Dec '01

15 Dec '01

hi Some time age wrote a program using an array of pointers to fixed capacity strings. The plan is to rewrite the program to use variable capacity strings. So while playing to see what *might* work got this: ../../../gcc-2.95.3/gcc/p/types.c:1107: failed assertion `capacity && TREE_CODE (capacity) == INTEGER_CST' buff.pas:25: Internal compiler error in `declared_string_capacity', at types.c:1107 Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://home.pages.de/~GNU-Pascal/todo.html> for details. from this: unit Buff; interface const MAXLINES = 20000; type lline = string ( 4000 ); {buffer for data xfer} procedure BB_AppendLine( Aline: lline ); {adds to end} implementation var cap : integer; type ptrline = ^Line; Line = string ( cap ); TbbArray = array[1..MAXLINES] of ptrline; var BigBuffer : Tbbarray; {array of pointers to data} LineCount : integer = 0; FileUpdate : boolean = false; LineItem : Line; procedure BB_AddLine( Aline: lline ); begin cap := lline.length; BigBuffer[ LineCount ] := new( ptrline, LineItem ); BigBuffer[ LineCount ]^ := Aline; inc( LineCount ); end; j.i.c., installed that latest patch - same results. Incidently, this won't work, either: type cap = integer; Aline = string( cap ); {gives err msg} Thanks, Russ

2 1

Internal compiler error related to packed arrays
by Emil Jerabek 14 Dec '01

14 Dec '01

Tested with GPC 2001/05/02 on Linux (i586), and GPC 2001/06/23 on DJGPP: [pas]% cat bug.pas program testbug; var t : packed array[0..1]of 0..32768; {non-packed is OK, <=32767 is OK} h : 0..1; {or integer or whatever} begin h:=0; t[h]:=0 {t[0]:=0 is OK} end. [pas]% gpc bug.pas bug.pas: In main program: bug.pas:10: Internal compiler error in `build_modify_expr', at gpc-typeck.c:6846 Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://home.pages.de/~GNU-Pascal/todo.html> for details. [pas]%

2 1

What should Trim do?
by Martin Liddle 13 Dec '01

13 Dec '01

What should the trim function do? It seems to me that under gpc it removes trailing spaces from a string. Under Delphi it removes leading and trailing spaces. Unfortunately I don't have any Turbo Pascal documentation to hand (I assume trim is a Borlandism). -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.

5 7

Units o libraries to create 2D graphics
by pascal＠gargal.com 13 Dec '01

13 Dec '01

Hello, I just installed gpc in a HP-UX 11.00. I programmed in Pascal a long time ago. I'd like to know if you know which unit or library I can use to create jpg files with 2D graphics like number of users vs. memory usage to make them viewable in a Web page? Thanks for your help! Hermenegildo

2 1

Re: GPC 2.1 RC 1 released
by CBFalconer 13 Dec '01

13 Dec '01

Maurice Lombardi wrote: > > CBFalconer wrote: > > > Maurice Lombardi wrote: > > > >>Frank Heckenbach wrote: > >> > >>>da Silva, Joe wrote: > >>> > >>>>Well AFAIK, there is no "later than 2.95.3", that is suitable. From > >>>>previous discussions, 3.XX is not currently supported by GPC and > >>>>2.96 is a broken version of GCC, so 2.95.3 is "it" (since this version > >>>>for DJGPP is not listed below, by implication there were no problems > >>>>with it, so I expect Maurice will have a build available shortly:-). > >>>> > >>>I haven't tested this particular configuration because I know that > >>>Maurice will do. :-) Though I don't expect problems here. > >>> > >>No problem indeed: 0 errors in the test suite. > >>It is uploaded as usual under the fixed link > >> > >>ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2953b.zip > > > > I assume that is the new version, even though it has the identical > > name to the older one? How are we to keep track :-) > > It is always the last alpha I have compiled with zero error in running the test suite. > The link points to the actual file in the same directory > ( gpc-20011202-gcc-2953.i586-pc-msdosdjgpp.zip presently ). > There is no reason not to download the last version successfully compiled and tested. > A fixed link is handy for people having http pages which points to gpc Woops - possible problem. I note the "i586" in that name. I am running on a 486. Does it have Pentium only opcodes embedded somewhere? -- Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)XXXXworldnet.att.net) Available for consulting/temporary embedded and systems. (Remove "XXXX" from reply address. yahoo works unmodified) mailto:uce@ftc.gov (for spambots to harvest)

3 2

Re: GPC 2.1 RC 1 released
by da Silva, Joe 13 Dec '01

13 Dec '01

Well AFAIK, there is no "later than 2.95.3", that is suitable. From previous discussions, 3.XX is not currently supported by GPC and 2.96 is a broken version of GCC, so 2.95.3 is "it" (since this version for DJGPP is not listed below, by implication there were no problems with it, so I expect Maurice will have a build available shortly:-). BTW, I did notice at "http://www.distrowatch.com/debian.htm", that there exists also a GCC 2.95.4, but I have not heard anything about this version ... Joe. PS. I've just noticed - the "Reply To" stuff has stopped working! :-( > -----Original Message----- > From: CBFalconer [SMTP:cbfalconer@yahoo.com] > Sent: Thursday, December 13, 2001 11:18 AM > To: gpc(a)gnu.de > Subject: Re: GPC 2.1 RC 1 released > > Frank Heckenbach wrote: > > > > GPC version 20011202 has been uploaded to the usual places, CVS and > > FTP: > > > > > ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/gpc-20011202.tar.g > z > > > > We consider this version the Release Candidate #1 for the upcoming > > GPC 2.1 release. > > > > Many things have changed since the last announced version. (Please > > see the `Done' section of the To-Do list and the `News' chapter in > > the manual or on the homepage for details.) > > > > Though many bugs have been fixed since the last version, there is > > still a number of known bugs left, some of which are longstanding > > issues that will take some time to be fixed. Therefore, according to > > a discussion in gpc(a)gnu.de, we have decided to make a 2.1 release > > now, anyway. > > > > This version has been tested successfully (i.e., the test suite ran > > without failures -- except martin2a.pas and fjf434c.pas on some > > platforms which should have been moved to knownbugs, and will be > > further investigated before the final release) on the following > > systems: > > > > i586-pc-linux-gnulibc1 (gcc-2.8.1) > > i586-pc-linux-gnulibc1 (gcc-2.95.3) > > i386-pc-msdosdjgpp (gcc-2.8.1) > > sparc-sun-solaris2.6 (gcc-2.95.2) > > mips-sgi-irix6.5 (gcc-2.95.2) > > alpha-dec-osf4.0b (gcc-2.95.3) > > > > Test reports from other systems are welcome. > > > > If you find new or especially important bugs, or very important > > missing features, let us know so we can perhaps fix them before 2.1. > > > > Any major changes, however, will not be done in the 2.1 source tree, > > but rather in the next alpha versions leading to 2.2. > > How about djgpp with gcc 2.95.3 (or later) ? > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)XXXXworldnet.att.net) > Available for consulting/temporary embedded and systems. > (Remove "XXXX" from reply address. yahoo works unmodified) > mailto:uce@ftc.gov (for spambots to harvest) > >

5 7

Will GPC ever be an integrated part of GCC?
by Preben Mikael Bohn 13 Dec '01

13 Dec '01

This question has probably been asked before, but anyway... Will GPC ever be an integrated part of GCC? Wouldn't this automatically increase it's use? Best regards Preben Bohn ===== This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message. __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

2 1

Re: Units o libraries to create 2D graphics
by da Silva, Joe 13 Dec '01

13 Dec '01

As I recall, there is a Pascal translation of the Independent JPEG Group's graphics library, available at Simtel.Net (haven't tried it, so I don't know if it's any good, nor if it does what you want). There are also some graphics libraries for Pascal listed at "http://www.thefreecountry.com/developercity/graphicslibraries.shtml" that support the JPEG format, some may include source. Again, haven't tried any, so the same comments apply. Of course, the JPEG format is fairly sophisticated (ie. complicated), with variable compression ratio (depending on image quality), so for a small number of images (ie. small storage requirements), it might be simpler to use another format, such as GIF or PCX? Beware that GIF compression uses the LZW algorithm and is patented, although it's use is optional (BTW, AFAIK, the LZW patent should expire in mid-2003). Joe. PS. Hmmm ... "Reply To" is working again! :-) > -----Original Message----- > From: pascal(a)gargal.com [SMTP:pascal@gargal.com] > Sent: Saturday, December 08, 2001 4:02 AM > To: gpc(a)gnu.de > Subject: Units o libraries to create 2D graphics > > Hello, I just installed gpc in a HP-UX 11.00. I programmed in Pascal a > long time ago. > I'd like to know if you know which unit or library I can use to create jpg > files with > 2D graphics like number of users vs. memory usage to make them viewable in > a Web page? > > Thanks for your help! > Hermenegildo > >

1 0

test result
by Russell Whitaker 13 Dec '01

13 Dec '01

Hi Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.3/specs gpc version 20011202, based on 2.95.3 20010315 (release) # of GPC tests 2177 # of GPC tests passed 2176 # of GPC tests skipped 1 # of GPC tests failed 0 Good. Thanks, Russ

1 0

ptags utility
by Loris Caren 11 Dec '01

11 Dec '01

Does anyone know of a ctags compatiable utility which was been extended to swallow pascal as well as c - I've found some hints that such a beast might exist, but the one that ships with Linux systems doesn't seem to.

1 0

Problems with iso-8859-2 charset and nroff source manpage X-lation
by Mirsad Todorovac 11 Dec '01

11 Dec '01

Hi, everybody, Anybody help me? I'm puzzled with this - I don't know how to display non-ASCII letters on a man page, and this seriously affects my efforts to translate docs to Croatian (considers everybody from non-US locales, I guess). So, the original looks like: ----------------------------------------------------------------- .SH DESCRIPTION This man page does not contain much information about GNU Pascal because the unstructured man page format is not well suited for documenting a large program such a GNU Pascal. You can find the relevant information in the GNU Pascal Manual which is avilable in ... ----------------------------------------------------------------- My translation is: ----------------------------------------------------------------- .SH OPIS Ova man stranica ne sadr¾i previ¹e informacija o GNU Pascalu jer nestrukturiran format man stranice nije prikladan za dokumentiranje tako velikog programa kao ¹to je GNU Pascal. Relevantne informacije mo¾ete pronaæi u GNU Pascal priruèniku koji je raspolo¾iv u Texinfo formatu i formatima proivedenima iz njega, ... ------------------------------------------------------------------ But it gets printed like (messy): ------------------------------------------------------------------ OPIS Ova man stranica ne sadrM->i previM-9e informacija o GNU Pascalu jer nestruktu - riran format man stranice nije prikladan za dokumentiranje tako velikog programa kao M-9to je GNU Pascal. Relevantne informacije moM->ete pronaM-fi u GNU Pascal priruM-hniku koji je raspoloM->iv u Texinfo formatu i formatima ... ------------------------------------------------------------------ In other words, '¾' ('z' with caret above) becomes M->, '¹' ('s' with caret above) becomes M-9, 'æ' ('c' with apostrophe above) becomes M-f ... and so on. It doesn't look pretty. Notice that I have iso-8859-2 (latin 2) font installed in terminal, and Pine displays so-called diacritic signs correctly. The problem is in ``more'' and it could be in ``info'' too, but I haven't translated all .texi files yet so I don't know. It's easy for me to write ``sed -e 's/¾/z/g' -e 's/¹/s/g' -e 's/æ/c/g' ...'' (on your terminal it may not look that way, but it's actually striping each character of it's 'apostrophe above' and 'caret above' marks) but I hope that somebody reading this has a better idea. Thanks for listening, Mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

4 10

20011123 good news - bad news
by Miklos Cserzo 10 Dec '01

10 Dec '01

Hi Folks, the good news about the 20011123 version under IRIX 6.5 is that it compiles without problems and no test fails with the 20011123 test kit. The writeln works properly thanks to the --big-endian trick of Frank. The bad news are: - the kit won't compile with the native sed/grep but with the GNU versions only. - the produced binary still leaks memory on string operations unless they are in the procedures. - the -static switch is broken. Here is the log with the -v switch: Reading specs from /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/specs gpc version 20011123, based on 2.95.2 19991024 (release) /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/gpcpp -lang-pascal -v -I/home/pugh/miklos/src -famtmpfile=/var/tmp/cca00jWd -fbig-endian -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_VERSION__=2.0 -D__GPC_RELEASE__=20011123 -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -Dunix -Dmips -Dsgi -Dhost_mips -DMIPSEB -D_MIPSEB -DSYSTYPE_SVR4 -D_LONGLONG -D_SVR4_SOURCE -D_MODERN_C -D__DSO__ -D__unix__ -D__mips__ -D__sgi__ -D__host_mips__ -D__MIPSEB__ -D_MIPSEB -D__SYSTYPE_SVR4__ -D_LONGLONG -D_SVR4_SOURCE -D_MODERN_C -D__DSO__ -D__unix -D__mips -D__sgi -D__host_mips -D__MIPSEB -D__SYSTYPE_SVR4 -Asystem(unix) -Asystem(svr4) -Acpu(mips) -Amachine(sgi) -D__CHAR_UNSIGNED__ -D__OPTIMIZE__ -D__LANGUAGE_C -D_LANGUAGE_C -DLANGUAGE_C -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__EXTENSIONS__ -D_SGI_SOURCE -D_MIPS_FPSET=32 -D_MIPS_ISA=_MIPS_ISA_MIPS3 -D_ABIN32=2 -D_MIPS_SIM=_ABIN32 -D_MIPS_SZINT=32 -D_MIPS_SZLONG=32 -D_MIPS_SZPTR=32 -D_COMPILER_VERSION=601 -U__mips -D__mips=3 -D__mips64 das.p /var/tmp/cca00jWd.i GNU Pascal Compiler PreProcessor version 20011123, based on gcc-2.95.2 19991024 (release) [AL 1.1, MM 40] SGI running IRIX 6.x #include "..." search starts here: #include <...> search starts here: /home/pugh/miklos/src /var/tmp/gpc/include /var/tmp/gpc/mips-sgi-irix6.5/include /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/include /usr/include End of search list. /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/gpc1 /var/tmp/cca00jWd.i -mno-abicalls -quiet -dumpbase das.pas -O -version -famtmpfile=/var/tmp/cca00jWd -fbig-endian -o /var/tmp/cca00jWd.s GNU Pascal version 2.95.2 19991024 (release) (mips-sgi-irix6.5) compiled by GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release). GNU Pascal version is actually 20011123, based on gcc-2.95.2 19991024 (release) /usr/bin/as -O2 -g0 -nocpp -show -G 0 -w -n32 -o /var/tmp/cca00jWd1.o /var/tmp/cca00jWd.s /usr/bin/../../usr/lib32/cmplrs/as -DEFAULT:abi=n32:isa=mips4:proc=r10k -O2 -g0 -nocpp -show -G 0 -w -n32 -o /var/tmp/cca00jWd1.o /var/tmp/cca00jWd.s /usr/lib32/cmplrs/asm -t5_ll_sc_bug -EB -pic2 -elf -O2 -g0 -G0 -w -mips4 -n32 /var/tmp/cca00jWd.s -o /var/tmp/cca00jWd1.o /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/collect2 -non_shared -init __do_global_ctors -fini __do_global_dtors -_SYSTYPE_SVR4 -woff 131 -n32 -o das.sgi /usr/lib32/mips3/nonshared/crt1.o /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/crtbegin.o -L/var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2 -L/usr/bin -L/var/tmp/gpc/lib /var/tmp/cca00jWd1.o -lgpc -lm -dont_warn_unused -lgcc -warn_unused -L/usr/lib32/mips3 -L/usr/lib32 -dont_warn_unused -lc -warn_unused -dont_warn_unused -lgcc -warn_unused /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/crtend.o /usr/lib32/mips3/crtn.o ld32: FATAL 9 : I/O error (/usr/lib32/mips3/nonshared/crt1.o): No such file or directory collect2: ld returned 32 exit status The crt1.o is actually in /usr/lib32/mips3. The /usr/lib32/mips3/nonshared is not exist. What is the civilized way to tell the compiler where to look for the proper objects? (Other than set up a symlink and fool the compiler.) Nice work otherwise, cheers, miklos

2 6

Logical Shift Right
by Gloria, Jing 09 Dec '01

09 Dec '01

Has anybody implemented a function to do Logical Shift Right operations on an integer in GNU PASCAL? SHR operator will do an arithmetic shift right. Or any suggestions on how to do this? I am using gpc version 20010623, based on 2.95.2 19991024 (release) on Solaris 7 in an Intel box.. Thanks in advance for any assistance. Jing Gloria Texas Instruments

5 6

How to build info from .texi???
by Mirsad Todorovac 09 Dec '01

09 Dec '01

Hi everybody! I tried to build info files from @texinfo .texi sources. What i've got is: > pwd /home/mtodorov/pascal/gcc-2.95.3/gcc/p/doc/en > makeinfo -I .. -I ../.. -I ../generated gpc.texi ./keywords.texi:15: Node `Kljuène rijeèi' previously defined at line 15. ./keywords.texi:15: Node `Kljuène rijeèi' previously defined at line 15. ./keywords.texi:15: Node `Kljuène rijeèi' previously defined at line 15. ./keywords.texi:15: Node `Kljuène rijeèi' previously defined at line 15. ./keywords.texi:15: Node `Kljuène rijeèi' previously defined at line 15. ./keywords.texi:15: Node `Kljuène rijeèi' previously defined at line 15. ./keywords.texi:15: Node `Kljuène rijeèi' previously defined at line 15. ./keywords.texi:15: Node `Kljuène rijeèi' previously defined at line 15. ./keywords.texi:15: Node `Kljuène rijeèi' previously defined at line 15. ./keywords.texi:15: Node `Kljuène rijeèi' previously defined at line 15. . . . ./keywords.texi:15: Node `Kljuène rijeèi' previously defined at line 15. ./keywords.texi:15: Node `Kljuène rijeèi' previously defined at line 15. Too many errors! Gave up. > I tried putting back `Keywords' instead of `Kljuène rijeèi', but I've got the same. Heeeeelp!!!!!!!!!! Marvin -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

2 1

Initializing variant records - how?
by Martin G C Davies 08 Dec '01

08 Dec '01

Hi, I need (want!) to initialize variant records. I have created a small example - doesn't compile of course because I can't find how to do it. I guess GPC can do it since VS_Pascal (IBM/MVS), VAXPascal and SPARCPascal all allow me to do it (all in different ways of course!). Anyone? Cheers, Martin. program varaint_test( input , output ) ; type variant_record = record case boolean of false : ( compare : integer( 32 ) ) ; true : ( case boolean of false : ( page , offset : integer( 16 ) ) ; true : ( len , disp : integer( 16 ) ) ; ) ; end ; var mgcd : variant_record := ( compare : 12345 ) ; (* How can I do this? *) begin writeln( 'ok' ) ; end.

3 6

Change in packing
by Martin Liddle 08 Dec '01

08 Dec '01

Having got 20011123 to compile, I found three differences in the compiler from our previous gpc version 20010604. It objected in two different units to code using a GOTO with the error message: " Label '1' used before containing binding contour'. The code looks correct and compiles and executes properly with the previous version. Is this a known problem as it looks as though it should be fairly easy to produce a test case if required. However the problem is easily worked around. Secondly it picked up a number of occurrences of incorrect code of the form St[9]:=Chr(65)+Random(26) that had been accepted by the previous version; so that is progress. My main problem is that the packing of records appears to have changed. For instance a record of the form TCompR=Packed Record AName:String(49); AClass:1..40; Awel:Set of 1..120; RLate,RTime:Integer; End; has the same size as previously (as reported by sizeof) but when using this record to read from a file written by code compiled with our previous version of the compiler gives nonsense values for AClass and Awel. I can work around this particular problem by changing the definition of AClass to Byte but sadly our code has a great many packed records (because it was originally written a long time ago when storage was more precious) but making all the files backwards compatible is not going to be trivial. So two questions: Is there any switch that will restore the previous packing behaviour? Assuming there is not, could someone explain in more detail what has changed and what are the rules governing packing so that I can work out how to redefine each of the affected records. -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.

3 11

Set Functions in RTS
by Loris Caren 06 Dec '01

06 Dec '01

I've created a 68k cross gpc (from gpc20010623). I fairly quickly found that I needed RTS set functions such as_p_set_equal and haven't found them anywhere. Can anybody point me to them, or check over the stubs that I've come up with (which appear to work for sets with fewer than 32 members)? I'm paricularly unhappy with the p_set_equal which seems to get called with one pointer being NULL if one is testing against the empty set. /* $Id$ */ #include <assert.h> /*------------------------------------------------------------------------ * *------------------------------------------------------------------------- */ typedef int SET_WORD; _p_set_equal(SET_WORD *s1, int s1z, int s1Size, SET_WORD *s2, int s2z, int s2Size) { if (s2 == (SET_WORD*)0) return *s1 == 0; if (s1 == (SET_WORD*)0) return *s2 == 0; return *s1 == *s2; } _p_set_copy(SET_WORD *s, int sz, int sSize, SET_WORD *d, int dz, int dSize) { assert(d && s); *d = *s; } _p_set_union(SET_WORD *s1, int s1z, int s1Size, SET_WORD *s2, int s2z, int s2Size, SET_WORD *d, int dz, int dSize) // [A] + [B] { *d = *s1 | *s2; } _p_set_intersection(SET_WORD *s1, int s1z, int s1Size, SET_WORD *s2, int s2z, int s2Size, SET_WORD *d, int dz, int dSize) // [A] * [B] { assert(d && s1 && s2); *d = *s1 & *s2; } _p_set_diff(SET_WORD *s1, int s1z, int s1Size, SET_WORD *s2, int s2z, int s2Size, SET_WORD *d, int dz, int dSize) // [s1] - [s2] { assert(d && s1 && s2); *d = *s1 & ~*s2; } _p_set_in(SET_WORD *s, int sz, int sSize, int bit) { return ((1<<bit) & *s) != 0; } __setbits(SET_WORD* out, unsigned long bitlength, long startbit, long endbit) { assert(startbit == endbit); *out = 1 << startbit; } /* $Log$ */

2 1

Problem building gpc-20011123
by Martin Liddle 03 Dec '01

03 Dec '01

I am trying to build gpc-20011123 based on gcc-2.95.2 under Red Hat Linux 7.2. I have done this before with earlier versions of gpc but on this occasion configure is stopping when applying the patch to gcc with the message: "Missing header for unified diff at line 449 of patch. The text leading up to this was |--- expr.c.orig Sun Nov 18 00:05:40 2001 Any clues as what the problem is ? -- Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, Cramlington, Northumberland, England, NE23 6EW. Phone: 01670-712624. Fax: 01670-717324. Web site: <http://www.tynecomp.co.uk>.

3 4

GPC Keywords/Reserved Words
by Gloria, Jing 01 Dec '01

01 Dec '01

Pls advise if there is a way to make GPC accept a field name in a RECORD or variable name and that field name or variable name is a reserved or key word in GPC. I am porting software from SPARC SunOS (using SUN PASCAL compiler) to INTEL Solaris 7 (using GPC). For example : EXAMPLE A: PROCEDURE Blkkut; VAR Trow, Tline_nbr, Tcnt :INTEGER; Tptr :Parm_ptr; Tmp_erlin :Er_typ; View :BOOLEAN; Repos :INTEGER; BEGIN (* Blkkut *) IF Slct_flg THEN BEGIN View := FALSE; Blkcopy(View); <<< this is line 349; View is a GPC reserved word. IF NOT Spare_buffer_used THEN I get the following errors during compile: Shared_tpl/Mprocsrc/blockcmd.p: In procedure `Blkkut': Shared_tpl/Mprocsrc/blockcmd.p:349: parse error before `View' Shared_tpl/Mprocsrc/blockcmd.p:349: missing `)' Shared_tpl/Mprocsrc/blockcmd.p:349: too few arguments to function `Blkcopy' Shared_tpl/Mprocsrc/blockcmd.p:349: parse error before `)' EXAMPLE B: Sortmask_rec = PACKED RECORD Bin_nbr :Int8; Class :Class_typ; <<< line 226 Class is a GPC reserve word. Any :BOOLEAN; Display_ch :Displ_char; Socket_quality_delta :INT16; Test_Sum :INT16; Test_List :PACKED ARRAY[1..Maximum_tests] of INT16; END; Error messages during compile. In file included from Shared_tpl/Inc/tplmain.typ:38, from Shared_tpl/Mprocsrc/blockcmd.p:67: Dependent/Inc/misc.typ:226: parse error before `Class' Dependent/Inc/misc.typ:226: extra semicolon I am using gpc version 20010623, based on 2.95.2 19991024 (release) and I use only -O and --no-mixed-comments options when calling gpc. Thanks in advance for any assistance. Jing Gloria Texas Instruments

4 6

Bug: error in writeln output
by Ian Thurlbeck 30 Nov '01

30 Nov '01

Dear All I've found a simple case of a bug in writeln(): program sumbug(input,output); begin writeln(10.0*0.01); writeln(100.0*0.001); writeln(1.0*0.1); end. All should print 0.1 I guess, but I get: % ./bug :.000000000000000e-02 :.000000000000000e-02 1.000000000000000e-01 Interestingly ':' is the next character after '9' in the ASCII table, so it appears to be trying to print out the ASCII chacter for '10' (ten). 10.0e-02 is 0.1 after all ! This happens with the latest gpc-20011123 and also gpc-20010512 (that's all I've tested). Many thanks Ian -- Ian Thurlbeck http://www.stams.strath.ac.uk/ Statistics and Modelling Science, University of Strathclyde Livingstone Tower, 26 Richmond Street, Glasgow, UK, G1 1XH Tel: +44 (0)141 548 3667 Fax: +44 (0)141 552 2079

3 2

GPC/Solaris2.7 installation problem
by Mirsad Todorovac 30 Nov '01

30 Nov '01

Hi, all! On sparc-sun-solaris2.7, with gpc-20011123 / gcc-2.95.3 I've had the problem that patching failed (in line 447 of diff file). The problem proved to be the following: I've had /usr/bin{/patch} in path before /usr/local/bin{/patch} ; and it appears that Sun's original patch utility doesn't understand GPC's .diff format. I can't tell for sure, but it seems to me that this problem didn't occur with gpc-20010924 / gcc-2.95.2 ??? (Or I would remember it I guess). After linking /usr/local/bin/patch to ~/bin (which *was* in path before /usr/bin) everything went fine - but for a moment I was really confused. Mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

2 1

Re: dostest crash with djgpp
by Maurice Lombardi 30 Nov '01

30 Nov '01

Frank Heckenbach wrote: >>After that there is no more error, and I have uploaded the resulting bin to agnes. >> > > I just discovered a pretty stupid bug I made recently. Though the > fix will be uploaded soon via Peter as usual, I'm sending it to you > already because you might want to rebuild the binary before too many > people get it. > > Frank Done. It is uploaded to agnes as gpc-20011130-gcc-2953.i586-pc-msdosdjgpp.zip and available as usual under the link ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2953b.zip Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

test results
by Russell Whitaker 30 Nov '01

30 Nov '01

Hi After editing diff file ( thanks, Maurice ), Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.3/specs gpc version 20011123, based on 2.95.3 20010315 (release) test results: # of GPC tests 2159 # of GPC tests passed 2158 # of GPC tests skipped 1 # of GPC tests failed 0 Russ

1 0

dostest crash with djgpp
by Maurice Lombardi 29 Nov '01

29 Nov '01

Hi all, I have compiled the last alpha (20011123) under DJGPP When running the test suite there is a weird crash in readb10.pas and friends (endless loop of SIGSEGV), due to a too small default stack size. The following diff to increase the stack solves the problem: --- read1.inc.orig Mon Nov 26 16:07:20 2001 +++ read1.inc Thu Nov 29 20:07:10 2001 @@ -1,5 +1,9 @@ uses gpc; +{$ifdef DJGPP} +const MinStackSize: Cardinal = $200000; asmname '_stklen'; {2 MB} +{$endif} + var dialect:string(100)='Unspecified dialect'; rangecheck :Boolean=(*@@not implemented yet True*)False; After that there is no more error, and I have uploaded the resulting bin to agnes. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

Re: investigating a core dump...
by da Silva, Joe 29 Nov '01

29 Nov '01

I have a vague recollection (from previous discussions on the list) that this sort of problem only occurred if debugging was enabled, or am I thinking of some other problem? Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, November 29, 2001 4:20 AM > To: gpc(a)gnu.de > Subject: Re: investigating a core dump... > > Stephan Eickschen wrote: > > > > This might be a case of a known GPC problem that causes a stack > > > overflow if the loop runs very often. If it's that, than the crash > > > should occur sooner or later depending on the stack limit set. > > > > > > A work-around in this case could be to assign the loop condition > > > (substr(zeile2,1,ls)=suchstr) to a Boolean variable and test this in > > > the `until'. > > Thanks a lot! The program seems to work now... > > Fine. The GPC bug might be fixed in the not too distant future, but > I don't want to promise too much. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 2

Re: GRX 2.4.4 pre-release
by da Silva, Joe 28 Nov '01

28 Nov '01

Yep! (Hey, it's all part of the Wirth family, right?;-) Joe. > -----Original Message----- > From: marcov(a)stack.nl [SMTP:marcov@stack.nl] > Sent: Thursday, November 29, 2001 10:16 AM > To: gpc(a)gnu.de > Subject: Re: GRX 2.4.4 pre-release > > > "Pointers: the GOTO of data structures" --- P.J. Moylan. > > Isn't Peter a Modula-2'er :-)

1 0

Re: GRX 2.4.4 pre-release
by da Silva, Joe 28 Nov '01

28 Nov '01

"Pointers: the GOTO of data structures" --- P.J. Moylan. Joe. ;-) > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, November 29, 2001 2:13 AM > To: gpc(a)gnu.de; grx(a)gnu.de > Subject: Re: GRX 2.4.4 pre-release > > Maurice Lombardi wrote: > > > Mariano Alvarez Fernandez wrote: > > > > > GrSaveContextToJpeg is a new function, the old SaveContextToJpeg lived > in the addon subdir, and I > > > didn't know if we can change it, so I had write a new one and his > pair: GrLoadContextToJpeg. Can > > Shouldn't this be `From' rather than `To'? > > > > you add it to grx.pas? > > > > OK. > > To check I have also written a demo program which is the exact > translation to pascal of > > jpgtest.c > > In doing this I have noticed a problem in the translation of passing > GrContext parameters > > to procedures/functions. In C they are passed as pointers. In Pascal the > best solution is > > usually to pass them as "var" parametrers, and this had been done > previously. > > However there is a trick in grx that when passing a NULL pointer instead > of a > > GrContext pointer, an internal GrContext is created and/or used. This > trick is > > very frequently used for the current context, and is done several times > in the > > demo program. But I know no way in Pascal to pass a nil pointer as a var > parameter. > > Null. :-) (This was introduced for exactly this purpose.) > > > So either one discards this possibility or pass the parameters as > pointers > > GrContextPtr like in C. This is not a natural way of doing in pascal but > it works. > > So we can do it with var parameters. However, I'm wondering if we > should do it. I'm not very familiar with using contexts in GRX, but > if the usual way to create them is via functions like > GrCreateContext that return pointers, then there is no disadvantage > in using pointers (in fact, it saves a `^'). But if there a > regularly situations where you have a real GrContext variable, then > it's better to use var parameters than have to use `@'. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: gpc-test-suite+rhide problems
by Per Persson 28 Nov '01

28 Nov '01

Frank Heckenbach wrote: >All RHIDE can really do is call GPC with different options (or >*perhaps* environment variables, but I don't think so). Try to see >which options it uses (don't know if/how this is possible from >within RHIDE -- if nothing else helps, you could temporarily install >in place of gpc a little script that just dumps its options). OK the problem was the option -ggdb Now it works (though rhide crashes sometimes). Thanks Per _________________________________________________________________ HÃ¤mta MSN Explorer kostnadsfritt pÃ¥ http://explorer.msn.se

1 0

investigating a core dump...
by Stephan Eickschen 28 Nov '01

28 Nov '01

Hi all, I am a little bit in trouble with gpc on solaris >gpc -v Reading specs from /home/GFZS1/gnu/gpc/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/specs gpc version 20010924, based on 2.95.2 19991024 (release) >uname -a SunOS aida3 5.8 Generic sun4u sparc SUNW,Ultra-5_10 The program is compiled and linked without any problems. >gpc -g -o antdb3 antdb3.pas But running it yields to core dumps... I tried to investigate on it with ddd but unfortunatly, I get stucked right after the starting shot. I have to mention, that I did not write the program on my own - and I am not a pascal hacker. I used to code in pascal some years ago, but "switched" to C. Maybe some of the wizards out there is able to help me to find the "malicious" code? As far as I know, the program was original written for BorlandPascal and then transferred to AIX using "extended syntax" (?). I tested it at home on ly linux box with gpc and everything works fine. So I installed gpc on our sun's but now I am in trouble... ############################### DDD 3.0 (sparc-sun-solaris2.5.1), by Dorothea Luetkehaus and Andreas Zeller. Copyright (c) 1998 Technische Universitaet Braunschweig, Germany. (gdb) file /home/AIDA102/eicksch/bin/antdb3 Reading symbols from /home/AIDA102/eicksch/bin/antdb3...done. (gdb) set args (gdb) run Starting program: /home/AIDA102/eicksch/bin/antdb3 warning: Unable to find dynamic linker breakpoint function. warning: GDB will be unable to debug shared library initializers warning: and track explicitly loaded dynamic code. Program received signal SIGSEGV, Segmentation fault. 0x52bb8 in Kludgestreq (S1=0xff3f00c8, L1=10, S2=0xa49b8, L2=10) at /home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/rts/string.pas:813 (gdb) ---- snip: string.pas ------------------------------------- 807 function KludgeStrEQ (s1: PCharsKludge; l1: Integer; s2: PCharsKludge; l2: Integer): Boolean; asmname '_p_eq'; 808 function KludgeStrEQ (s1: PCharsKludge; l1: Integer; s2: PCharsKludge; l2: Integer): Boolean; 809 var c1, c2: Char; 810 begin 811 { @@ kluuuuuudge } if l1 < 0 then begin l1 := 1; c1 := Chr (PtrInt (s1)); s1 := PCharsKludge (@c1) end; 812 if l2 < 0 then begin l2 := 1; c2 := Chr (PtrInt (s2)); s2 := PCharsKludge (@c2) end; 813 KludgeStrEQ := StrEQ (s1^[1 .. l1], s2^[1 .. l2]) 814 end; ---- snap ------------------------------------------------ Any suggestion highly appreciated, Stephan -- ---------------------------------------------------------------------- Stephan Eickschen Tel. : +49 (0)8153 28-1351 GeoForschungsZentrum Potsdam (GFZ) Fax. : +49 (0)8153 28-1207 Division 1, Section 1.2 c/o email: eicksch(a)gfz-potsdam.de DLR Oberpfaffenhofen www : http://op.gfz-potsdam.de Box 1116 82234 Wessling Germany ----------------------------------------------------------------------

3 9

Re: GRX 2.4.4 pre-release
by Maurice Lombardi 28 Nov '01

28 Nov '01

Mariano Alvarez Fernandez wrote: > GrSaveContextToJpeg is a new function, the old SaveContextToJpeg lived in the addon subdir, and I > didn't know if we can change it, so I had write a new one and his pair: GrLoadContextToJpeg. Can > you add it to grx.pas? OK. To check I have also written a demo program which is the exact translation to pascal of jpgtest.c In doing this I have noticed a problem in the translation of passing GrContext parameters to procedures/functions. In C they are passed as pointers. In Pascal the best solution is usually to pass them as "var" parametrers, and this had been done previously. However there is a trick in grx that when passing a NULL pointer instead of a GrContext pointer, an internal GrContext is created and/or used. This trick is very frequently used for the current context, and is done several times in the demo program. But I know no way in Pascal to pass a nil pointer as a var parameter. So either one discards this possibility or pass the parameters as pointers GrContextPtr like in C. This is not a natural way of doing in pascal but it works. I have thus corrected grx.pas this way, corrected makefiles and readme to include the new demo program, and also corrected vir_test.pas for the new syntax. I have checked that everything works on djgpp. All is contained in the attached grxdiff.zip Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

Re: Installation problem ?? ( now cannot exec `cc1'...)
by Frank Heckenbach 27 Nov '01

27 Nov '01

laurent(a)laurent-parise.com wrote: > The fisrt time I compiled GPC, installation process didn't detect > gcc 2.95.3 .... I think the only change is the directory to compile : > now I use /usr/src whereas I did it in /root/tmp before.... That seems strange. The base directory should not matter. It's only important that the GPC sources are placed properly below GCC (i.e. .../gcc/p). If you did this, and still gcc-2.95.3 was not detected, I'd be interested in details so I can fix it. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Installation problem ?? ( now cannot exec `cc1'...)
by Frank Heckenbach 27 Nov '01

27 Nov '01

laurent(a)laurent-parise.com wrote: > I put GCC (from Slack 8.0 source disk) and GPC sources in /usr/src and > proceed to installation. At the end of 'make', I read the message : > > checking if compiler f771 has been built... no > Configuring in i686-pc-linux-gnu/libchill > creating cache ./config.cache > checking if compiler cc1chill has been built... no > Configuring in i686-pc-linux-gnu/libobjc > creating cache ./config.cache > checking if compiler cc1obj has been built... no > > Do you think this is a normal message ? Yes, it is. It just notes that the Fortran, Chill and Objective C compilers were not built. I assume you didn't want to build them, so it's ok. > ('make' detected gcc 2.95.3 and > used a special patch ... ) so I run 'make pascal.install' in > 'gpc-build/gcc'. (Should I have done a 'make install' and install gcc > too ???) Yes. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Installation problem ?? (`Crt' could not be imported...)
by Maurice Lombardi 26 Nov '01

26 Nov '01

laurent(a)laurent-parise.com wrote: > However, I can find /usr/lib/gcc-lib/i386-slackware-linux/2.95.3/cc1 > here. (but not in /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/ ...) You need C files (cc1 among others) of the same version and in the same directory as the gpc files (gpc1 among others) to compile C files like crtc.c automatically with --automake. Or you have to use GPC_EXEC_PREFIX and/or GCC_EXEC_PREFIX: see the discussion in recent mails of the gpc list. But the surest if you can is to install them. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

Re: Installation problem ?? (`Crt' could not be imported...)
by Frank Heckenbach 24 Nov '01

24 Nov '01

laurent(a)laurent-parise.com wrote: > Frank Heckenbach wrote > > > Well, use `--automake' as you did below. > > gpc --automake crtdemo.pas returns this > > In file included from /usr/include/sys/time.h:30, > from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/units/crtc.c:939: > /usr/include/sys/select.h:52: warning: `__NFDBITS' redefined > /usr/include/linux/posix_types.h:22: warning: this is the location of the previous definition > /usr/include/sys/select.h:54: warning: `__FDMASK' redefined > /usr/include/linux/posix_types.h:34: warning: this is the location of the previous definition > cpp: -lang-c: linker input file unused since linking not done > gpc: installation problem, cannot exec `cc1': No such file or directory > gpc1: gpc exited with status 1 > gpc1: gpc exited with status 1 Oh yes, this was another bug in that version. It's been reported that the following will fix it: : Try moving the line `#include <sys/time.h>' in units/crtc.c from : line 1001 to the other includes (line ~50), > Yes, I would have downloaded a more recent binary, but I can't find some > on the ftp server and .... Well, we're getting close to the next official release, and then we'll make available some current binaries for various platforms. Now is just not a very good time to do so. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Mailing list archive
by Frank Heckenbach 24 Nov '01

24 Nov '01

I have set up a new archive of the GPC mailing list, using crystal (see my other announcement). It can be found at: http://fjf.gnu.de/crystal/gpc/en/ (English) http://fjf.gnu.de/crystal/gpc/de/ (German) If there are any problems with the archive, please report them to me. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Seek very slow...
by Preben Mikael Bohn 23 Nov '01

23 Nov '01

Hi all, I have a program where I need to iterate through a binary file many times, and where each binary data needs to be processed each time. I use something like: read(f, data); { process data } seek(f, filepos(f)-1); write(f, data); My program seems to spend a lot of time on file I/O, so just for fun I tried to remove the seek (of course the program now gives crap, but anyway :-)). This speeded it up by a factor of 4-5! Now, I *could* just use two files and swap these once per iteration, but since I have a lot of these files this would really be a mess. Can anyone tell me why it's so slow, and what may be done to speed it up? Isn't Linux also supposed to have a very efficient file-cashing system, so the above shouldn't really be problem? Best regards Preben BohnÂ´ ===== This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message. __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com

3 2

Re: Installation problem ?? (`Crt' could not be imported...)
by Frank Heckenbach 23 Nov '01

23 Nov '01

laurent(a)laurent-parise.com wrote: > but gpc -c crtdemo.pas returns : > > crtdemo.pas:32: module/unit interface `Crt' could not be imported > > What's the problem? Is there something to do to declare path to find > units ??? Well, use `--automake' as you did below. > OK. I found another problem now. Typing > > gpc --automake hello.pas returns : > > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/libgpc.a(randfile.o): In function `do_seek': > /home/elug/pascal-wochenende-20000729/gcc-2.95.2/gcc/p/rts/randfile.c:327: the `llseek' > function may be dangerous; use `lseek64' instead. > > but a.out is OK. > > I tried to find what to do last 2 days in manual, but .... A bug that was fixed last year. The binary you have was built before it was fixed. I don't know if anyone has uploaded a more recent binary somewhere, but onder Linux it's easy to build GPC from sources. Apart from this, it's only a warning, and harmless as long as you don't use files > 2GB. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Installation problem ?? (`Crt' could not be imported...)
by laurent＠laurent-parise.com 23 Nov '01

23 Nov '01

Hi. First, excuse me for my english ... I used Pascal 10 years ago at school (in France) and I want to use it again now, that's why I just installed GPC on my Linux box: Slackware 8.0 with gcc 2.95.3 So I downloaded binaries gpc-20000727.i686-pc-linux-gnu.tar.gz and installed it. I used install-gpc-binary without any pb and add the line GPC_EXEC_PREFIX /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/ in /etc/csh.login. My problem is that when I go to the demos directory, gpc -c hello.pas is OK but gpc -c crtdemo.pas returns : crtdemo.pas:32: module/unit interface `Crt' could not be imported What's the problem? Is there something to do to declare path to find units ??? OK. I found another problem now. Typing gpc --automake hello.pas returns : /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/libgpc.a(randfile.o): In function `do_seek': /home/elug/pascal-wochenende-20000729/gcc-2.95.2/gcc/p/rts/randfile.c:327: the `llseek' function may be dangerous; use `lseek64' instead. but a.out is OK. I tried to find what to do last 2 days in manual, but .... Thanks. Laurent PARISE. -- Web: http://www.laurent-parise.com E-mail: laurent(a)laurent-parise.com

1 0

Re: `Reply-To' (solution)
by da Silva, Joe 23 Nov '01

23 Nov '01

Well, I'm sorry to hear it! <g> I guess I've been lucky then, as I can only recall about two or three such occurrences over the past couple of years, on a variety of lists. So, the moral of the story is: if your e-mail system is "dumb", make sure to "suspend" (or whatever you call it) your lists before enabling an automated "vacation response"! Anyway, thanks to Peter and Frank for providing this "Reply-To" option - it's marvellous, wonderful, great, fantastic!!! Joe. > -----Original Message----- > From: Martin Liddle [SMTP:martin@tcs02.demon.co.uk] > Sent: Thursday, November 22, 2001 9:22 PM > To: gpc(a)gnu.de > Subject: Re: `Reply-To' (solution) > > In article > <01FD6EC775C6D4119CDF0090273F74A455A838(a)emwatent02.meters.com.au>, "da > Silva, Joe" <Joe.daSilva(a)emailmetering.com> writes > >Most e-mail systems, I'm told, know not to send "vacation" responses > >to mailing lists. So in most cases, this won't be a problem (eg. how > often > >has anyone seen such a response message on a mailing list?). > > > Lost and lots and lots of times :-( > -- > Martin Liddle, Tynemouth Computer Services, 27 Garforth Close, > Cramlington, Northumberland, England, NE23 6EW. > Phone: 01670-712624. Fax: 01670-717324. > Web site: <http://www.tynecomp.co.uk>.

1 0

bug?
by Adam Naumowicz 23 Nov '01

23 Nov '01

Hello, Maybe that is a known bug but I encountered a strange problem and don't know what happens. I reduced the example to these three silly files: --------------------- program tester; uses tester1; begin ImpSgnList.Init(8); end. ---------------------- unit tester1; interface uses tester2; var ImpSgnList:MList; implementation end. ---------------------- unit tester2; interface type MList = object constructor Init(ALimit: Integer); end; implementation constructor MList.Init(aLimit: Integer); begin end; end. ---------------------- The result of execution is as follows: tester.dpr: In main program: tester.dpr:5: Internal compiler error in `call_method', at objects.c:137 Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://home.pages.de/~GNU-Pascal/todo.html> for details. I use the following compiler version: Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs gpc version 20010623, based on 2.95.3 20010315 (release) BTW: the same is with my another GPC version: Reading specs from /usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.2/specs gpc version 20010121, based on 2.95.2 19991024 (release) I hope there is an explanation of this behavior, or if this is a new bug, there will be a way to correct it. Regards, Adam Naumowicz -------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------

3 4

Re: `Reply-To' (solution)
by da Silva, Joe 22 Nov '01

22 Nov '01

Most e-mail systems, I'm told, know not to send "vacation" responses to mailing lists. So in most cases, this won't be a problem (eg. how often has anyone seen such a response message on a mailing list?). Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, November 21, 2001 11:01 PM > To: gpc(a)gnu.de > Subject: Re: `Reply-To' (solution) > > Russell Whitaker wrote: > > > > Recently there was a discussion about whether the mailing list > > > software should automatically add `Reply-To' headers. > > > > > > Peter now told me that the new majordomo version used has the option > > > to set it on a per-user basis, so those who like it can have it, and > > > those who'd feel disturbed by it won't be. > > > > > > If you want it, just send a mail to <majordomo(a)gnu.de> with the > > > following command in the body: > > > > > > set gpc replyto your(a)mail.address > > > > > > (where your(a)mail.address, of course, is the address with which > > > you're subscribed to the list). > > > > > If someone also goes on vacation and uses an auto "vacation reply" > > will that set up an endless mail loop? > > Good point. If it uses the `Reply-To' header, and sends multiple > message to the same recipient (which I consider rather broken, > anyway) and the mailing list software doesn't detect vacation > replies or mail loops, then probably yes. > > So I suggest everyone who uses vacation replies to not use the > Reply-To feature unless they know for sure it won't cause problems > (I'm not sure) ... and unless they want to find themselves kicked > from the list when they return. ;-) > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

3 2

`Reply-To' (solution)
by Frank Heckenbach 21 Nov '01

21 Nov '01

Recently there was a discussion about whether the mailing list software should automatically add `Reply-To' headers. Peter now told me that the new majordomo version used has the option to set it on a per-user basis, so those who like it can have it, and those who'd feel disturbed by it won't be. If you want it, just send a mail to <majordomo(a)gnu.de> with the following command in the body: set gpc replyto your(a)mail.address (where your(a)mail.address, of course, is the address with which you're subscribed to the list). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 2

Re: Error recovery problem? (was: Label scope (?) bug in GPC)
by da Silva, Joe 21 Nov '01

21 Nov '01

Thanks for addressing the label scope problem, and for the tips about DJGPP, Frank. I should perhaps have been more clear however, that the inconsistent behaviour I observed with the DJGPP port of the compiler, when errors or warnings were reported, is a separate problem, I think. In other words, this is not specific to the label scope problem, although I used this as an example of this behaviour. So, have others using the DJGPP port observed similar behaviour when errors or warnings are reported? Does this also occur with other ports of GPC (20010924-2.95.3)? To recap, "whenever an error or warning is issued, the compiler misbehaves, often crashing. This behaviour is inconsistent, so that consecutive runs of the compiler with the same source code and environment produce different results. When no error or warning is reported, everything seems fine and the results are consistent". Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Friday, November 16, 2001 1:48 PM > To: gpc(a)gnu.de > Subject: Re: Label scope (?) bug in GPC > > da Silva, Joe wrote: > > > program test; > > > > label 1; > > > > procedure outer; > > label 1; > > procedure inner; > > begin {inner} > > goto 1 > > end; {inner} > > begin {outer} > > 1: > > end; {outer} > > > > begin {test} > > 1: > > end. {test} > > > > The compiler seems to think that the "goto" in the procedure "inner", > > goes to the label in the main program, rather than the label in the > > procedure "outer", which by the "rules of scope", is the appropriate > > label. > > Indeed. Thanks. Fixed. > > > However, there is an additional problem which may be platform/build > > "specific". It seems that whenever an error or warning is issued, the > > compiler misbehaves, often crashing. This behaviour is inconsistent, > > so that consecutive runs of the compiler with the same source code > > and environment produce different results. When no error or warning > > is reported, everything seems fine and the results are consistent. > > Attached for example, are some screen dumps of the 20010924 > > DJGPP compiler, attempting to compile the above sample program. > > Since I've changed a lot WRT labels in the meantime, I can't > reproduce it now. Please check again with the next version. > > > I apologise for the poor visual quality of these screen dumps, but > > this was to achieve acceptable compression of the two JPEG files > > For such kinds of images, PNG is much better suited than JPEG. I > suppose it would archive better compression, and it would surely be > more readable. > > However, much better than any image is text (smaller, copyable, and > I won't have to switch between my editor and GUI just to read it > :-). You can use the `redir' utility under DJGPP: > > # Redirect StdErr to foo > redir -e foo command args > > # Redirect StdOut and StdErr to foo > redir -e foo -oe command foo > > For more info, see the DJGPP FAQ (see redir in the index). > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Crystal-0.90 released
by Frank Heckenbach 20 Nov '01

20 Nov '01

This is to announce the first public release of crystal. Crystal is a web based mailing list archive. It is still under development, and some planned interesting features are still missing, but it should run stable already and has been tested (on some private lists) for several months. The main functionality of crystal is: - Archive incoming mails and make them accessible by date, author, subject, thread, topic, etc. - Do not require the archive to be updated regularly by a special command. Instead, each mail is visible as soon as it's received. - Make attachments accessible. - Provide a search function. - Allow authenticated and anonymous access (as configured by the administrator). - Let users send mails to the list via WWW (optionally anonymously). - Provide user administration where users can change, add and remove email addresses and change their passwords and other settings via WWW (optionally). - Can be configured either via config files or in the source. Crystal is free software (GNU GPL) and was written for GNU Pascal. More information and the sources for download can be found at http://fjf.gnu.de/crystal/ Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: Change of URL for standards
by da Silva, Joe 19 Nov '01

19 Nov '01

Hmmm ... Actually, the "ftp.digital.com/pub/DEC/Pascal/" directory had vanished several weeks ago. Of course, as soon as I decided to mention this, it re-appears! :-/ Which is the best URL? Well, unless someone from Digital/Compaq is on this list, it's difficult to judge. My guess is that the "ftp.europe.digital.com/pub/DEC/Pascal/" directory _seems_ more stable (at this time;-) ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Saturday, November 17, 2001 8:28 PM > To: gpc(a)gnu.de > Subject: Re: Change of URL for standards > > da Silva, Joe wrote: > > > Just a brief note that the link to the ISO standards on web page : > > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/resources.html > > is no longer valid. It should now point to : > > ftp://ftp.europe.digital.com/pub/DEC/Pascal/ > > Thanks. I saw the link didn't work, but now it seems to work again. > Yesterday, all of the following URLs worked (and seemed to point to > the same thing). Anyone knows which one is the offical or preferred > one (otherwise, I'll list all of them). > > http://ftp.digital.com/pub/Digital/Pascal/iso10206_a4.ps.gz > http://ftp.digital.com/pub/Digital/Pascal/iso10206.ps.gz > ftp://ftp.europe.digital.com/pub/DEC/Pascal/ > ftp://ftp.digital.com/pub/DEC/Pascal/ > > And there are copies at: > > http://www.employees.org/~samiam/iso7185.ps > http://www.employees.org/~samiam/iso10206.ps > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: gpc-test-suite+rhide problems
by Per Persson 18 Nov '01

18 Nov '01

>Per Persson wrote: >>1. When I run the test suite after installation of the gpc-20010924 with >>the gcc-core-2.95.2 >> according to the instructions (I have Red Hat Linux 6.2, kernel >>2.2.16-3 ) >>I get failure for 5 cases (out of 1763 ) > >> As I understand this, the problem seems to be the version of ncurses. >> But according to the KDE package manager I have ncurses 5.0-11 already >>installed. >> >> Do I need another version? >Frank Heckenbach wrote: >The check in crtc.c reads: > >So just check your ncurses.h file to see if/how >NCURSES_VERSION_MAJOR is set. A small possibility would be that >there are several versions installed, and an old one is used. Or the >installed one is broken -- it's a conincidence, but just today there >was a mail on the ncurses list from the maintainer: "[...] Redhat >7.2 does not ship ncurses 5.2 (as usual, Redhat ships a development >version of ncurses without noting this). [...] This is what Redhat >shipped (plus a few changes that I wouldn't want to own): [...]" > >So I wouldn't be surprised if similar problems exist in 6.2. In this >case, get an official ncurses version from ftp.gnu.org or mirrors, >and don't forget to complain to RH. ;-) I checked the ncurses.h file and NCURSES_VERSION_MAJOR was set to 4 although the file was dated 2000.. something. So I installed an update from REDHat (5.0-12). This time the file was dated even later but the NCURSES_VERSION_MAJOR was still set to 4. So then I downloaded the ncurses 5.0 sources from gnu and compiled. Now it works :=) (no failures when running test suite) > >Per Persson wrote: >>2. I have tried to install rhide in the the binary version >>rhide-1.4.7.8.linux.bin.tar.bz2 >> When I try to use this it seems to work, but when I compile a larger >>project I >> get error messages of the type: >> filtest.pas Error: Internal compiler error in 'scope_die_for' >>at >>dwarf2out.c:7794 >> >> then I compile the program using gpc at the command prompt it works. >> What can be the problem? > >Frank Heckenbach wrote: >The difference might be due to different compiler options. `-g' >seems a likely candidate. If you compile with `-g' on the command >line, does it crash as well. If so, you might want to use >`--debug-source' to find where in your program it crashes, but in >general, debug info generation in GPC is not very stable yet, so I >can't promise whether it can be fixed soon. > I tried the -g option with the gpc from the command prompt and the program compiled without problems (and an executable was produced), so I think the problem has to do with RHIDE in some way. The program also compiles from inside rhide in the djgpp version (gpc version 20010623, based on 2.95.3 20010315/djgpp (release)). I then tried to install another binary version (rhide-1.4.9-1.i386.rpm) but the result was the same. Should I try to compile rhide from the sources? Is it tricky? Thanks Per _________________________________________________________________ HÃ¤mta MSN Explorer kostnadsfritt pÃ¥ http://explorer.msn.se

2 1

Bug Report: goto bug
by John P.R. Archer 17 Nov '01

17 Nov '01

Sorry about this horrid use of gotos in the following nasty bit of code but it core dumps on Solaris 2.6 - it's easy to workaround in the following snippet but not so easy (actually just very laborious) in the original inherited code. 'bye for now, John For info:- gpc -v returns:- Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.3/specs gpc version 20010924, based on 2.95.3 20010315 (release) (* sample program *) program bug1 (Output); procedure level_1 ; procedure level_2 ; label 2; procedure level_3 ; begin (* level_3 code *) writeln( 'level_3' ) ; writeln( 'goto 2' ) ; goto 2 ; writeln( 'should not get here' ) ; end ; (* level_3 code *) begin (* level_2 code *) writeln( 'level_2' ) ; level_3 ; writeln( 'should not get here' ) ; return ; 2: writeln( 'label 2' ) ; end ; (* level_2 code *) begin (* level_1 code *) writeln( 'level_1' ) ; level_2 ; writeln( 'should not get here' ) ; end ; (* level_1 code *) begin level_1 ; end.

4 14

Change of URL for standards
by da Silva, Joe 17 Nov '01

17 Nov '01

Just a brief note that the link to the ISO standards on web page : http://agnes.dida.physik.uni-essen.de/~gnu-pascal/resources.html is no longer valid. It should now point to : ftp://ftp.europe.digital.com/pub/DEC/Pascal/ Joe.

2 1

GPC/SET bug[64 bit Alpha]: new bug
by Mirsad Todorovac 17 Nov '01

17 Nov '01

Hi, As far as I remember so far we've seen that some numbers were put in SET OF BYTE, but weren't found in by IN operator (which was acknowleged as a bug for Alpha/64bit platform - I don't know whether the test failed on any other architecture?). This is a test which stresses other issue: I've found some numbers IN SET which were NOT added to it! (Only on Alpha/64bit, on 32bit Solaris all tests pass with OK!). Also initialization fails, but IMHO all this bugs have something in common; so I went forth with these examples only in hope that they will help nail the bug. mirsad The test is (all four new tests are in attachment for your convenience): --mirsad05.pas------------------------------------------------------------ PROGRAM setranges5(output); { Written by: Mirsad Todorovac Nov 2001; copying by GPL. ------------------------------------------------------------ Stresses setrange construction and adding; checks if there's more in SET than we've put in. lasts few seconds where I've tested it.} CONST maxN = 255; VAR seta, setb, setc: SET OF 0..maxN; i, j, len, start, endr: Cardinal; failed: Boolean = false; BEGIN FOR i:= 0 TO maxN DO IF ((i IN seta) OR (i IN setb) OR (i IN setc)) THEN writeln('Failed: SET not initialized empty!'); FOR len:= 1 TO maxN+1 DO BEGIN FOR start:= 0 TO maxN-len+1 DO BEGIN endr := start+len-1; {writeln('constr. range = ', start, ',', endr);} setb := seta + [start .. endr]; FOR i:= 0 TO maxN DO BEGIN IF (((i < start) AND (i IN setb)) OR ((i > endr) AND (i IN setb))) THEN IF (NOT failed) THEN BEGIN writeln('Failed: ', i,' outside range found IN SET! ', '[',start, '..', endr,']'); {It's sufficient for one example to fail to find a bug!} failed := True; END END END END; IF (NOT failed) THEN writeln('OK'); END. ----------------------------------------------------------------------- -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

4 22

Re: Zodiac, Linux, sparse sets [Was: GPC/SET bug[64 bit Alpha]: new
by Mirsad Todorovac 16 Nov '01

16 Nov '01

On Thu, 15 Nov 2001, Frank Heckenbach wrote: > > Maybe. But (Visual) Basic, C++ and FORTRAN also evolve, don't they? > > For example, consider Visual Basic's "collections", which are basically > > sets of members which can have various types (also mentioned in gpc > > info's TODO list as ???). > > Err, where? info -f gpc::Welcome::Note To Do::Planned features::Planned features: Other types->item 9 in list. [ ... ] > > Anyway, range checking can be life saving. For example, remember Arianne > > launch failure when a 16-bit counter that was there for years rolled-over > > into negative when something was speeded-up. (In the time of design they > > said it can never go over 16 bits.) So, the unit failed, after which > > rendundant unit was consultet only to have the same result (of course, > > using the same software and same 16-bit counter). Then the rocket's > > computer thought it started to fall down and activated self-destruct > > sequence, even though it was climbing. > > > > This story makes me agree that extensive range-checking, especially with > > arrays, sets and (last but not the least) implicit precision conversions > > is very important. That's also a weakness of C language which C++ hasn't > > eliminated (but I'm slightly off-topic maybe?) ... > > Not really. Range-checking will at best generate runtime errors, not > correct the problems automatically. If Ariane's software would have > generated an error (even it if was an exception that could be > handled), it's quite unlikely that it could've found the cause of > the problem and corrected it (in real-time, therefore fully > automatically!). Here I'd always leave the possibility to programmer whether to compile-in range checking or not. Yet, in Arianne example, if you get runtime errors, it doesn't have to end execution, some errors may be recoverable. For example, life-support computers and similar applications can't just say "panic: freeing free inode: syncing file systems ..." (common message on SunOS 4.1.x :-) ... ). But to allow for error to go undetected is neither a good solution. > Range-cheking is mostly a debugging aid that will tell the > programmer more early about possible problems and easy debugging. > For an end-user application, it might even have negative impacts -- > think of an editor or smoething which suddenly abort with a runtime > error (while without a check it might behave wrongly but may just > keep working long enough so the users can save his changes). Of > course, the problem can be alleviated by catching runtime errors > (like I do, e.g., in PENG) which GPC allows but is certainly not > standard. On the other hand, by leaving range-checking out we could be able to calculate very expensive computations invain, and never be sure in results. I've got the grasp of that feeling while trying to design some of recent tests for example - there's just nothing firm and proven to attach to sometimes. For example, in 1995 Pentium had a float division bug. Then they tried to cover up and say it doesn't ocur too often (incredible). Yet, was anybody able to run tests of dividing every compination of two 80-bit double numbers to see if the result is correct to the last bit? This would require 2^80*2^80 ~ 1.461*10^48 tests. With 1 Gflops, this would require approx 4*10^31 years ... Much much longer than the Universe lasts. > So what I want to say is just that I don't see range-checks as the > panacea that some of you seem to. They're a debugging aid, sure, but > I've found other debugging aids (e.g., GPC's warnings about using > uninitialized variables) at least as useful. Yes, but UCSD pascal had it back then in 1987. If it can be switched on and off with compiler directive, I can't see why not? For example, who excludes floating-point checks to make code run faster and get a matrix full of NaN (not-a-number) as a result? With the editor example you have a point - but writer of the editor could disable runtime checks in production binary. On the other hand, in complex calculation with no range checking results become useless with slightest error ... To range checking I would especially add pointer checking. I think it's possible to avoid lots of wasted hours if we test whether pointer points at regularly allocated part of memory, or to a freed block. And this one could be very easily implemented. Of course, it shouldn't run in production binary, since checking every ointer for validit before dereferencing would be tremendously slow. But, if you don't like it - no problem, you are the boss :-) mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

3 3

GPC bug?: Boolean expression that doesn;t compile
by Mirsad Todorovac 16 Nov '01

16 Nov '01

Hi, all, Please don't hate me - while writting mirsad08.pas I came to this problem: line 14 with Boolean expression fails to compile (or I don't know Pascal syntax well enough). I reduced the example to the minimum at which problem still appears. Changing ... AND (i<start OR i>endr) AND ... to ... AND ((i<start) OR (i<endr)) AND ... made it compile. Here is the material: --------------------------------------------------------------------------- > more mirsad13.pas PROGRAM boolexp(output); { Written by: Mirsad Todorovac Nov 2001; copying by GPL. ------------------------------------------------------------ Accidentally discovered that this didn't compile. } VAR flag: Boolean; extra: Boolean; i, start, endr: Cardinal; BEGIN IF (NOT extra AND (i<start OR i>endr) AND (flag = true)) THEN {!thisline!} BEGIN extra := true; END; END. > gpc mirsad13.pas mirsad13.pas: In main program: mirsad13.pas:14: parse error before `>' mirsad13.pas:14: warning: expression used as a statement - value is ignored mirsad13.pas:14: warning: expression used as a statement - value is ignored mirsad13.pas:14: parse error before `)' > Best regards, Mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

4 7

Label scope (?) bug in GPC
by da Silva, Joe 16 Nov '01

16 Nov '01

It's at times like these, that I wish the mailing list archive was still working. There have been some discussions recently about the operation of labels on some platforms, plus a separate thread about errors when compiling the P4 interpreter. Unfortunately, I didn't keep a copy of these postings, but from memory, the following is new information on these issues ... By chance, I found a copy of the P4 compiler and interpreter "lying around" on my hard drive, so I thought I would see what happened when I tried to compile the interpreter, "PINT.P", with GPC ... >From memory, the previous discussions on this, concluded that the error reported by GPC was correct, since declaring a label but not using it, is regarded by the standard(s) as an error. However, on checking the "PINT.P" source more carefully, the label in question was in fact used correctly. Furthermore, while the 20010924/2.95.3 compiler reported an error, the "2.0 release" version did not. The situation that occurs in the "PINT.P" source can be simplified to the following code : program test; label 1; procedure outer; label 1; procedure inner; begin {inner} goto 1 end; {inner} begin {outer} 1: end; {outer} begin {test} 1: end. {test} The compiler seems to think that the "goto" in the procedure "inner", goes to the label in the main program, rather than the label in the procedure "outer", which by the "rules of scope", is the appropriate label. This seems to be what is happening, since by changing the label number in the main program from "1" to "2", the compiler no longer complains that the label in procedure "outer" has been "declared but not used". Also, if the "goto" statement is simply commented out, again the compiler stops complaining about the label in procedure "outer". So, there seems to be some confusion by the compiler about the scope of labels in "goto" statements, and possibly corruption of the internal information, that the compiler gathers about the label in procedure "outer", when this occurs. The above error occurred using the DJGPP port of GPC, both on a pure DOS platform and a W95 platform. I doubt this behaviour is platform or build specific, although I'm just speculating, of course. However, there is an additional problem which may be platform/build "specific". It seems that whenever an error or warning is issued, the compiler misbehaves, often crashing. This behaviour is inconsistent, so that consecutive runs of the compiler with the same source code and environment produce different results. When no error or warning is reported, everything seems fine and the results are consistent. Attached for example, are some screen dumps of the 20010924 DJGPP compiler, attempting to compile the above sample program. I apologise for the poor visual quality of these screen dumps, but this was to achieve acceptable compression of the two JPEG files (I couldn't find a way of obtaining a text file from the screen dumps). Joe. <<gpc-err.ZIP>>

2 1

gpc-test-suite+rhide problems
by Per Persson 16 Nov '01

16 Nov '01

Hi! I have two problems, that might be related: 1. When I run the test suite after installation of the gpc-20010924 with the gcc-core-2.95.2 according to the instructions (I have Red Hat Linux 6.2, kernel 2.2.16-3 ) I get failure for 5 cases (out of 1763 ) I get error messsages something like this: PC="gpc" PFLAGS="--autobuild -g -O3 -Wall -Werror " SRCDIR="." "./test_run" "*.pas" | "./test_sum" TEST crttest.pas: /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/units/crtc.c:122: warning: #warning The CRT unit needs ncurses version 5.0 or newer because older As I understand this, the problem seems to be the version of ncurses. But according to the KDE package manager I have ncurses 5.0-11 already installed. Do I need another version? 2. I have tried to install rhide in the the binary version rhide-1.4.7.8.linux.bin.tar.bz2 When I try to use this it seems to work, but when I compile a larger project I get error messages of the type: filtest.pas Error: Internal compiler error in 'scope_die_for' at dwarf2out.c:7794 then I compile the program using gpc at the command prompt it works. What can be the problem? Can it be related to the problem 1 above? Should I instead try to compile rhide from the sources? Thanks! Per _________________________________________________________________ HÃ¤mta MSN Explorer kostnadsfritt pÃ¥ http://explorer.msn.se

2 1

Re: GPC bug?: Boolean expression that doesn;t compile
by Maurice Lombardi 15 Nov '01

15 Nov '01

Mirsad Todorovac wrote: > Can you please point me to a complete stnadard somewhere on the net, so I > don't embarass myself again? Also extracted from the list [Joe da Silva] Yes, there are actually two ISO Pascal standards : 1. ISO 7185 - Non-extended (aka Classic) Pascal 2. ISO 10206 - Extended Pascal (superset) You can obtain a free copy of ISO 10206, in either A4 or US-Legal document size, at : http://ftp.digital.com/pub/Digital/Pascal/iso10206_a4.ps.gz http://ftp.digital.com/pub/Digital/Pascal/iso10206.ps.gz You can also find an easy-to-read introduction to Extended Pascal (by Prospero Software) at : http://www.prosperosoftware.com/epintro.html Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

New tests [that try to reveal 64 bit arch sets problem]
by Mirsad Todorovac 15 Nov '01

15 Nov '01

Hi, This test I've tried to tweak to isolate the set on Alpha problem. I hope they might give some help with finding bug (altough I'm aware that there are many other important things to do with GPC). New tests are in attachment (submitted for approval). I hope that it's not a problem - it may be harder to read on some email clients, but on the other hand it's easier to save them ... Results on SOlaris: all OK. Results on Alpha: mirsad06: Failed: extra: 31 IN [0..255]-[31..31] miss: 32 NOT IN [0..255]-[0..0] mirsad07: OK mirsad08: Failed: 32 not set but IN [0..255] mirsad09: Failed: 32 not set but IN [0..255] mirsad10: Failed: 31 set but not IN [32..95] mirsad11: Failed: 32 not set but IN [0..32] mirsad12: Failed: 31 set but not IN [32..32] I was surprized for mirsad07 passed OK, since I've designed it to fail on Alpha (you might say maliciously). It uses something like ``IF (i IN [start..endr]) THEN'' test which compiled correctly. This leas me to produce assembly, and I was surprized to see that it didn't call _p_set_in fucntion from RTS (p/rts/sets.pas, as Frank said). On the other hand, ``FOR i IN [start..endr] DO'' use _p_set_in and do fail. Once Frank has time, I hope this might help a step in the rigth direction. mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

2 1

ANNOUNCEMENT: pas2po
by Eike Lange 15 Nov '01

15 Nov '01

Hi Folks! I finished writing a tool, similar to `xgettext' named `pas2po'. This program extracts all translatable strings out of a GNU Pascal source file and creates a po file, similar to xgettext. Missing is the timezone information. The output is not sorted, but there are no duplicate entries. Like xgettext output, you have to edit the file by hand to include the missing informations. (Later on, you can process this po file with `msgfmt' to create a mo file) You can download the actual sources via ftp from: agnes.dida.physik.uni-essen.de/pub/home/lange/pas2po-0.2.tar.gz See, that this is _completely_ different from that in inter-unit (tools), but shares the same name. I'll remove the one in inter-unit. Eike

1 0

Bug Report: SET OF BYTE not working properly!!!
by Mirsad Todorovac 15 Nov '01

15 Nov '01

Dear Sirs, Following program (implementing sieve of Eratosthenes) doesn't work as expected: after adding [i] to SET it doesn't appear to be in it!!! This is for i in [32..63,96..127,160..191,224-255]. Numbers 95 and 195 _couldn't_be_removed_ from SET sieve. > gpc --version 2.95.3 20010315 (release) > uname -a OSF1 domac.alu.hr V4.0b 564 alpha --marvin01.pas-------------------------------------------------------------- PROGRAM sieveprogram(input,output); {Sieve of Eratosthenes for finding prime numbers} CONST maxN = 255; VAR i,j,k: CARDINAL; sieve: SET OF Byte; BEGIN FOR i:= 1 TO maxN DO {initialize sieve} BEGIN sieve := sieve + [i]; IF (NOT (i IN sieve)) THEN writeln('Error: ', i, ' not in SET after adding!'); END; FOR i:= 2 TO maxN DO BEGIN IF (i IN sieve) THEN FOR k := i+1 TO maxN DO IF ((k MOD i = 0) AND (k IN sieve)) THEN BEGIN sieve := sieve - [k]; IF (k IN sieve) THEN writeln('Error: ', k, ' in SET after deletion!'); END END; FOR i:= 2 TO maxN DO IF (i IN sieve) THEN BEGIN writeln('Checking if really prime: ', i); FOR j:= 2 TO i-1 DO IF (i MOD j = 0) THEN writeln('Error: ', i,' % ', j, ' = 0.'); END END. -------------------------------------------------------------------------- Program compiles with warnings: > gpc marvin01.pas marvin01.pas: In main program: marvin01.pas:12: warning: constructing limited integer set `0..511' marvin01.pas:23: warning: constructing limited integer set `0..511' > -------------------------------------------------------------------------- Program output (unexpected errors): -------------------------------------------------------------------------- > ./a.out Error: 32 not in SET after adding! Error: 33 not in SET after adding! . . . Error: 63 not in SET after adding! Error: 96 not in SET after adding! Error: 97 not in SET after adding! Error: 98 not in SET after adding! . . . Error: 127 not in SET after adding! Error: 160 not in SET after adding! Error: 161 not in SET after adding! Error: 162 not in SET after adding! . . . Error: 191 not in SET after adding! Error: 224 not in SET after adding! Error: 225 not in SET after adding! Error: 226 not in SET after adding! . . . Error: 255 not in SET after adding! Error: 159 in SET after deletion! Error: 95 in SET after deletion! Error: 95 in SET after deletion! Checking: 2 Checking: 3 Checking: 5 Checking: 7 Checking: 11 Checking: 13 Checking: 17 Checking: 19 Checking: 23 Checking: 29 Checking: 31 Checking: 67 Checking: 71 Checking: 73 Checking: 79 Checking: 83 Checking: 89 Checking: 95 Error: 95 % 5 = 0. Error: 95 % 19 = 0. Checking: 131 Checking: 137 Checking: 139 Checking: 149 Checking: 151 Checking: 157 Checking: 159 Error: 159 % 3 = 0. Error: 159 % 53 = 0. Checking: 193 Checking: 197 Checking: 199 Checking: 211 Checking: 223 > ------------------------------------------------------------------------- Thank you for reading this far. Best regards, Marvin -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

4 11

Q: Availability of GPC + GTK+ worldwide?
by Mirsad Todorovac 13 Nov '01

13 Nov '01

Hi, I just had a crazy idea of developing an application in GNU Pascal - yet it struck me: if I distribute in source code, how many (in %) sites will be able to install it? This lead me to another thought: when will GPC be stable enough to include it in main gcc-3.0.x (or later) distribution? (I guess this might help the compiler be more wide spread, as happened wiht g77 ...) mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

3 3

Problems building GPC when host!=build
by Andris Pavenis 13 Nov '01

13 Nov '01

Configuring in p/rts fails when host!=build (for example when building native compiler for DJGPP or MINGW under Linux) as newly built xgcc and xgpc cannot be run on build system. In this case we should run corresponding cross-compiler instead. Included patch is tested only for --build=i686-pc-linux-gnu, --host=i586-mingw32msvc --target=i586-mingw32msvc Andris --- gpc-20010924/p/Make-lang.in~1 Mon Sep 24 19:59:48 2001 +++ gpc-20010924/p/Make-lang.in Tue Oct 30 17:57:24 2001 @@ -154,8 +154,12 @@ ADD_RTS_PARENT_DIR = sed -e 's,-B$[^/][^:]$,-B../../\1,g;s,^$[^/][^:]$,../../\1,' # The ' ' is there so, e.g., `-B.' will be replaced by ADD_RTS_PARENT_DIR -RTS_COMPILERS = CC="`echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" \ - PC="`echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" +RTS_COMPILERS = CC="`if test \"$(build_canonical)\" = \"$(host_canonical)\" ; then \ + echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR); \ + else echo $(GCC_FOR_TARGET); fi`" \ + PC="`if test \"$(build_canonical)\" = \"$(host_canonical)\" ; then \ + echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR);\ + else echo $(GPC_FOR_TARGET); fi`" GPC_GENERATED_SRC = \ $(srcdir)/p/parse.c \

3 10

Re: Support for PowerMax OS
by da Silva, Joe 13 Nov '01

13 Nov '01

Well, I have no idea what PowerMax OS is, but AFAIK, if GCC is available for PowerMax (preferably V2.95.3 ;-), it should also be possible to build GPC (if a binary does not already exist). So, you should perhaps also check "http://gcc.gnu.org/install/specific.html" to see if this is listed by another name (I couldn't find the words "Concurrent" or "PowerMax" on the page). Joe. > -----Original Message----- > From: Sven Jauring [SMTP:sven.jauring@hiq.se] > Sent: Friday, November 09, 2001 11:56 PM > To: gpc(a)gnu.de > Subject: Support for PowerMax OS > > Hi all > > Is it possible to use GPC for (Concurrent's) PowerMax operating system? > > I looked through the GPC distribution (20010924), but didn't find > anything about PowerMax. > > Best Regards > Sven Jauring << File: Card for Sven Jauring >>

1 0

win32 GPC blues
by Pierre Muller 11 Nov '01

11 Nov '01

Trying to get strings output for GPC to work, I needed a win32 gpc binary to check my changes to GDB. But I have problems both with the latest cygwin binary port ftp://agnes.dida.physik.uni-essen.de/home/chief/win32/cygwin/2.95.3/gpc-2001 0924.i686-pc-cygwin.tar.gz With the latest cygwin tools (uploaded using cygwin setup program) I get a problem that seems related to the fact that the assembler is called without any argument. $ gpc -v test.p Reading specs from /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/specs gpc version 20010924, based on 2.95.3 20010315 (release) /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/gpcpp.exe -lang-pascal -v -iprefix /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specsi686-pc-cygwin/2.95.3/ -famtmpfil e=/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc000288 -fdelphi-comments -D__GNU _PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20010924 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__= 1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -D_WIN32 -DWINNT -D_X86_=1 -D__STDC__=1 -D_ _stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__d eclspec(x)=__attribute__((x)) -D__OS_DOS__=1 -D__i386__ -D_WIN32 -D__WINNT__ -D_ X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribu te__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__OS_DOS__=1 -D__i386 -D_ _WINNT -Asystem(winnt) -Acpu(i386) -Amachine(i386) -remap -D__CYGWIN32__ -D__CYG WIN__ test.p /cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cca00288 GNU Pascal Compiler PreProcessor version 20010924, based on gcc-2.95.3 20010315 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specsi686-pc-cygwin/2.95.3/include /usr/local/include /include /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/include /usr/include End of search list. /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/gpc1.exe /cygdrive/c/DOCUME~1/ADMI NI~1/LOCALS~1/Temp/cca00288 -quiet -dumpbase test.pas -version -famtmpfile=/cygd rive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc000288 -o /cygdrive/c/DOCUME~1/ADMINI~1 /LOCALS~1/Temp/ccb00288 GNU Pascal version 2.95.3 20010315 (release) (i686-pc-cygwin) compiled by GNU C version 3.0.1. GNU Pascal version is actually 20010924, based on gcc-2.95.3 20010315 (release) test.p:1: warning: missing program header test.p:2: warning: missing string capacity - assuming 255 as Assembler messages: for reading open : No such file or directory Administrateur@LAOCOON /home/muller Remebering that mingw32 is the prefered win32 version, I tried to download the latest gpc for mingw32, but here again, I had problems. F:\pas\cvs100\ide>gpc -v Reading specs from f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\spec s gpc version 20010623, based on 2.95.3 20010315 (release) F:\pas\cvs100\ide>gcc -v Reading specs from f:/mingw32/bin/../lib/gcc-lib/mingw32/2.95.3-5/specs gcc version 2.95.3-5 (mingw special) F:\pas\cvs100\ide>gpc -v --automake hello.pp Reading specs from f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\spec s gpc version 20010623, based on 2.95.3 20010315 (release) f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\gpcpp.exe -lang-pascal -v -iprefix f:/mingw32/usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/i386-mingw 32msvc\2.95.3\ -famtmpfile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cca01008 -fautomak e -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D_ _GPC__=2 -D__GPC_MINOR__=0 -D__GPC_RELEASE__=20010623 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -D_WIN32 -DWIN32 -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -DWINNT -D_X86_=1 -D__STDC__=1 -D__s tdcall=__attribute__((__stdcall__)) -D_stdcall=__attribute__((__stdcall__)) -D__ cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__OS_DOS__ =1 -D__i386__ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -D __WINNT__ -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D___s tdcall__=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__d eclspec(x)=__attribute__((x)) -D__OS_DOS__=1 -D__i386 -D__WIN32 -D__WINNT -D___s tdcall=__attribute__((__stdcall__)) -Asystem(winnt) -Acpu(i386) -Amachine(i386) -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ hello.pp C:\DOCUME ~1\ADMINI~1\LOCALS~1\Temp\ccb01008 GNU Pascal Compiler PreProcessor version 20010623, based on gcc-2.95.3 20010315 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: f:/mingw32/usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/i386-mingw32msvc\ f:/mingw32/usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/i386-mingw32msvc\2.95. 3\include /usr/local/include /include /usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/include /usr/local/i386-mingw32/include End of search list. f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\gpc1.exe C:\DOCUME~1\A DMINI~1\LOCALS~1\Temp\ccb01008 -quiet -dumpbase hello.pas -version -famtmpfile=C :\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cca01008 -fautomake -o C:\DOCUME~1\ADMINI~1\LO CALS~1\Temp\ccc01008 GNU Pascal version 2.95.3 20010315 (release) (i386-mingw32msvc) compiled by GNU C version 3.0. GNU Pascal version is actually 20010623, based on gcc-2.95.3 20010315 (release) hello.pp:1: warning: missing program header as -o C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccd01008 C:\DOCUME~1\ADMINI~1\LOCALS~1 \Temp\ccc01008 collect2 crt2.o -Lf:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3 C:\D OCUME~1\ADMINI~1\LOCALS~1\Temp\ccd01008 -lgpc -lmingw32 -lgcc -lmoldname -lmsvcr t -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmsvcrt gpc: installation problem, cannot exec `collect2': No such file or directory I have the correct gcc installed, but gpc needs collect2, where should I find that binary ? Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99

6 35

GPC bug?
by Shafiek Rasdien 11 Nov '01

11 Nov '01

In my attempt to compile the p4 interpreter, I came across the following. The program ################################# program pcode; label 1; begin end. ################################### yields ******************************* test.p: In function `program_Pcode': test.p:2: label `1' used but not defined ******************************* causing a compile time error. Should this not be a warning. that says "Unused label `1'". Also #################################### program pcode (output); label 1; procedure asm; begin 1: end; { asm } begin 1: end. ###################################### Should say "Multiple label `1' instances" but gives ******************************************************** pc: Internal compiler error: program gpc1 got fatal signal 11 ********************************************************* Shafiek Rasdien Internet Solutions Tel: +27 11 283 5500 Fax: +27 11 283 5401

3 2

GPC.p/test/test_sum script problem
by Mirsad Todorovac 09 Nov '01

09 Nov '01

Hi, -------------------------------------------------------------------------- 1. grep -e: -------------------------------------------------------------------------- p/test/test_run uses grep -e option that is not allowed in Solaris' default grep (I guess somebody in Sun likes archaeology): > /usr/bin/grep -e w /usr/bin/grep: illegal option -- e Usage: grep -hblcnsviw pattern file . . . /usr/xpg4/bin/grep understands this option without problems, so after I've added a symlink to /usr/xpg4/bin/grep in ~/bin testsuite ran OK. -------------------------------------------------------------------------- 2. gawk, awk, nawk: -------------------------------------------------------------------------- ``awk'' and ``nawk'' don't seem to understand ``fflush'' function used in p/test/test_sum script - they break at it. If GNU gawk is not installed, editing of the script is required. -------------------------------------------------------------------------- 3. alpha-sof-4.0b/gawk: -------------------------------------------------------------------------- On Alpha/OSF1/DU4.0b systems there is an ancient example of gawk installed in /usr/bin which neither understands long options, neither fflush() function (if it's GNU at all?), so the script breaks - I bailed out again with symlinking /usr/local/bin/gawk to ~/bin, but I feel it's kind of clumsy. Yes, and if you consider me worthy I'd be happy to help :-) Best regards, Mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

2 2

Support for PowerMax OS
by Sven Jauring 09 Nov '01

09 Nov '01

Hi all Is it possible to use GPC for (Concurrent's) PowerMax operating system? I looked through the GPC distribution (20010924), but didn't find anything about PowerMax. Best Regards Sven Jauring

1 0

Re: ANNOUNCE: gcc-3.0.2 for DJGPP
by da Silva, Joe 09 Nov '01

09 Nov '01

This matter has been raised before, so I'm just repeating what was said previously (I don't know about the issues involved;-) : GPC is currently compatible with GCC 2.95.3 but not GCC 3.X.X, although it is intended that some time in the future, it will be made compatible with whatever is the current version of GCC ... Joe. PS - BTW, is your "worldnet.att.net" e-mail address still used? > -----Original Message----- > From: CBFalconer [SMTP:cbfalconer@yahoo.com] > Sent: Friday, November 09, 2001 8:06 AM > To: gpc mail-list > Subject: Re: ANNOUNCE: gcc-3.0.2 for DJGPP > > pavenis(a)lanet.lv wrote: > > > > This is an announcement of DJGPP port of gcc-3.0.2 > > > > GCC used to stand for the GNU C Compiler, but since the compiler > > supports several other languages aside from C, it now stands for > > the GNU Compiler Collection. > > > > GCC 3.0.x has several new optimizations, new targets, new languages > > and many other new features, relative to GCC 2.95.x. See the new > > features page for a more complete list. > > > > See http://gcc.gnu.org/gcc-3.0/ for more information about gcc-3.0.2 > > > > Currently C, C++, Fortran and Objective C compilers are supported > > for DJGPP. Java compiler is not ported and is not included > > > > Also libg++ is no more included and will not be included in future. > > > > Archives are available from DJGPP distribution in Simtelnet > > (and mirror sites) in directory v2gnu: > > http://www.simtel.net/pub/djgpp/v2gnu/ > > > > There are 6 archives: > > readme-gcc-3.0.2.txt - readme file from DJGPP port of GCC-3.0.2. It's > in > > separate file to avoid need to download large archives > > to get this file. > > gcc302s.zip - sources of gcc-3.0.2. I put all sources in a single > > archive. This file is only needed if You're want to > > rebuild gcc-3.0.2 from sources. > > gcc302b.zip - binaries of C compiler > > gpp302b.zip - binaries of C++ compiler (needs gcc302b.zip) > > g77302b.zip - binaries of Fortran compiler (needs gcc302b.zip) > > objc302b.zip - binaries of Objective C compiler (needs gcc302b.zip) > > gcc302s2.zip - shell script and patches for original gcc-3.0.2. > > I used them to generate gcc-3.0.2 sources for DJGPP > > (gcc2953s.zip). > > > > Files user need: > > Programming languages Needed files > > C gcc302b.zip > > C++ gcc302b.zip, gpp302b.zip > > Fortran gcc302b.zip, g77302b.zip > > Objective-C gcc302b.zip, objc302b.zip > > > > NOTE: gcc302b.zip contains file cxxfilt.exe and there is file with same > name in > > binutils (bnu2112b.zip). You can safely overwrite the old one. > > > > For more information about this port see archive > > gnu/gcc-3.02/readme.DJGPP > > after unpacking either gcc302b.zip or gcc302s.zip or get file > > readme-gcc-3.0.2.txt from directory v2gnu in DJGPP distribution > > > > Also please DON'T mix C++ libraries (or object files) built with > > different compiler versions. C++ sources should be recompiled (seems > > that there is no need to do this for C sources). > > > > System requirements > > =================== > > > > DJGPP-2.03 or above (otherwise exceptions will not work at all) > > > > binutils-2.11.2 or above. It's no more possible to use binutils-2.8.1 > > or 2.9.1. Command line option -mno-bnu210 is no more supported. > > > > Some warning for users of C++. C++ compiler in gcc-3.0.2 does more > strict > > syntax checking than gcc and egcs versions older than gcc-3.0. As result > > errors are generated in many places where earlier one got warnings. > > What about the gpc package? It presently wants the gcc 2.9.5.3 > package? > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)XXXXworldnet.att.net) > Available for consulting/temporary embedded and systems. > (Remove "XXXX" from reply address. yahoo works unmodified) > mailto:uce@ftc.gov (for spambots to harvest) > >

2 1

Re: ANNOUNCE: gcc-3.0.2 for DJGPP
by CBFalconer 08 Nov '01

08 Nov '01

pavenis(a)lanet.lv wrote: > > This is an announcement of DJGPP port of gcc-3.0.2 > > GCC used to stand for the GNU C Compiler, but since the compiler > supports several other languages aside from C, it now stands for > the GNU Compiler Collection. > > GCC 3.0.x has several new optimizations, new targets, new languages > and many other new features, relative to GCC 2.95.x. See the new > features page for a more complete list. > > See http://gcc.gnu.org/gcc-3.0/ for more information about gcc-3.0.2 > > Currently C, C++, Fortran and Objective C compilers are supported > for DJGPP. Java compiler is not ported and is not included > > Also libg++ is no more included and will not be included in future. > > Archives are available from DJGPP distribution in Simtelnet > (and mirror sites) in directory v2gnu: > http://www.simtel.net/pub/djgpp/v2gnu/ > > There are 6 archives: > readme-gcc-3.0.2.txt - readme file from DJGPP port of GCC-3.0.2. It's in > separate file to avoid need to download large archives > to get this file. > gcc302s.zip - sources of gcc-3.0.2. I put all sources in a single > archive. This file is only needed if You're want to > rebuild gcc-3.0.2 from sources. > gcc302b.zip - binaries of C compiler > gpp302b.zip - binaries of C++ compiler (needs gcc302b.zip) > g77302b.zip - binaries of Fortran compiler (needs gcc302b.zip) > objc302b.zip - binaries of Objective C compiler (needs gcc302b.zip) > gcc302s2.zip - shell script and patches for original gcc-3.0.2. > I used them to generate gcc-3.0.2 sources for DJGPP > (gcc2953s.zip). > > Files user need: > Programming languages Needed files > C gcc302b.zip > C++ gcc302b.zip, gpp302b.zip > Fortran gcc302b.zip, g77302b.zip > Objective-C gcc302b.zip, objc302b.zip > > NOTE: gcc302b.zip contains file cxxfilt.exe and there is file with same name in > binutils (bnu2112b.zip). You can safely overwrite the old one. > > For more information about this port see archive > gnu/gcc-3.02/readme.DJGPP > after unpacking either gcc302b.zip or gcc302s.zip or get file > readme-gcc-3.0.2.txt from directory v2gnu in DJGPP distribution > > Also please DON'T mix C++ libraries (or object files) built with > different compiler versions. C++ sources should be recompiled (seems > that there is no need to do this for C sources). > > System requirements > =================== > > DJGPP-2.03 or above (otherwise exceptions will not work at all) > > binutils-2.11.2 or above. It's no more possible to use binutils-2.8.1 > or 2.9.1. Command line option -mno-bnu210 is no more supported. > > Some warning for users of C++. C++ compiler in gcc-3.0.2 does more strict > syntax checking than gcc and egcs versions older than gcc-3.0. As result > errors are generated in many places where earlier one got warnings. What about the gpc package? It presently wants the gcc 2.9.5.3 package? -- Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)XXXXworldnet.att.net) Available for consulting/temporary embedded and systems. (Remove "XXXX" from reply address. yahoo works unmodified) mailto:uce@ftc.gov (for spambots to harvest)

1 0

Subrange Bug with indentation?
by Eike Lange 08 Nov '01

08 Nov '01

Hi Folks! The following program compiles correctly (shouldn't there a warning?). &<---------- (snip) ----------- program fail; type TFoo = 2.7 .. 2.8; var MyFoo: TFoo; begin MyFoo := 1.0; WriteLn (MyFoo) end. &<---------- (snap) ----------- Notice, that you need spaces arround ".." to disable warning messages: "fail.pas:4: Only one decimal point in real number allowed" My GPC version is: Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20010924, based on 2.95.2 19991024 (release) Eike

3 3

Re: win32 GPC blues
by Pierre Muller 06 Nov '01

06 Nov '01

At 15:02 06/11/2001 , Prof. A Olowofoyeku (The African Chief) a écrit: >On 6 Nov 2001, at 13:39, Pierre Muller wrote: > > > Trying to get strings output for GPC to work, > > I needed a win32 gpc binary to check my changes to GDB. > > > > But I have problems both with the latest cygwin binary port > > ftp://agnes.dida.physik.uni-essen.de/home/chief/win32/cygwin/2.95.3/gpc-20 > > 01 0924.i686-pc-cygwin.tar.gz > >That version (0924) is broken under Windows. I haven't had time to >investigate why, because I simply regressed to 0623 at the time. I >thought I had removed 0924 from agnes, but perhaps forgot to do so (I >have done so now). Please get the 0623 version instead. I downloaded that version but I still have the same problem.... $ gpc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-cygwin/2.95.3/specs gpc version 20010623, based on 2.95.3 20010315 (release) >[...] > > as > > Assembler messages: > > for reading open > > : No such file or directory > >This is most likely a mount problem. For some reason, it seems that you >need to mount your volumes in textmode instead of binary. I don't understand, what change should I make to my mount.... I only had binary mounts but I tried to a a textmode mount to a directory that contains some pascal source code. But this does not change anything :( I still get the same error from as, both for a file on a binmode mount and on a textmode mount. > > Remebering that mingw32 is the prefered win32 version, I tried to download > > the latest gpc for mingw32, but here again, I had problems. >[...] > > -lmsvcr t -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc > > -lmoldname -lmsvcrt gpc: installation problem, cannot exec `collect2': No > > such file or directory > > > > > > I have the correct gcc installed, but gpc needs collect2, where should I > > find that binary ? > >Simply copy 'ld.exe' to 'collect2.exe'. I also tried this, but here again, I only made a small step forward: I does go up to linking but then I get this : F:\pas\cvs100\ide>gpc -v hello.pp -Lf:\mingw32\lib Reading specs from f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\spec s gpc version 20010331, based on 2.95.2 19991024 (release) f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\gpcpp.exe -lang-pascal -v -iprefix f:/mingw32/usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/i386-mingw 32msvc\2.95.2\ -famtmpfile=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cca02196 -fdelphi- comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D __GPC_MINOR__=0 -D__GPC_RELEASE__=20010331 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_ LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -Di386 -D_WIN32 -DWIN32 -D__WIN32_ _ -D__MINGW32__=0.2 -D__MSVCRT__ -DWINNT -D_X86_=1 -D__STDC__=1 -D__stdcall=__at tribute__((__stdcall__)) -D_stdcall=__attribute__((__stdcall__)) -D__cdecl=__att ribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__OS_DOS__=1 -D__i386 __ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -D__WINNT__ - D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D___stdcall__=__ attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)= __attribute__((x)) -D__OS_DOS__=1 -D__i386 -D__WIN32 -D__WINNT -D___stdcall=__at tribute__((__stdcall__)) -Asystem(winnt) -Acpu(i386) -Amachine(i386) -remap -Acp u(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ hello.pp C:\DOCUME~1\ADMINI~1 \LOCALS~1\Temp\cca02196.i GNU Pascal Compiler PreProcessor version 20010623, based on gcc-2.95.3 20010315 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: f:/mingw32/usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/i386-mingw32msvc\ f:/mingw32/usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/i386-mingw32msvc\2.95. 2\include /usr/local/include /include /usr/local/lib/gcc-lib/i386-mingw32msvc/2.95.3/include /usr/local/i386-mingw32/include End of search list. f:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\gpc1.exe C:\DOCUME~1\A DMINI~1\LOCALS~1\Temp\cca02196.i -quiet -dumpbase hello.pas -version -famtmpfile =C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cca02196 -o C:\DOCUME~1\ADMINI~1\LOCALS~1\Te mp\cca02196.s GNU Pascal version 2.95.3 20010315 (release) (i386-mingw32msvc) compiled by GNU C version 3.0. GNU Pascal version is actually 20010623, based on gcc-2.95.3 20010315 (release) hello.pp:1: warning: missing program header as -o C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cca021961.o C:\DOCUME~1\ADMINI~1\LOCAL S~1\Temp\cca02196.s collect2 crt2.o -Lf:\mingw32\lib -Lf:\mingw32\usr\local\lib\gcc-lib\i386-mingw3 2msvc\2.95.3 -Lf:\mingw32\usr\local\lib\gcc-lib\i386-mingw32msvc\2.95.3\i386-min gw32msvc\2.95.2\..\..\.. C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\cca021961.o -lgpc -l mingw32 -lgcc -lmoldname -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmin gw32 -lgcc -lmoldname -lmsvcrt collect2: cannot open crt2.o: No such file or directory Note that I added -Lf:\mingw32\lib to the command line options and this is the location of this crt2.o file ... Using / instead of \ or changing the option position on command line doesn't change the result. Anyway, I don't think its used for single files ... Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99

3 3

[RFA] Unify pascal string printing
by Pierre Muller 06 Nov '01

06 Nov '01

This change will allow to display GPC stings nicely as Free Pascal strings are already. The method is pretty generic and adding new types (widestings or ansistrings) should be easy. ChangeLog: 2001-11-06 Pierre Muller <muller(a)ics.u-strasbg.fr> * p-lang.c (is_pascal_string_type): new function to determine if a type is a string type. * p-valprint.c (pascal_val_print) : use is_pascal_string_type function to display strings nicely. Index: p-lang.c =================================================================== RCS file: /cvs/src/src/gdb/p-lang.c,v retrieving revision 1.3 diff -u -r1.3 p-lang.c --- p-lang.c 2000/08/11 01:02:35 1.3 +++ p-lang.c 2001/11/06 16:02:53 @@ -17,7 +17,7 @@ along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ -/* This file is derived from p-lang.c */ +/* This file is derived from c-lang.c */ #include "defs.h" #include "symtab.h" @@ -27,8 +27,56 @@ #include "language.h" #include "p-lang.h" #include "valprint.h" - +#include <ctype.h> + extern void _initialize_pascal_language (void); + + +/* Determines if type TYPE is a pascal string type. + Returns 1 if the type is a known pascal type + This function is used by p-valprint.c code to allow better string display. + If it is a pascal string type, then it also sets info needed + to get the length and the data of the string + length_pos, length_size and string_pos are given in bytes. + char_size gives the element size in bytes. + FIXME: if the position or the size of these fields + are not multiple of TARGET_CHAR_BIT then the results are wrong + but this does not happen for Free Pascal nor for GPC */ +int +is_pascal_string_type (struct type *type,int *length_pos, + int * length_size, int *string_pos, int *char_size) +{ + if (TYPE_CODE (type) == TYPE_CODE_STRUCT) + { + /* Old Borland type pascal strings from Free Pascal Compiler */ + /* Two fields: length and st */ + if (TYPE_NFIELDS (type) == 2 && + strcmp (TYPE_FIELDS (type)[0].name, "length") == 0 && + strcmp (TYPE_FIELDS (type)[1].name, "st") == 0) + { + *length_pos = TYPE_FIELD_BITPOS (type, 0) / TARGET_CHAR_BIT; + *length_size = TYPE_FIELD_TYPE (type, 0)->length; + *string_pos = TYPE_FIELD_BITPOS (type, 1) / TARGET_CHAR_BIT; + *char_size = 1; + return 1; + }; + /* GNU pascal strings */ + /* Three fields: Capacity, length and schema$ or _p_schema */ + if (TYPE_NFIELDS (type) == 3 && + strcmp (TYPE_FIELDS (type)[0].name, "Capacity") == 0 && + strcmp (TYPE_FIELDS (type)[1].name, "length") == 0) + { + *length_pos = TYPE_FIELD_BITPOS (type, 1) / TARGET_CHAR_BIT; + *length_size = TYPE_FIELD_TYPE (type, 1)->length; + *string_pos = TYPE_FIELD_BITPOS (type, 2) / TARGET_CHAR_BIT; + /* FIXME: how can I detect wide chars in GPC ?? */ + *char_size = 1; + return 1; + }; + } + return 0; +} + static void pascal_one_char (int, struct ui_file *, int *); /* Print the character C on STREAM as part of the contents of a literal Index: p-valprint.c =================================================================== RCS file: /cvs/src/src/gdb/p-valprint.c,v retrieving revision 1.4 diff -u -r1.4 p-valprint.c --- p-valprint.c 2001/03/27 20:36:24 1.4 +++ p-valprint.c 2001/11/06 16:02:53 @@ -40,6 +40,7 @@ + /* Print data of type TYPE located at VALADDR (within GDB), which came from the inferior at address ADDRESS, onto stdio stream STREAM according to FORMAT (a letter or 0 for natural format). The data at VALADDR is in @@ -53,7 +54,6 @@ The PRETTY parameter controls prettyprinting. */ - int pascal_val_print (struct type *type, char *valaddr, int embedded_offset, CORE_ADDR address, struct ui_file *stream, int format, @@ -63,6 +63,8 @@ unsigned len; struct type *elttype; unsigned eltlen; + int length_pos, length_size, string_pos; + int char_size; LONGEST val; CORE_ADDR addr; @@ -188,15 +190,17 @@ Pascal strings are mapped to records with lowercase names PM */ /* I don't know what GPC does :( PM */ - if (TYPE_CODE (elttype) == TYPE_CODE_STRUCT && - TYPE_NFIELDS (elttype) == 2 && - strcmp (TYPE_FIELDS (elttype)[0].name, "length") == 0 && - strcmp (TYPE_FIELDS (elttype)[1].name, "st") == 0 && - addr != 0) + if ( is_pascal_string_type (elttype, &length_pos, + &length_size, &string_pos, &char_size) && + addr != 0) { - char bytelength; - read_memory (addr, &bytelength, 1); - i = val_print_string (addr + 1, bytelength, 1, stream); + ULONGEST string_length; + void *buffer; + buffer = xmalloc(length_size); + read_memory(addr + length_pos, buffer, length_size); + string_length = extract_unsigned_integer (buffer, length_size); + xfree(buffer); + i = val_print_string (addr + string_pos, string_length, char_size , stream); } else if (pascal_object_is_vtbl_member (type)) { @@ -315,12 +319,11 @@ } else { - if ((TYPE_NFIELDS (type) == 2) && - (strcmp (TYPE_FIELDS (type)[0].name, "length") == 0) && - (strcmp (TYPE_FIELDS (type)[1].name, "st") == 0)) + if ( is_pascal_string_type (type, &length_pos, &length_size, + &string_pos, &char_size)) { - len = (*(valaddr + embedded_offset)) & 0xff; - LA_PRINT_STRING (stream, valaddr + embedded_offset + 1, len, /* width ?? */ 0, 0); + len = extract_unsigned_integer(valaddr + embedded_offset + length_pos, length_size); + LA_PRINT_STRING (stream, valaddr + embedded_offset + string_pos, len, char_size, 0); } else pascal_object_print_value_fields (type, valaddr + embedded_offset, address, stream, format, Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99

1 0

[RFA] p-exp.y uppercasing change
by Pierre Muller 06 Nov '01

06 Nov '01

In order to allow GPC compiled programs to find fields of structures, I need to change p-exp.y so that the case is only modifed if the symbol is really found. I also added a check for the standard GPC case which uses names in capitalized form (i.e. first char in uppercase, rest in lowercase). Note: before this patch, it is impossible to get any field of a record (pascal structure) compiled with GPC. Should I consider changing 5.1 branch also ? Changelog: 2001-11-06 Pierre Muller <muller(a)ics.u-strasbg.fr> * p-exp.y (): only change case of expression if symbol is found. Also check for GPC standard name form. Index: p-exp.y =================================================================== RCS file: /cvs/src/src/gdb/p-exp.y,v retrieving revision 1.6 diff -u -r1.6 p-exp.y --- p-exp.y 2001/06/10 16:25:51 1.6 +++ p-exp.y 2001/11/06 15:27:02 @@ -1306,14 +1306,48 @@ { if ((tmp[i]>='a' && tmp[i]<='z')) tmp[i] -= ('a'-'A'); - /* I am not sure that copy_name gives excatly the same result ! */ + } + sym = lookup_symbol (tmp, expression_context_block, + VAR_NAMESPACE, + &is_a_field_of_this, + (struct symtab **) NULL); + if (sym) + for (i = 0;i <= namelen;i++) + { if ((tokstart[i]>='a' && tokstart[i]<='z')) tokstart[i] -= ('a'-'A'); + } + } + /* Third chance Capitalized (as GPC does) */ + if (!sym) + { + for (i = 0;i <= namelen;i++) + { + if (i==0) + { + if ((tmp[i]>='a' && tmp[i]<='z')) + tmp[i] -= ('a'-'A'); + } + else + if ((tmp[i]>='A' && tmp[i]<='Z')) + tmp[i] -= ('A'-'a'); } - sym = lookup_symbol (tmp, expression_context_block, + sym = lookup_symbol (tmp, expression_context_block, VAR_NAMESPACE, &is_a_field_of_this, (struct symtab **) NULL); + if (sym) + for (i = 0;i <= namelen;i++) + { + if (i==0) + { + if ((tokstart[i]>='a' && tokstart[i]<='z')) + tokstart[i] -= ('a'-'A'); + } + else + if ((tokstart[i]>='A' && tokstart[i]<='Z')) + tokstart[i] -= ('A'-'a'); + } } /* Call lookup_symtab, not lookup_partial_symtab, in case there are no psymtabs (coff, xcoff, or some future change to blow away the Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99

1 0

Re: Re :Typecasting | record-field boundary
by Frank Heckenbach 05 Nov '01

05 Nov '01

Anuradha wrote: > The machine i am working with is sparc sun-solaris.Can you tell me more > on the alignment problem? Yes, Sparcs have strict alignment requirements. So I suggest to either use `SizeOf (LongestInt)' instead of 2 or, as I already said, avoid the extra code entirely and just use GetMem/FreeMem (the latter with only one argument if you like) instead of getmemory/freememory (provided you don't need the extra size information for any other purpose besides freememory). > I don't get the error with the original code if i just add "packed" > before the "record". GPC generates special code for packed records which avoids the alignment problem, but it clearly less efficient. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: Re :Typecasting | record-field boundary
by da Silva, Joe 05 Nov '01

05 Nov '01

Hey - you're right! "Word" is (usually) 32 bits for GPC. Lesson : Read the latest doc's, don't rely on the old ones! <G> Anyway, this issue shouldn't matter for the sample code presented, so we'll wait for some more input from Anuradha ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, November 05, 2001 12:00 PM > To: gpc(a)gnu.de > Subject: Re: Re :Typecasting | record-field boundary > > da Silva, Joe wrote: > > > Since the code "works with BP but not GPC", I presumed the > > hardware was X86 (IA32) ... I think Anuradha needs to clarify > > this, because as you say, misaligned access may not work > > with some other processors. BTW, the code also requires that > > a "word" is 16 bits - since the documentation implies that this > > is not true on all hardware, > > In fact, for GPC this is true for *none* of the platforms -- > `Integer' and `Word' are at least 32 bit (64 on some). Of course, > you can redeclare `Word' (see the System unit), though this is not > recommended. > > > this is another potential problem > > with the code. > > I think I mentioned this in my last mail. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: GPC
by da Silva, Joe 05 Nov '01

05 Nov '01

You don't say what platform. For example, if it's DOS/DJGPP, Maurice has the most recent/stable build for this available via : ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2953b.zip Joe. > -----Original Message----- > From: Vincent Derrien [SMTP:hyzzod@free.fr] > Sent: Wednesday, October 31, 2001 9:33 PM > To: gpc(a)gnu.de > Subject: GPC > > Hello, > > Can you say me where i can find the stable version of gpc please ? > I've got on the ftp, but i've just found the current (alpha) et old (2.0) > > thanks. > > -- > Vincent Derrien / hyzzod > hyzzod(a)free.fr

2 1

Re: Re :Typecasting | record-field boundary
by da Silva, Joe 05 Nov '01

05 Nov '01

Thanks for the clarification, Frank. Since the code "works with BP but not GPC", I presumed the hardware was X86 (IA32) ... I think Anuradha needs to clarify this, because as you say, misaligned access may not work with some other processors. BTW, the code also requires that a "word" is 16 bits - since the documentation implies that this is not true on all hardware, this is another potential problem with the code. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Saturday, November 03, 2001 4:52 AM > To: gpc(a)gnu.de > Subject: Re: Re :Typecasting | record-field boundary > > da Silva, Joe wrote: > > > So it seems this issue has arisen, because someone has decided > > to create 'getmemory' and 'freememory' routines, which simulate the > > functionality of 'new' and 'dispose' - strange!!! <g> > > Not quite. In BP (which the code was originally written for AFAIUI), > `New' does not support run-time variable sizes (there are no schema > types or similar in BP). So every allocation of variable size has to > be done via GetMem, and freed via FreeMem. Furthermore, BP does not > keep track of the size allocated by itself, and FreeMem must be > passed the correct size. So this stuff makes kind of sense for BP, > but is quite unnecessary for GPC. > > > Nevertheless, I can't see any reason why the sample code presented > > should fail, unless there is also some issue with accessing of record > > fields and their address alignment, right? > > Apart from the 2 vs. 4 bytes (i.e., SizeOf > (Integer/Word/SizeType/...)) problem, there can be alignment > problems. The Intel IA32 processors allow misaligned access, though > with a speed penalty, other processors will simply crash. > > With a "shift" of 2 bytes, you're sure to get alignment problems. > With a shift of 4 bytes (as would be reasonable for GPC, see above), > you might get problems with large types (LongInt, real types). Not > sure what diffferent processors require, but I wouldn't be surprised > if such code crashes on non-IA32 machines. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

GPC
by Vincent Derrien 02 Nov '01

02 Nov '01

Hello, Can you say me where i can find the stable version of gpc please ? I've got on the ftp, but i've just found the current (alpha) et old (2.0) thanks. -- Vincent Derrien / hyzzod hyzzod(a)free.fr

1 0

How can I get a complete copy of gpc ready to run?
by arvid.herzenberg 02 Nov '01

02 Nov '01

Section 5.3 of the GNU Pascal Manual says that many things are needed to compile GPC and to make sure that all necessary support libraries are installed. Just to learn how to do these things would take this 76 year old prospective user many, many boring months. I would prefer to spend this time on physical problems I care about, rather than on computer science. Can anybody tell me where or how I can get (or buy) a complete compiled copy of gpc on a CD (or set of floppies), containing all necessary libraries etc, all ready to run on SuSE Linux 7.1?

1 0

Re: Re :Typecasting | record-field boundary
by da Silva, Joe 02 Nov '01

02 Nov '01

Cute! ;-) So it seems this issue has arisen, because someone has decided to create 'getmemory' and 'freememory' routines, which simulate the functionality of 'new' and 'dispose' - strange!!! <g> Nevertheless, I can't see any reason why the sample code presented should fail, unless there is also some issue with accessing of record fields and their address alignment, right? Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Friday, November 02, 2001 4:50 AM > To: anuradha(a)adcc.alcatel.be; cbfalconer(a)worldnet.att.net; gpc(a)gnu.de > Subject: Re: Re :Typecasting | record-field boundry > > CBFalconer wrote: > > > Anuradha wrote: > > > > > > The whole code is in a function 'getmemory' that 'getmem's the > > > required number of bytes and stores the number of bytes in the > > > previous 2 bytes. > > > There is also a procedure 'freememory' that reads the previous > > > 2 bytes and frees as many bytes as was allocated earlier by > > > getmemory. what could be the problem ? > > > ----------------------------- > > > program typcast1; > > > type > > > Mytype=record > > > i : integer; > > > c:^char; > > > end; > > > var > > > p:pointer; > > > begin > > > getmem(p,sizeof(mytype)+2); > > > fillchar(p^,sizeof(mytype)+2,0); > > > word(p^):=sizeof(mytype); > > > p:=pchar(p)+2; > > > mytype(p^).c:=nil; > > > end. > > > > Totally unneccessary. The system remembers the size allocated all > > by itself. > > > > getmem(p, sizeneeded); > > operateon(p^); > > dispose(p); > > p := nil; (* safety measure *) > > > > Pascal is a simple language. It doesn't have pointer arithmetic > > for very good reasons. Don't try to contort it into C. > > > > (I believe. Certainly Pascalp operates this way, so does C, which > > supplies the underlying library for GPC. Frank can confirm or > > deny). > > Confirm. Dispose and FreeMem are completely equivalent in GPC, and > you even can omit the second parameter to FreeMem. So if you only > need the extra memory for this purpose, you can avoid it entirely > with GPC and replace getmemory by a simple GetMem. > > And, of course, the 2 vs. 4 bytes issue looks quite much like the > size of Integer, sso SizeOf (Integer) should work with both > compilers. (Think about it: GPC allows memory allocations greater > than 64 KB, so storing the size in 2 bytes is not a good idea. ;-) > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re :Typecasting | record-field boundry
by Anuradha 01 Nov '01

01 Nov '01

Hello, * Leave alone the const, even if i equate the pointer to 'nil' the problem occurs.{ofcourse i did remove the writeln statement that dereferences the pointer}. * Why such coding at all : The whole code is in a function 'getmemory' that 'getmem's the required number of bytes and stores the number of bytes in the previous 2 bytes. There is also a procedure 'freememory' that reads the previous 2 bytes and frees as many bytes as was allocated earlier by getmemory. what could be the problem ? ----------------------------- program typcast1; type Mytype=record i : integer; c:^char; end; var p:pointer; begin getmem(p,sizeof(mytype)+2); fillchar(p^,sizeof(mytype)+2,0); word(p^):=sizeof(mytype); p:=pchar(p)+2; mytype(p^).c:=nil; end. ---------------------- regards, Anuradha "da Silva, Joe" wrote: > I hope when you say "change p:=pchar(p)+2; to p:=pchar(p)+4;", you also > change "getmem(p,sizeof(mytype)+2);" to "getmem(p,sizeof(mytype)+4);"! > <g> > > I'm sure we all agree that this is very ugly, dangerous coding, but that's > not the point. You are trying to "stretch the boundaries" of the compiler, > to see how it behaves and to find out if there are any areas which may > in practice cause problems with porting other code, right? > > Well, to be honest, I can't see what the problem is here, although it must > have something to do with 32 bit alignment. As far as I can see, the two > lines "fillchar(p^,sizeof(mytype)+2,0);" and "word(p^):=sizeof(mytype);" > are irrelevant. All you are doing is allocating 2 extra bytes of memory than > your record type ("Mytype") needs, then offsetting a pointer to this by 2 > bytes, thereby forcing the compiler to address the record (and in > particular, > the pointer "c" within the record) on a 16 bit boundary. > > That's as far as I can analyse the situation, based simply on the source > code presented. Since I don't know the "inner workings" of the compiler > myself, perhaps someone else can comment further about this apparent > alignment issue. > > Joe. > > > -----Original Message----- > > From: Anuradha [SMTP:anuradha@adcc.alcatel.be] > > Sent: Wednesday, October 31, 2001 10:19 AM > > To: gpc > > Subject: Re: Typecasting > > > > Hello, > > > > I am really sorry for having missed a ^ in the program but you see , > > the > > program really worked in BP and not in GPC.But i do know that it is > > stupid to > > manipulate some parts of the pointer.kindly delete the previous mail. > > It is this program that i have problems in. > > ----------------- > > program typcast1; > > const ct :char='h'; > > type > > Mytype=record > > i : integer; > > c:^char; > > end; > > var > > p:pointer; > > begin > > getmem(p,sizeof(mytype)+2); > > fillchar(p^,sizeof(mytype)+2,0); > > word(p^):=sizeof(mytype); > > p:=pchar(p)+2; > > mytype(p^).c:=@ct; > > writeln(mytype(p^).c^); > > end. > > ------------------------ > > > > But if i change p:=pchar(p)+2; to p:=pchar(p)+4; then it works.Is it > > something to do with the word-boundaries? > > > > Thanks and regards, > > Anuradha > > > > > > Marco van de Voort wrote: > > > > > > What is the purpose of these two lines : ? > > > > word(p):=sizeof(mytype); > > > > > > In real mode TP it sets the offset of the segment:offset pair to 1. > > > > > > Probably it originally was meant as a simple inc(p); > > > > > > The problem it expects that the offset part of a newly allocated block > > is > > > always zero, which is afaik not true. (real mode TP allocates per half > > > segment). > > > > > > > p:=pchar(p)+2; > > > > > > inc(p,2); or p:=@p[2]; > > > > > > The overall effect therefore is inc(p,3); or p:=pchar(p)[3]; > > > > -- > > S.Anuradha > > Generic Data Tools, > > Alcatel Chennai. > > Alcanet : 2-757-7123

4 3

Avoiding warning message
by Preben Mikael Bohn 01 Nov '01

01 Nov '01

Hi all.. Is there any way to avoid the warning message " warning: missing string capacity - assuming 255" (other than correcting the problem, that is :-))? Best regards Preben Bohn ===== The two rules for success are: 1. Never tell them everything you know. ____________________________________________________________ Nokia Game is on again. Go to http://uk.yahoo.com/nokiagame/ and join the new all media adventure before November 3rd.

2 1

Re: Avoiding warning message
by Oldham, Adam 01 Nov '01

01 Nov '01

gpc -w should omit warnings liek that Adam -----Original Message----- From: Preben Mikael Bohn [mailto:preben_bohn@yahoo.com] Sent: Thursday, November 01, 2001 9:41 AM To: gpc(a)gnu.de Subject: Avoiding warning message Hi all.. Is there any way to avoid the warning message " warning: missing string capacity - assuming 255" (other than correcting the problem, that is :-))? Best regards Preben Bohn ===== The two rules for success are: 1. Never tell them everything you know. ____________________________________________________________ Nokia Game is on again. Go to http://uk.yahoo.com/nokiagame/ and join the new all media adventure before November 3rd.

1 0

not used or set
by toms＠ncifcrf.gov 01 Nov '01

01 Nov '01

Folks: I am compiling my programs with both GPC and Sun's compiler. A service that the Sun compiler provides is to check that a variable is actually used or set. For example, it will say: pc0: WorkShop Compilers 4.2 01/04/00 Pascal 4.2 patch 104632-11 Wed Oct 31 08:05:05 2001 numcode.p: In procedure checkcount: w 18260 variable f is neither used nor set This would be a very useful feature to have as it allows one to remove unused or leftover variables. In this case I was using a global (output) when I should have been using the locally defined file! Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/

2 1

Probs building gpc on sparc/solaris
by Stephan Eickschen 01 Nov '01

01 Nov '01

Dear List, May be it's an OT but I couldn't find anything matching in the archives or at google. I downloaded gpc-20010924.tar.gz gcc-core-2.95.2.tar.gz unpacked them, followed the instructions in INSTALL (...) configure --enable-languages=pascal (...) executed a gmake and get: > cd /home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/doc/en/info && makeinfo -I .. -I ../.. -I ../../generated -o gpc.info gpc.texi > Making info file `gpc.info' from `gpc.texi'. > ../install.texi:143: Unknown command `smallformat'. > ../install.texi:145: Unmatched `@end'. > ../install.texi:155: Unknown command `smallformat'. > ../install.texi:158: Unmatched `@end'. > ../reference.texi:8587: itemize requires an argument: the formatter for @item. > ../reference.texi:8599: itemize requires an argument: the formatter for @item. > makeinfo: Removing output file `gpc.info' due to errors; use --force to preserve. > gmake[1]: *** [/home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/doc/en/info/gpc.info] Error 2 > gmake[1]: Leaving directory `/home/AIDA301/eicksch/gpc/build/gcc' > gmake: *** [all-gcc] Error 2 uname -a SunOS aida3 5.8 Generic sun4u sparc SUNW,Ultra-5_10 Any suggestion / help??? Best regards, Stephan -- ---------------------------------------------------------------------- Stephan Eickschen Tel. : +49 (0)8153 28-1351 GeoForschungsZentrum Potsdam (GFZ) Fax. : +49 (0)8153 28-1207 Division 1, Section 1.2 c/o email: eicksch(a)gfz-potsdam.de DLR Oberpfaffenhofen www : http://op.gfz-potsdam.de Box 1116 82234 Wessling Germany ----------------------------------------------------------------------

2 1

Re: Typecasting
by da Silva, Joe 31 Oct '01

31 Oct '01

I hope when you say "change p:=pchar(p)+2; to p:=pchar(p)+4;", you also change "getmem(p,sizeof(mytype)+2);" to "getmem(p,sizeof(mytype)+4);"! <g> I'm sure we all agree that this is very ugly, dangerous coding, but that's not the point. You are trying to "stretch the boundaries" of the compiler, to see how it behaves and to find out if there are any areas which may in practice cause problems with porting other code, right? Well, to be honest, I can't see what the problem is here, although it must have something to do with 32 bit alignment. As far as I can see, the two lines "fillchar(p^,sizeof(mytype)+2,0);" and "word(p^):=sizeof(mytype);" are irrelevant. All you are doing is allocating 2 extra bytes of memory than your record type ("Mytype") needs, then offsetting a pointer to this by 2 bytes, thereby forcing the compiler to address the record (and in particular, the pointer "c" within the record) on a 16 bit boundary. That's as far as I can analyse the situation, based simply on the source code presented. Since I don't know the "inner workings" of the compiler myself, perhaps someone else can comment further about this apparent alignment issue. Joe. > -----Original Message----- > From: Anuradha [SMTP:anuradha@adcc.alcatel.be] > Sent: Wednesday, October 31, 2001 10:19 AM > To: gpc > Subject: Re: Typecasting > > Hello, > > I am really sorry for having missed a ^ in the program but you see , > the > program really worked in BP and not in GPC.But i do know that it is > stupid to > manipulate some parts of the pointer.kindly delete the previous mail. > It is this program that i have problems in. > ----------------- > program typcast1; > const ct :char='h'; > type > Mytype=record > i : integer; > c:^char; > end; > var > p:pointer; > begin > getmem(p,sizeof(mytype)+2); > fillchar(p^,sizeof(mytype)+2,0); > word(p^):=sizeof(mytype); > p:=pchar(p)+2; > mytype(p^).c:=@ct; > writeln(mytype(p^).c^); > end. > ------------------------ > > But if i change p:=pchar(p)+2; to p:=pchar(p)+4; then it works.Is it > something to do with the word-boundaries? > > Thanks and regards, > Anuradha > > > Marco van de Voort wrote: > > > > What is the purpose of these two lines : ? > > > word(p):=sizeof(mytype); > > > > In real mode TP it sets the offset of the segment:offset pair to 1. > > > > Probably it originally was meant as a simple inc(p); > > > > The problem it expects that the offset part of a newly allocated block > is > > always zero, which is afaik not true. (real mode TP allocates per half > > segment). > > > > > p:=pchar(p)+2; > > > > inc(p,2); or p:=@p[2]; > > > > The overall effect therefore is inc(p,3); or p:=pchar(p)[3]; > > -- > S.Anuradha > Generic Data Tools, > Alcatel Chennai. > Alcanet : 2-757-7123

1 0

Re: Typecasting
by da Silva, Joe 31 Oct '01

31 Oct '01

What is the purpose of these two lines : ? word(p):=sizeof(mytype); p:=pchar(p)+2; Joe. > -----Original Message----- > From: Anuradha [SMTP:anuradha@adcc.alcatel.be] > Sent: Tuesday, October 30, 2001 8:54 AM > To: gpc > Subject: Re: Typecasting > > Hello, > > Sorry for the wrong sample program and a silly doubt.The problem is we > have > large codes already written and we work in the support department that > converts these sources to executables runnable on unix and i cannot change > much of the code. > This time i have analysed more and am attaching a code that works fine > in BP > and doesnot work in GPC.It is something to do with the pointers. > Can you kindly tell me what the problem is? > ---------------------------------- > program typcast1; > {type > word=word(16);} > type > Mytype=record > c:char; > end; > var > p:pointer; > begin > getmem(p,sizeof(mytype)+2); > word(p):=sizeof(mytype); > p:=pchar(p)+2; > mytype(p^).c:='h'; > writeln(mytype(p^).c); > end. > ---------------------------------- > thanks and regards, > Anu > > Frank Heckenbach wrote: > > > Anuradha wrote: > > > > > It is not a typecasting error.It's probably fillchar question.I find > the > > > following sample program ending in a "segmentation fault -core dump" , > i > > > think because of doing a fillchar of a record which has a member > that's > > > a pointer . > > > > > > -------------------------------------- > > > program a; > > > type > > > myrec=record > > > x:^integer; > > > end; > > > var > > > ptr :^myrec; > > > > > > begin > > > getmem(ptr,sizeof(myrec)); > > > fillchar(ptr^,sizeof(myrec),0); > > > ptr^.x^:=5; > > > write(ptr^.x^); > > > end. > > > -------------------------------- > > > > Well, sure it crashes. You set ptr^.x to nil (by filling it with > > 0's), and then dereference it (ptr^.x^). Dereferencing nil pointers > > is one the most obvious bugs one can make with pointers, and it > > crashes on any Pascal compiler (except BP under Dos which will > > instead overwrite the system IRQ tables ;-). > > > > Please don't take the following personal, but I'd really suggest > > people not to use such low-level features (like GetMem, FillChar, > > etc.) unless they really understand what they do. Pascal is a > > high-level language and has plenty of "clean" features to use > > instead -- e.g., a simple `New (ptr)' instead of the GetMem line, > > and instead of the FillChar, either `ptr^.x := nil' or > > `New (ptr^.x)' -- depending on what you really mean (the latter will > > work correctly in the program above, the former will at least make > > it quite clear why it crashes). > > > > Rant over. ;-) > > > > Frank > > > > -- > > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > > GPC To-Do list, latest features, fixed bugs: > > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html > > -- > S.Anuradha > Generic Data Tools, > Alcatel Chennai. > Alcanet : 2-757-7123 > >

4 3

Cygwin build...
by Preben Mikael Bohn 31 Oct '01

31 Oct '01

Hi all I have just tried to build gpc on a cygwin installation on my Windows machine. Usually I fire of the following commands on a Linux-box and it works like a charm. cd /home/prb/program/gpc tar xzf gpc-20010924.tar.gz tar xzf gcc-core-2.95.2.tar.gz cd gpc-20010924 mv p ../gcc-2.95.2/gcc/ cd .. mkdir gpc-build cd gpc-build /home/prb/program/gpc/gcc-2.95.2/configure --enable-languages=pascal --prefix=/home/prb/program/gpc/ make cd gcc make pascal.install However on my cygwin installation, the make command fails with an error: test x"no" != xyes || \ gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I/home/prb/program/gpc/gcc-2.95.2/libiberty /../include /home/prb/program/gpc/gcc-2.95.2/libiberty/strerror.c -o pic/strer ror.o gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I/home/prb/program/gpc/gcc-2.95.2/libiberty/. ./include /home/prb/program/gpc/gcc-2.95.2/libiberty/strerror.c /home/prb/program/gpc/gcc-2.95.2/libiberty/strerror.c:461: conflicting types for `sys_errlist' /usr/include/sys/errno.h:23: previous declaration of `sys_errlist' make[1]: *** [strerror.o] Error 1 make[1]: Leaving directory `/home/prb/program/gpc/gpc-build/libiberty' make: *** [all-libiberty] Error 2 Can anyone tell me what I'm doing wrong? Best regards Preben Bohn ===== The two rules for success are: 1. Never tell them everything you know. ____________________________________________________________ Nokia Game is on again. Go to http://uk.yahoo.com/nokiagame/ and join the new all media adventure before November 3rd.

2 3

Re: Typecasting
by Anuradha 30 Oct '01

30 Oct '01

Hello, Sorry for the wrong sample program and a silly doubt.The problem is we have large codes already written and we work in the support department that converts these sources to executables runnable on unix and i cannot change much of the code. This time i have analysed more and am attaching a code that works fine in BP and doesnot work in GPC.It is something to do with the pointers. Can you kindly tell me what the problem is? ---------------------------------- program typcast1; {type word=word(16);} type Mytype=record c:char; end; var p:pointer; begin getmem(p,sizeof(mytype)+2); word(p):=sizeof(mytype); p:=pchar(p)+2; mytype(p^).c:='h'; writeln(mytype(p^).c); end. ---------------------------------- thanks and regards, Anu Frank Heckenbach wrote: > Anuradha wrote: > > > It is not a typecasting error.It's probably fillchar question.I find the > > following sample program ending in a "segmentation fault -core dump" , i > > think because of doing a fillchar of a record which has a member that's > > a pointer . > > > > -------------------------------------- > > program a; > > type > > myrec=record > > x:^integer; > > end; > > var > > ptr :^myrec; > > > > begin > > getmem(ptr,sizeof(myrec)); > > fillchar(ptr^,sizeof(myrec),0); > > ptr^.x^:=5; > > write(ptr^.x^); > > end. > > -------------------------------- > > Well, sure it crashes. You set ptr^.x to nil (by filling it with > 0's), and then dereference it (ptr^.x^). Dereferencing nil pointers > is one the most obvious bugs one can make with pointers, and it > crashes on any Pascal compiler (except BP under Dos which will > instead overwrite the system IRQ tables ;-). > > Please don't take the following personal, but I'd really suggest > people not to use such low-level features (like GetMem, FillChar, > etc.) unless they really understand what they do. Pascal is a > high-level language and has plenty of "clean" features to use > instead -- e.g., a simple `New (ptr)' instead of the GetMem line, > and instead of the FillChar, either `ptr^.x := nil' or > `New (ptr^.x)' -- depending on what you really mean (the latter will > work correctly in the program above, the former will at least make > it quite clear why it crashes). > > Rant over. ;-) > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html -- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123

2 1

Problems on Solaris 8 (secure)
by Serafim Dahl 30 Oct '01

30 Oct '01

The program below is implemented with the sole intention to show how to use procedures as parameters to procedures. However, it works when compiled with SUN Workshop Pascal but not when compiled with GNU Pascal. When trying to start it when compiled with GNU Pascal (version 20010623 on a Solaris 8, Ultra 5) I get the following error message: Oct 26 17:05:11 serafim.nada.kth.se genunix: NOTICE: test[4264] attempt to execute code on stack by uid 1167 Segmentation Fault Here is the program: -------- PROGRAM test(input,output); CONST low = 1; high = 10; TYPE index = low..high; natural = 0..Maxint; item = natural; intTable = ARRAY [index] OF item; VAR table : intTable; PROCEDURE doToEach(VAR t: intTable; PROCEDURE toDo(VAR i: item)); PROCEDURE iter(n: index); BEGIN toDo(t[n]); IF n < high THEN iter(Succ(n)) END; BEGIN iter(low) END; FUNCTION sum(VAR t: intTable): item; VAR tmpSum: item; PROCEDURE addItem(VAR i: item); BEGIN tmpSum := tmpSum + i END; BEGIN tmpSum := 0; doToEach(t, addItem); sum := tmpSum END; PROCEDURE readTable(VAR t: intTable); PROCEDURE readItem(VAR i: item); BEGIN Read(i) END; BEGIN doToEach(t, readItem) END; BEGIN Write('Enter ten numbers '); readTable(table); Writeln('The sum is ', sum(table):1); END. ------------- Now to my questions: 1. Is it the case that code actually executes on the stack? 2. If you say yes to 1., is it possible to compile GPC in a way that avoids this? The systems group at my job is not likely to back on security issues. The 'noexec_user_stack' flag is set on all computers in the network. I hope that it is possible as I am using GPC in a course and I don't like to go back to SUN Pascal, which I consider as inferior to GPC. Regards, Serafim Dahl Dept. of Comp.Sci. at The Royal Institute of Technology in Stcokholm.

2 1

Re: Errors and Standards (was: compiler bug)
by da Silva, Joe 26 Oct '01

26 Oct '01

Well, it's nice to see we are now in agreement in most areas. BTW, in case there is any remaining doubt, let me make it clear that I have never myself regarded a program without a parameter list as "pointless". I'm glad you liked those ISO-10206 citations, too. Even if you want to limit yourself to ISO-7185, the EP standard is still a useful guide to the interpretation of ISO-7185, since it builds directly upon this, but takes a broader view of the application of Pascal in the real world. You are correct that ISO-7185 only defines ONE mechanism by which program variables can be bound to external entities - via the program parameter list! Any other mechanism, which may be employed by a particular implementation, is a non-standard extension (well, by definition, all extensions are non-standard;-)! Joe. > -----Original Message----- > From: J. David Bryan [SMTP:dbryan@bcpl.net] > Sent: Thursday, October 25, 2001 2:01 AM > To: GNU Pascal List > Subject: Re: Errors and Standards (was: compiler bug) > > On 23 Oct 2001, at 11:44, da Silva, Joe wrote: > > > Sorry if I wasn't clear ... when I said "my understanding is ...", what > > this meant (and BTW, I thought this would be clear from the subject > being > > discussed) was "my understanding of the standard(s) is ...". > > I understood what your understanding was. ;-) My assertion is that > understandings of the standard don't count, only statements from the > standard do. > > > > So, if you have specific areas where you believe that I have > contradicted > > the standard(s), please indicate the particulars, so we can both > > double-check it. > > I can't, because I believe that you have asserted a restriction that is > not > in the standard (but see my comment about "the standard" below). I can't > cite a passage from the standard that specifically allows linking of non- > program-parameter, main-block variables to external entities, because the > standard says nothing about such linking (allowed or disallowed). Can you > > cite a passage that disallows such use? > > > > BTW, you should note that we are in agreement that a program without a > > parameter list is perfectly legal. > > Duly noted! ;-) > > > > As to whether such a program is "pointless", please note that any such > > inference (which arose when I semi-quoted Peter Grogono), was nothing > > more than a bit of humour. > > The issue for me is not whether certain programs are or are not pointless. > > My contention is broader, specifically, that any such assertion must be > supported by the standard and not simply by "common sense." The Pascal > standards are written in horribly arcane language to ensure that they are > not open to such interpretations, i.e., that everything stated is > unambiguous. We shouldn't have to argue about whether a given program is > or is not legal (or pointless), because the standard should either > prohibit > it or not. > > Given the choice, I would much rather decide things on the basis of > opinions and common sense, as reading the standards always gives me a > severe headache. But I believe that we cannot do that, if GPC is to claim > > adherence to those standards. If there is disagreement over positions > that > GPC should take, then the choice of position must be the one that is > supported by citations from the standards. > > > > Now, specific to your situation, a very quick check of the ISO-10206 > > standard revealed the following... > > Ah, but the assertion regarding "pointlessness" (i.e., that a program > without program parameters could have no side effects) was made in the > context of ISO 7185. Frank allowed that ISO 10206 programs could have > side > effects without program parameters (and is supported by the passages you > cite). > > I concur completely with your citations in the context of ISO 10206. > > However, ISO 7185 mentions binding to external entities only with > reference > to program parameters (section 6.10). I contend that 6.10 applies only to > > main block variables that are also program parameters and therefore is not > > applicable to (and therefore does not restrict) other main block variables > > being bound by some other mechanism external to the language. > > -- Dave

3 4

Failed tests for GPC
by arvid.herzenberg 26 Oct '01

26 Oct '01

The GPC Test Suite in section 11.7 of the GNU Pascal Manual gives me 29 failed tests. This is 1.6% of the total of about 1800 tests; except for the 29 failures, the other tests all give 'OK'. I would like your opinion whether I should simply ignore the 29 failures. Or do you want me to e-mail the titles of the 29 failed test to you? My operating system is SUSE Linux 7.1 (Professional). The computer is a 450 Mc/s Windows machine. There are two hard discs: One is completely devoted to Linux, and the other handles all of Windows. There does not seem to be any interference between the two discs. In trying out GPC, I have so far completely failed to get an answer to the GPC demo-program 'pi.pas'. All pi.pas gives me is an error message to say that linking was not possible. I presume that the answer should have been 3.14159... I desperately need a decent Pascal compiler. and I still have not given up hope that GPC yet be successful. My name is Arvid Herzenberg. My e-mail address is arvid.herzenberg(a)yale.edu I am looking forward to a reply from you.

3 2

Test
by Frank Heckenbach 25 Oct '01

25 Oct '01

My apologies, I know one shouldn't send test messages to mailing lists, but I've been having severe problems with the list software and I just have to check that everything's working again as far as I'm concerned. Frank

1 0

Re: Errors and Standards (was: compiler bug)
by da Silva, Joe 24 Oct '01

24 Oct '01

Sorry if I wasn't clear ... when I said "my understanding is ...", what this meant (and BTW, I thought this would be clear from the subject being discussed) was "my understanding of the standard(s) is ...". So, if you have specific areas where you believe that I have contradicted the standard(s), please indicate the particulars, so we can both double-check it. BTW, you should note that we are in agreement that a program without a parameter list is perfectly legal. As to whether such a program is "pointless", please note that any such inference (which arose when I semi-quoted Peter Grogono), was nothing more than a bit of humour. Now, specific to your situation, a very quick check of the ISO-10206 standard revealed the following : Technical development section : d) Binding of variables. -A variable may optionally be declared to be bindable. Bindable variables may be bound to external entities (file storage, real-time clock, command lines, etc.). Only bindable variables may be so bound ... 6.2.3.5 section : .... Each variable contained by an activation of a block or module, unless it is a program-parameter or module-parameter, shall be created not bound to an external entity .... 6.7.5.6 section : Binding procedures ... {stuff about "bind" ...} I'm sure there's plenty of other stuff in the standard relevant to this, of course. Like I said, this was just a quick check ... Joe. > -----Original Message----- > From: J. David Bryan [SMTP:dbryan@bcpl.net] > Sent: Tuesday, October 23, 2001 1:26 AM > To: GNU Pascal List > Subject: Re: Errors and Standards (was: compiler bug) > > On 22 Oct 2001, at 15:43, da Silva, Joe wrote: > > > On the topic of "binding" variables, my understanding is... > > It is not my intent to argue simply for the sake of arguing. Honestly! > But if we're going to decide Pascal issues on the basis of understandings > and beliefs, then why have standards? > > I have found over time that many of my understandings as to how things > work > turn out to be wrong when I examine the systems in detail. Here, > fortunately, we do not have to decide how Pascal works by trial and error. > > We have a standard that says explicitly how things are supposed to work. > > I plead that we cannot make GPC standards-compliant if we base its > operation on our belief and assumptions. Instead, we must structure GPC's > > operation strictly according to the semantics outlined in the relevant > standards -- at least, we do if we want to claim compliance. > > > > ...this variable could not have any other binding - it is simply a > normal > > variable and must behave as such! > > Can you support the "must" with a citation from the standard? > > I work with embedded systems, i.e., microprocessor-based controller cards. > > I develop these "bare board" controllers using Pascal, specifically, on an > > HP development system. On that system, the Pascal compiler separates the > program code and static data (i.e., main block-level data). It does this > so that the code may be burned into ROM. > > The particular processor that I target, the Motorola M68K family, has no > I/O instructions. All I/O is memory-mapped, i.e., I/O is performed by > normal reads and writes to address locations that are mapped to specific > hardware registers instead of RAM. Because there is no controlling > operating system on these boards, there is no implementation of program > parameters (because there is nothing "outside" of the program). > > So in this application, I/O devices are represented in the Pascal programs > > as main block-level variables. A serial port configuration register might > > be mapped to an "integer" variable, for example. The actual mapping of > variables to devices is done by the linker, which allows the specification > > of the addresses at which the variables are to be assigned. > > So the programs that control these boards have no program parameters and > no > "read" or "write" calls; they control the machines in which they are > embedded through the mechanism of variable mapping. These programs cannot > > be classified as "pointless." > > But are they legal Pascal? That is, do they conform to the syntax and > semantics of the standard? > > They conform to the syntax, surely (e.g., GPC compiles them without > complaint). As far as I can determine, they conform to the semantics as > well, i.e., they obey all of the rules in the standard. The standard > requires certain semantics for, e.g., integer variables (scope rules > followed, arithmetic behaves as expected, etc.), and all of those rules > are > followed by the hardware as well. I do not see anything in the standard > that precludes the implementation of variables in hardware devices, rather > > than in RAM, as long as the semantics listed in the standard are obeyed. > > As I've noted, I would be pleased if someone could cite a section of the > standard that says that a Pascal program constructed as above is illegal. > > My "understanding" is that my program is legal, but with such a citation, > I > would withdraw that assertion. But I regret that simply saying that such > a > program seems to be illegal, or isn't normal, or ought to be prohibited, > just isn't good enough if the goal here is to make GPC conform strictly > with the ISO standards. > > And that's the only point I'm trying to make: whether you or Frank or I > believe that a given program is "pointless" isn't the issue. The only > issue is whether the standard prohibits it, and the standard itself is the > > only authority on that matter. Any discussion of what GPC must or must > not > do has to be supported by the standard. > > -- Dave

2 1

Typecasting
by ANURADHA Srinivasan 24 Oct '01

24 Oct '01

Hello , Is typecasting like MyType(Myvar); not allowed? How do i do something like the following? ------------------------------------- p:pointer; mytype=record ..... end; with mytype(p^) do begin ..... end; ----------------------------------------- Here i cannot use another temporary variable also. Thanks & Regards, Anuradha

3 3

Re: Errors and Standards (was: compiler bug)
by da Silva, Joe 24 Oct '01

24 Oct '01

As far as I know, this was simply an oversight, since it was Wirth himself that requested this to be changed, when the standard was being formulated. Also AFAIK, this particular problem was first highlighted by Lecarme and Desjardins, in their paper "More comments on the programming language Pascal", "Acta Informatica", 4, 231-243, 1975 (quoted by J. Welsh, W.J. Sneering, and C.A.R. Hoare, in their 1977 paper "Ambiguities and insecurities in Pascal", "Software Practice and Experience", reprinted in "Pascal - The Language and its Implementation", Barron, 1981). Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Tuesday, October 23, 2001 1:42 PM > To: gpc(a)gnu.de > Subject: Re: Errors and Standards (was: compiler bug) > > da Silva, Joe wrote: > > > Oops! I'm sorry, the example I gave wasn't quite right! :-( > > > > Below is a corrected example, which I hope is both correct (per > > J&W) and illustrates why this insecurity was changed when > > Pascal was standardized : > > > > program test; > > .... > > procedure fred (function smith : integer); > > var > > dummy : integer; > > begin {fred} > > dummy := smith('A') > > end; {fred} > > .... > > function one (x : boolean) : integer; > > .... > > function two (x, y : integer) : integer; > > .... > > begin {test} > > .... > > fred(one); > > .... > > fred(two); > > .... > > end. {test} > > > > As you can see, when the procedure "fred" is compiled, the > > compiler does not know how many parameters "smith" has, > > nor what type they are. This makes it difficult for the compiler > > to validate the program, and just imagine what will happen to > > the stack - yuck! <g> > > Oh dear, then it's really as bad as I'd feared. So I think we won't > introduce `--wirth-pascal' in GPC anytime soon. ;-) > > Does anyone know why this was so? Wirth must certainly have noticed > the problem. Was he just afraid of the nested parentheses in a > SP-like declaration with parameters? > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Errors and Standards (was: compiler bug)
by da Silva, Joe 23 Oct '01

23 Oct '01

Oops! I'm sorry, the example I gave wasn't quite right! :-( Below is a corrected example, which I hope is both correct (per J&W) and illustrates why this insecurity was changed when Pascal was standardized : program test; .... procedure fred (function smith : integer); var dummy : integer; begin {fred} dummy := smith('A') end; {fred} .... function one (x : boolean) : integer; .... function two (x, y : integer) : integer; .... begin {test} .... fred(one); .... fred(two); .... end. {test} As you can see, when the procedure "fred" is compiled, the compiler does not know how many parameters "smith" has, nor what type they are. This makes it difficult for the compiler to validate the program, and just imagine what will happen to the stack - yuck! <g> Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, October 22, 2001 11:03 PM > To: gpc(a)gnu.de > Subject: Re: Errors and Standards (was: compiler bug) > > da Silva, Joe wrote: > > > Well, from memory, a procedure or function parameter in > > J&W looked something like the following example : > > > > program test; > > .... > > procedure fred (function smith : integer); > > .... > > function one (x : boolean) : integer; > > .... > > function two (x, y : integer) : integer; > > .... > > begin {test} > > .... > > fred(one(true)); > > .... > > fred(two(1,2)); > > .... > > end. {test} > > > > Notice how the formal parameter in procedure "fred" is a function > > ("smith") of known type (integer) but unknown parameters? Dr. Wirth > > later decided this was unsafe, so when the ISO-7185 standard was > > formalised, this was changed (now the formal parameter, function > > "smith", must show it's formal parameters too). This also applies to > > ISO-10206, of course. > > Do you mean the parameters given to the inner function (one, two) > are already specified when calling the outer one (fred)? In this > case, it's not much different than making smith type Integer, and > passing the function result to fred. (Sure, there could be a > difference in when and whether at all one/two are called, but unless > they have side-effects, the result will be the same.) > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

back to strings and fillchar
by Oldham, Adam 22 Oct '01

22 Oct '01

I have been going through some test cases to test some instances of things.... This has led me to another question. It appears that it you define a record with a string in it and then declare it or new it. Both store the capacity of the string in the schema. And Both 0 out the entire string. If the string is going to be zeroed out by default, why not just 0 out the entire data structure? Or all data structures 0'd by default? Adam ----------------------------------------------------------------------- C. Adam Oldham Marconi Commerce Systems Inc. Software Engineer 7300 West Friendly Ave. adam.oldham(a)marconi.com Greensboro, NC 27420-2087 Phone : 336.547.5952 Fax : 336.547.5079 ----------------------------------------------------------------------- This document contains confidential information of Marconi Commerce Systems Inc. In consideration of the receipt of this document, the recipient agrees not to reproduce, copy, use or transmit this document and/or the information contained herein, in whole or in part, or to suffer such actions by others, for any purpose except with written permission, first obtained, of Marconi Commerce Systems Inc., and further agrees to surrender the same to Marconi Commerce Systems Inc. upon demand. -----------------------------------------------------------------------

2 1

problem_with_reset_rewrite_commands
by michael pfeiffer 22 Oct '01

22 Oct '01

I am beginner in pascal programming. I apply the gpc-compiler on a computer at home, running under linux (suse 6.0 distribution). Some self made programs run well, but my problem is application of reset, rewrite commands. Please give me a hint, how to solve it. The situation: With the var g:text;s:string[5] in the main program the sequence s:='alpha'; rewrite(g,s); writeln(g,'test'); . results in a runtime-code a.out (o.k.) When I let run it applying ./a.out the program standing before the above given sequence runs well, but then it stops with ?Gpc runtime error:(gpc-rts)'Internal file namei wrong (#700)'. As a result a file named 'alpha' with zero content is created. Applying the reset(g,s);readln(g,s1); I obtain ?GPC runtime error:File is not open for reading(#14). What is my mistake? I would be highly thankful for a hint to solve the problem. Yours sincerely Michael Pfeiffer

3 2

Re: Errors and Standards (was: compiler bug)
by da Silva, Joe 22 Oct '01

22 Oct '01

Oops! Forgot to fiddle the send address, yet again! :-( Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Saturday, October 20, 2001 7:57 AM > To: gpc(a)gnu.de > Subject: Re: Errors and Standards (was: compiler bug) > > J. David Bryan wrote: > > > On 19 Oct 2001, at 1:33, Frank Heckenbach wrote: > > > > > So, the following program would be allowed to output 0, according to > the > > > standard (because i might be mapped to an I/O address that happens to > > > always yield 0)? I strongly doubt it? > > > > Well, you've caught me without my copy of the standard at hand :-), but > as > > I recall, there is a requirement that operations on integers must follow > > > the rules of integer math. I can't check whether assignment is one of > > those operations listed, but it seems reasonable. So, no, the program > you > > cited wouldn't be a conforming program (pending confirmation from the > > standard). > > I hope so. > > > But how could the compiler possibly enforce this? Binding to RAM vs. a > > mapped I/O port (or to ROM) would be done at link time, so must the > > compiler issue a warning for the "var" statement that variables must be > > bound to RAM? How else can we disallow such a program? > > I think a "processor" according to the standard includes the > compiler as well as the linker. Whether in practice a compiler alone > [Joe da Silva] Yes, in the case of GPC, the "processor" must mean the compiler _and_ linker (it doesn't make sense to talk about just half a "processor" ;-). On the topic of "binding" variables, my understanding is that any variables declared in the "var" block of a program are local to the program and exist only during the execution of the program, unless they are included in the program's parameter list - just like file variables! Suppose there is an implementation-dependent system variable called "user", that contains a string (with the user's name). Now, if the "processor" has a predefined binding for this variable, a program could reference it, _without_ defining it in the "var" block. However, if "user" were defined in the program's "var" block, then this would be a _local_ variable called "user", not the predefined system variable (assuming of course it isn't also included in the program's parameter list)! So, in your previous example, where you defined a variable called "i" and assigned it the value 42, this variable could not have any other binding - it is simply a normal variable and must behave as such! > (such as GPC) that might be used in conjunction with various linkers > could be 100% conforming, is another question (and the answer is > probably no, without making some requirements on the linker and > forbidding the user of linker scripts etc.). > > > > Yes, but some things (like that the program above should write 42, > > > possibly preceded by a number of spaces) are guaranteed, I think. > > > > Unfortunately, what you and I think has no bearing on the matter. Only > > what the standard "thinks" is important! ;-) Cite a passage from the > > standard that states that main program block-level variables may not be > > bound to external entities, and I will concede your point happily. > > I'm just packing my bags and will be gone for the weekend, but I'll > look when I'm back ... > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Errors and Standards (was: compiler bug)
by da Silva, Joe 22 Oct '01

22 Oct '01

On the subject of missing "output" as a program parameter, or in the more general case, where the program header has no parameters at all (assuming of course "input" and "output" are neither explicitly nor implicitly used), Peter Grogono (in his book 'Programming in Pascal') says words to the effect of : It is legal to omit the parameters from the program header, provided neither "input" or "output" is used, however, a program which provides no input or output is generally not very useful. The above has an element of humour in it, but makes it quite clear that it is perfectly legal to omit "input" and/or "output" from the program header if these are not used. Note that the above is not an exact quote, just from memory, however, I could spend a bit of time to locate the exact text, if required. On the subject of standards, please see below ... Joe. > -----Original Message----- > From: J. David Bryan [SMTP:dbryan@bcpl.net] > Sent: Wednesday, October 17, 2001 6:04 AM > To: GNU Pascal List > Subject: Re: compiler bug > > On 16 Oct 2001, at 20:34, Frank Heckenbach wrote: > > > I don't see a big difference between `--standard-pascal' and > > `--iso-pascal'.... > > I don't either, except it removes the possibly misleading word "standard" > (implying that "standard-pascal" is standardized or preferred, whereas > "extended-pascal" is not -- I hope I now take Joe's point correctly :-). > [Joe da Silva] Yes, you do! :-) I find that awareness of the Extended Pascal Standard is unsatisfactory, and in promoting Pascal, we need to improve this. IMHO, we should avoid any inference that ISO-7185 is the only standard, likewise any inference that Extended Pascal is non-standard. > > (EP is also ISO). > > Hence the suggestion of "--iso-extended-pascal". The title pages of the > respective standards say, "Pascal" and "Extended Pascal," so my suggestion > > incorporated those titles in the switch names. > > > > So if anything, I'd tend to `--classic-pascal' or so. > > "Classic Pascal" is meaningless to me (it's actually more suggestive of > some variant with proprietary extensions, as the ISO standard was never > "classic" in the sense that it was the version that everyone used; GPC is > the first Pascal compiler I've used -- and I've used many -- that provides > > a strict ISO 7185 option). > [Joe da Silva] "Classic" is a perfect description of ISO-7185 (thanks, Prospero), since it corresponds exactly (well, with just one change, suggested by Wirth) to the language originally defined in the 'User Manual and Report' published by Jensen and Wirth, in 1974. An alternative description would be "minimalist", but "classic" sounds much nicer! <g> > I'm happy with "--standard-pascal" and "--extended-pascal" if everyone > else > is. > > > > And every user who uses the option would have to change it ... > > Which may be the best argument for leaving it alone. > > -- Dave

4 15

Re: Errors and Standards (was: compiler bug)
by Frank Heckenbach 22 Oct '01

22 Oct '01

(I assume you hit the wrong reply button, and the mail was meant for the list. ;-) > > J. David Bryan wrote: > > > > > But how could the compiler possibly enforce this? Binding to RAM vs. a > > > mapped I/O port (or to ROM) would be done at link time, so must the > > > compiler issue a warning for the "var" statement that variables must be > > > bound to RAM? How else can we disallow such a program? > > > > I think a "processor" according to the standard includes the > > compiler as well as the linker. Whether in practice a compiler alone > > > [Joe da Silva] > > Yes, in the case of GPC, the "processor" must mean the > compiler _and_ linker (it doesn't make sense to talk about > just half a "processor" ;-). So everything the linker does must be according to the standard as well. (Of course, we can't really enforce this in GPC, except telling people, don't use any weird linker scripts if you want to be conformant. ;-) > On the topic of "binding" variables, my understanding is > that any variables declared in the "var" block of a program > are local to the program and exist only during the execution > of the program, unless they are included in the program's > parameter list - just like file variables! > > Suppose there is an implementation-dependent system > variable called "user", that contains a string (with the > user's name). Now, if the "processor" has a predefined > binding for this variable, a program could reference it, > _without_ defining it in the "var" block. However, if "user" > were defined in the program's "var" block, then this would > be a _local_ variable called "user", not the predefined > system variable (assuming of course it isn't also included > in the program's parameter list)! > > So, in your previous example, where you defined a variable > called "i" and assigned it the value 42, this variable could > not have any other binding - it is simply a normal variable > and must behave as such! Then we agree. If I understand you correctly, the following might be valid if `user' is predefined: program Foo (Output); begin WriteLn (user) end. That's no valid SP program because `user' is undefined, but such implementations that define it as an extension would accept it. So, there could be programs with no parameters that "do something" (if the predefined variables are also used for output purposes), but such programs would not be strictly conformant. So, it seems again that a conformant program with no parameters is "pointless". Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: Errors and Standards (was: compiler bug)
by da Silva, Joe 22 Oct '01

22 Oct '01

Well, from memory, a procedure or function parameter in J&W looked something like the following example : program test; .... procedure fred (function smith : integer); .... function one (x : boolean) : integer; .... function two (x, y : integer) : integer; .... begin {test} .... fred(one(true)); .... fred(two(1,2)); .... end. {test} Notice how the formal parameter in procedure "fred" is a function ("smith") of known type (integer) but unknown parameters? Dr. Wirth later decided this was unsafe, so when the ISO-7185 standard was formalised, this was changed (now the formal parameter, function "smith", must show it's formal parameters too). This also applies to ISO-10206, of course. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, October 18, 2001 11:47 PM > To: gpc(a)gnu.de > Subject: Re: Errors and Standards (was: compiler bug) > > da Silva, Joe wrote: > > > Correct. Conformant arrays are optional, so that isn't the > > *real* change to the language ... It is this : > > > > When you have a procedure or function (A), as a formal > > parameter of another procedure or function (B), you must > > declare it's (A) formal parameters (as shown in example > > 6 in section 6.11.6 of ISO-10206; there's probably a similar > > example given in ISO-7185, although haven't looked for it). > > > > This (declaring the formal parameter of a formal parameter ;-) > > wasn't required in the original language definition, in the > > "User Manual and Report". > > What do you mean exactly? Did they allow parameter names to be > omitted (syntax?), or no parameter list at all? The latter would > seem strange to me since it would be type-unsafe. > > Could you give an example of something that's valid in J&W, but not > ISO 7185? > > > "Otherwise" was a common and useful extension to > > the language, but *non-standard*, prior to ISO-10206 (of > > course, Borland recycled the word "else", just to be > > different!). > > ... and to introduce yet another ambiguity into their dialect ... > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Is this a bug that is planning to be fixed (from documentatio
by Oldham, Adam 22 Oct '01

22 Oct '01

Well, Unfortunately, this is bad for us here. SVS and some of the old Oasis Pascal and other Pascal compiler developed back in the mid and early 1980s allowed this split interface/implementation method declaration in different Units. This allows one Unit to act as a sort of header file (like in C) and the other Unit to actually define the function. In this way, you can have a global type repository of Units that only contain Interface declarations. When dealing with an App like ours where you are dealing with 500000 to 900000 lines of code in 200-400 files in 10+ project trees, changing something as simple as this could end up being a hufe proposition. That would be on top of the changes to FILLCHARing records, Strings that aren't of the "BP String" type, and other differences we find. As for Mangled Names? Are you going to move more towards name Mangling much like FPC uses? If so, couldn't create a flag that would just keep all functions from using the Mangled Name? FPC does things much in this way, and I worked on modifying the compiler to allow this method in split interface/implementation type of thing. I ran into other problems getting it to work correctly (I'll spare the list the details) but for the most part, it worked. Adam -----Original Message----- From: Frank Heckenbach [mailto:frank@g-n-u.de] Sent: Thursday, October 18, 2001 7:09 PM To: gpc(a)gnu.de Subject: Re: Is this a bug that is planning to be fixed (from documentatio n)? Oldham, Adam wrote: > So, once this bug is fixed, will function declarations in the interface and > function bodies in implementation sections of different files be allowed, > like they are today? Different files for the same module, yes (unfortunately, since EP more or less requires this, though it doesn't directly talk about source files). Different units/modules, no. > And if not, can the bug sort of be left for > compatibility with other Pascal Languages that do utilize this method? Say > with maybe a command line parameter? Which compiler uses this method? I only know compilers that require such routines to be declared as `external' or similar, and GPC will (continue to) allow this as well. Disabling this check would be easy at first, but once we introduce qualified identifiers, the method won't work, since the implementation would choose another "mangled linker name" (if you don't know what that means, please ignore it) than the interface declaration, and without an explicit specification (such as `external' and/or `asmname'), it won't work. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: installation problems
by Oldham, Adam 22 Oct '01

22 Oct '01

As I stated in my last email, I used the exact same linking command lines, on with -lm, one without. So that is: gcc -static `cat lnk.tmp` -lgpc -lgcc -lpthread -lpanel -lncurses -Xlinker -Map rds.map -and- gcc -static `cat lnk.tmp` -lm -lgpc -lgcc -lpthread -lpanel -lncurses -Xlinker -Map rds.map I also used -v in both command lines without in further useful information being output. Upon further research, libm comes with glibc, or at least the glibc package. I'm going to dive deeper into this and will post my results. Adam -----Original Message----- From: Frank Heckenbach [mailto:frank@g-n-u.de] Sent: Friday, October 19, 2001 10:53 AM To: gpc(a)gnu.de Subject: Re: installation problems Oldham, Adam wrote: > I have added the -lm for the math library to the link statement, no changes > result in my desired output. I tried that yesterday. Then please post the exact command line that you used, including -lm. > Is the Math Library part of the gcclib package that is compiler dependant? As I said, no. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

--object-destination-path
by Preben Mikael Bohn 21 Oct '01

21 Oct '01

Hi all, I'm trying to use --object-destination-path=obj to place all *.o files in the directory 'obj'. However it won't work... What do I do wrong? The complete line is: gpc --object-destination-path=./obj/ --automake main.pas I'm using version 20010924 and I have placed main.pas and test.pas in the current dir, and their content is (but this probably doesn't matter): program main; uses test; begin writeln('main'); testfunc; end. unit test; interface procedure testfunc; implementation procedure testfunc; begin writeln('test'); end; { testfunc } end. Best regards Preben Bohn ===== The two rules for success are: 1. Never tell them everything you know. ____________________________________________________________ Nokia Game is on again. Go to http://uk.yahoo.com/nokiagame/ and join the new all media adventure before November 3rd.

4 5

Re: installation problems
by Oldham, Adam 19 Oct '01

19 Oct '01

SOrry Frank, I have added the -lm for the math library to the link statement, no changes result in my desired output. I tried that yesterday. Is the Math Library part of the gcclib package that is compiler dependant? Adam -----Original Message----- From: Frank Heckenbach [mailto:frank@g-n-u.de] Sent: Friday, October 19, 2001 8:23 AM To: gpc(a)gnu.de Subject: Re: installation problems Oldham, Adam wrote: > Sorry Frank, here is the complete report: > I link a rather large application (500+ Pascal files with 20 C files) into > one executable. I precompile everything as objects and then perform the > following commands to link: > find /src -name '*.o' -exec echo -n {} " " \; > lnk.tmp > echo -n /src/os/os.a " " >> lnk.tmp\ > touch rds.map > gcc -static `cat lnk.tmp` -lgpc -lgcc -lpthread -lpanel -lncurses -Xlinker > -Map rds.map So, there's no -lm. Just add it. (gpc does this automatically, together with -lgpc, but it you link with gcc, you have to provide both explicitly.) You might have to find the correct library order (porbably -lgpc -lm I think). > Someone needs to write these companies like Mandrake, Redhat, Suse and get > them to stop using these bad compilers. People have been complaining about > this 'v2.96' compiler for 2 years now and they are still distributing them. > It's a real pain and trying procedure to get that compiler off and still > have their stock programs run correctly (because of library dependencies). And I've heard SuSE has a broken GPC installation in their recent distribution again (they had one some years ago, and it took some letters from Peter to make them fix it). Any volunteers? :-/ Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: installation problems
by Oldham, Adam 19 Oct '01

19 Oct '01

Sorry Frank, here is the complete report: I link a rather large application (500+ Pascal files with 20 C files) into one executable. I precompile everything as objects and then perform the following commands to link: find /src -name '*.o' -exec echo -n {} " " \; > lnk.tmp echo -n /src/os/os.a " " >> lnk.tmp\ touch rds.map gcc -static `cat lnk.tmp` -lgpc -lgcc -lpthread -lpanel -lncurses -Xlinker -Map rds.map The os.a is just a library I create from all the precompiled C stuff. I do not think any of this is a big deal, as I have done this successfully in the past, before the system had to be upgraded. My library paths should be fine (/lib /usr/lib/ /usr/local/lib /usr/C11R6/lib /usr/local/fpc/lib). Nothing unusual, and /usr/lib is where all the gcc/gpc libraries live. Using '-v' does not give much more info other than showing all the objects I am linking together. However, I can compile small test programs of 1 file or slightly more successfully using GPC on the command line (--automake). They will run with no problems. Someone needs to write these companies like Mandrake, Redhat, Suse and get them to stop using these bad compilers. People have been complaining about this 'v2.96' compiler for 2 years now and they are still distributing them. It's a real pain and trying procedure to get that compiler off and still have their stock programs run correctly (because of library dependencies). Thanks guys! Adam -----Original Message----- From: Frank Heckenbach [mailto:frank@g-n-u.de] Sent: Thursday, October 18, 2001 7:20 PM To: gpc(a)gnu.de Subject: Re: installation problems Oldham, Adam wrote: > I am using Mandrake Linux with kernel 2.4.8. It had the wonderful version > of gcc 2.96 installed on it stock. I've since downgraded to gcc 2.95.3. > I've downloaded gpc-20010924, and installed it the regular old way I've > installed all the other version of GPC I've gotten the past 2 years. It > installs fine, into /usr just like gcc. > > I can compile files with no problem as well. I compile all my pascal files > to only create object files, no other parameters from the command line. > When linking all these objects together statically, I get a few errors like > this: > /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o): In function > `_p_Real_Sin': > /v/oldham/gcc-2.95.3/gcc/p/rts/rts.c:642: undefined reference to `sin' > > I get the same thing for the functions cos, log, pow, sinl, cosl, logl, > expl, powl, sinh, cosh. I've researched this some, and linking the -lm > (math library) while performing my link does not help this. Can anyone help > at all with this in particular? How you do link? Do you call gpc, gcc, or ld directly? What command line? Does it work if you just compile and link with GPC (--automake)? Does the linker command line you see with `-v' help you? ... I think I mentioned once or twice in the past few days that I'd prefer complete reports ... :-( > Should GPC have linked -lm while it was building? No, it's not the gpc executable, but your program executable that needs -lm. Marco van de Voort wrote: > > Should GPC have linked -lm while it was building? And if so, can someone > > help me find where that is. I've been looking at this for hours now. > > Sounds like not linked with libgcc, or wrong (out of sync) version. No, libm is quite independent of libgcc. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

strings & fillchar
by Oldham, Adam 18 Oct '01

18 Oct '01

Another question from the documentation: Section 6.12: "GNU Pascal knows Borland Pascal's procedures FillChar and Move. However, their use can be dangerous because it often makes implicit unportable assumptions about type sizes, endianness, internal structures or similar things. Therefore, avoid them whenever possible. E.g., if you want to clear an array of strings, don't `FillChar' the whole array with zeros (this would overwrite the Schema discriminants, see section 8.13.14 BP compatibility: Strings), but rather use a `for' loop to assign the empty string to each string. In fact, this is also more efficient than `FillChar', since it only has to set the length field of each string to zero." What is your recommended fix if you call FillChar on a record, and that record contains the string. Even if you do a for loop to fill the record with 0's, you will still overwrite the schema, correct? Are there any recommended workarounds for that? Thanks, Adam ----------------------------------------------------------------------- C. Adam Oldham Marconi Commerce Systems Inc. Software Engineer 7300 West Friendly Ave. adam.oldham(a)marconi.com Greensboro, NC 27420-2087 Phone : 336.547.5952 Fax : 336.547.5079 ----------------------------------------------------------------------- This document contains confidential information of Marconi Commerce Systems Inc. In consideration of the receipt of this document, the recipient agrees not to reproduce, copy, use or transmit this document and/or the information contained herein, in whole or in part, or to suffer such actions by others, for any purpose except with written permission, first obtained, of Marconi Commerce Systems Inc., and further agrees to surrender the same to Marconi Commerce Systems Inc. upon demand. -----------------------------------------------------------------------

2 1

installation problems
by Oldham, Adam 18 Oct '01

18 Oct '01

I am using Mandrake Linux with kernel 2.4.8. It had the wonderful version of gcc 2.96 installed on it stock. I've since downgraded to gcc 2.95.3. I've downloaded gpc-20010924, and installed it the regular old way I've installed all the other version of GPC I've gotten the past 2 years. It installs fine, into /usr just like gcc. I can compile files with no problem as well. I compile all my pascal files to only create object files, no other parameters from the command line. When linking all these objects together statically, I get a few errors like this: /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o): In function `_p_Real_Sin': /v/oldham/gcc-2.95.3/gcc/p/rts/rts.c:642: undefined reference to `sin' I get the same thing for the functions cos, log, pow, sinl, cosl, logl, expl, powl, sinh, cosh. I've researched this some, and linking the -lm (math library) while performing my link does not help this. Can anyone help at all with this in particular? Should GPC have linked -lm while it was building? And if so, can someone help me find where that is. I've been looking at this for hours now. Thanks, Adam ----------------------------------------------------------------------- C. Adam Oldham Marconi Commerce Systems Inc. Software Engineer 7300 West Friendly Ave. adam.oldham(a)marconi.com Greensboro, NC 27420-2087 Phone : 336.547.5952 Fax : 336.547.5079 ----------------------------------------------------------------------- This document contains confidential information of Marconi Commerce Systems Inc. In consideration of the receipt of this document, the recipient agrees not to reproduce, copy, use or transmit this document and/or the information contained herein, in whole or in part, or to suffer such actions by others, for any purpose except with written permission, first obtained, of Marconi Commerce Systems Inc., and further agrees to surrender the same to Marconi Commerce Systems Inc. upon demand. -----------------------------------------------------------------------

3 2

Re: Is this a bug that is planning to be fixed (from documentatio
by Oldham, Adam 18 Oct '01

18 Oct '01

Frank, So, once this bug is fixed, will function declarations in the interface and function bodies in implementation sections of different files be allowed, like they are today? And if not, can the bug sort of be left for compatibility with other Pascal Languages that do utilize this method? Say with maybe a command line parameter? Adam -----Original Message----- From: Frank Heckenbach [mailto:frank@g-n-u.de] Sent: Thursday, October 18, 2001 3:00 PM To: gpc(a)gnu.de Subject: Re: Is this a bug that is planning to be fixed (from documentation)? Oldham, Adam wrote: > I have a question about something that is stated below > > "Note that GPC does not yet check whether all interface declarations are > resolved in the same unit. Procedures and functions which are in fact not > used may be omitted, and/or procedures and functions may be implemented > somewhere else, even in a different language. However, relying on a GPC bug > (that will eventually be fixed) is not a good idea, so this is not > recommended." > > In the Programmer's Guide -> Source Structures -> Modules and Unites -> > Units > > > The comment about ..."relying on a GPC bug (that will eventually be > fixed) is not a good idea, so this is not recommended.", what is > the GPC bug and which part of its paragraph does it apply to? That GPC does not yet check whether all interface declarations are resolved in the same unit (like they should by definition of both EP modules and BP units). > 1 - "...Procedures and functions which are in fact not used may > be omitted, " I.e., you can declare a routine, never implement it, and as long as it's not actually called, GPC will not complain (but it should). > 2 - "...Procedures and functions may be implemented somewhere else, > even in a different language." You can declare a routine in the normal way and provide the implementation, say, in a C file. GPC should also complain here, unless you declare them as `external' (which, BTW, is the answer to the problem described; I'll add it to that paragraph in the manual). > I a, a bit confused as to what this bug is. I looked in the list of known > bugs and didn't seem to see anything that directly related to this. I don't find it there either, so I'm adding it now ... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Is this a bug that is planning to be fixed (from documentation)?
by Oldham, Adam 18 Oct '01

18 Oct '01

I have a question about something that is stated below "Note that GPC does not yet check whether all interface declarations are resolved in the same unit. Procedures and functions which are in fact not used may be omitted, and/or procedures and functions may be implemented somewhere else, even in a different language. However, relying on a GPC bug (that will eventually be fixed) is not a good idea, so this is not recommended." In the Programmer's Guide -> Source Structures -> Modules and Unites -> Units The comment about ..."relying on a GPC bug (that will eventually be fixed) is not a good idea, so this is not recommended.", what is the GPC bug and which part of its paragraph does it apply to? 1 - "...Procedures and functions which are in fact not used may be omitted, " 2 - "...Procedures and functions may be implemented somewhere else, even in a different language." I a, a bit confused as to what this bug is. I looked in the list of known bugs and didn't seem to see anything that directly related to this. Thanks, Adam ----------------------------------------------------------------------- C. Adam Oldham Marconi Commerce Systems Inc. Software Engineer 7300 West Friendly Ave. adam.oldham(a)marconi.com Greensboro, NC 27420-2087 Phone : 336.547.5952 Fax : 336.547.5079 ----------------------------------------------------------------------- This document contains confidential information of Marconi Commerce Systems Inc. In consideration of the receipt of this document, the recipient agrees not to reproduce, copy, use or transmit this document and/or the information contained herein, in whole or in part, or to suffer such actions by others, for any purpose except with written permission, first obtained, of Marconi Commerce Systems Inc., and further agrees to surrender the same to Marconi Commerce Systems Inc. upon demand. -----------------------------------------------------------------------

2 1

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