- Gpc - gnu.de

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 19 Oct '01

19 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 19 Oct '01

19 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 19 Oct '01

19 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