Gpc July 2000

gpc@gnu.de

35 participants
109 discussions

Re: Compiling GCC under Irix 6.5
by Frank Heckenbach 25 Jul '00

25 Jul '00

Jean-Marc Ottorini wrote: > I am still trying to build the gpc-20000719 / gcc-2.95.2 suite on > top of Irix 6.5. > > Following Frank Heckenbach advice to replace BYTES_BIG_ENDIAN by 0 > in line 64 of stor-layout.c, the compilation process has progressed > but is again stopped many steps further by the following error: > > -- > > /usr/people/ottorini/pascal/gcc-2.95.2/gcc/p/rts/string.pas:224: > Internal compiler error in `add_bound_info', at > gcc-2.95.2/gcc/dwarf2out.c:7376 > > Please submit a full bug report. > > See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. > gmake[2]: *** [string.o] Error 1 > gmake[2]: Leaving directory `/usr/people/ottorini/pascal/gpc-build/gcc/p/rts' > gmake[1]: *** [pascal.rts] Error 2 > gmake[1]: Leaving directory `/usr/people/ottorini/pascal/gpc-build/gcc' > gmake: *** [all-gcc] Error 2 > ---- > > > Function `Memcompcase' reads: > > function MemCompCase (const s1, s2; Size : SizeType) : Boolean; > var > i : Integer; > a1 : array [1 .. Size] of Char absolute s1; > a2 : array [1 .. Size] of Char absolute s2; > begin > for i := 1 to Size do > if (a1 [i] <> a2 [i]) and (LoCase (a1 [i]) <> LoCase (a2 [i])) then > return False; > MemCompCase := True > end; > > > Personnally, I cannot see what is harmful here (the problem persists > after consistently replacing BYTES_BIG_ENDIAN by 0 in dwarf2out.c) I don't think you should've done that. What I meant was that the initialization of the variable set_words_big_endian doesn't matter, but the value of BYTES_BIG_ENDIAN elsewhere does matter, and might explain the problem described. Since it's not used as an initialization in dwarf2out.c, I don't suppose there are compiling problems when leaving BYTES_BIG_ENDIAN there. It's just the one place in stor-layout.c where it should be changed. 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

Which gpc version
by Ernst-Ludwig Bohnen 25 Jul '00

25 Jul '00

Hi, on ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/ I found several brand new gpc versions, last one is 20000724. Questions to the gpc designers: 1) Which version is recommended to work with SuSe 6.x ? 2) Which version is planned to come with SuSe 7.0 on CD? Thank you in advance Ernst-Ludwig Bohnen

2 1

Re: Compiling GCC under Irix 6.5
by Jean-Marc Ottorini 25 Jul '00

25 Jul '00

I am still trying to build the gpc-20000719 / gcc-2.95.2 suite on top of Irix 6.5. Following Frank Heckenbach advice to replace BYTES_BIG_ENDIAN by 0 in line 64 of stor-layout.c, the compilation process has progressed but is again stopped many steps further by the following error: --- gmake[2]: Entering directory `/usr/people/ottorini/pascal/gpc-build/gcc/p/rts' ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith \ -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations \ -g -O2 -DRTS_RELEASE_STRING="'`cat \ /usr/people/ottorini/pascal/gcc-2.95.2/gcc/p/rts/rts-version`'" \ --unit-path=/usr/people/ottorini/pascal/gcc-2.95.2/gcc/p/rts \ --automake /usr/people/ottorini/pascal/gcc-2.95.2/gcc/p/rts/string.pas /usr/people/ottorini/pascal/gcc-2.95.2/gcc/p/rts/string.pas: In function `Memcompcase': /usr/people/ottorini/pascal/gcc-2.95.2/gcc/p/rts/string.pas:224: Internal compiler error in `add_bound_info', at gcc-2.95.2/gcc/dwarf2out.c:7376 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. gmake[2]: *** [string.o] Error 1 gmake[2]: Leaving directory `/usr/people/ottorini/pascal/gpc-build/gcc/p/rts' gmake[1]: *** [pascal.rts] Error 2 gmake[1]: Leaving directory `/usr/people/ottorini/pascal/gpc-build/gcc' gmake: *** [all-gcc] Error 2 ---- Function `Memcompcase' reads: function MemCompCase (const s1, s2; Size : SizeType) : Boolean; var i : Integer; a1 : array [1 .. Size] of Char absolute s1; a2 : array [1 .. Size] of Char absolute s2; begin for i := 1 to Size do if (a1 [i] <> a2 [i]) and (LoCase (a1 [i]) <> LoCase (a2 [i])) then return False; MemCompCase := True end; Personnally, I cannot see what is harmful here (the problem persists after consistently replacing BYTES_BIG_ENDIAN by 0 in dwarf2out.c) I would be grateful to know whether someone has faced this this problem and has got a workaround. Jean-Marc _________________________________________________________________ | Jean-Marc Ottorini (MailTo://ottorini@nancy.inra.fr) | | Institut National de la Recherche Agronomique - Centre de Nancy | | 54280 Champenoux | | FRANCE | | tel. [+33] 03 83 39 40 46 | | fax 03 83 39 40 34 | |_________________________________________________________________|

1 0

Bug-report
by Christian Neumann 25 Jul '00

25 Jul '00

Hi everyone. I'm running Linux 2.2.13 out of the Suse distribution. After recompilng the gcc with pascal options (gcc.rpm.source packages of the 6.4 dist). compiler version is 2.95.2 19991024 (release). The following file produce errors in the provided test-suite: TEST constovfl.pas: failed: failed: 0 TEST fjf149.pas: Failed: 64 TEST fjf83.pas: failed: Failed /tmp/ccqm2gyD.s: Assembler messages: /tmp/ccqm2gyD.s:110: Error: suffix or operands invalid for `mov' TEST goto4.pas: failed I hope this helps. Otherwise the compiler works just fine. sincerly Christian Neumann christian.neuann(a)nrw-online.de ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

1 0

build problem with cygwin and gpc20000724 and before
by Joachim Falk 25 Jul '00

25 Jul '00

Ah yes i have forgotten to report another problem with rts.{h,c} in rts.h if HAVE_STRSIGNAL is defined it does declare the function char *strsignal( int ) witch conflicts with the strsignal definition in the cygwin include file string.h const char *_EXFUN(strsignal, (int __signo)); => compiler abort If we have defined HAVE_STRSIGNAL does it mean we have a strsignal function defined in string.h or does it only mean the lib has one ? In any case you can put a #ifndef __CYGWIN__ around the strsignal definition in rts.h

2 1

Re: build problem with cygwin and gpc20000724 and before
by Frank Heckenbach 25 Jul '00

25 Jul '00

Joachim Falk wrote: > Ah yes i have forgotten to report another problem with rts.{h,c} > in rts.h if HAVE_STRSIGNAL is defined it does declare > the function char *strsignal( int ) witch conflicts with > the strsignal definition in the cygwin include file string.h > const char *_EXFUN(strsignal, (int __signo)); => compiler abort > If we have defined HAVE_STRSIGNAL does it mean we have a > strsignal function defined in string.h or does it only mean > the lib has one ? > In any case you can put a #ifndef __CYGWIN__ around the > strsignal definition in rts.h We don't use system checks because they are unportable, but rather autoconf checks for certain properties. I will add checks whether strsignal() (and a few other functions and variables) are declared. You might want to test if it works with them. 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: Compiling GCC under Irix 6.5
by Frank Heckenbach 24 Jul '00

24 Jul '00

Jean-Marc Ottorini wrote: > While trying to build the gpc-20000719 / gcc-2.95.2 suite on top of > Irix 6.5 (), the following command is issued by gmake: > > gcc -c -DIN_GCC -DGPC -g -O2 \ > -I. -I.. \ > -I../../../gcc-2.95.2/gcc/p \ > -I../../../gcc-2.95.2/gcc/p/.. \ > -I../../../gcc-2.95.2/gcc/p/../config \ > -I../../../gcc-2.95.2/gcc/p/../../include \ > ../../../gcc-2.95.2/gcc/p/../stor-layout.c > > > This command results in a compiling error: > > ../../../gcc-2.95.2/gcc/p/../stor-layout.c:64: initializer element is > not constant > > > Indeed, line 64 of stor-layout.c reads: > > int set_words_big_endian = BYTES_BIG_ENDIAN; /* @@@ Needn't be a constant! */ > > > Where is the truth ? I've talked with Peter about this problem, and it turned out that this variable is not really used currently. Until he'll fix the problem, you can just replace BYTES_BIG_ENDIAN by 0. 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: p/scripts/find-sed problem with djgpp and gpc20000723
by Frank Heckenbach 24 Jul '00

24 Jul '00

Maurice Lombardi wrote: > > I think the default DJGPP installation creates this directory > > because DJGPP's goal is to be as Unix compatible as possible, and > > the typical Unix script may assume /tmp to exist. > > Unfortunately no. But I had previously to compile a unix package which needed /tmp. > So I created it and never removed it afterwards. Oh right, what I meant was $DJDIR/tmp, not /tmp... 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: p/scripts/find-sed with djgpp; cygwin rts.c; problem building rts gpc
by Frank Heckenbach 24 Jul '00

24 Jul '00

Joachim Falk wrote: > the find-sed script assumes that the temp dir is /tmp witch isnt always > true under djgpp. > instead you should use the TMPDIR var witch is set in djgpp.env I'll change it (also in two other scripts, but those are not normally needed for building GPC). If TMPDIR isn't set, they'll default to /tmp -- or should they rather use /var/tmp? > The Problem is that the latest version of cygwin downloaded just 3 days > ago doesnt have MAP_FAILED in /usr/include/sys/mman.h > this prevents rts.c to compile > I dont know if this is a bug in the cygwin header files or in > gpc I don't know either, but it seems easy enough to change in GPC. Just to be sure: It does have mmap, but not MAP_FAILED? What does mmap return on failure? If it's either NULL or ((void *) -1), it should be alright after my change. If it's something else, let me know. > The problem is the `echo $CC | sed 's/gcc/gpc/'` in p/rts/Makefile.in > if $CC contains gcc in more than one position > patched attached > I havent tested this on the djgpp system but it schould work > i have test dos style path with the sed script and it works Good point, I'll apply your patch. (BTW, inside `[]' you don't need to quote the backslash. A single `\' is enough, but of course, `\\' also works, it's just redundant.) Thanks for the reports and fixes. 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: p/scripts/find-sed problem with djgpp and gpc20000723
by Frank Heckenbach 24 Jul '00

24 Jul '00

Maurice Lombardi wrote: > Joachim Falk a Ã©crit : > > > > the find-sed script assumes that the temp dir is /tmp witch isnt always > > true under djgpp. > > instead you should use the TMPDIR var witch is set in djgpp.env > > Indeed I did not notice this because y have a /tmp dir in my tree I think the default DJGPP installation creates this directory because DJGPP's goal is to be as Unix compatible as possible, and the typical Unix script may assume /tmp to exist. But of course, it's safer to check $TMPDIR, and as I said, the GPC scripts do so now (and the GPC function GetTempDirectory has always done so as well). 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

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 2000