Gpc

gpc@gnu.de

5400 discussions

Re: Trouble using GPC modules
by da Silva, Joe 21 Jan '02

21 Jan '02

Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, January 21, 2002 1:59 AM > To: gpc(a)gnu.de > Subject: Re: Trouble using GPC modules > > Nicolas Courtel wrote: > > > I'm trying to use the simple GPC modules mechanism, as described in the > Doc > > (7.1.8.1, page 85), and can't figure out how to link the provided > example, with > > module DemoMod3 and program ModDemo3. > > > > I'm using GPC 20011202 on Solaris-8; I tried several methods, for > example: > > > > % gpc --automake moddemo3.pas > > > > and always get undefined linking errors: > > > > Setfoo /var/tmp/cc2daawp1.o > > Getfoo /var/tmp/cc2daawp1.o > > > > I guess the solution is really simple, but can't find it, please help! > > > > Here's the example source code: > > Works for me. Perhaps you need to specify the `asmname's (anyway, > this will be required in the future when GPC will support qualified > identifiers, so you might as well do it now, and perhaps it will > solve your problem): > > module DemoMod3; > > type > FooType = Integer; > > var > Foo : FooType; > > procedure SetFoo (f : FooType); asmname 'setfoo'; > procedure SetFoo (f : FooType); > [Joe da Silva] OK, time for a silly question ... <g> Why does the procedure header need to be given twice? (Looks weird!)

2 1

Trouble using GPC modules
by Nicolas Courtel 20 Jan '02

20 Jan '02

Hi all, I'm trying to use the simple GPC modules mechanism, as described in the Doc (7.1.8.1, page 85), and can't figure out how to link the provided example, with module DemoMod3 and program ModDemo3. I'm using GPC 20011202 on Solaris-8; I tried several methods, for example: % gpc --automake moddemo3.pas and always get undefined linking errors: Setfoo /var/tmp/cc2daawp1.o Getfoo /var/tmp/cc2daawp1.o I guess the solution is really simple, but can't find it, please help! Here's the example source code: module DemoMod3; type FooType = Integer; var Foo : FooType; procedure SetFoo (f : FooType); begin Foo := f; end; { SetFoo } function GetFoo: Footype; begin GetFoo := Foo; end; { GetFoo } end. program ModDemo3 (Output); type FooType = Integer; procedure SetFoo (f : FooType); external; function GetFoo: FooType; external; begin SetFoo (999); Writeln (GetFoo); end. -- Nicolas

2 1

Trouble using GPC modules
by Nicolas Courtel 20 Jan '02

20 Jan '02

1 0

Re: GPC Variable/Procedure Naming Convention
by Gloria, Jing 18 Jan '02

18 Jan '02

Frank, thanks for your inputs that I read in the mailing list archives. I was hoping there is an option to allow making the names in lowercase. Everyone, can somebody please send me information on how to change the GPC naming schema so that it will generate names that are all in lowercase? At this point I am willing to take a chance and rebuild my GPC compiler if it will generate all lowercase names. I have Pascal procedures/functions that are called by both Pascal and C modules. Global variables are used in both C and Pascal modules. There are close to 100 global variables and around sixty Pascal procedures/functions shared by both C and Pascal. All these scattered over 500 Pascal and C source files. The C modules use all lowercase for the names. So I either convert the C files to have first character uppercase names or add asmname in the Pascal files. Either way, I will need to edit hundreds of files. Regards, Jing Gloria Texas Instruments Sherman, TX

2 1

array of 24-bit cardinals?
by Toby Ewing 17 Jan '02

17 Jan '02

Hello, all I'm working with some large arrays (2^27 elements), and am about to run into memory limitations. Currently I'm using a bytecard for each element, but in expanding my program's capabilities, I want to add a second array of cardinal. This second cardinal needs to have a range larger than 2^16 (65535), but I don't have enough memory for a 2^32 cardinal. Sounds like 2^24 cardinals would be appropriate... I looked into the range-specified integers in the manual. It says: >>> 8.2.3.3 Integer Types with Specified Size In some situations you will need an integer type of a well-defined size. For this purpose, GNU Pascal provides three families of signed and unsinged integer types. The type Integer (42) is guaranteed to have a precision of 42 bits. In a realistic context, you will most often give a power of two as the number of bits, and the machine you will need it on will support variables of that size. If this is the case, the specified precision will simultaneously be the amount of storage needed for variables of this type. <<< So perhaps the 24-bit cardinal would work fine. My questions: 1) will the compiler really allocate only 24 bits, or will it align the array elements along 32-bit boundaries? 2) If the compiler does indeed make true 24-bit-aligned cardinals, how much speed will I lose in memory access? If this is an unexplored issued, please let me know, in which case I'll attempt it and report back on how it worked. regards, Toby Soil Scientist, Iowa State University

3 3

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

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