Gpc February 2005

gpc@gnu.de

26 participants
64 discussions

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 11 Feb '05

11 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > You should also try setting the C_INCLUDE_PATH environment variable. I > have this in my "~/.profile" file: > > if [ $MSYSTEM == MINGW32 ]; then > export C_INCLUDE_PATH=/mingw/include > export LIBRARY_PATH=/mingw/lib > export CC=gcc.exe > export PS1='(Mingw)$PWD $' > else > export C_INCLUDE_PATH=/usr/include:/usr/gnu/include > export LIBRARY_PATH=/usr/lib:/usr/gnu/lib > export CC=i686-pc-msys-gcc.exe > export TERM=pcansi > export PS1='(MSYS)$PWD $' > fi Thank you very much -- that did the trick! :-) `make' gets a lot farther now. I'm still running into an error, though: ../.././xgpc -B../.././ -L../.. -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/rts --unit-path=/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/p/units `cat needed-options` "binobj.pas" ld: cannot open crt2.o: No such file or directory Any ideas? Thanks, Markus ____________________________________________________________________ Valentinsgeschenke online einkaufen, WEB.Cent sammeln und bei ueber 300 Partnern ausgeben! http://webcentsammeln.web.de/?mc=021303

2 1

test-fjf949.pas - endless loop
by jan.ruzicka＠comcast.net 10 Feb '05

10 Feb '05

Hi list, the test fjf949.pas from the test suite gpc-test-20041218.tar.gz (beta) seems to be getting into a endless loop. with gdb: #0 $000025a4 in init_pascal_main_program () at fjf949.pas:4 #1 $00002614 in main (argc=1, argv=$bffff01c, envp=$bffff024) at <implicit code>:10 the line is 4 a: array [Byte] of String (2); I am running gpc on Mac OS X and it was installed through fink. There were more test failures in test suite, but this one seems to be the most critical. Jan Ruzicka PS: Disassembled portion of the code is: 0x0000253c <init_pascal_main_program+0>: mflr r0 0x00002540 <init_pascal_main_program+4>: stmw r30,-8(r1) 0x00002544 <init_pascal_main_program+8>: stw r0,8(r1) 0x00002548 <init_pascal_main_program+12>: stwu r1,-80(r1) 0x0000254c <init_pascal_main_program+16>: mr r30,r1 0x00002550 <init_pascal_main_program+20>: bcl- 20,4*cr7+so,0x2554 <init_pascal_main_program+24> 0x00002554 <init_pascal_main_program+24>: mflr r31 0x00002558 <init_pascal_main_program+28>: addis r9,r31,4 0x0000255c <init_pascal_main_program+32>: addi r9,r9,-22972 0x00002560 <init_pascal_main_program+36>: lbz r0,0(r9) 0x00002564 <init_pascal_main_program+40>: clrlwi r0,r0,24 0x00002568 <init_pascal_main_program+44>: cmpwi r0,0 0x0000256c <init_pascal_main_program+48>: bne- 0x25b8 <init_pascal_main_program+124> 0x00002570 <init_pascal_main_program+52>: addis r9,r31,4 0x00002574 <init_pascal_main_program+56>: addi r9,r9,-22972 0x00002578 <init_pascal_main_program+60>: li r0,1 0x0000257c <init_pascal_main_program+64>: stb r0,0(r9) 0x00002580 <init_pascal_main_program+68>: li r0,0 0x00002584 <init_pascal_main_program+72>: stb r0,56(r30) ;-------------------- here starts the loop 0x00002588 <init_pascal_main_program+76>: addis r9,r31,4 0x0000258c <init_pascal_main_program+80>: addi r9,r9,-26044 0x00002590 <init_pascal_main_program+84>: lbz r0,56(r30) 0x00002594 <init_pascal_main_program+88>: clrlwi r0,r0,24 0x00002598 <init_pascal_main_program+92>: mulli r0,r0,12 0x0000259c <init_pascal_main_program+96>: add r9,r0,r9 0x000025a0 <init_pascal_main_program+100>: li r0,2 0x000025a4 <init_pascal_main_program+104>: stw r0,0(r9) 0x000025a8 <init_pascal_main_program+108>: lbz r9,56(r30) 0x000025ac <init_pascal_main_program+112>: addi r0,r9,1 0x000025b0 <init_pascal_main_program+116>: stb r0,56(r30) 0x000025b4 <init_pascal_main_program+120>: b 0x2588 <init_pascal_main_program+76> ;-------------------- here ends the loop 0x000025b8 <init_pascal_main_program+124>: lwz r1,0(r1) 0x000025bc <init_pascal_main_program+128>: lwz r0,8(r1) 0x000025c0 <init_pascal_main_program+132>: mtlr r0 0x000025c4 <init_pascal_main_program+136>: lmw r30,-8(r1) 0x000025c8 <init_pascal_main_program+140>: blr

10 45

gpc & gcc-3.3.5
by Russell Whitaker 10 Feb '05

10 Feb '05

Hi Findly got around to compiling latest gpc: Using patch for 3.3.4, emit-rtl.c hunk #1 failed. Comiled using make bootstrap. test results: Unsuported: arerextest.pas # tests 4112 # expected pass 4111 # unsupported 1 Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/specs Configured with: ../gcc-3.3.5/configure --enable-languages=c,c++,pascal Thread model: posix gpc version 20041218, based on gcc-3.3.5 Thought you'd like to see some good news for a change. Russ

3 2

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 10 Feb '05

10 Feb '05

Prof A Olowofoyeku (The African Chief) wrote: > I have built gpc-20041218 successfully under Mingw with no > problem. Perhaps this is backend (or bison) thing? I tend to build > GPC/Mingw on a gcc-3.2.3 backend. Okay, I changed to gcc-3.2.3 now, and I'm getting the error: In file included from C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/include/limits.h:132, from C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/include/syslimits.h:7, from C:/msys/1.0/home/gerwinsk/mysoftware/gcc-3.2.3/gcc/include/limits.h:11, from tsystem.h:84, from libgcc2.c:37: include/limits.h:132:75: no include path in which to find limits.h In file included from libgcc2.c:37: tsystem.h:87:18: time.h: No such file or directory Since time.h definitely exists in C:\MinGW\include, I don't see whatever could cause that error. Any ideas? Thanks, Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

2 1

Re: Cannot compile gpc-20041218 on
by Markus Gerwinski 10 Feb '05

10 Feb '05

Frank Heckenbach wrote: > Prof A Olowofoyeku (The African Chief) wrote: > > No idea. I have built gpc-20041218 successfully under Mingw with no > > problem. Perhaps this is backend (or bison) thing? I tend to build > > GPC/Mingw on a gcc-3.2.3 backend. > Which is currently recommended because of the system conditional > issues, so you (Markus) might prefer this as well. Still you might > want to report the problem, so it'll hopefully be fixed in future > GCC releases. Okay, I changed to gcc-3.2.3 (see parallel mail), and I'll report it to the GCC team. Thanks, Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

1 0

Re: Bug? Delphi-style result variable
by Markus Gerwinski 10 Feb '05

10 Feb '05

Adriaan van Os wrote: > I agree with Frank that "Result" should behave as in Delphi and it does > consistently behave there the way it was designed to, As for the Delphi-style implicitly declared `Result', I completely agree with you and Frank. But we also have the ISO10206 feature of an explicitly declared result variable with a freely chosen name. _And_ until gpc-20041218, we were able to use it in a way that was IMO significantly better than defined by the standard. I think we should get back there. > although the > example shows that the whole idea of an "unnamed" Result identifier is > in itself a poorly designed language feature. Obviously, not much > thought went into it. Indeed. I suppose this is the reason -- or one reason -- why Delphi programmers usually try to avoid local sub-routines. ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

1 0

Re: Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 10 Feb '05

10 Feb '05

I wrote: > In file included from intl/libgnuintl.h:22, > from intl.h:31, > from c-parse.y:40: > C:/MinGW/include/locale.h:87: parse error before "const" > > Any idea what could be wrong here? I meanwhile found out a really strange thing. The line denoted by the error message reads: _CRTIMP char* __cdecl setlocale (int, const char*); If I rename `setlocale' into e.g. `setlocale_foo', this header is compiled without complaint. Could that be due to a difference between gcc 3.3.3 (which I'm basing my gpc-build on) and the gcc 3.2.3 that came with my MinGW? Yours, Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

2 1

Bug? Delphi-style result variable
by Markus Gerwinski 10 Feb '05

10 Feb '05

Hi Folks, compiling the program Program Test; var x: integer; Function foo: integer; Procedure bar; begin (* bar *) result:= 7; end (* bar *); begin (* foo *) bar; end (* foo *); begin x:= foo; end. yields an error message test.pas: In procedure `bar': test.pas:14: error: invalid access to `Result' test.pas: In function `foo': test.pas:20: error: result of function not assigned Bug or feature? Yours, Markus

5 5

Cannot compile gpc-20041218 on MinGW/Windows 2000
by Markus Gerwinski 09 Feb '05

09 Feb '05

Hi Folks! When trying to compile gpc-20041218 on a system with - Windows 2000 ver. 5.00.2195 - Service Pack 4 - MinGW 3.1.0 - MSys 1.0.9 I get the following error message during `make`: gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -DCYGWIN_CROSS_DIR=\"/usr/local/i686-pc-mingw32\" -I. -I. -I. -I./. -I./config -I./../include \ -c ./c-parse.c -o c-parse.o make[1]: Leaving directory `/home/gerwinsk/mysoftware/gcc-3.3.3/gcc' In file included from intl/libgnuintl.h:22, from intl.h:31, from c-parse.y:40: C:/MinGW/include/locale.h:87: parse error before "const" Any idea what could be wrong here? Thanks in advance, Markus ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

2 1

Re: Bug? Delphi-style result variable
by Markus Gerwinski 09 Feb '05

09 Feb '05

CBFalconer wrote: > Markus Gerwinski wrote: > > Program Test; > > > > var > > x: integer; > > > > Function foo: integer; > > > > Procedure bar; > > begin (* bar *) > > result:= 7; > > end (* bar *); > > > > begin (* foo *) > > bar; > > end (* foo *); > > > > begin > > x:= foo; > > end. > > > > yields an error message > > > > test.pas: In procedure `bar': > > test.pas:14: error: invalid access to `Result' > > test.pas: In function `foo': > > test.pas:20: error: result of function not assigned > > > > Bug or feature? > > Feature. The program is flat out wrong No, it's not. Try compiling ... Function foo: integer; begin (* foo *) result:= 7; end (* foo *); ... This works. It is Delphi standard, supported by GPC since 2003. Only if you move `result ' into a local subroutine, you get an error. ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

1 0

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 February 2005