Gpc

gpc@gnu.de

5400 discussions

Start a nNew thread

Boost Your Windows Reliability!!!!!!!!!! 14824
by mikeedw＠heybytheway.com 04 Jul '01

04 Jul '01

1 0

ENLARGE YOUR PENIS GUARANTEED 29950
by jb4700＠hotmail.com 04 Jul '01

04 Jul '01

1 0

LEARN HOW YOU CAN LOSE WEIGHT/FEEL GREAT 3752
by imlauf＠hotmail.com 04 Jul '01

04 Jul '01

1 0

Initialisation section of units
by Anuradha 28 Jun '01

28 Jun '01

Hello, Does gpc support initialisation section like: unit <name> interface implementation Begin{initialisation} end. Regards, Anuradha -- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123

5 7

one failed
by Russ Whitaker 25 Jun '01

25 Jun '01

Hi TEST fjf469.pas failed: ./fjf469.pas:4: referenced type `Undef' undefined. Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.3/specs gpc version 20010605, based on 2.95.3 20010315 (release) No biggy - just thought you'd like to know. Russ

1 0

(no subject)
by Kocherlakota Harikrishna 25 Jun '01

25 Jun '01

1 0

Problem with FILE of RECORD
by david＠tcs01.demon.co.uk 24 Jun '01

24 Jun '01

This very small program demonstrates a bug in handling FILEs of a particular RECORD. It has been cut down from a much larger real-life example, so it looks very artificial. File F (a FILE of TSMALLPOINT) is not written correctly using GPC version 20010516 (based on 2.95.2 19991024 (release)) on Kernel 2.2.16 on an i686 under RedHat Linux 6.2. The behaviour has changed sometime since version 19991030 (based on 2.95.2 19991024 (release)). Here is the program: ==================== program daj23(input,output); const MAXCOMP=5; MAXROUND=2; type TSMALLPOINT=RECORD REGNO:integer; PNTS:ARRAY[1..MAXROUND] OF integer; END; var i,J,cat,count,ordinal:INTEGER; st1:string(255); PROCEDURE SAVE_CAT; VAR I,J:INTEGER; F:FILE OF TSMALLPOINT; BEGIN writeSTR(st1,CAT:1); REWRITE(F,'ch'+ST1); F^.REGNO:=ORDINAL; for j:=1 to maxround do f^.pnts[j]:=0; PUT(F); FOR I:=1 TO MAXCOMP DO BEGIN F^.REGNO:=100+i; FOR J:=1 TO MAXROUND DO BEGIN F^.PNTS[J]:=i+j; END; PUT(F); END; CLOSE(F); END; begin (*daj20*) cat:=1; ordinal:=10; save_cat; end. (*daj20*) od -d ch1 shows the file contains: 0000000 0 0 0 0 0 0 0 0 0000020 0 0 3 0 0 0 0 0 0000040 4 0 0 0 0 0 5 0 0000060 0 0 0 0 6 0 0 0 0000100 0 0 7 0 0000110 Under GPC version 19991030, od -d ch1 shows: 0000000 10 0 0 0 0 0 101 0 0000020 2 0 3 0 102 0 3 0 0000040 4 0 103 0 4 0 5 0 0000060 104 0 5 0 6 0 105 0 0000100 6 0 7 0 0000110 which is the correct contents. -- David James mailto:david@tcs01.demon.co.uk Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>

3 6

bug when upgrading bnu210->bnu211 ?
by Maurice Lombardi 23 Jun '01

23 Jun '01

Hi all, I have recently upgraded binutils, from bnu210 to bnu211 (all on djgpp v2.03) I used it to compile gpc-20010605 and ran the test suite. Everything is OK except for a bug in fay.pas which was not present with bnu210 (with the same gpc sources). C:\djgpp\b\gnu\gcc-2.953\gcc\p\test>gpc -g -O3 --autobuild fay.pas c:/djgpp/tmp\ccdaaaaa: Assembler messages: c:/djgpp/tmp\ccdaaaaa:934: Fatal error: C_EFCN symbol out of scope This is related to COFF debugging: it compiles and runs perfectly without the -g option. Looking into coff.h, I found #define C_EFCN 0xff /* physical end of function */ and line 934 is the last line of fay.s, so this seems consistent. Looking to gpc mail archives I found two occurences of the same error in the same test program fay.pas, in mails from andris when we upgraded from gcc-2.95.2 to gcc-2.95.3, and which disappeared when his suggestions enabled to compile gpc. Nothing I can think about with such an erratic bug. For reference, if somebody has an idea, I have uploaded to agnes in the directory ftp://agnes.dida.physik.uni-essen.de/home/maurice/ gpc compiled with the two versions of bnu (names are explicit), and the modified version of gcc2953s2.zip I used to compile them: modifications include a libiberty/configure.in.diff necessary to use version 2.50 of autoconf and changes in build.bat and djbuild1.sh to compile only gcc and gpc instead of the whole compiler collection. Meanwhile I reverted to bnu210 and the link gpc2953b.zip points to the bnu210 version. Hope this helps (little hope in fact) Maurice. -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

GNU PASCAL
by Cortelli Paolo 23 Jun '01

23 Jun '01

Hi, I'm trying to run the simple included program, but I receive that error: Internal error: string capacity cannot be negative. I have noticed that the problem start on readln inside the loop. Is there a way to overcome that? Window95, gpc version 2.53. Thanks for your help. Paolo Cortelli program txt2rec; type rmaterie = record m_materia:string[18]; m_esclude:string[78]; m_len: integer; m_esc: array[1..5] of integer; end; tmaterie = array[0..0] of rmaterie; pmaterie = ^tmaterie; var k,len_m: integer; materie: pmaterie; f: text; procedure p_mat(fl:string); begin assign(f,fl); reset(f); readln(f,len_m); getmem(materie,sizeof(rmaterie)*len_m); for k := 1 to len_m do readln(f,materie^[k].m_materia,materie^[k].m_esclude); close(f); freemem(materie,sizeof(rmaterie)*len_m); end; begin p_mat('materie.txt'); end. { This is the contents of MATERIE.TXT 36 BIOLOGIA \LAB.BIOLOG CALCOLO \LAB.CALCOLO CHIMICA \LAB.CHIMICA }

2 1

forward pointers
by Christopher Ferrall 22 Jun '01

22 Jun '01

This is listed in "Other known bugs" > forward referencing pointers generate debug info that appears as generic pointers; no information of `with' > statements is currently given to the debugger; error in debug entries generated for objects Is this the same as this problem: type xptr = ^x_type; x_type = record stuff ... next : xptr; end; var xlist, x : xptr; begin new(xlist); xlist.next:=nil; ... x := xlist; repeat with x^ do begin new(next); x := next; until no_more_to_create; At runtime: Program received signal SIGSEGV, Segmentation fault. Inside gdb: (gdb) print x[0] Attempt to dereference a generic pointer. Obviously next can be "pointer" and xptr can be defined after x_type, but it is inconvenient to change code based on one of the building blocks of Pascal. --Chris

3 2

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