Gpc November 1999

gpc@gnu.de

32 participants
67 discussions

Re: Problem with strings in record imported/exported from/to modules
by Frank Heckenbach 20 Nov '99

20 Nov '99

David James wrote: > I'm having problems with a string in a record that is exported > from one module and imported into another. I *hope* I am doing > something stupid! > > The maodule (dajmod3.pas) and main program (daj3.pas) below > should illustrate the problem. > > [...] This seems to be another innstance of a known bug with string types. Thanks for the report and the test program which I'm adding to the test suite. 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

1 0

Re: Problem with strings in record imported/exported from/to modules
by david＠tcs01.demon.co.uk 20 Nov '99

20 Nov '99

In message <214E52CA.19991120140550.FOO-4F71.frank(a)g-n-u.de> Frank Heckenbach writes: > David James wrote: > > > I'm having problems with a string in a record that is exported > > from one module and imported into another. I *hope* I am doing > > something stupid! > > [...] > > This seems to be another innstance of a known bug with string types. > Thanks for the report and the test program which I'm adding to the > test suite. Any ideas on whether this is likely to be fixed soon? or whether there are any reasonable work-arounds? The application I am trying to port uses shared memory to share data between multiple processes (running for different users). The shared memory is handled as a large (>200 kbyte) Pascal record with the definition of the record and the procedures to handle the data structure being defined and exported in a module and imported by nearly all the rest of the system. This bug looks rather like a showstopper for my application. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

1 0

Re: -x lang and .PAS extension
by Frank Heckenbach 19 Nov '99

19 Nov '99

Dr A Olowofoyeku wrote: > One option for dealing with this is for gpc.exe to convert the filename > to lowercase before passing it on (only on systems such as Win32 > and Dos which do not care about the case of filenames). Another option would be to recognize '*.PAS' as Pascal files. This could be done on every system and would prevent a (small) problem when, say, unpacking a zip file created on Dos with capital file names on a Unix machine... 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: -x lang and .PAS extension
by Alexandre Oliva 19 Nov '99

19 Nov '99

On Nov 18, 1999, "Dr A Olowofoyeku" <laa12(a)keele.ac.uk> wrote: >> % gpc FOO.PAS > One option for dealing with this is for gpc.exe to convert the filename > to lowercase before passing it on I don't think this is a good idea. Case matters even on MS-DOS based systems; think of .C (implies -x c++) and .c (implies -x c). Of course, GPC could recognize .PAS and .Pas as pascal extensions, but I don't see any need for it, as long as -x pascal works. > I can send you a diff for gpc.c if you want Thanks, but it was just a week-end issue. Thanks God now I'm back to real operating systems :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){lsd.ic.unicamp.br,guarana.{org,com}} aoliva(a){acm,computer}.org oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

1 0

-x lang and .PAS extension
by Alexandre Oliva 18 Nov '99

18 Nov '99

Hi! I've recently had the unfortunate opportunity of having to invoke gpc/cygwin from a compiling/testing engine that used only MS-DOS file names (i.e., all-caps 8.3). (if anybody cares, it was University of California at San Diego's PC^2, an ACM Programming Contest management program) The problem was that, when invoking gpc, the program used the .PAS extension, which gpc didn't recognize as a valid source file, and passed it to the linker. % gpc FOO.PAS /n/gnu/gcc-2.95.2-gpc-19991030-libg++-2.8.1.3-libgcj-2.95.1/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/real-ld:FOO.PAS: file format not recognized; treating as linker script /n/gnu/gcc-2.95.2-gpc-19991030-libg++-2.8.1.3-libgcj-2.95.1/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/real-ld:FOO.PAS:1: parse error collect2: ld returned 1 exit status No problem, I though, I just need to insert `-x pascal' before the source filename, as I had done in the gcc and g++ compiling scripts. Unfortunately, it failed too: % gpc -x pascal FOO.PAS gpc: Internal GPC problem: internal option `--amtmpfile' not given I ended up having to write a shell-script that would convert the extension to lower case, so it wasn't a show-stopper. Anyway, I believe it would be nice if gpc were more gcc-like, in the sense of accepting `-x' (and any other flags gcc accepts, for that matter). Cheers, -- Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){lsd.ic.unicamp.br,guarana.{org,com}} aoliva(a){acm,computer}.org oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

2 1

Re: What do you want to have fixed/implemented in gpc-2.1?
by Frank Heckenbach 18 Nov '99

18 Nov '99

On Tue, 19 Oct 1999 Peter wrote: Hello, folks! : We are approaching a version of GPC that will (a) compile with : gcc-2.95.x and (b) only need minimal patches to the GCC backend. : : With the next version of the GNU Compiler Collection (GCC), we want : to publish the long-expected gpc-2.1 as a fully integrated frontend. : We expect this next GCC release (2.9x or 3.0) to happen within the next : two months or so. : : It is not realistic to fix all bugs and to implement all wanted features : listed in the GPC TODO list (http://fjf.gnu.de/gpc-todo_toc.html) within : this time schedule. However, most of the bugs listed there are not : really relevant to real-world praxis. So we are planning to re-sort the : TODO list and to focus on the most important bugs and feature requests. : : Please tell us which bugs and/or missing features on the TODO list, : section "Urgent", you consider the most urgent. : : And of course, your help to fix those bugs is welcome. Based of the feedback we have received, I have updated the To-Do list which will hopefully enable us now to produce a GPC 2.1 fully integrated into GCC soon. 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

3 6

Problem with strings in record imported/exported from/to modules
by david＠tcs01.demon.co.uk 17 Nov '99

17 Nov '99

I'm having problems with a string in a record that is exported from one module and imported into another. I *hope* I am doing something stupid! The maodule (dajmod3.pas) and main program (daj3.pas) below should illustrate the problem. This is on a system which identifies itself as Eridani / Red Hat Linux 6.0 (Hedwig) Kernel 2.2.5-15 on an i586 The output of gpc -v is Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 19991030, based on 2.95.2 19991024 (release) daj3.pas: ======== program daj3(output); import globaltypes in 'dajmod3.pas'; globalvars in 'dajmod3.pas'; begin shared_data.prefix:='ABCD'; if (shared_data.prefix='ABCD') then writeln('OK') else writeln('failed ',shared_data.prefix,'|'); end. dajmod3.pas: =========== module dajmod3 interface; export globaltypes =(astring); globalvars =(shared_data); TYPE astring=string(255); VAR shared_data : record prefix:astring; end; end. {of module header} module dajmod3 implementation; end. {of module implentation}

1 0

32-bit dll in GNU Pascal
by Joanna Owczarzak 17 Nov '99

17 Nov '99

Hi! I generated 32-bit dll in GNU Pascal. I used examples from GNU Pascal. My new functions (added to that example) work with *.exe program (that program was in examples too) which uses that dll. But when I'm trying to run function from my dll in my program written in Power Builder 6.0 I get message:"Error opening dll library testdll.dll for external function" Thanks in advance. Joanna

2 1

Re: native building of gpc 19991030 / gcc 2.95.2 for djgpp
by Frank Heckenbach 16 Nov '99

16 Nov '99

Maurice Lombardi wrote: > I succeeded in this native building with only one change to gpc sources due to a > DOS peculiarity. > The problem comes from the following lines contained (at two different > locations) in p/Make-lang-2.95.in > > CC="`echo $(GCC_FOR_TARGET) | sed -e 's,-B$[^/]$,-B../../\1,g' -e > 's,^$[^/][^ ]*$,../../\1,'`" \ > PC="`echo $(GPC_FOR_TARGET) | sed -e 's,-B$[^/]$,-B../../\1,g' -e > 's,^$[^/][^ ]*$,../../\1,'`" \ > > It means that to go the to rts subdirectory it prepends ../.. to G?C_FOR_TARGET > if this is a relative, not an absolute directory name. Absolute is recognized by > the first character being a slash. However in DOS an absolute pathname starts > with a drive letter c:/ In particular GCC_FOR_TARGET is in my case an absolute > pathname built through `pwd` in the top makefile, which gives the drive letter. > Solutions could be > - saying that an absolute pathname has either / as first character or : as > second. Can be garbled by a unix relative path starting with d: is this possible > in this context? This gives the attached notroot.dif > - saying that a relative pathname starts by ./ or ../ This is what occurs for > GPC_FOR_TARGET. Can be garbled if the relative path starts with an ordinary > character, is this possible in this context? This gives the attached > relative.dif. > You can incorporate one of these solutions (or a better you may imagine) into > the gpc sources, or let the djgpp maintainers to make the patch only for djgpp > (and probably other DOS systems). The last solution would mean however the need > to modify the patch for each new gpc alpha or beta distribution, so that the > first is highly preferred. As you say, it can garble unix paths starting with `d:', and also (Unix and Dos) paths consisting of only 1 letter, in particular `.'. I don't know the build process of gcc-2.95 well, so I don't know if these are possible in this context, but it's possible to modify the substitution so as to recognize 1-letter paths. The following should do the trick, but is *untested*: 's,-B$[^/]\([^:].*$\?\)$$,-B../../\1,g' (The double `$' is necessary when using it in a Makefile.) Furthermore, in order to restrict the change only to Dos systems, I suggest the following: - Make the substitution (the string above) a make variable. - Set it to the Unix substitution by using an assignment in the Makefile. - Make sure the variable is transported to sub-makes (see GPC_FLAGS_TO_PASS, GPC_INSTALL_FLAGS_TO_PASS). - When building under Dos, you can override the value on the command line (takes precedence over assignments in the Makefile). You can put this in a batch file or whatever you use to invoke make. - Alternatively, you can hack config-lang.in to add this value automatically on Dos systems, but I can't give you any advice about this, since I don't know this stuff well. > For those interested to internals of djgpp. The beta bash version enables (when > setting PATH_EXPAND=N) pwd to output /dev/c/ instead of c: to have a more > unix-like behavior, which seems to solve the above problem. Bash understands > command lines starting with /dev/c/bin/something.exe but DOS (command.com) does > not understand ! Now, as explained to me by Eli Zaretskii to solve an other > hairy problem, the djgpp port of Make sends command lines to bash only if he > thinks that the shell is involved, and to COMMAND.COM otherwise (to save > overhead). He recognizes that the shell is needed if the make line includes > something which belongs to the shell, which could be a simple ; at the end of > the makefile line. I have tried to build with PATH_EXPAND=N, it stops building > the rts at the first command line > $(GCC_FOR_TARGET) so so > When adding a ; at the end of that makefile line, make goes somewhat further, > but stops at the next occurrence, which shows that this is indeed the problem. > Now is the overhead in make large enough to warrant all these inconveniences? I'm not sure, though I would guess not, as far as GPC's build process is concerned. But if I understood you right, there's nothing we can do about it anyway, because that happens to be make's behaviour under DJGPP, doesn't it? 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

New bug in GPC 19991030 ?
by Maurice Lombardi 16 Nov '99

16 Nov '99

Hi all, While running demos and tests on the newly built GPC 1991030 / gcc-2.95.2 for djgpp I have found two occurences of the same bug. They are in test/goto4.pas and demos/parserdemo.pas Error message is (for parserdemo) f:/djgpp/tmp\ccbqrrbj.s: Assembler messages: f:/djgpp/tmp\ccbqrrbj.s:2010: Error: operands given don't match any known 386 instruction The offending instruction is movl $L177,$__p_MPNGHS eliminating the second $ to give movl $L177,__p_MPNGHS manual assembly and linking gives the correct result. Is this reproducible on other systems ? Has it something to do with new assembly errors generated by gcc-2.95 ? Hope this helps 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 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

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 November 1999