Gpc

gpc@gnu.de

5400 discussions

About GNU Pascal Record Type
by pascaltomath＠yahoo.fr 11 Jul '07

11 Jul '07

Dear All; I would like to ask you if it is possible in 32 Bit and/or 64 Bit GNU Pascal; to determine, to precise the 'Bit' value of each member of a Record, as it is so for a Structure in C. Thanks a lot for a prospective reply. With kind regards. Kadir Yuce Below is a C code example : #include <stdio.h> struct bitprecising { char ch : 8; int n : 2; long l : 3; } ; int main() { struct bitprecising x; struct bitprecising *p; p= &x; (*p).ch= 'a'; (*p).n= 1; (*p).l= 2L; printf("x.ch= %c\n", x.ch); printf("x.n= %d\n", x.n); printf("x.l= %ld\n", x.l); } --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail

1 0

attempted build with gcc-4.2.0
by Russ Whitaker 17 Jun '07

17 Jun '07

hi Applied Waldek's gcc patch for an older gcc. Got these rejects: dbxout.c.rej *************** *** 1916,1922 **** { stabstr_S ("@s"); stabstr_D (BITS_PER_UNIT * int_size_in_bytes (type)); - stabstr_S (";-20;"); } else { --- 1916,1922 ---- { stabstr_S ("@s"); stabstr_D (BITS_PER_UNIT * int_size_in_bytes (type)); + stabstr_S (";-20"); } else { gimplify.c.rej *************** *** 4948,4953 **** case POINTER_TYPE: case REFERENCE_TYPE: gimplify_type_sizes (TREE_TYPE (type), list_p); break; --- 4952,4959 ---- case POINTER_TYPE: case REFERENCE_TYPE: + break; + gimplify_type_sizes (TREE_TYPE (type), list_p); break; tree-flow-inline.h.rej *************** *** 1470,1476 **** return false; return (AGGREGATE_TYPE_P (TREE_TYPE (v)) && - TREE_CODE (TREE_TYPE (v)) != ARRAY_TYPE); } --- 1470,1477 ---- return false; return (AGGREGATE_TYPE_P (TREE_TYPE (v)) && + TREE_CODE (TREE_TYPE (v)) != ARRAY_TYPE + && TREE_CODE (TREE_TYPE (v)) != SET_TYPE); } varasm.c.rej *************** *** 2725,2731 **** VEC(constructor_elt, gc) *v; unsigned HOST_WIDE_INT idx; tree purpose, value; - v = VEC_alloc(constructor_elt, gc, VEC_length(constructor_elt, CONSTRUCTOR_ELTS (exp))); FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (exp), idx, purpose, value) --- 2725,2731 ---- VEC(constructor_elt, gc) *v; unsigned HOST_WIDE_INT idx; tree purpose, value; + v = VEC_alloc(constructor_elt, gc, VEC_length(constructor_elt, CONSTRUCTOR_ELTS (exp))); FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (exp), idx, purpose, value) *************** *** 3765,3771 **** /* Allow conversions to struct or union types if the value inside is okay. */ if (TREE_CODE (dest_type) == RECORD_TYPE - || TREE_CODE (dest_type) == UNION_TYPE) return initializer_constant_valid_p (src, endtype); } break; --- 3765,3776 ---- /* Allow conversions to struct or union types if the value inside is okay. */ if (TREE_CODE (dest_type) == RECORD_TYPE + || TREE_CODE (dest_type) == UNION_TYPE + #ifdef GPC + || TREE_CODE (TREE_TYPE (value)) == ARRAY_TYPE + #endif + ) + return initializer_constant_valid_p (src, endtype); } break; However, for that last one was able to find where the patch belongs, so here's a diff: 3843c3843,3847 < || TREE_CODE (dest_type) == UNION_TYPE) --- > || TREE_CODE (dest_type) == UNION_TYPE > #ifdef GPC > || TREE_CODE (TREE_TYPE (value)) == ARRAY_TYPE > #endif > ) 4017c4021 < --- > Wasn't sure how to correct the other rejects, so at least I got this far: *** glibc detected *** corrupted double-linked list: 0x08aa5f50 *** ../../gcc-4.2.0/gcc/tree-ssa-loop-ivopts.c In function 'find_optimal_iv_set': ../../gcc-4.2.0/gcc/tree-ssa-loop-ivopts.c: 5271 internal complier error: aborted Hope this helps Russ

1 0

Re: Bit packing
by Contestcen＠aol.com 15 Jun '07

15 Jun '07

In a message dated 6/14/2007 1:40:34 AM Eastern Standard Time, florian(a)freepascal.org writes: How does the pascal macro compiler solve it? It tries to solve it for bit/booleans arrays but not for subrange types which are much harder because of endian issues. Tries because it doesn't take care of things like debugging. (Continuing previous answer) If the problem is that some Pascal compilers store large integers with the least-significant byte first, while others store the most-significant byte first, one solution would be to form the concatenation of bit fields into a string of integers, and let each compiler store them according to its own rules. How complex the macros become depends on what is needed. Do the bit fields need to cross boundaries of integer fields? Are mixed-sized integers needed within each record? Are you carving up a large array into bit fields whose lengths will be determined at runtime? If the problem is that one compiler stores array elements in order x[1], x[2], x[3], ... which another compiler stores them x[100], x[99], ... then you simply let the compiler use its own array indexing scheme. Frank ************************************** See what's free at http://www.aol.com.

1 0

Re: Bit packing
by Contestcen＠aol.com 15 Jun '07

15 Jun '07

1 0

Bit packing
by Contestcen＠aol.com 14 Jun '07

14 Jun '07

On 13 jun 2007, at 07:26, Contestcen(a)aol.com wrote: > That's precisely the point. The Borland, TMT, FPC and GPC > compilers are not > compatible on bit-packing. By using the Macro Compiler you get bit- > packing > which is independent of the compiler, so that programs compiled > with any of > these Pascal compilers can exchange data. The bitpacking format is defined in the ABI of the respective platforms (at least all SYSV processor-specific supplements define how you should bitpack), and gcc follows that ABI. Some documentation: * http://www.sco.com/developers/devspecs/abi386-4.pdf : i386 sysv abi supplement, see p. 3-6 and following (look, SCO is still useful for something after all :) * http://refspecs.freestandards.org/elf/elfspec_ppc.pdf : ppc sysv abi supplement, see p. 3-8 and following Jonas Let me see if I follow this. You posted to this forum because you were having problems with bit-packing. You said that you wanted bit-packing that would allow data exchange between programs that were compiled with different compilers, and perhaps ran on different platforms. The Pascal Macro Compiler could make that possible. Now you say that there are standards for bit-packing, and that the GCC compiler follows the standards. Apparently the other Pascal compilers don't follow the standard. (So far as I know, the Borland and TMT compilers don't do bit-packing at all.) Also, the standard does not seem to work across multiple platforms because of different unit sizes. But you still won't use the Pascal Macro Compiler because it solves the bit-packing problem by a means other than enforcing the bit-packing standard on all Pascal compilers. Does that sum it up? Frank ************************************** See what's free at http://www.aol.com.

3 2

TR : GP Internal error
by Pascal Viandier 13 Jun '07

13 Jun '07

Sorry, the gp version I use is 0.61 not 0.60 - typo :-( - Pascal -----Message d'origine----- De : gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de] De la part de Pascal Viandier Envoyé : June 13, 2007 14:12 À : gpc(a)gnu.de Objet : GP Internal error In the course of the SUN Pascal to GNU Pascal conversion of a all set of programs, I use gp to handle the compilation of a program that has many - around 750 - modules. I call gp with the main program and correct errors progressively as they are encountered. I already compiled more than 600 modules this way. Until now all was going well but today I got an error message from gp when it calls "gpc --interface-only" for a module that has never been compiled yet: gp: internal error: complete cycle not found Since gp worked perfectly well for the previous modules, I suspect something wrong in this particular module but I don't see any error when looking at the Pascal code. What kind of twist in the source code can produce this error? I use gp 0.60 build with gpc 20051116 based on gcc-3.4.4 under SPARC Solaris 10 Kind regards. Pascal Viandier

1 0

GP Internal error
by Pascal Viandier 13 Jun '07

13 Jun '07

In the course of the SUN Pascal to GNU Pascal conversion of a all set of programs, I use gp to handle the compilation of a program that has many - around 750 - modules. I call gp with the main program and correct errors progressively as they are encountered. I already compiled more than 600 modules this way. Until now all was going well but today I got an error message from gp when it calls "gpc --interface-only" for a module that has never been compiled yet: gp: internal error: complete cycle not found Since gp worked perfectly well for the previous modules, I suspect something wrong in this particular module but I don't see any error when looking at the Pascal code. What kind of twist in the source code can produce this error? I use gp 0.60 build with gpc 20051116 based on gcc-3.4.4 under SPARC Solaris 10 Kind regards. Pascal Viandier

1 0

Packing of 64 bit values
by Jonas Maebe 13 Jun '07

13 Jun '07

Hello, After noticing that gdb does not print 64 bit fields of (bit)packed records properly if they don't start on a byte boundary (both with fpc and with gpc), I decided to check what gcc does. It turns out that gcc (4.0.1, Mac OS X/ppc) only bitpacks values up to and including 59 bits. Fields declared as 60-64 bits are automatically aligned to the target-specific alignment boundary. Does anyone here know why this is the case, and possibly where this is documented? I can't find anything with Google. Thanks, Jonas Simple test case follows (compile with -c -gdwarf-2, then use dwarfdump/elfread --debug-dump on the .o file to look at the debug info). both l and l2 are aligned on an 8 byte boundary for ppc64 and to a 4 byte boundary for ppc32. *** struct tt { int a; int j; }; struct S { int j:5; long long l:60; long long l2:60; int k:6; int m:5; int n:8; struct tt s; }; int main(struct S s) { } *** Compare with a Pascal program: *** {$ifdef fpc} {$bitpacking on} {$endif} type {$ifndef fpc} int64 = longint; {$endif} tenum = (ea,eb,ec,ed,ee,ef,eg,eh); tr = packed record a: 0..3; // 2 bits i: int64; c: boolean; // 1 bit d: 0..31; // 5 bits e: tenum; // 3 bits end; procedure t(var r2: tr); var r: tr; begin r.a := 2; r.i := 1234567890123456789; r.c := true; r.d := 5; r.e := ed; r2 := r; end; var r: tr; begin t(r); if (r.a <> 2) or (r.i <> 1234567890123456789) or (not r.c) or (r.d <> 5) or (r.e <> ed) then halt(1); end. *** If you debug this, step over the "t" call and print r, you get (for gpc): (gdb) p r $1 = { A = 2, I = 0, C = true, D = 5, E = Ed } (gdb) ptype r type = record A : 0..3 : 2; I : Int64 : 64; C : Boolean : 1; D : 0..31 : 5; E : Tenum : 3; end Looking at the stabs (the gpc for Mac OS X I have doesn't support dwarf), gpc also puts the 64 bit int right after the two first bits, without aligning to a byte/4 byte/8 byte boundary first.

2 3

Bit-packing
by Contestcen＠aol.com 13 Jun '07

13 Jun '07

> Maybe you should be looking into the bit-packing macros provided > with the > Pascal Macro Compiler. This will give you bit-packing which is > independent of > the particular Pascal compiler you happen to be using. See > www.mastersoftware.biz/pasbit.htm Thanks, but I want to implement bit packing which is compatible with what gcc and other compilers use so data exchange is possible. Jonas That's precisely the point. The Borland, TMT, FPC and GPC compilers are not compatible on bit-packing. By using the Macro Compiler you get bit-packing which is independent of the compiler, so that programs compiled with any of these Pascal compilers can exchange data. Frank ************************************** See what's free at http://www.aol.com.

2 1

Unreachable label
by Adriaan van Os 13 Jun '07

13 Jun '07

Any comment on <http://www.freepascal.org/mantis/view.php?id=9053> and Daniël Mantione's note ? Regards, Adriaan van Os

7 10

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