Gpc January 2002

gpc@gnu.de

27 participants
45 discussions

Re: Is this a bug or me being stupid?
by da Silva, Joe 17 Jan '02

17 Jan '02

What if you define your variable as -32767..32767, instead of -32768..32767? Does that work? I know that the full range of a 16 bit, two's complement integer is indeed -32768..32767, but Pascal does not assume two's complement implementation, hence the range for an integer is -maxint..maxint, not -(maxint+1)..maxint. Therefore, GPC may at least in some cases regard the need for -32768 as an integer type whose maxint is 32768 or greater, in which case 16 bits would be deemed inadequate (with 32 bits chosen instead). If the above analysis is true, then GPC has two bugs : 1. It is inconsistent about whether -32768..32767 fits within 16 bits. 2. It is allowing the "external" qualifier to circumvent checking for duplicate identifiers (as Maurice has already pointed out). Joe. > -----Original Message----- > From: Martin G C Davies [SMTP:martin.g.c.davies@ntlworld.com] > Sent: Wednesday, January 16, 2002 10:54 PM > To: gpc(a)gnu.de > Subject: Re: Is this a bug or me being stupid? > > > > > -----Original Message----- > > From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de]On Behalf Of Maurice > > Lombardi > > Sent: 16 January 2002 10:47 > > To: gpc(a)gnu.de > > Subject: Re: Is this a bug or me being stupid? > > > > > > Martin G C Davies wrote: > > > > > main: sizeof curpseudoreg=2 > > > main: alignof curpseudoreg=2 > > > main: curpseudoreg initially set to 5 > > > initregcons: sizeof curpseudoreg=4 > > > initregcons: alignof curpseudoreg=4 > > > initregcons: curpseudoreg=327680 > > > initregcons: curpseudoreg now set to 99 > > > main: curpseudoreg=0 > > > > > > So the quuestion is, why is the sizeof and alignog different in the > two > > > modules? > > > > They are not the same variable. You see that the values also of > > curpseudoreg > > are different. > > Thanks for the analysis Maurice but I don't think it's correct for three > reasons:- > > 1. If I change packed -32768..32767 to integer(16) the problem goes away > for > the example given. > > 2. I added a writlen of the addr of curpseudoreg and it is the same > address > in each module (new code below). > > 3. 327680 is hex 50000 so it just looks like the sizeof and alignof of 4 > are > what is mucking it up. > > Thus I still think this a gpc bug. > > main.pas > ======== > > program main(output) ; > > procedure initregcons ; external ; > > var > curpseudoreg : packed -32768..32767number ; external ; > > begin > writeln( 'main: addr curpseudoreg=' , integer( addr( curpseudoreg ) ) > ) > ; > writeln( 'main: sizeof curpseudoreg=' , sizeof( curpseudoreg ) ) ; > writeln( 'main: alignof curpseudoreg=' , alignof( curpseudoreg ) ) ; > curpseudoreg := 5 ; > writeln( 'main: curpseudoreg initially set to ' , curpseudoreg ) ; > initregcons ; > writeln( 'main: curpseudoreg=' , curpseudoreg ) ; > end. > > regabs.pas > ========== > > module regabs ; > > var > curpseudoreg : packed -32768..32767 ; external ; > var > curpseudoreg : packed -32768..32767 ; > > procedure initregcons ; external ; > > procedure initregcons ; > begin > writeln( 'initregcons: addr curpseudoreg=' , integer( addr( > curpseudoreg ) ) ) ; > writeln( 'initregcons: sizeof curpseudoreg=' , sizeof( curpseudoreg ) > ) > ; > writeln( 'initregcons: alignof curpseudoreg=' , alignof( > curpseudoreg ) ) ; > writeln( 'initregcons: curpseudoreg=' , curpseudoreg ) ; > curpseudoreg := 99 ; > writeln( 'initregcons: curpseudoreg now set to ' , curpseudoreg ) ; > end ; > > end. > > and the output when run is:- > > main: addr curpseudoreg=522892 > main: sizeof curpseudoreg=2 > main: alignof curpseudoreg=2 > main: curpseudoreg initially set to 5 > initregcons: addr curpseudoreg=522892 > initregcons: sizeof curpseudoreg=4 > initregcons: alignof curpseudoreg=4 > initregcons: curpseudoreg=327680 > initregcons: curpseudoreg now set to 99 > main: curpseudoreg=0 >

4 4

Is this a bug or me being stupid?
by Martin G C Davies 16 Jan '02

16 Jan '02

I have a cut down version of a bug I have found:- File 1 (main.pas) ================= program main(output) ; procedure initregcons ; external ; var curpseudoreg : packed -32768..32767 ; external ; begin writeln( 'main: sizeof curpseudoreg=' , sizeof( curpseudoreg ) ) ; writeln( 'main: alignof curpseudoreg=' , alignof( curpseudoreg ) ) ; curpseudoreg := 5 ; writeln( 'main: curpseudoreg initially set to ' , curpseudoreg ) ; initregcons ; writeln( 'main: curpseudoreg=' , curpseudoreg ) ; end. File 2 (regabs.pas) =================== module regabs ; var curpseudoreg : packed -32768..32767 ; external ; var curpseudoreg : packed -32768..32767 ; procedure initregcons ; external ; procedure initregcons ; begin writeln( 'initregcons: sizeof curpseudoreg=' , sizeof( curpseudoreg ) ) ; writeln( 'initregcons: alignof curpseudoreg=' , alignof( curpseudoreg ) ) ; writeln( 'initregcons: curpseudoreg=' , curpseudoreg ) ; curpseudoreg := 99 ; writeln( 'initregcons: curpseudoreg now set to ' , curpseudoreg ) ; end ; end. I compile them:- gpc -Wall main.pas regabs.pas and there are no warnings. By the way gpc -v gives:- Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gpc version 20010924, based on gcc-2.8.1 When I run the program I get:- main: sizeof curpseudoreg=2 main: alignof curpseudoreg=2 main: curpseudoreg initially set to 5 initregcons: sizeof curpseudoreg=4 initregcons: alignof curpseudoreg=4 initregcons: curpseudoreg=327680 initregcons: curpseudoreg now set to 99 main: curpseudoreg=0 So the quuestion is, why is the sizeof and alignog different in the two modules? Cheers, Martin P.S. I am testing using integer(16) for this example but I have other similar problems (different packed ranges).

2 3

GPC Variable/Procedure Naming Convention
by Gloria, Jing 16 Jan '02

16 Jan '02

Is there a way such that the variable names (or procedure/function names) in GPC are created so that the name is all lowercase? This would make it match C variable names which are in lowercase. I understand the GPC converts the names to uppercase for the first character and lower case for all the succeeding characters in the name. I am converting an application where some modules are in written in Pascal and others in C. They share many global variables and some procedures and functions. There are too many lines of code and too many files to change if I use asmname. Furthermore, I need to keep the source files such that I can build on either a Sun Sparc system or Intel Solaris 7 system. Since these two systems have different compilers, this GPC naming convention is requiring a lot of work. Bottomline, I want GPC and GCC to generate the same name so that I can link all the modules. Any suggestions or comments? GPC is version 19991030. based on 2.95 19990728. GCC is 2.95.2. Thanks in advance for any assistance the community provides. Regards, Jing Gloria Texas Instruments Sherman, TX

2 1

Re: gpc problems in 2.95
by Matthias Klose 16 Jan '02

16 Jan '02

[CC to gpc(a)gnu.de; the gpc version is the RC2, the gcc version 2.95.4 CVS] Philip Blundell writes: > The version of gpc in the 2001-12-23 upload doesn't seem to work on arm, > sparc, m68k or s390; they all seem to segfault somewhere during the build. > > ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings > -Wmissing-prototypes -Wmissing-declarations -g -O3 > -DRTS_RELEASE_STRING="'`cat /build/buildd/gcc-2.95-2.95.4.ds7/src-native/gcc/p/ > rts/rts-version`'" --unit-path=/build/buildd/gcc-2.95-2.95.4.ds7/src-native/gc > c/p/rts --automake `cat needed-options` /build/buildd/gcc-2.95-2.95.4.ds7/src-n > ative/gcc/p/rts/heap.pas > xgpc: Internal compiler error: program gpc1 got fatal signal 11 > make[5]: *** [heap.o] Error 1 on sparc it fails in another file: ../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O3 -DRTS_RELEASE_STRING="'`cat /home/doko/2.95/gcc-2.95-2.95.4.ds7/src-native/gcc/p/rts/rts-version`'" --unit-path=/home/doko/2.95/gcc-2.95-2.95.4.ds7/src-native/gcc/p/rts --automake `cat needed-options` /home/doko/2.95/gcc-2.95-2.95.4.ds7/src-native/gcc/p/rts/endian.pas xgpc: Internal compiler error: program gpc1 got fatal signal 11 make[5]: *** [endian.o] Error 1 > > What's to be done? I'll go back to the gpc-20010924 version for these architectures, if I get no feedback from upstream.

3 6

A compiler crash with -g -O3
by Emil Jerabek 16 Jan '02

16 Jan '02

Something is bad with function inlining, when debug info is being generated: [pas]% uname -a ; gpc -v Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 unknown Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20011222, based on 2.95.2 19991024 (release) [pas]% cat crash.pas program P (Output); (* FLAG -g -O -finline-functions *) var A: Integer; procedure S; var B: 0 .. 1; begin A := B end; begin S; WriteLn ('OK') end. [pas]% gpc -g -O -finline-functions crash.pas gpc: Internal compiler error: program gpc1 got fatal signal 11 [pas]% gdb /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/gpc1 core GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `/usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/gpc1 /tmp/ccoAW9qr.i -quiet -du'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 print_int_cst_octal (c=0x8257cbc) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:1597 1597 int width = TYPE_PRECISION (TREE_TYPE (c)); (gdb) bt #0 print_int_cst_octal (c=0x8257cbc) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:1597 #1 0x08140986 in dbxout_type (type=0x8259fc0, full=0, show_arg_types=0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:1171 #2 0x0814230c in dbxout_symbol_location (decl=0x825a920, type=0x8259fc0, suffix=0x0, home=0x825a8a4) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2161 #3 0x08141ebc in dbxout_symbol (decl=0x825a920, local=1) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:1944 #4 0x0814245b in dbxout_syms (syms=0x825a920) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2230 #5 0x08142a6d in dbxout_block (block=0x825a984, depth=4, args=0x0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2585 #6 0x08142bc8 in dbxout_block (block=0x825a9cc, depth=3, args=0x0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2644 #7 0x08142bc8 in dbxout_block (block=0x8279134, depth=2, args=0x0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2644 #8 0x08142bc8 in dbxout_block (block=0x827917c, depth=1, args=0x0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2644 #9 0x08142bc8 in dbxout_block (block=0x82791ac, depth=0, args=0x0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2644 #10 0x08142d07 in dbxout_function (decl=0x82776c0) at ../../../gcc-2.95.2/gcc/p/../dbxout.c:2706 #11 0x08171879 in rest_of_compilation (decl=0x82776c0) at ../../../gcc-2.95.2/gcc/p/../toplev.c:4419 #12 0x08189a28 in finish_function (nested=0) at ../../../gcc-2.95.2/gcc/p/gpc-decl.c:9708 #13 0x081a41d2 in yyparse () at parse.y:525 #14 0x0816fb91 in compile_file (name=0xbffffb69 "/tmp/ccoAW9qr.i") at ../../../gcc-2.95.2/gcc/p/../toplev.c:3265 #15 0x08172e7a in main (argc=11, argv=0xbffff9ec) at ../../../gcc-2.95.2/gcc/p/../toplev.c:5440 #16 0x40041e5e in __libc_start_main (main=0x8171ec4 <main>, argc=11, ubp_av=0xbffff9ec, init=0x8049194 <_init>, fini=0x81bcf80 <_fini>, rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffff9dc) at ../sysdeps/generic/libc-start.c:129 Emil Jerabek

2 1

#466 ???
by 320017353451-0001＠t-online.de 16 Jan '02

16 Jan '02

Where do I find errorcodes in general and this one in particular ? I had a look into /usr/share/doc/packages/gpc etc witout finding anything ... : -) Thanks Douglas P.S. It s an error which is not really reproduceable ... so I would like to know where to look closer ?!

2 1

Re: Complex_SqRt bug
by da Silva, Joe 14 Jan '02

14 Jan '02

OK, if you're happy that the code is correct ... I guess I just don't understand what the "a := Abs(Im(z)) / (2 * b)" statement does ... More accurate results are always welcome, anyway. Anyway, although you might say the Clipped_SqRt solution is a kludge, it is certainly not second-guessing. It would only be applied where the minimum theoretical argument was zero, in which case it would avoid (and eliminate) rounding errors which produced a slightly negative "zero". Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, January 10, 2002 9:30 PM > To: gpc(a)gnu.de > Subject: Re: Complex_SqRt bug > > da Silva, Joe wrote: > > > To be honest, the revised Complex_SqRt function you present > > is a bit too complicated for me. <G> > > > > So, my thinking is that, instead of re-writing the algorithm of > > Complex_SqRt and similar routines, it would be simpler and > > less error-prone in these situations, to utilize a new, alternative > > SqRt function, eg. : > > > > Function Clipped_SqRt (x : double) : double; > > {Alternative SqRt : Clips negative arguments, returning zero} > > begin {Clipped_SqRt} > > if x > 0 > > then > > Clipped_SqRt := SqRt (x) > > else > > Clipped_SqRt := 0 > > end; {Clipped_SqRt} > > > > Of course, you would only apply this alternative to SqRt when > > the argument cannot theoretically be negative ... > > I don't think so. This seems more like a kludge to me (first compute > a wrong value, and then second-guess in a subroutine what it could > really be). Besides, it would only avoid the problem in the "< 0" > case -- as Emil noted, "the patch above gives more accurate results > (even for arguments which do not trigger the bug)." > > BTW, I checked his code carefully to make sure it's mathematically > correct. > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

4 3

Problems with GtkUnit
by Klaus F. Østergaard 14 Jan '02

14 Jan '02

Hi, I have a small problem with the GtkUnit. I have the unit installed, using make every thing just worked. All the tutorial programs compiled and they are ready to use. But when I try to compile the simple helloworld.pas with this: gpc -O2 -Wall --automake helloworld.pas -o ../../../pascal/bin/helloworld I get this error: In file included from helloworld.pas:5: ../units/gtk.inc:23: module/unit `gtkmarshal' could not be compiled In the helloworld I have changed the path from '../units' to '/home/klaus/temp/gtk/units' Am I missing something on the command line when I call the compiler, or is there a bug in the unit? Kind regards, Klaus F. Oestergaard

3 4

Complex_SqRt bug
by Emil Jerabek 14 Jan '02

14 Jan '02

The complex square root function crashes with a funny error message on some arguments close to the real line: [pas]% cat sqrt.pas program SqrtTest (Output); var C: Complex; begin C := Sqrt (Cmplx (4.2, 1e-8)); WriteLn ('OK') end. [pas]% uname -a ; gpc -v Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 unknown Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20011222, based on 2.95.2 19991024 (release) [pas]% gpc sqrt.pas [pas]% ./a.out ./a.out: argument to `SqRt' is < 0 (error #708 at 805d837) [pas]% The square root is computed as \sqrt{X+iY} = \sqrt{(A+X)/2} + i \sqrt{(A-X)/2} sgn(Y), where A=|X+iY|. It seems that due to inaccuracies etc., A may turn out to be _less_ than |X|, if |Y| << |X|, which means that SqRt((A+-X)/2) gets a negative argument. I suggest the following patch. --------------------------------------------------- diff -U3 orig/p/rts/math.pas p/rts/math.pas --- orig/p/rts/math.pas Mon Sep 3 12:48:15 2001 +++ p/rts/math.pas Mon Jan 7 21:34:43 2002 @@ -192,8 +192,7 @@ function Complex_SqRt (z: Complex): Complex; var - a: Double; - Sign: Integer; + a, b: Double; begin { SqRt (x + yi) = +/- (SqRt ((a + x) / 2) +/- i * SqRt ((a - x) / 2)) @@ -203,10 +202,15 @@ Principal value defined in the Extended Pascal standard: Exp (0.5 * Ln (z)), i.e. Sign (Re (SqRt (z)) := 1, Sign (Im (SqRt (z))) := Sign (Im (z)) } a := Abs (z); - if Im (z) < 0 then Sign := -1 else Sign := 1; - if a <> 0 - then Complex_SqRt := Cmplx (SqRt ((a + Re (z)) / 2), Sign * SqRt ((a - Re (z)) / 2)) - else Complex_SqRt := 0 + if a = 0 then Complex_SqRt := 0 + else begin + b := SqRt ((a + Abs (Re (z))) / 2); + if Abs (Im (z)) > Abs (Re (z)) then a := SqRt ((a - Abs (Re (z))) / 2) + else a := Abs (Im (z)) / (2 * b); + if Re (z) < 0 then begin var c: Double = a; a := b; b := c end; + if Im (z) < 0 then Complex_SqRt := Cmplx (b, -a) + else Complex_SqRt := Cmplx (b, a) + end end; function Complex_Ln (z: Complex): Complex; ---------------------------------------------------- It would also work to simply insert if Abs (Re (z)) > a then a := Abs (Re (z)); into the original version, but the patch above gives more accurate results (even for arguments which do not trigger the bug). When talking about math.pas, I also suggest a little optimization to the complex logarithm function; \log \sqrt x = (\log x)/2, but the RHS is (I guess) computed faster and more precisely: --------------------------------------------------- diff -U3 orig/p/rts/math.pas p/rts/math.pas --- orig/p/rts/math.pas Mon Sep 3 12:48:15 2001 +++ p/rts/math.pas Mon Jan 7 22:10:08 2002 @@ -211,7 +211,8 @@ function Complex_Ln (z: Complex): Complex; begin - Complex_Ln := Cmplx (Ln (Abs (z)), ArcTan2 (Im (z), Re (z))) + Complex_Ln := Cmplx (Ln (Sqr (Re (z)) + Sqr (Im (z))) /2, + ArcTan2 (Im (z), Re (z))) end; function Complex_Exp (z: Complex): Complex; ----------------------------------------------------- Emil Jerabek

4 8

packed arrays again
by Emil Jerabek 14 Jan '02

14 Jan '02

There are still some problems with packed arrays of subrange types. (1) Initializers don't work properly. [pas]% cat packed1.pas program P (Output); type T = packed array [0 .. 2] of 0 .. 1000; var A: T value (1, 2, 0); begin if (A[0] = 1) and (A[1] = 2) and (A[2] = 0) then WriteLn ('OK') else WriteLn ('Failed: ', A[0] : 4, A[1] : 4, A[2] : 4) end. [pas]% uname -a ; gpc -v Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 unknown Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs gpc version 20011222, based on 2.95.2 19991024 (release) [pas]% gpc packed1.pas packed1.pas:9: warning: too few initializers for array [pas]% ./a.out Failed: 1 0 0 [pas]% (2) In certain situations, assignment statements work incorrectly when the same subscribed packed array variable is accessed on both sides of the assignment. [pas]% cat packed2.pas program P (Output); var A: packed array [0 .. 2] of 0 .. 1000; function F (N: Integer): Integer; begin if N = 0 then F := 0 else begin A[N] := F (A[N]); F := A[N] + 1 end end; begin A[0] := 1; A[1] := 2; A[2] := 0; A[0] := F (A[0]); if A[0] = 2 then WriteLn ('OK') else WriteLn ('Failed: ', A[0]) end. [pas]% gpc packed2.pas [pas]% ./a.out Failed: 1 [pas]% The problem is in the statement "A[N] := F (A[N]);" in the body of F. During its execution, A[N] is _cleared_ before the function call, in particular the argument passed to F is always 0. The debugger session below illustrates this behavior. (gdb 5.0 doesn't understand packed arrays; I used a type-cast to Integer as a workaround. Integer(A)=A[0]+1024*A[1]+1048576*A[2], i.e. 2049=(1,2,0) and 1=(1,0,0).) [pas]% gpc -g packed2.pas [pas]% gdb a.out GNU gdb 5.0rh-5 Red Hat Linux 7.1 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) break F Breakpoint 1 at 0x8049c2c: file packed2.pas, line 8. (gdb) run Starting program: /home/emil/pascal/pas/a.out Breakpoint 1, F (N=1) at packed2.pas:8 8 if N = 0 then F := 0 Current language: auto; currently pascal (gdb) watch Integer(A) Hardware watchpoint 2: (Integer) A (gdb) step 10 A[N] := F (A[N]); (gdb) step Hardware watchpoint 2: (Integer) A Old value = 2049 New value = 1 $08049cb4 in F (N=1) at packed2.pas:10 10 A[N] := F (A[N]); (gdb) bt #0 $08049cb4 in F (N=1) at packed2.pas:10 #1 $0804a1a9 in pascal_main_program () at packed2.pas:19 #2 $0804a2bb in main (argc=1, argv=$bffffacc, envp=$bffffad4) at <implicit code>:21 #3 $40064e5e in __libc_start_main (main=$804a294 <main>, argc=1, ubp_av=$bffffacc, init=$80494c8 <_init>, fini=$8066b50 <_fini>, rtld_fini=$4000d3c4 <_dl_fini>, stack_end=$bffffabc) at ../sysdeps/generic/libc-start.c:129 (gdb) step Breakpoint 1, F (N=0) at packed2.pas:8 8 if N = 0 then F := 0 (gdb) Emil Jerabek

2 1

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