Gpc

gpc@gnu.de

5400 discussions

Re: Zero-length types (was: Record alignment)
by da Silva, Joe 14 Mar '02

14 Mar '02

With 20011222 (djgpp), the "set of void" example produces a similar result, except the internal error is not a "fatal signal 11", but rather, an "Internal compiler error in 'layout_type', at stor-layout.c:1055". The "array of void", "packed array of void" and "array of empty record" examples are OK with 20011222 - no errors or crashes, either at compile or run times. I wasn't brave enough to play around with the "file type" example, though. <g> Joe. > -----Original Message----- > From: Emil Jerabek [SMTP:ejer5183@artax.karlin.mff.cuni.cz] > Sent: Wednesday, March 13, 2002 11:54 PM > To: gpc > Subject: Zero-length types (was: Record alignment) > > > Hello, > > Is it possible to make the set datatype to occupy only one byte? Now > > by default the compiler allocates 4 bytes.We even tried packing it,but > > it's still the same. > > After reading this message, I tried to experiment with set types > a little bit. It turned out that the compiler segfaults on "set of Void" > (this is a nonsense type, but anyway...) > > [pas]% gpc -v ; uname -a > Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/specs > gpc version 20020308, based on 2.95.2 19991024 (release) > Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 > unknown > [pas]% cat voidset.pas > program VoidSet (Output); > > type > T = set of Void; (* WRONG *) > > begin > WriteLn ('failed') > end. > [pas]% gpc voidset.pas > voidset.pas:4: ordinal type expected > gpc: Internal compiler error: program gpc1 got fatal signal 11 > (Segmentation fault) > [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/ccSEiSIV.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 0x0816d399 in layout_type (type=0x8274028) > at ../../../gcc-2.95.2/gcc/p/../stor-layout.c:1053 > 1053 ../../../gcc-2.95.2/gcc/p/../stor-layout.c: No such file or > directory. > in ../../../gcc-2.95.2/gcc/p/../stor-layout.c > (gdb) bt > #0 0x0816d399 in layout_type (type=0x8274028) > at ../../../gcc-2.95.2/gcc/p/../stor-layout.c:1053 > #1 0x081b2159 in build_set_type (members=0x8274014) > at ../../../gcc-2.95.2/gcc/p/types.c:579 > #2 0x081a358f in yyparse () at parse.y:2043 > #3 0x0816fae1 in compile_file (name=0xbffffb84 "/tmp/ccSEiSIV.i") > at ../../../gcc-2.95.2/gcc/p/../toplev.c:3265 > #4 0x08172dca in main (argc=8, argv=0xbffffa1c) > at ../../../gcc-2.95.2/gcc/p/../toplev.c:5440 > #5 0x40041e5e in __libc_start_main (main=0x8171e14 <main>, argc=8, > ubp_av=0xbffffa1c, init=0x80490f8 <_init>, fini=0x81ba7a0 <_fini>, > rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffffa0c) > at ../sysdeps/generic/libc-start.c:129 > > > GPC accepts "array of Void" (and even static variables of that type; > should it?), but it crashes on "packed array of Void". More importantly, > it crashes the same way on the following ISO 7185 code: > > [pas]% cat recordend1.pas > program Foo (Output); > > type > T = packed array [1 .. 42] of record end; > > begin > WriteLn ('OK') > end. > [pas]% gpc recordend1.pas > recordend1.pas:4: Internal compiler error in `float_signal', at > toplev.c:2418 > Please submit a full bug report. > See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for > instructions. > > > A similar file-type generates a run-time error: > > [pas]% cat recordend2.pas > program Foo (Output); > > type > EmptyType = record end; > > var > F: file of EmptyType; > > begin > rewrite (F); > { F^ := EmptyType[]; } > put (F); > reset (F); > get (F); > writeln ('OK') > end. > [pas]% gpc recordend2.pas > [pas]% ./a.out > ./a.out: internal error: `InitFDR' has not been called for file (error > #913 at 8049c05) > > > Emil Jerabek

1 0

Bug in gpc-20020304 ?
by Maurice Lombardi 11 Mar '02

11 Mar '02

Hi all I have compiled gpc-20020304 with djgpp I found a (new ?) bug given by the following simple program: ---------------------------------------------------------------- program TestSize; type tR = object constructor init; function Size: integer; virtual; destructor fini; end; constructor tR.init; begin end; function tR.Size: integer; begin Size := 1 end; destructor tR.fini; begin end; begin end. --------------------------------------------------------------- Compilation fails with the message: TestSize.pas:7: duplicate field `Size' TestSize.pas:7: excess elements in record initializer after `vmt_Tr' "Virtual" is essential. Has Size become an hidden identifier (size of the vmt ?) 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 2

GPC 2.1 RC 3 released
by Frank Heckenbach 09 Mar '02

09 Mar '02

Hi everyone, I sent this announcement to gpc-announce(a)gnu.de on Monday, but it still hasn't appeared here. So apparently that list or its moderator is dead or something, or they've stopped forwarding gpc-announce to this list. (If the latter is not the case, you'll get the announcement again -- if this bothers you, please complain to the list owner, not me. ;-) As some of you have found out yourselves by now, GPC version 20020304, the release candidate #3 for GPC 2.1, has been uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/current/gpc-20020304.tar.gz (CVS is not available currently.) Due to a relatively large number of bug reports and discussions on the mailing list in the last several weeks, there have been many changes since RC 2. Some internal problems which led to compiler crashes (especially with `-O3' and/or `-g', and often hard to reproduce) have been resolved (thanks to J. Booij, Matthias Klose and others for reports). I hope that GPC will now crash noticeably less often than it did before. ;-) However, it is (still) a known problem that `-g' (debug info) does not work perfectly, and fails completely on some platforms (such as IRIX/MIPS). A number of other problems have been solved. Some of the most important ones are described below. For a more detailed listing, please refer to the `Fixed bugs' section of the To-Do list. First and foremost, the type checking has become much stricter. This might cause GPC to find some "new" bugs in your programs, but I suppose they often will turn out to be real bugs in the Pascal code which just were not detected before (as was the case with some bugs that appeared in my own Pascal code). E.g., two records which are declared separately with identically looking declarations are not compatible in Pascal, but GPC used to accept them as compatible. The automake and GPI file mechanisms have been changed (and hopefully improved) significantly (thanks to the Chief for some bugs reports). Since I can't test them in every conceivable way, please check if they (still) work for you. Many things related to schema types have been changed (only for the better I hope). Various other bugs have been fixed, e.g., the long-standing problem that initializers of arrays of length 1 didn't work and that the import and export of huge interfaces was very slow (quadratic time behaviour). Some complex number routines have been improved numerically, thanks to Emil Jerabek and Joe da Silva. The manual is now available (partly) in a Croatian translation, thanks to Mirsad Todorovac. A new feature is the `FormatString' function (a main use of which will be for internationalization support, together with Eike Lange's Intl unit). Many of the planned features are still missing, but it should be sufficient already for many ordinary purposes. Some things have been added in the object-orientation support. In particular, abstract objects and methods work fully now (they were only partially supported in previous versions), the `is' and `as' operators have been implemented, and `TypeOf' does not return an untyped pointer anymore, but a pointer of type `PObjectType' pointing to the object type record (a.k.a. VMT) which currently contains the fields `Size', `NegSize', `Parent' and `Name'. Due to some changes in GPC, some problems with debug info in the COFF output format (which only DJGPP still uses, as far as I know) may now appear more often than they did before. The problems arise when the same identifier is used in different units (even with different asmnames), or for a global variable and a local function (see test/fjf500.pas for further notes and an example). (The problems themselves are not now, and seem to be inherent in the COFF format, so only a switch of DJGPP to ELF would be a real solution, and it's uncertain if this will ever happen. However, when GPC will support qualified identifers, chances are that this will make one or both of the problems disappear.) If you are affected by this problem under DJGPP (error messages: `Fatal error: C_EFCN symbol out of scope', or duplicate definitions at link time even though asmnames are different), you might have to rename one of the offending identifiers, or compile without debug info. I've tested GPC on some systems, test reports from other systems are welcome, and if you find new or especially important bugs, or very important missing features, please report them. I'll be out of town over the weekend, so I can't look into any new bugs until Monday ... Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 2

Re: Record alignment
by Anuradha 08 Mar '02

08 Mar '02

Hello, We attempted reading them bit by bit . We attempted giving 'packed' before records. We attempted giving --pack-struct . The last gave compilation errors and the first and the second are not all that simple to incorporate in the code because there are many types with records within records within records within records... Is there no way out other than to (vastly) change the code? BTW, Is implementation of the alignment-size-indication($Z) planned? Thanks for the support , Regards, Anuradha Frank Heckenbach wrote: > Anuradha wrote: > > > Hello, > > > > Sorry for the last mail.We are resending it. > > ================================ > > We have a problem as follows. > > We have a database file tabinfo.mdb created under WINDOWS using > > pervasive SQL(Btrieve).Now > > we are trying to access it with GPC. > > We fear that there is some allignment problem in the records stored > > and the record passed to read data > > out. > > The record we used to create the tabinfo in windows is : > > > > MDB_MLTABL_TYPE = RECORD > > MLTABLNM : CHAR_8 ; > > RID : word ; > > LENPHYS : word ; > > PHYSINF : PH_ADDR ; > > EDITION : BYTE ; > > DATALEV : FS_FILE_TYPE ; > > MLTABDES : PH_ADDR ; > > ATTCOUNT : BYTE ; > > ATTINFO : ARRAY [ 1..MAX_ATTRIBS ] > > OF MDB_ATTR_INFO_TYPE ; > > RELFILES : ARRAY [ 1..MAX_RELFILES ] > > OF MDB_REL_FILE_TYPE ; > > END ; > > > > We use the same record structure to read data back from it (but in > > GPC).But it doesnot read properly. > > Can you tell us why this happens? > > BTW, fs_file_type is a Enumerated type . > > ph_addr is longint. > > (We have given > > longint=int32 > > word=word16 in our program). > > First of all, declare the record and the sub-arrays and sub-records > (if any; I don't know what MDB_ATTR_INFO_TYPE etc. is) as `packed' > (and be aware of the inefficiencies involved -- the first field > seems to a a single byte, so the following fields will be at odd > addresses which is clearly less efficient on IA32 and much less > efficient on RISCs; I guess you don't have much choice here, but if > you do serious processing, you might want to copy the data in/out of > the packed structure). > > Then check the sizes of each field, using `SizeOf', and use > `Integer (n)' or `Cardinal(n)' in GPC for a type of size n bits. > > For the enum field, you'll probably have to use `Cardinal(8)' (if > the other compiler makes it 8 bits big), since otherwise GPC would > pack it as small as possible (e.g., 4 bits if it has 9 .. 16 > values). > > 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 -- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123

2 1

Re: Record alignment
by KOCHERALKOTA harikrishna 08 Mar '02

08 Mar '02

Hello, Thank you for the advice and it worked fine for enum type. We have many recordS and other structures and we have created a big database using these structures using BP. We have now problems in accesing this database, as lot of misalignments are resulting as we move from BP to GPC. we have problem in declaring all the records and arrays as 'PACKED' , Bcoz they are countless in number. Instead we used '--pack-struct' option. But this is resulting in an compilation error "Cannot take address of bit feild". Could you advise us on this . Thanks and Regards hari Frank Heckenbach wrote: > KOCHERALKOTA harikrishna wrote: > > > How can we set size of enumerated data type in GPC?. > > That's not possible currently. Your best bet probably is using an > integer type, e.g. `Cardinal (n)' (where n is the desired size in > bits), and declaring the enum values as constants (starting from 0). > > > Because in GPC, even if > > we give 2 values (0..1) also, it assigns 4 bytes by default. > > Yes (for alignment and efficiency reasons), and 1 bit in a packed > record/array. > > 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

1 0

Re: Record alignment
by KOCHERALKOTA harikrishna 07 Mar '02

07 Mar '02

Hello, Good Morning! As you said , by default Enum type is 8-bit in BP.The Enumsize can be controlled by compiler directive {$Z} in Delphi. {$Z1} or {$Z2} or {$Z4} {$MINENUMSIZE 1} or {$MINENUMSIZE 2} or {$MINENUMSIZE 4} Default {$Z1} {$MINENUMSIZE 1} The $Z directive controls the minimum storage size of enumerated types. An enumerated type is stored as an unsigned byte if the enumeration has no more than 256 values, and if the type was declared in the {$Z1} state (the default). If an enumerated type has more than 256 values, or if the type was declared in the {$Z2} state, it is stored as an unsigned word. Finally, if an enumerated type is declared in the {$Z4} state, it is stored as an unsigned double-word. The {$Z2} and {$Z4} states are useful for interfacing with C and C++ libraries, which usually represent enumerated types as words or double-words. Note: For backwards compatibility with earlier versions of Delphi and Borland Pascal, the directives {$Z-} and {$Z+} are also supported. They correspond to {$Z1} and {$Z4}, respectively. How can we set size of enumerated data type in GPC?.Because in GPC, even if we give 2 values (0..1) also, it assigns 4 bytes by default. Have a Nice Day! Thanking You, Kind Regards, Karthic and Hari Frank Heckenbach wrote: > Anuradha wrote: > > > Hello, > > > > Sorry for the last mail.We are resending it. > > ================================ > > We have a problem as follows. > > We have a database file tabinfo.mdb created under WINDOWS using > > pervasive SQL(Btrieve).Now > > we are trying to access it with GPC. > > We fear that there is some allignment problem in the records stored > > and the record passed to read data > > out. > > The record we used to create the tabinfo in windows is : > > > > MDB_MLTABL_TYPE = RECORD > > MLTABLNM : CHAR_8 ; > > RID : word ; > > LENPHYS : word ; > > PHYSINF : PH_ADDR ; > > EDITION : BYTE ; > > DATALEV : FS_FILE_TYPE ; > > MLTABDES : PH_ADDR ; > > ATTCOUNT : BYTE ; > > ATTINFO : ARRAY [ 1..MAX_ATTRIBS ] > > OF MDB_ATTR_INFO_TYPE ; > > RELFILES : ARRAY [ 1..MAX_RELFILES ] > > OF MDB_REL_FILE_TYPE ; > > END ; > > > > We use the same record structure to read data back from it (but in > > GPC).But it doesnot read properly. > > Can you tell us why this happens? > > BTW, fs_file_type is a Enumerated type . > > ph_addr is longint. > > (We have given > > longint=int32 > > word=word16 in our program). > > First of all, declare the record and the sub-arrays and sub-records > (if any; I don't know what MDB_ATTR_INFO_TYPE etc. is) as `packed' > (and be aware of the inefficiencies involved -- the first field > seems to a a single byte, so the following fields will be at odd > addresses which is clearly less efficient on IA32 and much less > efficient on RISCs; I guess you don't have much choice here, but if > you do serious processing, you might want to copy the data in/out of > the packed structure). > > Then check the sizes of each field, using `SizeOf', and use > `Integer (n)' or `Cardinal(n)' in GPC for a type of size n bits. > > For the enum field, you'll probably have to use `Cardinal(8)' (if > the other compiler makes it 8 bits big), since otherwise GPC would > pack it as small as possible (e.g., 4 bits if it has 9 .. 16 > values). > > 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

2 1

zero function
by Michael Underwood 06 Mar '02

06 Mar '02

In the past I have been a Compaq VAX Pascal user. One useful feature was the ZERO function. Does GPC have an equivalent? Regards Michael Underwood Systems Analyst Consulting Division Hydro Tasmania Ph: (03) 6230 5494 This message and any attachments may contain confidential or privileged information, and are intended solely for the named recipient(s). If you are not a named recipient of this message, you are hereby notified that you must not use, disseminate, copy or take any action in reliance on this message or any part of it. If you have received this message in error, please notify the author immediately via mailto:michael.underwood@hydro.com.au <mailto:michael.underwood@hydro.com.au> NB: Unless otherwise specified, opinions and personal views expressed herein are purely those of the author and do not represent the views of Hydro Tasmania.

2 1

Re. Record alignment
by Anuradha 06 Mar '02

06 Mar '02

Hello, How can we set size of enumerated data type in GPC? thnaks and regards Anu -- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123

1 0

Re: Record alignment
by Anuradha 01 Mar '02

01 Mar '02

Hello, Sorry for the last mail.We are resending it. ================================ We have a problem as follows. We have a database file tabinfo.mdb created under WINDOWS using pervasive SQL(Btrieve).Now we are trying to access it with GPC. We fear that there is some allignment problem in the records stored and the record passed to read data out. The record we used to create the tabinfo in windows is : MDB_MLTABL_TYPE = RECORD MLTABLNM : CHAR_8 ; RID : word ; LENPHYS : word ; PHYSINF : PH_ADDR ; EDITION : BYTE ; DATALEV : FS_FILE_TYPE ; MLTABDES : PH_ADDR ; ATTCOUNT : BYTE ; ATTINFO : ARRAY [ 1..MAX_ATTRIBS ] OF MDB_ATTR_INFO_TYPE ; RELFILES : ARRAY [ 1..MAX_RELFILES ] OF MDB_REL_FILE_TYPE ; END ; We use the same record structure to read data back from it (but in GPC).But it doesnot read properly. Can you tell us why this happens? BTW, fs_file_type is a Enumerated type . ph_addr is longint. (We have given longint=int32 word=word16 in our program). thanks and Regards Hari & Anu

2 1

Record alignment
by KOCHERALKOTA harikrishna 01 Mar '02

01 Mar '02

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