- Gpc - gnu.de

max/memavail
by Michael Behm 24 Sep '02

24 Sep '02

hello together, i have the following questions: i've been working with borland pascal under DOS for quite a long time, and now i changed to gpc under Solaris 8 on a SUN Blade 1000. i've to admit that i don't know much of UNIX itself. when i use the functions Max/MemAvail, the program seems to halt (it doesn't crash, just waits until i destroy via ctrl-c). i suppose that MaxAvail/MemAvail does only make sense under DOS - i don't know if there is anything like a heap in UNIX. are there any similiar functions (which work) in gpc/UNIX ? how can i determine the space which is free for a single pointer variable ? what is the heap-system (if there is one) in UNIX ? with GetMem, can i address the whole memory (which is 1 GByte) ? a lot of questions, i know, but i hope somebody can help me. thank you, and best wishes, michael ! ===== HÃ¶hlenforschung in Ãsterreich: www.xploration.at.tt __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de MÃ¶chten Sie mit einem GruÃ antworten? http://grusskarten.yahoo.de

2 1

Re: Dev+GNU Pascal [Was Re: Installation problem gpcpp.exe no such]
by Prof. A Olowofoyeku (The African Chief) 21 Sep '02

21 Sep '02

On 18 Sep 2002 at 9:21, I wrote: > On 18 Sep 2002 at 0:57, Frank Heckenbach wrote: [...] > > But something else (I still don't really understand the story): > > Searching of gpcpp does not use the unit-path. The path is > > hard-coded while building GPC, so if it is installed in the same > > directory, no option is needed to find it. Otherwise it can be set > > with a `-B' option or an environment variable GPC_EXEC_PREFIX. Is > > that what the IDE sets for the "bin directory"? > > This is an example of output of the "compile log" window: > "c:\dev_gpc\bin\gpc --automake c:\dev_gpc\examples\untitled1.pas > -oc:\dev_gpc\examples\untitled1.exe -fno-inline -fno-io-checking > -fno-stack-checking -O1 -march=i386 -mcpu=i386 > -funit-path=c:\dev_gpc\units -Bc:\dev_gpc\lib\ -Bc:\dev_gpc\lib\gcc- > lib\ -Bc:\dev_gpc\bin\" > > So the necessary "-B" switches are there - and I cannot see why there > should be a problem. I have now checked the compile log again, and I can see that the entire command line contains about 273 characters. Perhaps we have come across a DOS limitation here? I seem to remember that DOS (or command.com) has some limits in respect of how long a command line can be (128 characters?). If this is the problem, then I don't know what one can do about it. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

4 14

Automake problems - excessive compilation times
by Marten Jan de Ruiter 20 Sep '02

20 Sep '02

Since I threw away everything I tried to repeat the problem. I will try to explain what I did using a log: % which gpc /dutw54/deruiter/system/bin/gpc % mv /dutw54/deruiter/system/bin/gpc /dutw54/deruiter/system/bin/gpc.hide % rehash % which gpc /usr/tm/bin/gpc % gpc --version 2.95.2 19991024 (release) % make_clean % time make_fem >& /dev/null 169.390u 15.880s 4:31.73 68.1% 0+0k 0+0io 257172pf+0w % make_clean % mv /dutw54/deruiter/system/bin/gpc.hide /dutw54/deruiter/system/bin/gpc % which gpc /dutw54/deruiter/system/bin/gpc % gpc --version 20020910, based on gcc-2.95.2 19991024 (release) % make_clean %time make_fem > & ! make_log 1502.410u 434.950s 46:40.99 69.1% 0+0k 0+0io 11139770pf+0w % mv make_log make_log_first % time make_fem > & ! make_log 0.170u 0.090s 18:11:58.94 0.0% 0+0k 0+0io 4003pf+0w % grep gpcpp make_log_first | wc 43327 2166121 70806935 % grep gpcpp make_log | wc 177116 8855798 287544862 % grep gpcpp make_log | cut -f49 -d\ >make_log_gpcpp % grep gpcpp_first make_log | cut -f49 -d\ >make_log_first_gpcpp % ls -l make_log* -rw-r--r-- 1 deruiter staff 377521106 Sep 20 09:53 make_log -rw-r--r-- 1 deruiter staff 93209349 Sep 19 15:00 make_log_first -rw-r--r-- 1 deruiter staff 1043211 Sep 20 09:53 make_log_first_gpcpp -rw-r--r-- 1 deruiter staff 2388112 Sep 20 09:55 make_log_gpcpp make_clean is a script that removes all the object and gpi files make_fem builds the executable. So, I hid the new binary to use the old compiler, made sure that the old compiler was used, and nothing was compiled, and managed to obtain a executable in 4:31.73 ( Then I trew everything away, restored the new compiler, and obtained an executable in 46:40.99, which is considerably longer After moving the log file only, I tried to compile again (overnight!), without succes. I interrupted the process after 18:11:58.94 The last lines tell that gpcpp was invoked 43327 times in the first run, that yielded an executable, and 177116 times in the interrupted last. The 48-th arguments, that are the unit file names, are selected and put in the _gpcpp files Since I do not want to flush the entire gpc mailinglist with (hundreds of) megabytes of log files, I do not include the logfiles to this mail, but I hope I can highlight some of the output, that points in the right direction. More commands follow: % head -50 make_log > make_log.firstlines % head -200 make_log_first_gpcpp > make_log_first_gpcpp.firstlines % head -200 make_log_gpcpp > make_log_gpcpp.firstlines % cat -n make_log_first_gpcpp | grep NODES | head -40 > make_log_first_gpcpp_NODES % cat -n make_log_gpcpp | grep NODES | head -40 > make_log_gpcpp_NODES The attachment make_log.firstlines shows the first lines of the logfile, hopefully showing all that is used invoking the compilation. The other attachments show that NODES/*/*.p are compiled in one row of invocations of gpcpp, in the `clean' invocation of make_fem, namely line 18-29, whereas when all units are already compiled and available, then all dependencies are checked and double checked, so that the invocations are 6 apart, and cover 51 to 117. Hoping this helps to pinpoint the problem, regards, Marten Jan

1 0

Installation problem gpcpp.exe no such file or directory
by Pekka Mustonen 20 Sep '02

20 Sep '02

This is making me mad. It says that the file isn't there, but it is !! I've checked maybe 100 times, and the file is there !The path is correct, but GPC keeps telling me that the file is not there ! This is unbelievable. I'm using win98 and DEV+Gnu Pascal 1.9.2

5 12

Extended Pascal language restriction or GPC bug?
by S. Achterop IWI-120 3932 20 Sep '02

20 Sep '02

Hello here! The code below yields the following error on (e.g.) gpc version 20020910, based on gcc-2.95.4 20011002 (Debian prerelease) v.p: In procedure `Getfilename': v.p:8: prior parameter's size depends on `Fext' v.p:8: prior parameter's size depends on `Fext' If the second parameter of the activation of set_suffix is set to the variable "fextt", then it compiles normally. HOWEVER, if getfilename is removed from the interface, such that getfilename is completely local to IMPLEMENTATION, and apart from the structuring by modules the program is exactly the same, it ALSO compiles normally. AND, if for instance the TYPE IsoString is changed to a fixed array, no schemata, all is well ALSO. The question is, is using the second parameter as below ALLOWED according to the Extended Pascal report? 1 If so, this is a gpc bug. 2 If NOT, I can't find it in the Extended Pascal report. (Somehow I can see the need for this restriction, and I can live with it, I just can find it. Actually I started reading the report but stranded in the, for me, too complex formulation :) ) Does anyone on the list know the answer, is it 1 or 2? Regards, Sietse {************************************} MODULE msge INTERFACE; EXPORT msge = ( IsoString, getfilename); TYPE IsoString (Capacity : Integer) = array [1 .. Capacity + 1] of Integer; PROCEDURE getfilename (VAR fnm: IsoString; fext: IsoString); END. MODULE msge IMPLEMENTATION; VAR fextt : IsoString(30); PROCEDURE set_suffix (VAR fnm: IsoString; fext: IsoString); BEGIN END; PROCEDURE getfilename; BEGIN set_suffix (fnm, fext); END; END. {************************************}

2 1

Re: gpc 2.1 and rhide
by Per Persson 19 Sep '02

19 Sep '02

>From: Frank Heckenbach <frank(a)g-n-u.de> > >Per Persson wrote: > > > I have a question regarding gpc and rhide under Linux: > > I have been using gpc-20000913 under Red Hat Linux 6.2 and 7.1 together >with > > rhide 1.4.9-1 (which I got from a rpm-file :rhide-1.4.9-1.i386.rpm I > > downloaded..) > > This version of rhide has been somewhat buggy but very useful for >debugging > > purposes. > > Now, when I upgraded to gpc 2.1 the debugging does not work at all any > > longer. > > I can not watch an expression while stepping through the code as I >could > > before. > > I have tried different combinations of upper case and lower case in the > > specification > > of the watch but nothing seems to work. > >There was a bug with debug info in 2.1 which has been fixed in the >newer alphas. I don't know if that's the reason for your problems, >but you might want to try those. > >Frank OK gpc-20020910 works Thanks Per > _________________________________________________________________ MSN Hotmail Ã¤r vÃ¤rldens populÃ¤raste e-posttjÃ¤nst. Skaffa dig ett eget konto du ocksÃ¥: http://www.hotmail.com

1 0

internal compiler error with GPC on debian
by S. Achterop IWI-120 3932 19 Sep '02

19 Sep '02

L.S. On a Debian system (woody) with gpc version: 20020410, based on gcc-2.95.4 20011002 (Debian prerelease) the code below yields the following: home/doko/packages/gcc/2.95/x/gcc-2.95-2.95.4.ds11/src-native/gcc/p/module.c:3384:create_gpi_files: failed assertion `itab->interface_name_node' bug.p:11: Internal compiler error: bug.p:11: Internal compiler error. Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://www.gnu-pascal.de/todo.html> for details. The problem goes away if the IMPORT is removed. Any pointers? CODE: ==================================== MODULE A; EXPORT A = ( B ); { removing the next 2 lines resolves the issue. } IMPORT StandardOutput; PROCEDURE B; END; PROCEDURE B; BEGIN END; END. ========================================= Thanks in advance, Sietse Achterop (University of Groningen, The Netherlands, computing science department) PS. On other systems (e.g. Suse with version 2.95.3 20010315 (SuSE) ) there are no problems.

2 1

Automake problems - excessive compilation times
by Marten Jan de Ruiter 18 Sep '02

18 Sep '02

L.S. I was happy to notice that the memory leak in the file-io is fixed, after I succesfully compiled and installed gpc version 20020910, based on gcc-2.95.2 19991024 (release). However, currently I am compiling a FE program using the automake option, and it turns out that the build is recursively. Creating a log file (using gpc -v and editing a bit) yields the following result: 1 /tmp/ccAHxoUT.i 2 ch_const.p 3 general.p 4 NODES/nodes.p 5 MATERIAL/constitution.p 6 NODES/nodes.p 7 MATERIAL/constitution.p 8 ELEMENTS/elements.p 9 NODES/nodes.p 10 MATERIAL/constitution.p 11 NODES/nodes.p 12 MATERIAL/constitution.p 13 ELEMENTS/elements.p 14 global.p 15 NODES/nodes.p 16 NODES/SCAL/scalnode.p ... The main program uses the units ch_const, general, initnode, ... where initnode uses nodes, constitution, elements, ... whele elements uses nodes, constitution, ... Looking at the log file, NODES/nodes.p is compiled multiple times due to the recursive nature of automake. That this really is a problem can be seen from the fact that, according to top, the size of gpc1 is 611M, and running for 2920min, whereas a previous version of gpc only took minutes. However, that previous version creates a memory leak. More figures on the size of the problem: gpcpp has been invoked more than 250000 times, resulting in 213 units that are compiled. The source of the problem is the recursion. Take the following worst case scenario: unit 1. unit 2 uses unit 1 unit 3 uses unit 1,2 unit 4 uses unit 1,2,3 unit 5 uses unit 1,2,3,4 .... the program uses unit 1....n Compilation takes 1 step for unit 1, 2 for unit 2 (namely 1 for unit 1 and 1 for unit 2), 4 for unit 3 ( namely 1 for unit 1, 2 for unit 2,1 for unit 3), 8 for unit 4 (namly 1 for unit 1, 2 for unit 2, 4 for unit 3 and 1 for unit 4) By induction, the program requires 2^n steps. Now 250000 is negligible compared to 2^(more than 213), so my whining on the compilation effort should be taken with a bit of salt. The situation could be far worse ;-) This recursion scenario makes sure that the object files of the units are always based on the latest versions of the source. Anyway, I would like to suggest the following method (which I hope is easy to implement, and I hope I did not overlook some problem scenario) Basically, it boiles down to pruning the recursive branches that are done earlier. Create an empty list of up-to-date object files for each unit that is required do: procedure create_object_file * verify that the units it requires are on the list, if not, call create_object_file for that unit * compile the unit. In this case, compilation of unit 5 takes considerable less steps: 1 for unit 1, 2 for unit 2 (1 to see unit 1 is up to date, 1 for unit 2), 3 for unit 3 (2 to see unit 1 and 2 are up to date, 1 for unit 3), 4 for unit 4 (3 to see unit 1,2 and 3 are up to date, 1 for unit 4), and 1 for unit 5. This requires 5 unit compilations, and 6 `up to date'-checks in the list. Thus n(n+1)/2 + 1 steps are required to compile the program, of which n+1 compilations and n(n-1)/2 `up to date' checks. The savings are in the fact that an `up to date' check of, e.g., unit 4 does not require the `up to date' checks of its dependencies, since it is already in the `up to date' list after its compilation. Based on these considerations, only 22792 steps would be required, whereas now more than 250000 gpcpp invocations occurred. Regretfully, I do not have the time to start hacking around in gpc myself, so I hope you have some use for these comments. For the time being, I just compile the units in exactly the sequence as they occur in the logfile, and build without automake ;-) Regards, Marten Jan de Ruiter Structural Optmimzation and Computational Mechanics group, Delft University of Technology

2 1

[Fwd: 20020910]
by Maurice Lombardi 17 Sep '02

17 Sep '02

There has been a crash of our mail system this week-end and the following message never arrived to the list -------- Message d'origine -------- Objet: 20020910 Date: Fri, 13 Sep 2002 19:31:16 +0200 De: Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> A: gpc <gpc(a)gnu.de> Hi all While trying to compile the 20020910 alpha snapshot for DJGPP I have obtained the following error message c:/djgpp/b/gnu/gcc-2.953/gcc/p/rts/configure: line 2651: syntax error near unexpected token `GPC_MSG_CHECKING(for' c:/djgpp/b/gnu/gcc-2.953/gcc/p/rts/configure: line 2651: `GPC_MSG_CHECKING(for pw_gecos in struct passwd,if struct passwd in <pwd.h> contains a pw_gecos field)' make.exe[1]: *** [p/rts/Makefile] Error 2 make.exe[1]: Leaving directory `c:/djgpp/b/gnu/gcc-2.953/build.djg/gcc' make.exe: *** [all-gcc] Error 2 GPC_MSG_CHECKING has been changed betwen 0905 and 0910 in p/rts/configure.in by the following -------------------------------------------------------------------------------------- # The second parameter is used by make-acconfig-h.m4 -AC_DEFUN(GPC_MSG_CHECKING,[AC_MSG_CHECKING([$1])]) +ifdef([GPC_MSG_CHECKING],,[AC_DEFUN([[GPC_MSG_CHECKING]],[AC_MSG_CHECKING([$1])])]) --------------------------------------------------------------------------------------- It seems that you want to define it only if it is not already defined. I am lost with all those [] quoting. I have tried to simple quote by applying the following diff on the 20020910 sources (where the previous one has already been applied): ----------------------------------------------------------------------------- --- configure.in.orig 2002-09-13 00:40:32.000000000 +0000 +++ configure.in 2002-09-13 00:42:16.000000000 +0000 @@ -52,7 +52,7 @@ AC_SUBST(with_shared) AC_DEFUN(GPC_DEFINE,[AC_DEFINE(translit($1, [abcdefghijklmnopqrstuvwxyz ], [ABCDEFGHIJKLMNOPQRSTUVWXYZ_]))]) # The second parameter is used by make-acconfig-h.m4 -ifdef([GPC_MSG_CHECKING],,[AC_DEFUN([[GPC_MSG_CHECKING]],[AC_MSG_CHECKING([$1])])]) +ifdef([GPC_MSG_CHECKING],,[AC_DEFUN([GPC_MSG_CHECKING],[AC_MSG_CHECKING([$1])])]) # Checks for header files AC_HEADER_STDC ---------------------------------------------------------------------------- Then everything works OK. Is this just an error while uploading or some subtle difference between autoconf 2.13 you use and autoconf 2.50 I use ? I need to run DJGPP autoconf to regenerate the configure scripts to take into account some DJGPP peculiarities. 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 -- 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

gpc 2.1 and rhide
by Per Persson 15 Sep '02

15 Sep '02

Hello! I have a question regarding gpc and rhide under Linux: I have been using gpc-20000913 under Red Hat Linux 6.2 and 7.1 together with rhide 1.4.9-1 (which I got from a rpm-file :rhide-1.4.9-1.i386.rpm I downloaded..) This version of rhide has been somewhat buggy but very useful for debugging purposes. Now, when I upgraded to gpc 2.1 the debugging does not work at all any longer. I can not watch an expression while stepping through the code as I could before. I have tried different combinations of upper case and lower case in the specification of the watch but nothing seems to work. (The gpc 2.1 compiler pass all test in the test directory of the gpc-distribution (except 3 with are omitted) ) Does anybody know of a version of rhide which work reasonable well with gpc2.1 and RH ? Thanks Per _________________________________________________________________ Skicka snabbmeddelanden till dina vÃ¤nner online med MSN Messenger: http://messenger.msn.se

3 2