Gpc

gpc@gnu.de

5400 discussions

Download the doc...
by Spidey 04 Jul '98

04 Jul '98

Hi! I'm sorry if I fill you're mailboxes for a stupid question but, is it possible to download the doc in one big file instead of borwsing it always online? Thanks! -- Spidey ________________________________________ | Imagine a good steak (8 oz)... | | | | Then imagine 45 to 50 persons sitting | | around you with there plate empty. | | | | Then remember that you could replace | | your meat by enough cereal to feed all | | these 50 persons... | | | | Think of it twice when you'll feed your| | belly with sick meat. | | | | Source: Small diet for a small planet, | | 1980, Frances Moore. | \----------------------------------------/

2 1

__OS_DOS__ symbol
by Frank Heckenbach 04 Jul '98

04 Jul '98

Hi, all! While Peter, The Chief and I were discussing some issues about GPC on Dos like systems, we found that it seems like a good idea to let GPC pre-define the symbol __OS_DOS__ on all such platforms automatically. This would make it easy to do an {$ifdef __OS_DOS__} around things that are different on these systems, e.g. the different directory separators ('\', not '/') and path separators (';', not ':'), or the different way of printing (writing to a priter device like 'lpt1', not calling a printer spooler like 'lpr'). Up to now, one has to use a series of ifdefs which is not very convenient, error-prone, and a maintenance problem when new such platforms are "created". A predefined __OS_DOS__ would reduce this maintenance to one place within the compiler. So, what I'm asking you is (a) if anyone would see any (hidden) problems with doing so -- perhaps an already existing different use of the symbol __OS_DOS__ --, and (b) which platforms this should be defined on exactly: I looked at the GCC sources to find out which platforms use ';' as a path separator, these are: ./config/i386/xm-dos.h ./config/i386/xm-go32.h ./config/i386/xm-mingw32.h ./config/i386/xm-os2.h ./config/i386/xm-vsta.h ./config/winnt/xm-winnt.h Searching for '\' as a dir separator yields: ./config/i386/xm-cygwin32.h ./config/i386/xm-dos.h ./config/i386/xm-mingw32.h ./config/i386/xm-os2.h ./config/winnt/xm-winnt.h I'm a bit surprised that the lists are different, but that's probably by mistake, e.g. the go32 (i.e. DJGPP Dos extender) platform surely has a '\' dir separator. (I'm aware of the fact that most, if not all, DJGPP routines do an automatic translation from '/' to '\'; that's not the issue here.) So, I hope it's correct to assume that the union of both sets is a complete list of (currently supported) Dos-like systems: ./config/i386/xm-dos.h ./config/i386/xm-go32.h ./config/i386/xm-mingw32.h ./config/i386/xm-cygwin32.h ./config/i386/xm-os2.h ./config/i386/xm-vsta.h ./config/winnt/xm-winnt.h Any comments? BTW, what's vsta? Regards, Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

GPC troubles on AIX (cont'd)
by Nick Cremelie 03 Jul '98

03 Jul '98

Hi again, As you will recall, I had problems with gpc on AIX when opening files. I made a little change in rts-file.c: I replaced line 370: _p_generic (701); /* FDR not initialized */ with _p_initfdr(File,filename,8,0xf); This means: if m_SIZ(File) == 0 (indicating that _p_initfdr was not called), I call it with a standard buffersize and flags). This enables me indeed to open files for reading and writing! However, I have no clue about the impact of this change. But then we noticed something else: reading a string (string[255]) with readln (from file or stdin) always returned an empty string, although eoln and eof are set appropriately (so it is actually reading the file!). We checked and noticed that the argument maxlen to _p_reads in rts-rdsub.c is always zero. Question: would this be because va_arg (which gets maxlen from a variable argument list) doesn't work probably, or because the variable argument list is not set properly when calling _p_read in rts-read.c ? Anyone any idea about what's going wrong?? If I hard code maxlen=256 then everything runs (on a simple test at least; again, the impact of this setting is not clear and it may be a dangerous setting!) We've come that far now, I hope we can eventually get gpc running on our aix boxes...... Nick

1 0

Re: gpc on AIX: troubles!
by Frank Heckenbach 03 Jul '98

03 Jul '98

Klaus Espenlaub wrote: > > To continue: I resumed gmake and > > now the rts part of p has been built! I got a few errors which did not > > cause s stop of gmake, I'm not sure if they are a problem (should I > > worry about them?): > > I would worry about them. But it's possible that they go away after you > installed gpc and re-do the gpc compilation. You can check if something is > wrong with the gpc driver program if you start it with option -v for the > program issuing the errors. There should be either a "-D__BYTES_BIG_ENDIAN__" > or a "-D__BYTES_LITTLE_ENDIAN__" in the command line for the preprocessor. > Similarly for BITS and WORD. > > I wouldn't trust gpc until there are no #error lines left. True. When these things are not defined, some of the RTS will not work realiably. I think the problems are due to the fact that a previously installed GPC was used to compile the RTS. I think (hope) that this will be fixed in the next version. > Part of the > problem seems to be that the automake feature doesn't pass the error code > of a failed sub-compile command back to the calling make program. > > Peter: can you put this on the automake todo list? It is already on the To-Do list, namely under "Fixed Bugs". :-) IOW, it will work this way in the next version. Nick Cremelie wrote: > ...but: txtfile and binfile both crash with: > > ?GPC runtime error: (gpc-rts) _p_initfdr() has not been called for file (#701) > > Now what's that??????? > > I suppose it has something to do with the "bind" functionality in gpc > for binding an external file to a variable??? Not really with bindings, but anyway: There's a known bug "On IRIX work stations, _p_initfdr() must be called manually" on the To-Do list. So, I'm adding AIX there. I don't know anything about these architectures, but I agree that fixing this would be a good idea... :-/ Frank -- Frank Heckenbach, frank(a)pascal.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Re: gpc on AIX: troubles!
by Klaus Espenlaub 02 Jul '98

02 Jul '98

Nick Cremelie wrote: > And this is what gdb shows me (I think it's pretty much the same) > ---begin--- > GDB 4.16 (rs6000-ibm-aix4), Copyright 1996 Free Software Foundation, Inc... > Core was generated by `gpc1'. > Program terminated with signal 6, IOT/Abort trap. > #0 0xd0077eac in raise () > (gdb) bt > #0 0xd0077eac in raise () > #1 0xd0019a74 in abort () > #2 0x1004f258 in output_epilog (file=0xf013f4c0, size=-1) at rs6000.c:4027 > #3 0x10142664 in final_end_function (first=0x0, file=0xf013f4c0, optimize=-1) > at final.c:1151 > #4 0x10005548 in rest_of_compilation (decl=0x20080a2c) at toplev.c:3647 > #5 0x100b8ce4 in finish_function (nested=0) at gpc-decl.c:8734 > #6 0x1018dbc0 in yyparse () at parse.y:6628 > #7 0x10003084 in compile_file (name=0x0) at toplev.c:2494 > #8 0x10006624 in main (argc=15, argv=0x2ff227cc, envp=0xffffffff) > at toplev.c:4377 > #9 0x100001f4 in __start () > ---end--- > > Apparently there's something not right in rs6000.c. What do you think? I haven't read the previous stack dump closely enough, I think. And I think your analysis is correct. The code around line 4027 in rs6000.c looks like this: /* Language type. Unfortunately, there doesn't seem to be any official way to get this info, so we use language_string. C is 0. C++ is 9. No number defined for Obj-C, so use the value for C for now. */ if (! strcmp (language_string, "GNU C") || ! strcmp (language_string, "GNU Obj-C")) i = 0; else if (! strcmp (language_string, "GNU F77")) i = 1; else if (! strcmp (language_string, "GNU Ada")) i = 3; else if (! strcmp (language_string, "GNU Pascal")) i = 2; else if (! strcmp (language_string, "GNU C++")) i = 9; else abort (); fprintf (file, "%d,", i); So here you go, abort! Who messed around with the language_string recently? This should be rather trivial to fix for Peter. The actual bug is in p/parse.c and is even documented. Just take the language_string hack for _IBMR2 out and your compiler should work. The "bug" is around line 360 in p/parse.c. Of course, to fix this, we need to change p/parse.y, being the source for parse.c. Nick, do you have bison installed on your machine? If not, you have to change p/parse.c by hand for a quick fix, and don't apply the p/parse.y patch below. oops, just noticed that I forgot to add useful options to diff. I hope that the following works for you, Peter. If not, drop me a note. I got to run now, and probably won't be back till 12:30 CEST. Klaus 115,123d114 < * < * rs6000.c calls abort() if this is "GNU Pascal" :-) < * < * I have modified rs6000.c. Since "Pascal" is a person's name < * like "Ada" it has the right to be written in the same manner. :-) < * - PG < * < * Sigh, I don't want to change rs6000.c; I will inform Kenner to change < * it in the next release. 125,127d115 < #ifdef _IBMR2 < char *language_string = "GNU PASCAL"; < #else 129d116 < #endif /* Sigh */

2 3

unsubscribe
by jgouv＠pop03.ca.us.ibm.net 30 Jun '98

30 Jun '98

unsubscribe

1 0

unsubscribe
by csap00jp 28 Jun '98

28 Jun '98

Unsubscribe me please

1 0

SizeOf bug
by Maurice Lombardi 27 Jun '98

27 Jun '98

Hi all, When looking to a redent discussion on the fpk-mailing list with this subject, I have tried to make the same tests on gpc. I have found a bug in gpc which has nothing to do with the subject of the discussion. Working on plain dos djgpp with gpc-980511. The program is: program size_bug; type Time = object h,m,s:byte; constructor init; destructor done; virtual; end; var OT:Time; constructor Time.init; begin end; destructor Time.done; begin end; begin OT.init; writeln(SizeOf(OT)); end. when compiling it says Abort! with the message: Reading specs from f:/djgpp/lib/gcc-lib/djgpp/2.81/specs gpc driver version 2.81 executing gpc version 2.8.1 f:/djgpp/lib/gcc-lib/djgpp/2.81/gpc-cpp.exe -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__DJGPP_MINOR__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 size_bug.pas G:/ccba5tpj GNU CPP version 2.81 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: f:/djgpp/contrib/grx23/include /usr/local/include JDIR/djgpp/include JDIR/lib/gcc-lib/djgpp/2.81/include $DJDIR/include End of search list. f:/djgpp/lib/gcc-lib/djgpp/2.81/gpc1.exe G:/ccba5tpj -quiet -dumpbase size_bug.pas -version -famtmpfile=size_bug.gpc -o G:/ccca5tpj GNU Pascal version 2.81 (djgpp) compiled by GNU C version 2.8.1. size_bug.pas: In function `Time_Init': size_bug.pas:13: `with' element is of wrong type Abort! It is the identifier Time which causes the problem. All becomes correct if it is replaced everywhere by Tim. As far as I know time is not a reserved word, and anyway you have allowed to redefine nearly all identifiers. ??? (otherwise gpc has the correct behaviour with respect to the purpose of the test: it bangs under CWSDPMI for dereferencing uninitialized pointer if OT is not initialized before computing SizeOf(OT), and gives a nonsense result when working in a WIN 3.11 DOS box which does not catch this illegal memory addressing, but this behavior is different from BP) -- 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

1 0

gpc for aix
by Nick Cremelie 25 Jun '98

25 Jun '98

Hi all, After a few days work, I finally got gpc compiled on a powerpc based RS/6000 with AIX4.1.4. I thought I'd first try it with a simple program called littletest.pas: program littletest; var i,j: integer; begin i:=1; j:=2; writeln('Sum is ',i+j); end. Well, this is the result: $ gpc --verbose littletest.pas Reading specs from /usr/local/lib/gcc-lib/powerpc-ibm-aix4.1.4.0/2.7.2.1/specs gpc version 971001(2.7.2.1) /usr/local/lib/gcc-lib/powerpc-ibm-aix4.1.4.0/2.7.2.1/gpc-cpp -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=7 -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -Asystem(unix) -Asystem(aix) -Acpu(powerpc) -Amachine(powerpc) -D__CHAR_UNSIGNED__ -D_ARCH_PPC littetest.pas /tmp/ccQLxsya.i GNU CPP version 971001(2.7.2.1) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/powerpc-ibm-aix4.1.4.0/include /usr/local/lib/gcc-lib/powerpc-ibm-aix4.1.4.0/2.7.2.1/include /usr/include End of search list. /usr/local/lib/gcc-lib/powerpc-ibm-aix4.1.4.0/2.7.2.1/gpc1 /tmp/ccQLxsya.i -quiet -dumpbase littletest.pas -version -famtmpfile=littletest.gpc -o /tmp/ccQLxsya.s GNU PASCAL version 971001(2.7.2.1) compiled by GNU C version 2.7.2.1. gpc: Internal compiler error: program gpc1 got fatal signal 6 Needless to say, I get a beautiful coredump out of that which my debugger dbx can't read very well, but anyways this is the result of a "where": raise(??) at 0xd0077eac abort() at 0xd0019a70 emit_stack_save(??, ??, ??), line 887 in "explow.c" init_main_program_rtx(), line 1588 in "util.c" yyparse(), line 545 in "parse.y" compile_file(name = "/tmp/ccQLxsya.i")line 2232 in "toplev.c" main(argc = 9, argv = 0x2ff22b94, envp = 0xffffffff), line 3931 in "toplev.c" If anyone would have any idea on how to solve this, it would be greatly appreciated. Please reply by mail as I am not yet subscribed to this mailing list! Nick Cremelie

2 1

ld problem under RH 5.0 with gpc rpm
by dtroeger＠ix.netcom.com 25 Jun '98

25 Jun '98

I have installed (Redhat 5.0) gpc-2.0-1.i386.rpm, but running it on any pascal program produces an error: ld: cannot open crtbegin.o: No such file or directory (If I use gpc -S hello.pas, I _do_ get successful compilation; the problems clearly arise later.) Can anyone point me in the right direction on this? Specifically, are there configuration steps which must be taken _after_ rpm has completed its installation? Thanks, Doug Troeger

2 1

Jump to page:

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