Gpc July 1998

gpc@gnu.de

19 participants
25 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

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 July 1998