Gpc March 1997

gpc@gnu.de

17 participants
53 discussions

Re: Pascal Compiler Bug
by Peter Gerwinski 20 Mar '97

20 Mar '97

According to Gareth Wilson: > The following code, especially the Arrays, causes GPC1.EXE to page fault. I > think this is a bug of the compiler because if I comment them out the > compiler runs (complaining about invalid reference to Colours, Cmds, etc.) Yes, this was an error in GPC. It is corrected in recent Alpha versions of GPC. Look at ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ However there are still known problems with initializers. For example array indices and field names are ignored in initializers; the components of a structured variable are always initialized in order. Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Two bugs
by Tomas Srb 20 Mar '97

20 Mar '97

{ Propably any bug in gpc 2.0 (GNU Pascal) } program Bug1(Input,Output); type Str255=String(255); procedure Gogo(S:String; var SOut:Str255); begin WriteLn(' Before Error '); SOut:='aha'; { ! ?GPC runtime error: runtime error (#-1) ! } WriteLn(' After Error '); end; var S:Str255; begin S:='1234'; Gogo(S,S); end. { Bug #2 ! } program Bug2(Input,Output); type Str255=String(255); var I:Integer; function Gogo(S:String):Str255; begin WriteLn(' Gogo '); Inc(I); Gogo:=S; end; var S:Str255; begin I:=0; S:='1234'; S:=Gogo(S); { ! No one call Gogo bat three calls ! } WriteLn(I); { ! I=3 I!=0 } end. { Please send my if you know any solution srbt(a)fsid.cvut.cz } .

1 0

Re: Variable number of parameters
by Frank Heckenbach 18 Mar '97

18 Mar '97

(Continuation of this thread from c.l.p.b) kblix(a)sn.no (Kim Robert Blix) wrote: > heckenb(a)mi.uni-erlangen.de (Frank Heckenbach) once said: > >> There is NO challange in locating the obstacles - they will become obvious > >> anyway. Try to find a solution instead - Its so much more rewarding. > > > >No, I don't agree. Your approach sounds much like "let's just program a few > >lines, and if it doesn't work, we'll change everything". This ad-hoc strategy > >might work for small projects, but any larger project (of which a Pascal > >compiler is most definitely one), needs some good planning and design before > >starting the actual coding. This includes identifying all the obstacles in > >advance, and finding solutions to them - first a general solution, then a > >concrete way to implement the solution, then verify that the solution really > >covers all situations... It might not be as much fun as just sitting down in > >front of the screen and typing a few lines of code, but it's the only way to > >manage the complexity of such a project. > > Yes, I agree. What I meant was that when this was first presented to the group, > a lot of people started by saying "this cant be done" and "this is not possible" > instead of "this would be hard because of that and that, but could possibly be > solved by this" .. The only constructive replays has come from you. Thanks! But don't forget that the newsgroup is about *Borland* Pascal, and most people are mainly interested in it, and speaking from this perspective. > >But again: be careful with it! C needs it because the language itself lacks > >some features like constants or modularization. However, Pascal - in a > >sufficiently sophisticated version - should not need a preprocessor at all, > >except for things like symbol-dependent compilation. IMHO, it's good style > >to avoid the preprocessor when possible. > > But It can be oooh so practical when needed. :) But there are many traps. Imagine the following: {$define sum a+b} d*sum - this will be d*a+b, i.e. (d*a)+b instead of d*(a+b) as one might expect. or: {$define square(a) a*a} (if sqr wasn't already declared) function f:real; begin {Long and complicated code} end; square(f) - you see what happens? > >> you could just check what the variable was defined as, and then handle it in the > >> appropriate way. this would go for any declared variable. In cases like this: > >> write('this is a number',51) > >> > >> you check if its a string (quoted) or a number (non-quoted). This pretty much > >> includes most cases. > > > >Not quite. Detecting the types is a bit more complex than you might imagine > >now, but it is surely possible - it's one of the important things the compile > >has to keep track of. The difficulty comes in when the compiler has to decide > >between several possible procedures/functions to call (as it can do for > >Write(ln), but is quite more involved for user-defined overloading/varargs). > > Do you have an example where the above approach would fail? You mean the rule: string if quoted, number otherwise? There are many examples: - variables: not quoted, but can be strings, numbers or anything else - function results: the same - expressions (like a+b): the same - constants: the same - ... And dont't forget that there are many other types besides strings and numbers! If you're really interested in how these things works, you'll have to find out a lot about parsing and similar things. > >I think we should carry on this discussion on the mailing list. If you follow > >up, please post there. Anyone else from this group who's interested in this > >subject can subscribe to the list or fetch the postings from its archive, > >with the URLs I posted the other day. > > Argh! :) You could have mentioned that a bit earlier in your post! :) > I'll Jump in and subscribe today. I'd assume you read the whole article before starting to reply... Besides, you could still have posted to the list instead of the newsgroup, I suppose... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Pascal Compiler Bug
by Gareth Wilson 18 Mar '97

18 Mar '97

Please Read This Text File :-( _____________________________________________________________________ Sent by RocketMail. Get your free e-mail at http://www.rocketmail.com The following code, especially the Arrays, causes GPC1.EXE to page fault. I think this is a bug of the compiler because if I comment them out the compiler runs (complaining about invalid reference to Colours, Cmds, etc.) Type TComStr = String(8); TColStr = String(12); Const NumCmds : Byte = 12; Var Colours : Array[0..15] Of TColStr Value (0 :'BLACK'; 1 :'BLUE'; 2 :'GREEN'; 3 :'CYAN'; 4 :'RED'; 5 :'MAGENTA'; 6 :'BROWN'; 7 :'LIGHTGREY'; 8 :'DARKGREY'; 9 :'LIGHTBLUE'; 10:'LIGHTGREEN'; 11:'LIGHTCYAN'; 12:'LIGHTRED'; 13:'LIGHTMAGENTA'; 14:'YELLOW'; 15:'WHITE'); Cmds : Array[1..12] Of TComStr Value (1 :'@POS('; 2 :'@COLOUR('; 3 :'@CLS'; 4 :'@WAIT('; 5 :'@CURSON'; 6 :'@CURSOFF'; 7 :'@FILE('; 8 :'@LOAD('; 9 :'@SAVE('; 10:'@FILL('; 11:'@SLEEP('; 12:'@SOUND('); Stack trace: Exiting due to signal SIGSEGV Page fault at eip=0003bdbd, error=0004 eax=00000112 ebx=00191ecc ecx=0018db3c edx=00191e38 esi=00182dd4 edi=00000006 ebp=00182cf8 esp=00182cec program=c:/utils/djgpp/bin\gpc1.exe cs: sel=0127 base=100d0000 limit=001cffff ds: sel=012f base=100d0000 limit=001cffff es: sel=012f base=100d0000 limit=001cffff fs: sel=010f base=000165b0 limit=0000ffff gs: sel=013f base=00000000 limit=ffffffff ss: sel=012f base=100d0000 limit=001cffff Call frame traceback EIPs: 0x0003bdbd 0x0003bdee 0x0001b2a4 0x0006fdfa 0x000721e9 0x0011818e Please respond to Gareth_Wilson(a)RocketMail.Com.

1 0

Re: Sockets
by Berend de Boer 18 Mar '97

18 Mar '97

You wrote: >I need to use network sockets from gpc. Can I do this? How? Yes, by writing a module which links in the corresponding c routines. Groetjes, Berend.

1 0

Sockets
by Stephen Lindholm 17 Mar '97

17 Mar '97

I need to use network sockets from gpc. Can I do this? How?

1 0

Re: GPC for the DEC Alpha
by Peter Gerwinski 17 Mar '97

17 Mar '97

According to JanJaap van der Heijden: > I don't know much about the Alpha and GPC related bugs, but I did some work > to build Redhat RPM's for GPC. RPM? What's that? > As you may know, Redhat Linux is available > for iX86, sparc and alpha. The GCC sources from redhat come with a number of > patches to build on the alpha. Anybody who wants to build GPC for > Linux/alpha will have to apply these, probably. Are these patches freely available? If so, we should point to them in the GPC documentation and README files. And in the FAQ - even more important. > Normally, I would not have > come up with this untill it matured a bit, but since the topic of Alphas has > come up: is there anybody out there running a Redhat Linux/Alpha machine who > would want to test these RPM's on it? The Alpha I have access to does not run Linux. Perhaps somebody else has a Linux/Alpha system? And I am still interested in example programs which trigger those Alpha-with-high-optimization-specific errors, you know. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: gpc and gcc 2.7.2.2
by JanJaap van der Heijden 14 Mar '97

14 Mar '97

At 09:11 AM 3/11/97 +0100, you wrote: >Hi, > >I have install gcc and would like to take 2.7.2.2. >I read that gpc 2.0 is for gcc 2.7.2.1. Is it difficult >to make it work with 2.7.2.2? > Quoting gcc-2.7.2.1-2.7.2.2.diff: "The reason for the 2.7.2.2 release is to add support for GNU C library version 2 on GNU/Linux systems." If you study this (small) patch, you find out that no changes have been made to the compiler internals at all, only minor changes to some config files. So, unless you have a Linux/glibc2 system, I see no need to upgrade from 2.7.2.1 to 2.7.2.2 If you have 2.7.2.2 and want to built GPC with it, just edit Makefile.in and change GCCVERSION to 2.7.2.2. It will not harm GPC since no _real_ changes to GCC were made anyway. Have fun, JanJaap -- "Nothing shocks me, I'm a scientist", Indiana Jones

1 0

Re: GPC for the DEC Alpha
by JanJaap van der Heijden 14 Mar '97

14 Mar '97

At 11:19 PM 3/14/97 +0100, you wrote: >Hi! > >As you know perhaps from the GPC documentation, there are some known bugs >with optimization on the DEC Alpha. Up to now I was not able to hunt >them, but it seems like that I will get access to an Alpha workstation >till 1. November. > >Since I only know that these bugs exist but I don't have a single example >program, I would be glad if the DEC Alpha users among you could send me >their example programs which fail with high optimization levels. > I don't know much about the Alpha and GPC related bugs, but I did some work to build Redhat RPM's for GPC. As you may know, Redhat Linux is available for iX86, sparc and alpha. The GCC sources from redhat come with a number of patches to build on the alpha. Anybody who wants to build GPC for Linux/alpha will have to apply these, probably. Normally, I would not have come up with this untill it matured a bit, but since the topic of Alphas has come up: is there anybody out there running a Redhat Linux/Alpha machine who would want to test these RPM's on it? JanJaap -- "Nothing shocks me, I'm a scientist", Indiana Jones

1 0

GPC for the DEC Alpha
by Peter Gerwinski 14 Mar '97

14 Mar '97

Hi! As you know perhaps from the GPC documentation, there are some known bugs with optimization on the DEC Alpha. Up to now I was not able to hunt them, but it seems like that I will get access to an Alpha workstation till 1. November. Since I only know that these bugs exist but I don't have a single example program, I would be glad if the DEC Alpha users among you could send me their example programs which fail with high optimization levels. Thanks in advance, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc March 1997