Gpc June 2002

gpc@gnu.de

22 participants
29 discussions

Re: Pascal-Standard Question
by da Silva, Joe 07 Jun '02

07 Jun '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, June 06, 2002 12:29 PM > To: gpc(a)gnu.de > Subject: Re: Pascal-Standard Question > > da Silva, Joe wrote: > > > I've been following this debate and wondering just what the ISO > standards > > define. As you know, it's not easy reading through the standards and > > finding obscure little details such as this. <g> > > > > However, I think section 6.13 of ISO-10206 indicates that a program can > > indeed consist of multiple modules and can include one main program, > > each of which is terminated by a "full stop" (aka. "period"). > > Yes, even in any order. This is rather difficult to handle, if a > program precedes a required module. A way to do it is to split the > source file and pass each part separately to the compiler. This > could be done transparently by a preprocessor, and serve as a (more > general) replacement for the current feature ... > [Joe da Silva] Yes, odd isn't it? Well, IMHO, if it's too difficult to handle sections (ie. program-components) in any order, it should be an acceptable implementation restriction to require that the main program is the last section (in the usual "define it before you use it" manner). > > Also, regarding EOLN and EOF, section 6.7.6.5 indicates that "When > > eoln(f) is activated, it shall be an error if ... eof(f) is true". > > This means, in my words, that it's a runtime error to test EOLn when > the file is already at EOF. However, 6.4.3.6 says: > > : The structure of the type denoted by text shall define an additional > : sequencetype whose values shall be designated lines. A line shall be a > : sequence cs~S(endofline), where cs is a sequence of components > possessing > : the chartype, and endofline shall represent a special componentvalue. > : > : [...] > : > : Every value t of the type denoted by text shall satisfy the following > two > : rules: > : > : a) If t.M = Inspection, then t.L~t.R shall be a linesequence. > : > : b) If t.M = Generation, then t.L~t.R shall be ls~cs, where ls is a > : linesequence and cs is a sequence of components possessing the > : chartype. > : > : NOTE --- 5 In rule b), cs may be considered, especially if it is > nonempty, > : to be a partial line that is being generated. Such a partial line cannot > : occur during inspection of a file. Also, cs does not correspond to t.R, > : since t.R is the empty sequence if t.M = Generation. > > This indicates that it doesn't support partial lines at the end of > the file except during writing -- whether or not that's a good idea > is certainly arguable (I don't really think so) ... > [Joe da Silva] Yes, the standards seem to consider that a text file must consist of lines and that therefore such a file is invalid (as a text file) if there isn't an EOLN before EOF. Of course, such a file can still be a "file of char", but this means the text file features of read() and write() are lost. IMHO, the ability of a compiler to handle invalid situations in a more "user friendly" manner, does not truly detract from it's standards compliance, provided this does not affect how it handles valid situations, of course. I consider it a form of "error recovery". Therefore, I see nothing really wrong with a compiler simply returning TRUE for eoln() when eof() is TRUE. > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html

1 0

Re: Crash & various misc problems
by Waldek Hebisch 06 Jun '02

06 Jun '02

Frank's patches fixed crash and --nested-comments works. Thanks -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

Re: Insight-gdb crash + fix
by Robert B. Scher 06 Jun '02

06 Jun '02

Pierre Muller pointed out that, in my post of July 2 on this topic, I forgot to indicate that the file to patch is `gdb/dbxread.c' under the source tree. Sorry. > Did you test it by using insight in non windowed mode (with --nw option), then you get the normal text mode version of gdb. In my original post I wrote: > insight running in non-graphical mode (with the --nowin flag ) does > not exhibit this problem. One difference, I think, between the two modes is that, in the graphical mode, the entire symbol table is read at the time the binary file is opened, whereas it is apparently NOT read, at least not by the same routine, in the text mode. *** A few more details: If you use gdb on itself, as I did, and you break at line 2768 of dbxread.c, within fcn. process_one_symbol (which is the first line of my patch), you'll see that the context of the call is below `gdb_load_disassembly'. Apparently this fcn. is not called, or not in the same way, in the text mode. (Alternatively, in the unpatched source, line 2755 is the pop_context macro invocation where the problem occurs, and provides a suitable breakpoint for analysis. After fewer than 10 breaks, if memory serves, you arrive at one where context_stack_depth is already 0 - which is the problem situation. It's only easier to see this in the patched version because the variable is right in front of you. BTW, my procedure is to give `gdb gdb', set args to "" and run, and when the `debuggee' appears, to command it to open `smalltest' or some other program built with gpc 2.1.) ***** With regard to my post of July 3, "GPC2.1: all types "void" under gdb", please note that this problem can be easily observed in the text mode by using the "print" commmand. Finally, as a user, I'd like to thank the developers collectively for an impressive and useful product. Bob Scher

1 0

Insight-gdb crash + fix
by Robert B. Scher 06 Jun '02

06 Jun '02

Hello. Hopefully this will be of interest to some of you - if not, my apologies if I am off-topic. I found that when trying to use the "insight gdb" visual debugger on a binary made using (my locally built) GPC 2.1, the debugger crashes while performing an initial read of the "stabs" info in the binary. But it doesn't crash on binaries made from the (Redhat distributed binary) gpc-19990118. I'm not 100% sure that this is an insight gdb problem - it might take a stabs expert to decide whether insight's logic is correct here or whether there's anything invalid about the stabs sequence emitted by gpc. In any case, below is a simple patch of insight to work around the problem. It works for a couple of multi-module gpc programs that I've tried it with. BTW, the debugger source is ftp://sources.redhat.com/pub/gdb/releases/insight-5.2.tar.bz2 I just submitted a problem report to the insight developers - we'll see what they say. Here's the patch: 1,12d0 < /* modified 5/31/02 Robert Scher. Changes flagged with "RBS". < Works around a problem encountered when reading executables produced < by gpc (Gnu Pascal) version 2.1. Without this change - or hopefully < a more proper correction that attacks the problem head-on, < the "insight" (graphical) variant of gdb crashes at the point where it < reads the stabs section associated with the file error.pas in the < gpc 2.1 support files set. This is a problem peculiar to the graphical < mode (and has been seen on several versions of "insight"). < insight running in non-graphical mode (with the --nowin flag ) does < not exhibit this problem. < */ < 1613c1601 < { --- > { 1641d1628 < 1652a1640 > 2767,2771c2755 < // start RBS patch: check to prevent popping garbage when depth is already 0 < if (!context_stack_depth) < break; // ignore it! < // end RBS patch < new = pop_context (); --- > new = pop_context (); Bob Scher

2 1

Re: Pascal-Standard Question
by da Silva, Joe 06 Jun '02

06 Jun '02

I've been following this debate and wondering just what the ISO standards define. As you know, it's not easy reading through the standards and finding obscure little details such as this. <g> However, I think section 6.13 of ISO-10206 indicates that a program can indeed consist of multiple modules and can include one main program, each of which is terminated by a "full stop" (aka. "period"). Also, regarding EOLN and EOF, section 6.7.6.5 indicates that "When eoln(f) is activated, it shall be an error if ... eof(f) is true". Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Wednesday, June 05, 2002 8:00 PM > To: cbfalconer(a)worldnet.att.net; gpc(a)gnu.de > Subject: Re: Pascal-Standard Question > > CBFalconer wrote: > > > Frank Heckenbach wrote: > > > Eike Lange wrote: > > > > On Tue, Jun 04, 2002 at 10:16:21AM -0400, CBFalconer wrote: > > > > > Put in those terms, he is absolutely right IMO. Anything that > > > > > follows the "end ." should be ignored, in fact not even read. The > > > > > period should be parsed and cause compilation to stop. I think > > > > > the syntax is something like: > > > > > > > > > > program ::= 'program' progparms ';' declarations block '.' > > > > > > > > Yes, but there might be a statement like this (not exactly BNF :-) > > > > part ::= program or unit > > > > file ::= part until EOF > > > > > > Yes, I'd also think so. Normally, a grammar doesn't imply that > > > anything may follow the program. > > > > > > However, BP behaves like this, and GPC does so with > > > `--borland-pascal' (but I don't think we should make this the > > > default). > > > > Who are you agreeing with? I hope it is me :-) > > No, Eike who I quoted directly. > > > I actually had to go to some trouble to get this to work correctly > > in PascalP, because I allowed EOF to appear immediately after the > > '.', with no eoln. At the same time I wanted to collect source > > lines for a listing. > > Why don't you just read it as a text file (provided PascalP was > written in Pascal)? According to the standard, a text file in Pascal > consists of lines, so there is always an EOLn before EOF (whether or > not the external file contains a newline at the end). > > Obviously, GPC (written in C) doesn't do this, either. It just > processes the input character-wise and counts the newlines (for > messages) and outputs it character-wise (with `--debug-source'). > > > This characteristic is convenient for appending rambling notes > > after the final "end." without worrying about forming proper > > comments. > > The question is not whether it's convenient, but whether it's > allowed by the standards. Do you have any reference where they allow > it? > > > BTW I just ran across a fascinating essay at: > > > > <http://www.epemag.com/zuse/forword.htm> > > > > which might especially interest you. > > Gives me a 404. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://www.gnu-pascal.de/todo.html

2 1

Pascal-Standard Question
by Eike Lange 05 Jun '02

05 Jun '02

Hi folks! In our department, we have a little conversion about Pascal-Standards: Is the following allowed and should the program be compiled if the unit and the program share the same file? It seems, that GPC does and TurboPascal (tm) does not AFAIK. 8<---------------- unit foo; interface ... implementation ... end. program bar; uses foo; begin ... end. ------------->8 Eike

5 12

GPC2.1: types "void" under gdb?
by Robert B. Scher 04 Jun '02

04 Jun '02

Hi everyone. My recenty build of GPC 2.1 from source produces programs that don't permit pascal variables to be examined within gdb! Since this is such an egregious problem I assume that it's peculiar to my build, but could someone please tell me? For example: {************************************} program smalltest; var n: integer; begin n := 3; while n > 0 do begin writeln( 'hello'); n := n - 1; end; end. {************************************} I have tried compiling this with either the -g and -gstabs flag. (With --ggdb, my gpc 2.1 crashes). -g or -gstabs both produce runnable but non-identical binaries. However, in either case, if I give `print n' within gdb, the response is `$1 = void'. I've tried this on larger programs as well, and variables of various types exhibit the same. And I get the same behavior whether using an old "stock binary" version of gdb or the newer "insight variant" version 5.2. On the other hand, when I compile using gpc-19990118, the variables CAN be examined using both versions of gdb. (BTW, I need to move to gpc 2.1 in order to get "crt" unit functionality, which AFAICS was not available under the redhat-distributed gpc-19990118.) With the command `objdump --stabs smalltest' I'm able to see that the type definitions produced by gpc 2.1 are quite different in form from those produced by gpc-19990118. (The order in which the C and Pascal type stabs occur is different, but I suspect that's unimportant.) For "integer", here's the comparison: Integer:t(0,1)=r(0,1); -2147483648; 2147483647 from gpc-19990118 and Integer:t(0,65)=(0,65) from my gpc 2.1 The previous type def. is of "range" type, and defines the integer range of the type. I suspect that the completely uninformative type def's. produced by my gpc 2.1 - and all of them are like the "integer" definition shown" - is the reason that gdb can't display values. Only other thing I could say is that I built gpc from gcc-core-2.95.2 and gpc-2.1 from http://www.gnu-pascal.de/current/. I ran configure using arguments `--enable-languages=pascal --prefix=/usr/gcc2.95.2' I did NOT use a separate build directory, but ran configure from the directory where I had unpacked it, /usr/src/gcc-2.95.2. Thanks for any suggestions or comments. Bob Scher

1 0

Crash & various misc problems (resent)
by Waldek Hebisch 04 Jun '02

04 Jun '02

Hi I just intalled gpc 2.1 on top of gcc 2.95.3 (all on slightly updated RedHat 7.0). When I type: gpc --interface-only tp.pp I get gpc: Internal compiler error: program gpc1 got fatal signal 11 The content of tp.pp is: program tp; begin end. It looks that compiler crashes when there is no interface in the file (I found it on much bigger files, and with lot of other options). The problem also appears in older version of gpc on another machine. The manual says that gpc 2.1 accepts nested comments but when I try gpc --nested-comments nn.pas with nn.pas beeing program nn; (* Can NOT compile with --nested-comments *) begin (* (* *) *) end. the compiler complains about '*' The following ugly syntax (taken from FPC sources :) is not accepted even in Borland Pascal mode (supposedly BP compiles the code): unit ttt; interface function foo(const s : string) : integer; implementation function foo(const s : string) : integer; var i,j:integer; begin for i:=1to 5 do j:=j+1; foo := j; end; end. The compiler complines about 'nondigits in number whose radix <= 10' in the line containing 'for' and then cannot find 'to' or 'downto'. Finally, the manual claims that all one-letter switches in BP are supported, but (again in FPC source) R switch (range check) is not recognized and compilation is aborted on {$ifopt R+} -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

3 4

GPC install script
by Ernst-Ludwig Bohnen 03 Jun '02

03 Jun '02

Hi all! A new version of the GPC install script (install.gpc) is available from URL: http://gnu-pascal.de/contrib/ernst/tools/install.gnu Installations of gpc-2.1 (and older) have been made successfully on: SunOS 5.7 as user under AFS Linux, SuSe 7.3 as local user, as root, and as user under AFS Users working under AFS und varying CPU architectures need to care about storing architecture dependent *.gpi, *.o files in different directories. This problem can't be solved by the installer. Feedback welcome. Ernst-Ludwig

1 0

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 June 2002