- Gpc - gnu.de

range checking
by Adam Naumowicz 29 Aug '01

29 Aug '01

Hello, Maybe that is a trivial question but I want to know whether there is a way to turn on/off range checking with GPC. I missed to find it in the man pages, seems it is in the set of options inherited from GCC which I'm not very familiar with ;-) Thanks in advance, Adam Naumowicz -------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------

3 2

gcc-3
by Russell Whitaker 27 Aug '01

27 Aug '01

Hi Frank, Peter: Now that gcc-3.0.1 is out, looked at libbackend.a which is an internal lib of gcc's OBJS and compared that with the list of OBJS in 2.95.3: (no guarentee the following is 100% accurate) Going from 2.95.3 to 3.01: These were droped: stupid.o getpw.o mbchar.o dyn-string.o These are added: diagnostic.o builtins.o haifa-sched.o regrename.o predict.o lists.o ggc-common.o stringpool.o simplify-rtx.o ssa.o bb.reorder.o dcc.o sched-vis.o sched-dcps.o sched-rgn.o sched-ebb.o params.o ( What started this train of thought was the idea that perhaps I could make a 2.95.3 version of libbackend.a and then try writing a makefile to compile gpc without recompiling gcc. Last step would be to try using 3.0.1 libbackend.a ). The lists above any help? Russ

1 0

Re: Need a complete set implementation in GPC (data alignment)
by da Silva, Joe 23 Aug '01

23 Aug '01

Please see below ... Joe. > -----Original Message----- > From: Sven Jauring [SMTP:sven.jauring@hiq.se] > Sent: Thursday, August 23, 2001 6:52 PM > To: gpc(a)gnu.de > Subject: Re: Need a complete set implementation in GPC (data > alignment) > > Hi Frank > > Thank you for your help. I modifed the compiler according to your > instructions so that it uses Byte instead of MedCard for sets. > It worked wonders for the two 8 bit sets. (BSLB and BSHB in my example > code below). > Unfortunately I ran into trouble with the 16 bit sets. > > I need BIT0 to represent the least and BIT15 the most significant bit, but > since the 16 bit set is split into two bytes, BIT8 represents the least > and BIT7 the most significant bit: > > +-----+---+----+-----+---+----+ > USRINT |bit15|...|bit8|bit7 |...|bit0| > +-----+---+----+-----+---+----+ > BT |BIT7 |...|BIT0|BIT15|...|BIT8| > +-----+---+----+-----+---+----+ > > This seems like some sort of LittleEndianness? > [Joe da Silva] It sure does! Since this code seems to still be supported by it's creators, perhaps you can request them to put some sort of conditional compilation in the code, to take care of big/little-endianness? > Is it possible to have the byte order shifted, so that USRINT and BT > aligns? > > I can't just change the order of declaration for BITS, e.g > BITS=(BIT8,...,BIT15,...,BIT0,...,BIT7), since that would "undermine" the > use of ord() and subsets (e.g [BIT6..BIT8]). > > The Pascal code that I need to compile is not actually ours, so any > changes to the code has to be done everytime a new version is released. > (It is also rather large...) > The code would not have had this kind of contructions had it been ours. > ;-) > > Best Regards > Sven Jauring > > Frank Heckenbach wrote: > > Sven Jauring wrote: > > > Recently I posted some questions concerning problems with 16 bit > sets. > > I got good suggestions from some of you, but further analysis of > the > > code revealed this kind of construct: > > **************************** > > TYPE > > INT16 = INTEGER(16); > > INT8 = packed 0.. > > INT0_65535 = packed 0..65535; > > B_TYPE = (B1, B2, B3, B4, B5, B6, B7, B8); > > BITS = > (BIT0,BIT1,BIT2,BIT3,BIT4,BIT5,BIT6,BIT7,BIT8,BIT9, > > > > BIT10,BIT11,BIT12,BIT13,BIT14,BIT15); > > B_TYPE_SET = set of B_TYPE; > > BIT_SET = set of BITS; > > > > VAR > > OUT_REC = record case INT16 of > > 0 : (BSLB: B_TYPE_SET; > > BSHB: B_TYPE_SET); > > 1 : (USRINT : INT0_65535); > > 2 : (BT: BIT_SET); > > END; > > > > ****************************** > > I haven't followed the thread too intensely since I was out of town > last week. If I understand it correctly, what you need is that a set > > of a type of, say 8, elements is only 1 byte large. (However, in the > > code above, there will also be endianness problems, i.e. on a > little-endian system BSLB would align with the least significant > bits of USRINT and on a big-endian system with the most significant > bits; this problem could be overcome with a conditional compilation, > > see, e.g., the declaration of TWindowXY in GPC's CRT unit). > > GPC internally stores sets as arrays of a certain type, currently > MedCard. It is fairly easy to change that type to Byte (requires a > small change in p/rts/sets.pas (TSelElement) and two in p/util.c > (set_word_size and set_alignment)). > > However note: > > - This will slightly decrease the performance of set routines since > they will use byte rather than word operations internally. > > - Sets with and without this change will be incompatible. Don't try > to mix object files created by a patched and an unpatched > compiler. > > - This works only down to bytes. Trying even smaller types (like > Cardinal (4)) there will not work. > > Another approach would be to keep the array of words for sets at > least as big as a word, and use a single smaller type for smaller > sets. Then they would take only as many bits as required within a > packed record. However, this would require quite some effort. > Basically, every set operation would have to check if their > arguemnts are of the second type and convert them, and likewise > convert back the result. > > Personally, I'd suggest to change your Pascal code to not rely on > the variant alignment and such ... > > 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> > << File: Card for Sven Jauring >>

1 0

Need a complete set implementation in GPC (data alignment)
by Sven Jauring 23 Aug '01

23 Aug '01

Hi Recently I posted some questions concerning problems with 16 bit sets. I got good suggestions from some of you, but further analysis of the code revealed this kind of construct: **************************** TYPE INT16 = INTEGER(16); INT8 = packed 0.. INT0_65535 = packed 0..65535; B_TYPE = (B1, B2, B3, B4, B5, B6, B7, B8); BITS = (BIT0,BIT1,BIT2,BIT3,BIT4,BIT5,BIT6,BIT7,BIT8,BIT9, BIT10,BIT11,BIT12,BIT13,BIT14,BIT15); B_TYPE_SET = set of B_TYPE; BIT_SET = set of BITS; VAR OUT_REC = record case INT16 of 0 : (BSLB: B_TYPE_SET; BSHB: B_TYPE_SET); 1 : (USRINT : INT0_65535); 2 : (BT: BIT_SET); END; ****************************** The code heavily depends on the record variants to be aligned exactly on top of each other. Is there anyone in the GPC project that is working, or planning to work, on this issue? ("optimized set constructor"??) How long would it take? The company I'm working for, HiQ Approve AB, is willing to discuss a financial contribution to get this done. Best Regards Sven Jauring

2 2

Variables not on the stack
by Oldham, Adam 22 Aug '01

22 Aug '01

I was wondering if anyone could tell me where variables not are not declared within procedures (aka not on the stack) are stored? And can this address space be changed by the user easily? Thanks, Adam ----------------------------------------------------------------------- C. Adam Oldham Marconi Commerce Systems Inc. Software Engineer 7300 West Friendly Ave. adam.oldham(a)marconi.com Greensboro, NC 27420-2087 Phone : 336.547.5952 Fax : 336.547.5079 ----------------------------------------------------------------------- This document contains confidential information of Marconi Commerce Systems Inc. In consideration of the receipt of this document, the recipient agrees not to reproduce, copy, use or transmit this document and/or the information contained herein, in whole or in part, or to suffer such actions by others, for any purpose except with written permission, first obtained, of Marconi Commerce Systems Inc., and further agrees to surrender the same to Marconi Commerce Systems Inc. upon demand. -----------------------------------------------------------------------

4 3

gpc compilation error under Solaris 7
by Thomas Keller 20 Aug '01

20 Aug '01

Dear support I just tried to compile gpc on Sun Solaris 7 with gcc 2.95.3. I got the following error message: Making info file `gpc.info' from `gpc.texi'. ../install.texi:143: Unknown command `smallformat'. ../install.texi:145: Unmatched `@end'. ../install.texi:155: Unknown command `smallformat'. ../install.texi:158: Unmatched `@end'. ../reference.texi:8587: itemize requires an argument: the formatter for @item. ../reference.texi:8599: itemize requires an argument: the formatter for @item. makeinfo: Removing output file `gpc.info' due to errors; use --force to preserve. make: *** [p/doc/en/info/gpc.info] Error 2 Can you give some hints how to overcome this problem? Thomas

2 1

output segmentation fault
by Christopher Ferrall 17 Aug '01

17 Aug '01

Before I spent a lot of time getting RewriteDemo to fail in the same way, any short answer to the following? A program that was running under Linux is failing on a sunfire cluster with GPC recently installed. The "RewriteDemo" in the manual executes normally, and I've tried several variants of the following code segments with the same results. var dmp_file : text; envname : string; ... assign(dmp_file,envname+'.output'); extend(dmp_file); ... A gdb backtrace: (gdb) run Starting program: /home/hpc1014/fmtest/./a.out Program received signal SIGSEGV, Segmentation fault. 0xff2b303c in strlen () from /usr/lib/libc.so.1 (gdb) bt #0 0xff2b303c in strlen () from /usr/lib/libc.so.1 #1 0xff302890 in _doprnt () from /usr/lib/libc.so.1 #2 0xff304658 in sprintf () from /usr/lib/libc.so.1 #3 0x2f664 in _p_get_file_name (File=0x690d8) at file.c:1512 #4 0x358b8 in Ioerrorfile (N=404, F=@0x690d8) at error.pas:849 #5 0x43050 in _p_unbind (File=0x690d8) at bind.c:271 #6 0x3d20c in Assignfile (T=@0x690d8, Name=@0xffbed128) at files.pas:198 #7 0x1bcec in Client_create (Environment=0x6da88, Starting_point=0x0, Starting_options=0x0) at /home/hpc1014/fmopt/fmopt_client.pas:215 #8 0x17804 in Fm_create (Environment=@0xffbed8b8, Fmobject=@0xffbed890, Starting_point=0x0, Starting_options=0x0, Sname=@0xffbed8a8) at /home/hpc1014/fmopt/fmopt.pas:86 #9 0x2b700 in Tmain () at /home/hpc1014/fmtest/testsh.pas:72 #10 0x2b794 in pascal_main_program () at /home/hpc1014/fmtest/testsh.pas:80 #11 0x2bb80 in main (argc=1, argv=0xffbefdec, envp=0xffbefdf4) at <implicit code>:81

2 1

gpc compilation error
by Thomas Keller 17 Aug '01

17 Aug '01

Hi I just tried to compile gpc on Sun Solaris 7 with gcc 2.95.3. I got the following error message: In file included from gpc-common.c:29: gbe.h:152: conflicting types for `xmalloc' ../../include/libiberty.h:129: previous declaration of `xmalloc' In file included from gpc-common.c:35: util.h:196: conflicting types for `concat' ../../include/libiberty.h:48: previous declaration of `concat' make[2]: *** [gpc-common.o] Error 1 make[2]: Leaving directory `/usr/local/gcc-2.95.3/gcc/p' make[1]: *** [gpc1] Error 2 make[1]: Leaving directory `/usr/local/gcc-2.95.3/gcc' make: *** [all-gcc] Error 2 Can you give some hints how to overcome this problem? with best regards Thomas

2 1

GPC Pedigree
by Loris Caren 17 Aug '01

17 Aug '01

Forgive me if this is a FAQ - the archive is still down and I haven't seen the question in the last month! Can anybody point to 'significant' users of GPC that I can offer to management to demonstate it's pedigree? I'd particularly like to hear of users in the aerospace / safty industries and in embedded environments.

1 0

GPC on Mac OS X / Darwin.
by pascal.pignard 16 Aug '01

16 Aug '01

Hello, I try and retry to port GPC - GNU Pascal compiler - on Mac OS X, all details are on my french web site http://perso.wanadoo.fr/blady section "Créations". I try the port with gcc 2.95.2 - (926-3) and gpc 2.1 (20010417). My strategy is to modified compiler files with the Apple gcc modified files, as it has been done for gpc based on GNU gcc files. I obtain some internal error when launching gpc - please see results file at http://perso.wanadoo.fr/blady/telechargements/gpc/resultats.pdf. The compiler don't seem to accept CALL instr for reload operation. Perhaps, I may have modify some critical sections for the compiler - please see http://perso.wanadoo.fr/blady/telechargements/gpc/CompGPC2_1.pdf for my instructions to build the compiler and http://perso.wanadoo.fr/blady/telechargements/gpc/gpc_a.tgz for the modified source files. Can you indicate where are these errors ? Otherwise, can you indicate me an other person to contact ? Is there any other person who is involved in the same port ? Thanks for all your effort, I apologize for my bad English and the French texts. Best regards, Pascal Pignard.

1 0