Gpc April 1997

gpc@gnu.de

24 participants
111 discussions

New Alpha: EMX run time library broken?
by Peter Gerwinski 23 Apr '97

23 Apr '97

Hello, I was reported that the EMX run time library of the latest alpha GPC (gpc-970420) is broken: Not even `hello.pas' can be linked. Since I cannot reproduce the error on my own system (I can link even more complicated EMX programs here ... :-) I ask whether somebody else has observed the same problem. Perhaps there is a bug which only shows up in some configurations ... 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: New Alpha
by Frank Heckenbach 23 Apr '97

23 Apr '97

First of all: Thanks for implementing all the new features and removing many bugs! I like especially the packed arrays and records and the write(ln) with subranges! :-) Most of the bugs I reported in the last few months seem to have gone. However, the following still doesn't work (if it's already/still on the bug list, please ignore): PROGRAM x; CONST n:1..16=6; {"subrange bounds are not of the same type"} {The same with "var ...=...", ok with "var ... value ..."} BEGIN END. Then, a very small problem: I have a Pascal program (let's say foo.pas) that uses some units. I've put the following line into it: {$IFDEF __GPC__}{$automake="-O3"}{$ENDIF} It also needs some C functions contained in bar.c . If I compile it with "gpc foo.pas bar.c", it works fine. But if I do "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions). In the latter situation also the file foo.gpc is left. It's no real problem since the first version works, but I just want to make sure if this is supposed behaviour (for any reason) or a little bug. BTW, the problem in Linux that I described is still there, but I solved it (temporarily) by moving cpp to cpp_ and putting the following script as cpp: #!/bin/sh /usr/lib/gcc-lib/i486-linux/2.7.2.1/cpp_ $* -U__GNUC_MINOR__ -D__GNUC_MINOR__=7 Probably not a very elegant solution, but it seems to work for now... -- 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

New Alpha
by Peter Gerwinski 20 Apr '97

20 Apr '97

Hello! Here again is a new GPC alpha version. Changes since gpc-970412: General news: * `Packed' works. A "packed array [ 1..8 ] of Boolean" now occupies one byte instead of 8 like before (or like with Borland Pascal which claims to pack all arrays automatically). Also, the type packed record a: Boolean; b: 0..3; c: -3..3; end; now also has just one byte (instead of 3). :-) As a result, the built-in procedures `pack' and `unpack' are probably broken. Since I have no experience with these procedures, please send me some test programs which do exactly "writeln ( 'OK' )" if everything works, or else "writeln ( 'failed' )" (or crash or don't compile) if not. Thanks in advance. * GPC now has yet another new option `--debug-tree="Foo"' which is useful for debugging GPC itself. I use it to look at GPC's internal information about a variable `foo' during compilation by inserting (*$debug-tree="Foo"*) into the Pascal source. * Implemented more warnings about unrecognized compiler directives or combinations which make no sense. Bug fixes: * Comparisions of ordinal types as `if' conditions work again (was broken in gpc-970412). * `Const' or `protected Var' parameters which are transported through GPI files do not spoil type declarations any more. * Assignment to char type subranges work again. (Was broken, probably in gpc-970215.) * The `write' and `writeln' procedures applied to subranges (e.g. `Char' subranges, `Byte' variables, etc.) work now. Borland Pascal: * Untyped parameters now can be passed as parameters to subsequent functions which also want untyped parameters. Extended Pascal: * GPC now warns about `or else' and `and then', which are GPC extensions, when `--extended-pascal' is given. (ISO Pascal wants `or_else' and `and_then'.) * Assignments <char variable> := <string value> (allowed in EP, not in BP) now work in parameter passing, too. (This means they should work in all situations now.) With `--borland-pascal', a warning is given. * Modules: Exported ranges work. * I herewith present first results from the Schema Project. (-: The following schemata work now: Type MySubrange ( LastChar: Char ) = 'A'..LastChar; MyArray ( n: Integer ) = array [ 1..n ] of Real; (Not yet implemented: `New', `Dispose', and parameter passing with undiscriminated schemata. And probably more.) If you want to contribute to this part of GPC, please test these types of schemata in as many contexts as possible. It is impossible for myself to try this out with all underlying data types, in the context of assignments, other expressions, parameter passing, etc. The source - a diff against gpc-970412 - is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ together with binaries for DOS (DJGPP), DOS and OS/2 (EMX), Linux (ELF), and FreeBSD. Thanks to Abimbola A. Olowofoyeku, Frank Heckenbach, Berend de Boer, and Sven Hilscher for finding the bugs. Again: Is anybody interested to help to document all this? For example, to write a list of Extended Pascal [Borland Pascal] features which work [do not yet work] in GPC which replace the somehow outdated chapter "Extensions", "Extended Pascal", and "Borland Pascal" in the on-line manual? Or to complete and improve the description of the compiler option in chapter "Invoking GPC"? Finally I have one more question: Let's assume the Schema Project to be done. How much compatibility to Extended Pascal and to Borland Pascal can we claim then? In case it is EP > 90% I would like to enter beta test stage and to prepare for the release of gpc-2.1. If not, I would like to know which parts of EP should be implemented to achive > 90% compatibility. (* This condition arises from former announcements where I misunderstood some notes in the GPC source and already claimed 90%. )-: Instead of decreasing this number in future releases I want to improve GPC and announce at least 91% - which must be justified then. We aim the possibility to have 100% EP with `--extended-pascal' anyway. {I aim the 100% only with the switch, because - for instance - this nested comment would be an error in Extended Pascal.;-} *) Greetings, 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 [970420] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: New Alpha
by Frank Heckenbach 19 Apr '97

19 Apr '97

Peter Gerwinski wrote: > Yes, conditional defines. GPC pre-defines the symbol "__GPC__": > > (*$ifdef __GPC__ *) > (* GNU Pascal switches *) >[...] > (*$else *) > (* Borland Pascal switches *) >[...] > (*$endif *) > > What would you consider "simpler" than this? ;-) OK, if "__GPC__" is predefined, this is viable. I didn't know about this, I tried just "GPC"... > > BTW: Is it legal (with the currect version) to use "gpc foo.c bar.pas"? > > I asked about this already in my mail about "Re: Linking directives..." on > > 3 Apr, but unfortunately got no replies. > > Oh - sorry, I overlooked it. #-) Yes, it's legal, and it works on my > Linux box, too. (You wrote that it didn't work on yours; perhaps this > bug is fixed now?) No, it seems to be an installation problem. Up to now, I could trace it down to the fact that "-D__GNUC_MINOR__=0(2" is passed to cpp if called via gpc, instead of "-D__GNUC_MINOR__=7" with gcc. I'm not sure yet why this is so, does it have anything to do with "gpc version 2.0(2.7.2.1)"? ^^^ -- 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

2 1

New Alpha: libgpc.a for DJGPP
by Peter Gerwinski 17 Apr '97

17 Apr '97

Hello, the runtime library in the DJGPP binary distribution of the last Alpha GPC was bogus. Even `hello.pas' did not work. Sorry for that ... #-) (But the source is okay!) I am updating `gpc-970412.i386-djgppv201.zip' on agnes. Yours, 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 [970412] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: New Alpha
by Peter Gerwinski 16 Apr '97

16 Apr '97

According to Frank Heckenbach: > > BTW: You recently said that one has to use '-pedantic', not '-fpedantic' > in specs. Is there a general rule when to use '-f...' and when simply '-...'? AFAIK, the GNU compiler originally accepted only `-ffoo-bar' flags. (The `-f' stands for "flag".) Nowadays, just `--' is okay as an alternative for `-f'. (Note that these long options start with two dashes, not just one.) The `specs' file only understands the old syntax. `--pedantic' is an exception, because it is originally `-pedantic' (with one dash), not `-fpedantic' (i.e. no "flag" in this sense). To get all options, read the (loooooooooooong) section "Invoking GPC" from the info documentation, and pick up the flags not explained there from my "New Alpha" announcements. In the worst case, look at the GPC source file `gpc-options.h' for a list of all `--' (or `-f') options, and see `gpc-decl.c' for what they do. > Just to make sure: 'AutoMake="--foo"' means that '--foo' is used for the > compilation of the units involved and the program itself, while > 'AutoMake, --foo' would apply '--foo' only to the program. Is that right? Almost. Within the directive, `--' (in fact: `-f') is automatically prefixed, so don't give it explicitly. (*$AutoMake="--foo"*) correct; gives `--foo' to the compilation of Units (*$AutoMake="foo"*) wrong; gives `foo' to the compilation of Units (which is nonsense) (*$AutoMake,foo*) correct; gives `--foo' to the current compilation (*$AutoMake,--foo*) wrong; gives `----foo' (in fact: `-f--foo') to the current compilation. > A minor "problem": If I compile a program with such a compiler switch with TP, > TP complains about an "Invalid compiler directive". Is there a way [...] > to supply the options so that gpc will recognize them and TP will ignore > them? Yes, conditional defines. GPC pre-defines the symbol "__GPC__": (*$ifdef __GPC__ *) (* GNU Pascal switches *) (*$no-field-widths *) (*$AutoMake="--foo --bar"*) (*$N+*) (* Nested comments *) (*$E-*) (* No C-style char escapes *) (*$else *) (* Borland Pascal switches *) (*$M 65536 *) (* Stack size *) (*$N+*) (* Numeric coprocessor on *) (*$E-*) (* Don't link the Emulator *) (*$endif *) (* Switches for both compilers *) (*$B-*) (* Short-circuit Boolean operators *) > (perhaps a simpler way than conditional defines) What would you consider "simpler" than this? ;-) > What about compiler options for "-o foo", "foo.o" and/or "bar.c"? Are you > working on them, or are they too difficult to implement? Working on them. I don't expect much trouble from (*$L foo.o *) and (*$L bar.c *), but I am not so sure about "-o foo" ... > BTW: Is it legal (with the currect version) to use "gpc foo.c bar.pas"? > I asked about this already in my mail about "Re: Linking directives..." on > 3 Apr, but unfortunately got no replies. Oh - sorry, I overlooked it. #-) Yes, it's legal, and it works on my Linux box, too. (You wrote that it didn't work on yours; perhaps this bug is fixed now?) > And another contribution to the GPC test suite... :-| > > The following program and unit cause the latest gpc to fail with SIGSEGV. > It worked with a previous version of gpc [...] I can reproduce the error. Okay, it will be fixed in the next Alpha. (I hope at least.;) Greetings, 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 [970412] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Boolean operators (Was: Re: New Alpha)
by Peter Gerwinski 16 Apr '97

16 Apr '97

According to Frank Heckenbach: > > Indeed, I think this is good if one uses complete evaluation by default. > However, I prefer to have short circuit evaluation by default. > So what about similar operators to force complete evaluation - it would seem > cleaner to me than using {$B+} ... {$B-}? ISO Pascal's short circuit operators are "and_then" and "or_else"; GPC also allows "and then" and "or else". Perhaps "or_then" and "and_else" would be their natural counterparts? BTW, can anybody tell me a case where complete evaluation is desirable? IMHO, no reasonable Pascal program should use functions with side-effects in `if' conditions containing `and' because you can never know in which order they are evaluated (except with short-circuit operators, but here we are again). ... Ahhh! 8-) PS: ISO 10206, 6.8.3.1 says: NOTE - This means, for example, that the operands [of ordinary `or' and `and'] may be evaluated in textual order, or in reverse order, or in parallel, or they may not both be evaluated. This means that short circuit operators being the default does not break ISO conformance. Fine. :-) AND it means that if you want to produce portable code you cannot rely on complete evaluation, so be careful. 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 [970412] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: BP RTL
by Peter Gerwinski 16 Apr '97

16 Apr '97

According to skye: > I was wondering if anyone has put together a lib for BP compatibility. Try the "BPcompat" package, available at ftp://kampi.hut.fi/jtv/gnu-pascal/contrib/ ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/ 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 [970412] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: BP RTL
by The African Chief 16 Apr '97

16 Apr '97

On Tue, 15 Apr 1997 14:58:26 -0700 skye <s_c(a)iname.com> wrote: >I was wondering if anyone has put together a lib for BP compatibility. A >most-commonly-used-functions one? Something? I'm new to GPC and would like >to use it for my lessons as well as encorage my students to use it. I've >already got them using DJGPP for C/C++. Peter already has a BPCOMPAT package which implements some of the Borland RTL routines. I myself am implementing some more. Some of this has involved importing some functions from the C library. I am also producing Pascal UNITs for many of the C headers (io.h, stdio.h, stdlib.h, ctype.h, dos.h, dir.h, etc). When all this is finished, it will be released to the GPC community. Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

1 0

BP RTL
by skye 15 Apr '97

15 Apr '97

I was wondering if anyone has put together a lib for BP compatibility. A most-commonly-used-functions one? Something? I'm new to GPC and would like to use it for my lessons as well as encorage my students to use it. I've already got them using DJGPP for C/C++. Thanks, -SC

1 0

← Newer
1
2
3
4
5
6
7
8
...
12
Older →

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