Gpc August 2002

gpc@gnu.de

18 participants
17 discussions

gpc with gcc 3.1.1
by Waldek Hebisch 09 Sep '02

09 Sep '02

I am trying to make gpc work with gpc 3.1.1. Currently gpc1 compiles and links (I omitted gcpp, runtime and the 'gpc' driver). About 80% of testsuite works, but the remaining bugs still make compiler unuseable: -- gcp1 crashes trying to use gpc unit -- sometimes arrays and records are mislayed -- record layout functions complain about function declarations in objects. Of course, a bunch of minor bugs also shows up. I have a few questions about getting my work into mainline: -- is there anybody working on the same thing (the disscusion few months ago suggested that nobody)? -- should I try to resolve remaning bugs before I submit a patch? -- is gpc supposed to compile with other C compilers or only with gcc? More specific questions will follow (I spent last week offline). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

5 8

Comparision Cardinal/Integer Bug?
by Eike Lange 05 Sep '02

05 Sep '02

Hi Folks! I don't know whether it's a feature or a bug, I didn't find it on the list of known bugs so here is my report: Comparisions between Cardinal and Integer may fail, if the Integer value is negative. Version: 2.1 (20020510), based on gcc-2.95.2 19991024 (release) program testcase; var aCard: Cardinal; aInt: Integer; begin aCard := 1; aInt := -1; { "FAIL" } if (aCard > aInt) then WriteLn ('OK') else WriteLn ('FAIL'); { "FAIL" } if (aCard > -1) then WriteLn ('OK') else WriteLn ('FAIL'); { just for completness: "OK" } if (1 > -1) then WriteLn ('OK') else WriteLn ('FAIL') end. BTW: The gcc C fontend does the same. Eike

2 1

Cannot display variables with GDB
by J. David Bryan 04 Sep '02

04 Sep '02

When debugging GPC 2.1 programs with GDB, I am unable to print the values of variables that are of the "standard" types. Variables of user-defined types appear to print OK. I am using the Chief's "i486-mingw32" port from: http://www.gnu-pascal.de/contrib/chief/win32/mingw32/ ...but I have observed the same problem in a Mingw version that I built myself. Test case: program gdbtest (output); var i : integer; r : real; c : char; e : (enum1, enum2); s : 0..10; t : string (12); begin i := 3; r := 3.14159; c := 'Q'; e := enum2; s := 4; t := 'test string'; writeln (i, r, c, s, t); end. To reproduce: D:\>gpc -v Reading specs from /mingw/lib/gcc-lib/mingw32/2.95.3-6/specs gpc version 2.1 (20020510), based on 2.95.3-6 (mingw special) D:\>gpc -o gdbtest.exe -g gdbtest.pas D:\>gdb gdbtest.exe GNU gdb 5.1.1 (mingw experimental) Copyright 2002 Free Software Foundation, Inc. [...] This GDB was configured as "mingw32"... (gdb) b gdbtest.pas:18 Breakpoint 1 at $4012c2: file gdbtest.pas, line 18. (gdb) r Starting program: D:/gdbtest.exe Breakpoint 1, pascal_main_program () at gdbtest.pas:18 18 writeln (i, r, c, s, t); (gdb) p i $1 = void (gdb) p r $2 = void (gdb) p c $3 = void (gdb) p e $4 = Enum2 (gdb) p s $5 = 4 (gdb) p t $6 = 'test string' (gdb) c Continuing. [program prints "3 3.141590000000000e+00Q4test string" as expected] Note that the first three variables (of standard types "Integer", "Real", and "Char") print void values in the debugger. I have also tried this with GDB 4.18 and observe the same problem. Could someone please confirm whether these results are reproducible across platforms or are specific to the ix86-mingw32 platform? Thanks! -- Dave Bryan

4 11

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

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 August 2002