Gpc

gpc@gnu.de

5400 discussions

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

Re: Bug in function parsing?
by Markus Gerwinski 08 Feb '05

08 Feb '05

Hi Folks! Frank Heckenbach wrote: > Markus Gerwinski wrote: > > This results in a 'Header does not match previous definition' for function Bar. > Yes, according to the standard (*), the result variable must be > present in the original declaration as well. GPC didn't check this > before, but does now. > > (*) This is only stated in the Object-Oriented Extensions, 6.7 (d): > > : [...] and if one function definition contains a result variable > : specification, then the other also has a result variable > : specification of the same spelling. What's the point in declaring a local result variable in the unit interface?!? I mean, the code Function bar = result: integer; begin (* bar *) ... end (* bar *); is, in fact, nothing but an abbreviated way to write: Function bar: integer; var result: integer; begin (* bar *) ... bar:= result; end (* bar *); So `result` is actually a local variable, and no module using the unit will ever be able to access it. Why put it into the interface? I'd definitely feel more comfortable if we could skip the standard here and permit the other syntax again... Regards, Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

3 3

not 0
by Adriaan van Os 08 Feb '05

08 Feb '05

GPC accepts: var i: integer value not 0; but it doesn't accept: var w: word value not 0; not.pas:4: error: constant out of range not.pas:4: error: initial value is of wrong type so, the workaround is: var w: word value not word( 0); At first sight, this looks a bit clumsy (but at second sight it may not). It gives rise to general questions about the type of constants in Pascal, e.g. * is there a difference between $FF.. and $0FF.. ? * is $FF.. signed or not ? Any comments ? Regards, Adriaan van Os

5 18

Wanted: Maintainer for my Units and Documentation
by Eike Lange 08 Feb '05

08 Feb '05

Hi Folks! I cannot maintain my units and documentation due to some personal activities any longer. It would be nice, if someone could overtake my contributions, which are * unit for mysql version 4 * unit for mysql version 3 * unit which interfaces Xlib.h * unit for zlib * PostgreSQL unit * a simple SDL unit * Program, which extracts pascal-strings and writes a ".po"-file for the use of internationalization (pas2po). (See http://www.gnu-pascal.de/contrib/eike/ ) * German documentation about GNU-Pascal (See http://www.gnu-pascal.de/~eike/ ) Eike

1 0

Re: Bug in function parsing?
by Markus Gerwinski 08 Feb '05

08 Feb '05

CBFalconer wrote: > My own attitude is that the use of result is pointless in the first > place. It gains nothing that I can see over the standard method > "bar := ...". In fact I like to code many things as: > > FUNCTION foo : T > > VAR > anotherTvalue : T > > BEGIN > foo := someTvalue; (* default *) > .... > IF whatever THEN foo := anotherTvalue; > .... > END; > > Please show me something that the traditional method can't do. Function getIndexOf ( aData: tDataType ) = result: integer; var data: tDataType; begin (* getIndexOf *) result:= 0; data:= someFirstDataInForExampleALinkedList; while ( data <> aData ) and ( data <> nil ) do begin data:= getNextData ( data ); inc ( result ); (* ... and this is what you definitely need a result variable for. *) end (* while *); end (* getIndexOf *); Of course, you also can do so by explicitly declaring `result`as a local variable and assigning it to getIndexOf in the end, but personally, I find the above way far more elegant. Frank: Would it cause much effort/pain to make the old syntax possible again? ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

2 1

Bug in function parsing?
by Markus Gerwinski 07 Feb '05

07 Feb '05

Hi Folks! Seemingly the following code snippet cannot be compiled with the current GPC version: Unit Foo; Interface Function Bar: integer; Implementation Function Bar = result: integer; begin (* Bar *) result:= 2; end (* Bar *); end. This results in a 'Header does not match previous definition' for function Bar. Yours, Markus

2 1

segmentation fault
by willett 07 Feb '05

07 Feb '05

program file attached is a program missing a "}" which should get compilation error, but which compiles without errors and when run, gets a "Segmentation fault" and quits. tested on GNU Pascal version 20030830, based on gcc-3.3.2 Willett Kempton

7 19

64 bit GPC on AIX
by Peter Keenan 06 Feb '05

06 Feb '05

I have built GPC 20041218 on GCC 3.3.4 on AIX 5.2, and thought it might be useful to document my experiences. I wanted to have the capacity to build 64 bit programs, however only 32 bit libraries are installed for GPC. Following my earlier post http://www.gnu- pascal.de/crystal/gpc/en/mail11115.html Waldek suggested trying build a 64 bit version of GCC including GPC. However having tried various strategies I was not successful in building a 64 bit only version of any version of GCC, even without GPC. So I tried to just build a 64 bit libgpc.a. I eventually achieved this export OBJECT_MODE = 64 export CFLAGS=-maix64 then run ./configure in ...gcc3.3.4/gcc/p/rts directory edit Makefile add -maix64 to CFLAGS (CFLAGS=-O2) copy libgpc.a to ...lib/gcc-lib/power..../3.3.4/ppc64 This allowed me generate 64 bit programs. My program contained a reference to the memavail function in system.pas. I had earlier had some problems with this function in 32 bit mode when it gave an error http://www.gnu-pascal.de/crystal/gpc/en/mail11086.htm In 64 bit mode the use of this function did not report an error but partly disabled the operating system, which should have been quite impossible for a normal user without root privileges! The operator had to reset the machine following this error. Programs without this function call seem to work fine.

2 1

testsuite with gp
by Adriaan van Os 05 Feb '05

05 Feb '05

Built gp-0.57 on powerpc-apple-darwin. Tried to run the testsuite with PC=gp. [G5:gcc/p/test] adriaan% make EXTRA_PFLAGS=--longjmp-all-nonlocal-labels PC=gp rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core PC="gp" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log | "./test_sum" -d ./test_run: fatal: `--print-needed-options' yields: gp: internal problem: unexpected additional output of `gp -dumpmachine' Nothing was run. gp -dumpmachine on the command line displays gp help lines. I don't know if running the testsuite with gp is something that can already be done. Just reporting the results. Regards, Adriaan van Os

2 3

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