Gpc

gpc@gnu.de

5400 discussions

double inclusion of unit DOS with gpc (Mingwin version)
by Jean-Pierre Vial 03 Sep '02

03 Sep '02

When the DOS unit (and strangely only the DOS unit) is used both in a program and an unit used by this program, all the interface is flagged as redefined and compilation fails. This happens only with the Mingwin version, DJGPP and Linux version are OK (but they are older) Here is a test: a programm and a unit Note that the unit DOS is not actually used. ******************************** program testinc; uses dos,unitinut; begin writeln(affichage); end. ********************************** unit unitinut; interface var affichage:string; implementation uses dos; begin affichage:="affiche"; end. *********************************** -- Jean-Pierre Vial

4 3

Packed records
by Waldek Hebisch 29 Aug '02

29 Aug '02

Is there any definitive info how packed types _should_ work in GPC. The following program: Program BitSz; Var R: packed record aa: packed record c: Boolean; end; a: Boolean; b: 1..3; end (* R *); begin writeln ( ' R.aa:', BitSizeOf ( R.aa ), ' R.aa.c:', BitSizeOf ( R.aa.c), ' R.a:', BitSizeOf ( R.a ), ' R.b:', BitSizeOf ( R.b ), ' R:', BitSizeOf ( R )); end. writes: R.aa:8 R.aa.c:1 R.a:1 R.b:2 R:16 which shows that packed records inside packed records currently (with gpc 2.1) take the same space as outside. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

2 1

Problems compiling GPC on NetBSD/sparc
by Philip Plant 29 Aug '02

29 Aug '02

Hi folks, I've been trying to compile GPC on my NetBSD/sparc 1.5.2 system. Unfortunately it fails with a bunch of 'undefined reference' errors for calls to libc functions. Here are a few snips of the output from make. If anyone could suggest a fix, I'd be very grateful. bash-2.05$ uname -a NetBSD helios 1.5.2 NetBSD 1.5.2 (GENERIC) #0: Wed Aug 22 04:33:09 CST 2001 toor@proxima:/usr/src/sys/arch/sparc/compile/GENERIC sparc bash-2.05$ make make all-recursive Making all in intl Making all in lib Making all in makeinfo gcc -DIN_GCC -DHAIFA -g -O2 -DHAVE_CONFIG_H -o cccp cccp.o cexp.o intl.o prefix.o version.o mbchar.o obstack.o ../libiberty/libiberty.a /usr/lib/crt0.o: In function `___start': /usr/lib/crt0.o(.text+0xf8): undefined reference to `main' cccp.o: In function `safe_read': /usr/tmp/gcc-2.95.2/gcc/cccp.c(.text+0x224): undefined reference to `_read' /usr/tmp/gcc-2.95.2/gcc/cccp.c(.text+0x238): undefined reference to `___errno' cccp.o: In function `safe_write': /usr/tmp/gcc-2.95.2/gcc/cccp.c(.text+0x280): undefined reference to `_write' /usr/tmp/gcc-2.95.2/gcc/cccp.c(.text+0x294): undefined reference to `___errno' cccp.o: In function `eprint_string': /usr/tmp/gcc-2.95.2/gcc/cccp.c(.text+0x2d8): undefined reference to `_(short, (void))' <snip> `___divdi3' /tmp/sky/share/bison.simple(.text+0xafc): undefined reference to `___udivdi3' /tmp/sky/share/bison.simple(.text+0xb70): undefined reference to `___moddi3' /tmp/sky/share/bison.simple(.text+0xb8c): undefined reference to `___umoddi3' <snip> /usr/tmp/gpc-build/gcc/obstack.c(.text+0x510): undefined reference to `_(short, (void))' /usr/tmp/gpc-build/gcc/obstack.c(.text+0x514): undefined reference to `_fputs' collect2: ld returned 1 exit status *** Error code 1 Stop. *** Error code 1 Stop. Regards, Philip.

4 5

GPC 2.1 (GCC 2.95.2) optimization.
by Martin G C Davies 28 Aug '02

28 Aug '02

Hi, What is the status as far as using optimization is concerned? Is it supposed to be usable? If so I have a problem... I'm on a Solaris 2.6 Ultra 1 using GPC 2.1 (based on GCC 2.95.2). Source code showing the problem is below. When I build and run with the commands:- gpc -c opt.pas gpc -c -DMYMODULE opt.pas -o lichkp1.o gpc opt.o lichkp1.o a.out I see "ok" but if I use -O i.e. gpc -c opt.pas gpc -c -DMYMODULE opt.pas -o lichkp1.o -O gpc opt.o lichkp1.o a.out I see "failed". Can anyone help? Cheers, Martin G C Davies. #if defined MYMODULE module opt; #else program opt(output); #endif const lmpages = 24576 ; lcpgsize = 4096 ; lcpgctrl = 28 ; lmalloc = lcpgsize - lcpgctrl - 4 ; type mylupage = record number : packed 0..lmpages ; datadisp : packed 0..lmalloc end ; mylopage = ^mylupage; function lichkp1( mypage : mylopage ) : boolean ; external ; #if defined MYMODULE function lichkp1( mypage : mylopage ) : boolean ; begin if mypage^.number <> 1 then lichkp1 := false else if ( mypage^.datadisp < lcpgctrl ) or ( mypage^.datadisp > ( lmalloc div 8 ) ) then lichkp1 := false else lichkp1 := true ; end ; #else var mypage : mylupage ; begin mypage.number := 1 ; mypage.datadisp := lcpgctrl ; if lichkp1(addr(mypage)) then writeln('ok') else writeln('failed'); #endif end.

2 2

Re: gpc with gcc 3.1.1
by Waldek Hebisch 27 Aug '02

27 Aug '02

strobe anarkhos wrote: >At 9:55 PM +0200 8/26/02, Waldek Hebisch wrote: >>I am trying to make gpc work with gpc 3.1.1. Currently gpc1 > >Good luck. > >Are you targeting 3.1.1 due to Apple using it, or is there another reason? For me it is largely a learning exercise -- how a front end fits into GCC back end. Newer technology is better for that, also 3.x series looks much cleaner then 2.x. On the other hand big plus for GCC is its wide reach -- it supports many architectures and many languages -- and I would like to have that all in a _single_ version. 2.95.3 today is probably best as production compiler, but I think in a few months 3.x will have fewer bugs. 3.1 have support for new architectures: s390, and better HP support. Also Ada is integrated in 3.1, and java in 3.x is much better then in 2.95.3. Finally, C++ in 3.1 is binary incompatible with 2.95.3 -- so currently that stops wide adoption of 3.x, but then the transition will be very fast. In other words: staying with newest 3.x seems only logical choice for Grand Unification. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

gpc statistics
by Prof. A Olowofoyeku (The African Chief) 27 Aug '02

27 Aug '02

Hi folks Since this list has been rather quiet of late, I thought to bore you all with statistics (sorry!) - but the download count of the GPC 2.1 binary release from the official Mingw website just hit 5,000, which to me is good news. Is GPC about to take over the world? Answers on a postcard ... Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Email: African_Chief(a)bigfoot.com http://www.bigfoot.com/~african_chief/

1 0

[bat@niipmm.tsu.ru: Questions about GNU Pascal]
by Dieter Schmitz 26 Aug '02

26 Aug '02

----- Forwarded message from "Alexei P. Baturin" <bat(a)niipmm.tsu.ru> ----- From: "Alexei P. Baturin" <bat(a)niipmm.tsu.ru> To: <gpc-owner(a)gnu.de> Subject: Questions about GNU Pascal Date: Thu, 15 Aug 2002 16:49:39 +0700 Good day, Would you like to answer two questions about GNU Pascal (MS DOS with DGJPP) for which I haven't found the answer in documentation? I work in MS-DOS under Windows 98 (processor Pentium II). 1. Is it possible to force the functions sin, cos, exp, ln, **, etc. to calculate a result of type LongReal (10 bytes) with a precision of 19 decimal digits (as in BP or Delphi)? 2. How to use DLL's in GP-programs? I tried to import a function from DLL by usual way (as in Delphi): function esin(x:extended):extended; external 'extenlib.dll' index 1; but the compiler didn't understand this. Can you help me to solve this problem? Best regards, Alexei Baturin (Tomsk, Russia) ----- End forwarded message -----

4 3

New bug in gpc 2.1 ?
by Maurice Lombardi 25 Aug '02

25 Aug '02

Hi all, It seems that a new bug has crept in in recent versions of gpc (I use 2.1 / djgpp). I found it in recompiling a program which worked correctly some times ago. A simple program to display the bug is obtained by splitting the docdemos/operatordemo.pas program into a main and a unit: ----------------------------------------------------------------- program bugoper; uses uoper; var a, b, c: Vector3 = (1, 2, 3); begin c := a + b end. ----------------------------------------------------------------- unit uoper; interface type Vector3 = record x, y, z: Real; end; operator + (u, v: Vector3) w: Vector3; implementation operator + (u, v: Vector3) w: Vector3; begin w.x := u.x + v.x; w.y := u.y + v.y; w.z := u.z + v.z; end; end. ------------------------------------------------------------------- I obtain the following error mesage bugoper.pas: In main program: bugoper.pas:10: invalid operands to binary + bugoper.pas:10: invalid operands to binary + Everything is correct of course with the original program 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 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

Some strange behaviour of GPC
by Nick Ioffe 14 Aug '02

14 Aug '02

Hi! I use packed arrays of booleans and need to look for bit set and clear in them. The arrays are of different sizes, but I cannot use a conformant array. I've written function Find_First_bit_Set (buff_ptr:pointer, bit_size:integer) : integer; and then to pass Addr(bit_array) and BitSizeOf(bit_array). The problem is that for BitSizeOf (packed array of boolean) always returns me 8*SizeOf like in the following case: program tst; var aa : packed array [1..19] of boolean; begin writeln (SizeOf(aa), ' ', BitSizeOf(aa)); end. the output I get is: 4 32. what can be wrong? I use GPC 2.1 compiled on HP-UX B.11.00 Thank you in advance, Nick

3 2

bad configuration with mingwin
by Jean-Pierre Vial 13 Aug '02

13 Aug '02

I just tried, several times, to install gpc under Mingwin. I fail every time in the same way: when I launch gpc, it does not find its own parts. 1) I get a message <<cannot exec /mingw/lib.....>> even though the required exe does exist, precisely where gpc looks for it I have a dirty workaround for this problem: if I do not set GPC_EXEC_PREFIX but put the directory /mingw/lib/gcc-lib/mingw32/2.95.3-6 in the path the executables are found. I then fall on the second problem 2) Units are not found (crt, gpc, etc...) My last attempt was with a fresh Mingwin distribution, specially downloaded form the mingwin site, with just the same version number as the gpc package, so I do not know what to do. There is no problem with the djgpp version (well, almost: the crt unit does not display accented letters !) -- Jean-Pierre Vial

2 1

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