Gpc

gpc@gnu.de

5400 discussions

New (randomized) test ...
by Mirsad Todorovac 20 May '03

20 May '03

Hi, Frank, others! Here is the first test I wrote using GPC manual's instructions for writting randomized tests. It concerns sets, since they have been a place where bugs appeared in the past - even though Frank's implementation seems invariant to number of bits ``MedCard'' type could have sometimes in the future. BTW, there seems to be a need for something called a "random set" of data, pehaps even with given ``Monte Carlo'' function, to get a different distibution than uniform one. The most plain random set could be the one with its MedCards initialized with random numbers with probably 0.5 probability for each bit being set. Having them initialized correctly is inefficient, and relying on internal implementation that could change without prior notice can backfire - hence IMHO it would be great to have a function like e.g. RandomSet{,Uniform}(LBound, UBound) Please consider this, IMHO right now it could be used for testing purposes, yet probably other uses could be seen ... All the best, Mirsad -- "I have a dream!" -- Martin Luther King Jr. "You can't hold someone down ... without staying down with him." -- Booker T. Washington

3 12

Gcc-3.3 release and gpc-20030507
by David Kredba 17 May '03

17 May '03

Hello all, when I am bootstraping new gcc-3.3 release with GNU Pascal 20030507 I got : make[3]: Entering directory `/home/david/gcc-3.3-build/gcc/p/rts' .../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/home/david/gcc-3.3-gpc/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /home/david/gcc-3.3-gpc/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.3'" /home/david/gcc-3.3-gpc/gcc/p/rts/numtodec.pas /home/david/gcc-3.3-gpc/gcc/p/rts/numtodec.pas:113: internal compiler error: in dwarf2out_finish, at dwarf2out.c:12666 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [numtodec.o] Error 1 make[3]: Leaving directory `/home/david/gcc-3.3-build/gcc/p/rts' make[2]: *** [pascal.rts] Error 2 make[2]: Leaving directory `/home/david/gcc-3.3-build/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/home/david/gcc-3.3-build/gcc' make: *** [bootstrap] Error 2 gcc -v : Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3/specs Configured with: ../gcc-3.3/configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,objc,f77,ada,java Thread model: posix gcc version 3.3 uname -r : 2.4.21-0.16mm-mdksmp Configure command: .../gcc-3.3-gpc/configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,objc,f77,ada,java,pascal Make command : make -j4 bootstrap4 After 1st fail in gpc : make bootstrap4 and after fail in gpc : make bootstrap The same error results in all cases. David

5 9

New Install questions
by gpc＠radstream.com 17 May '03

17 May '03

It has been a while but I have come back to GPC again... I just installed the 20030507 Linux binary on my RH ver 8 machine. I thought I followed the FAQ and INSTALL instructions but I get this: [ken@illinois demos]# gpc hello.pas /usr/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status So, I try another file... [ken@illinois demos]# gpc pi.pas pi.pas:31: module/unit interface `GPC' could not be imported Tell me the truth... Was I sleeping when I installed GPC last night? TNX Ken Linder KC7RAD

1 0

Re: Gcc-3.3 release and gpc-20030507
by Waldek Hebisch 16 May '03

16 May '03

David Kredba wrote: > Thank U, > > I`ll try gstabs. > > Your patch is not working for me : > > [david@g200 gcc]$ patch -Np1 -i ./dwarf.patch > patching file p/declarations.c > patch: **** malformed patch at line 11: return block; > > > David > I checked the patch both before sending and again after seeing your message (this time using the copy I got back from the list) and it was OK. Maybe your mailer garbled the patch (the original of the line which appears in the error message has four spaces at the beginning, while I see sixteen spaces after semicolon -- looks that that some whitespace may be converted to tabs and back). This time I put the patch as an attachment (should be more resistant to mailers...). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

object assignment
by David Ulbrich 16 May '03

16 May '03

Hi all, I like to use objects as data container only: (records with "inheritence", no methods.) type tHead=object ID :integer; sum :integer; end; type tFoo1=object(tHead) data:float; end; type tFoo2=object(tHead) data:longint; end; var headvar:tHead; foo1var:tFoo1; Head:=foo1; <- gpc gives "invalid explicit assignment between objects" //BP and Delphi assign with the statement above all common fields: // Headvar.ID :=foo1var.ID // Headvar.sum :=foo1var.sum it there a legal way to get the base-data from foo1var into headvar at once? Thanks David

2 1

Dynamic object methods
by Frank Heckenbach 15 May '03

15 May '03

One item on the to-do list are BP compatible dynamic methods. As far as I understand the BP description, they are semantically equivalent to virtual methods, only the syntax is different (an integer index added) and the implementation (which we don't have to follow, of course). Ignoring this index syntactically would be easy to do. Would this be useful, and is it really all that's required? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

10 36

Common symbols
by Adriaan van Os 12 May '03

12 May '03

While trying to build a Mach-O dynamically linked shared library with GPC and LD, I get the following error: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_0__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_1__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_2__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_3__ (size 32) In the Mach-O Runtime Architecture docs I found: "A common symbol is a symbol that may appear in multiple intermediate object files. The static linker permits multiple common symbol definitions with the same name in input files, and copies the one with the largest size to the final product. If there is an another symbol with the same name as a common symbol, the static linker will ignore the common symbol instead. The standard C compiler generates a common symbol when it sees a tentative definition—a global variable that has no initializer and is not marked extern. The following line is an example of a tentative definition: int x; A shared library cannot have common symbols. To eliminate common symbols in an existing shared library, you must either explicitly define the symbol (with an initialized value, for example) in one of the modules of the shared library, or pass the -fno-common flag to the compiler." My questions are: 1. Is there something special about symbols for sets ? 2. Would it help to rebuild libgpc.a with the --no-common flag ? 3. Any other ideas or suggestions ? Regards, Adriaan van Os

3 6

[Fwd: Re: gcc 3.x breaks ABI compatibility? [Was: Re: Bug 00314 -- div() still broken]]
by CBFalconer 11 May '03

11 May '03

Here is something I still have on my machine about this problem -------- Original Message -------- Subject: Re: gcc 3.x breaks ABI compatibility? [Was: Re: Bug 00314 -- div() still broken] Date: Tue, 29 Apr 2003 08:44:45 +0100 From: Richard Dawe <rich(a)phekda.freeserve.co.uk> Reply-To: djgpp-workers(a)delorie.com To: Andris Pavenis <pavenis(a)latnet.lv> CC: djgpp-workers(a)delorie.com, Ben Peddell <killer.lightspeed(a)bigpond.com>,rudd(a)cyberoptics.com References: <3e9c6920$0$21928$afc38c87@> <lzLqa.23283$1s1.356122(a)newsfeeds.bigpond.com> <3EABA5AA.99B8EDE3(a)phekda.freeserve.co.uk> <200304280954.02899.pavenis(a)latnet.lv> Hello. Andris Pavenis wrote: > > On Sunday 27 April 2003 12:40, Richard Dawe wrote: [snip] > > I've just looked at the gcc 2.95.2 sources and it looks like > > -fpcc-struct-return (i.e.: use memory) is the default there. > > > > The gcc 3.2.2 source seems to default to using registers. See the end > > gcc/config/i386/djgpp.h: > > > > /* Don't default to pcc-struct-return, because gcc is the only compiler, > > and we want to retain compatibility with older gcc versions. */ > > #define DEFAULT_PCC_STRUCT_RETURN 0 > > > > Why is this defined? I couldn't see a ChangeLog entry for djgpp.h. AFAICT > > this breaks backwards compatibility, i.e.: the opposite of what the > > comment says. Is there something I'm missing? > > I copied it from other i386 targets. GCC-3.2.2 didn't compile without > defining DEFAULT_PCC_STRUCT_RETURN, as there is no default Not all i386 targets define DEFAULT_PCC_STRUCT_RETURN to be 0. Linux and NetBSD ELF don't. I think we need to use the same as the default for 2.95.x, i.e.: #define DEFAULT_PCC_STRUCT_RETURN 1 This is a pretty critical bug. Do you have any plans to rebuild gcc 3.2.2 (or 3.2.3) with this fix? Thanks, bye, Rich =] -- Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

2 1

GPC on Palm OS ?
by Adriaan van Os 10 May '03

10 May '03

I would be curious to know if anybody on the list * ever tried to build gpc for Palm OS, using prc-tools (<prc-tools.sourceforge.net>), * or worked with the PocketStudio Pascal compiler for Palm OS. Regards, Adriaan van Os

1 0

Re: gpc-20030507 - attribute bug?
by Prof A Olowofoyeku (The African Chief) 10 May '03

10 May '03

On 10 May 2003 at 12:22, I wrote: [...] > I have another problem. This code used to compile: > > unit attrbug_2; > interface > uses GPC; > FUNCTION DirectoryExists ( CONST DirName : String ) : Boolean; > attribute (name = '_p_DirectoryExists'); external; > FUNCTION FileSearch ( CONST FileName, DirList : String ) : TString; > attribute (name = '_p_FSearch'); external; implementation end. > > Now, it dies with this error: "attributes in forward declared routines > are not allowed". If "external" is removed, then you get an error like > "unresolved forward declaration `FileSearch'". > > This code is taken from the Sysutils unit, which exports some functions > that already exist in the GPC unit. In older times, you just asmnamed > them. In the penultimate snapshot, that was changed to the above. Now, > it doesn't work. I need this to work (or at least I need to have a way > to reexport routines from other units). This is reminiscent of the > earlier discussions on unit propagation. I am not sure how that > discussion was resolved. > Unfortunately, this problem is not only related to unit propagation. I have just tried to compile the Windows unit (that exports thousands of winapi routines, interfacing to the Mingw winapi libraries), and two of those routines are now rejected with the "attributes in forward declared routines are not allowed" error. There is no reason for those two routines to be singled out, and there is no USES problem here. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

1 0

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