Gpc June 1999

gpc@gnu.de

22 participants
50 discussions

GNU Binary for SGI
by Oliver Puetz 03 Jun '99

03 Jun '99

Hi, I've downloaded the binary beta "gpc-19990118_mips-sgi-irix6_2_tar.gz" from ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/, as I'm not really familiar with unix. It should run on a SGI, Power-Challenge-XL12 with IRIX64 v6.2. GCC v2.7 is already installed. The environmental variable GPC_EXEC_PREFIX does not seem to work, setting the dir with -B as a command option helps. By compiling a little test program (no uses etc) a fatal error occured: ld32: FATAL 9: I/O error (-lgpc): No such file or directory I've copied the files from /gpc/usr/local/lib/gcc-lib/mips-sgi-irix6.2/2.8.1 into the bin-dir, but it doesn't helped. Can anyone help or had made experiences with this version? Thanks in advance Oliver -- Oliver Puetz Tel.: 0234-700-2982 Lehrstuhl fuer Fluidenergiemaschinen Fax.: 0234-7094-358 Ruhr-Universitaet Bochum, Universitaetsstr. 150, 44801 Bochum opuetz(a)fem.ruhr-uni-bochum.de Gebaeude IB 4/141 www.ruhr-uni-bochum.de/www-public/volgmwbr/mitarb/puetz.htm

2 1

run time trap with packed array of boolean
by Richard Sharman 02 Jun '99

02 Jun '99

gpc version 19990118, based on gcc-2.8.1 running on a sun % cat bug.pas program f(input, output) ; type lottery_number = 1..49 ; var lotto_1 : array[lottery_number] of boolean; lotto_2 : packed array[lottery_number] of boolean; n : integer ; begin n := 3 ; lotto_1[n] := true ; lotto_2[n] := true ; end . % gpc -o bug bug.pas % ./bug Bus error (core dumped) % ------------------------------------------------------------------------ What follows is a dump from gdb of the registers, the immediate context, and the full assember file (produced by gpc -S -g bug.pas). ------------------------------------------------------------------------ Continuing. Program received signal SIGBUS, Bus error. 0x231c in program_F () at bug.pas:16 1: x/i $pc 0x231c <program_F+140>: lduh [ %o4 + %o5 ], %o4 (gdb) p/x $pc-0x20 $pc A syntax error in expression, near `'. (gdb) disas $pc-0x20 $pc Dump of assembler code from 0x22fc to 0x231c: 0x22fc <program_F+108>: sethi %hi(0x2a800), %g2 0x2300 <program_F+112>: ld [ %g2 + 0x29c ], %g3 ! 0x2aa9c <N> 0x2304 <program_F+116>: add %g3, -1, %g2 0x2308 <program_F+120>: and %g2, 0xf, %g3 0x230c <program_F+124>: mov 1, %o7 0x2310 <program_F+128>: sll %o7, %g3, %g2 0x2314 <program_F+132>: mov %g2, %g3 0x2318 <program_F+136>: xnor %g3, 0, %g2 End of assembler dump. (gdb) sho reg Undefined show command: "reg". Try "help show". (gdb) info reg g0 0x0 0 g1 0xef780408 -277347320 g2 0xfffffffb -5 g3 0x4 4 g4 0x0 0 g5 0x0 0 g6 0x0 0 g7 0x0 0 o0 0x0 0 o1 0xeffff99c -268437092 o2 0x0 0 o3 0x2aa95 174741 o4 0x0 0 o5 0x2aa95 174741 sp 0xeffff860 -268437408 o7 0x1 1 l0 0x9 9 l1 0x21b8 8632 l2 0x0 0 l3 0x10000 65536 l4 0x10 16 l5 0x20008011 536903697 l6 0x38 56 l7 0x5 5 i0 0x1 1 i1 0xeffff99c -268437092 i2 0xeffff9a4 -268437084 i3 0x0 0 i4 0x0 0 i5 0x1834 6196 fp 0xeffff8d0 -268437296 i7 0x2504 9476 y 0x0 0 psr 0x41400080 1094713472 wim 0x0 0 tbr 0x0 0 pc 0x231c 8988 npc 0x2320 8992 fpsr 0x0 0 cpsr 0x0 0 (gdb) ------------------------------------------------------------------------ gcc2_compiled.: ___gnu_compiled_pascal: .stabs "/home/tools/sharman/pas-stuff/",100,0,0,Ltext0 .stabs "bug.pas",100,0,0,Ltext0 .text Ltext0: .stabs "Integer:t(0,1)=r(0,1);-2147483648;2147483647;",128,0,0,0 .stabs "Char:t(0,2)=@s8;-20;",128,0,0,0 .stabs "Medint:t(0,3)=r(0,3);-2147483648;2147483647;",128,0,0,0 .stabs "Sizetype:t(0,4)=r(0,4);0;-1;",128,0,0,0 .stabs "Medcard:t(0,5)=r(0,5);0;-1;",128,0,0,0 .stabs "Longestint:t(0,6)=r(0,1);01000000000000000000000;0777777777777777777777;",128,0,0,0 .stabs "Longestcard:t(0,7)=r(0,1);0000000000000;01777777777777777777777;",128,0,0,0 .stabs "Smallint:t(0,8)=r(0,8);-32768;32767;",128,0,0,0 .stabs "Shortcard:t(0,9)=r(0,9);0;65535;",128,0,0,0 .stabs "Byteint:t(0,10)=r(0,10);-128;127;",128,0,0,0 .stabs "Bytecard:t(0,11)=r(0,11);0;255;",128,0,0,0 .stabs "Longestreal:t(0,12)=r(0,1);8;0;",128,0,0,0 .stabs " complex int:t(0,13)=s8real:(0,1),0,32;imag:(0,1),32,32;;",128,0,0,0 .stabs " complex float:t(0,14)=r(0,14);4;0;",128,0,0,0 .stabs "Complex:t(0,15)=r(0,15);8;0;",128,0,0,0 .stabs " complex long double:t(0,16)=r(0,16);8;0;",128,0,0,0 .stabs "Ptrcard:t(0,17)=r(0,17);0;-1;",128,0,0,0 .stabs "Ptrint:t(0,18)=r(0,18);-2147483648;2147483647;",128,0,0,0 .stabs "String:t(0,19)=s12Capacity:(0,1),0,32;length:(0,1),32,32;string:(0,20)=ar(0,1);1;1;(0,21)=@s8;-20;,64,8;;",128,0,0,0 .stabs "Timestamp:t(0,22)=s36Datevalid:(0,23)=@s8;-16;,0,8;Timevalid:(0,23),8,8;Year:(0,1),32,32;Month:(0,24)=r(0,1);1;12;,64,32;Day:(0,25)=r(0,1);1;31;,96,32;Dayofweek:(0,26)=r(0,1);0;6;,128,32;Hour:(0,27)=r(0,1);0;23;,160,32;Minute:(0,28)=r(0,1);0;59;,192,32;Second:(0,28),224,32;Microsecond:(0,29)=r(0,1);0;999999;,256,32;;",128,0,0,0 .stabs "Bindingtype:t(0,30)=s312Bound:(0,23),0,8;Force:(0,23),8,8;Extensions_valid:(0,23),16,8;Readable:(0,23),24,8;Writable:(0,23),32,8;Executable:(0,23),40,8;Existing:(0,23),48,8;Directory:(0,23),56,8;Size:(0,6),64,64;Accesstime:(0,6),128,64;Modificationtime:(0,6),192,64;Changetime:(0,6),256,64;Error:(0,1),320,32;Cfile:(0,31)=*(0,32)=(0,32),352,32;Name:(0,33)=s264Capacity:(0,1),0,32;length:(0,1),32,32;string:(0,34)=ar(0,1);1;256;(0,21),64,2048;;,384,2112;;",128,0,0,0 .stabs "Pointer:t(0,31)",128,0,0,0 .stabs "Shortreal:t(0,35)=r(0,1);4;0;",128,0,0,0 .stabs "Real:t(0,36)=r(0,1);8;0;",128,0,0,0 .stabs "Cstring:t(0,37)=*(0,2)",128,0,0,0 .stabs "Boolean:t(0,23)",128,0,0,0 .stabs "Void:t(0,32)",128,0,0,0 .stabs "Text:t(0,38)=d(0,2)",128,0,0,0 .stabs "_p_MPNGHS:S(0,31)",40,0,1,__p_MPNGHS .reserve __p_MPNGHS,4,"bss",4 .stabs "_p_MPNGSL:S(0,31)",40,0,1,__p_MPNGSL .reserve __p_MPNGSL,4,"bss",4 .stabs "_p_MPNGFP:S(0,31)",40,0,1,__p_MPNGFP .reserve __p_MPNGFP,4,"bss",4 .stabs "Lottery_number:t(0,39)=(0,40)=r(0,1);1;49;",128,0,4,0 .stabs "Lotto_1:S(0,41)=ar(0,1);1;49;(0,23)",40,0,7,_Lotto_1 .reserve _Lotto_1,49,"bss",1 .stabs "Lotto_2:S(0,42)=ar(0,1);1;49;(0,23)",40,0,8,_Lotto_2 .reserve _Lotto_2,7,"bss",1 .stabs "N:S(0,1)",40,0,9,_N .reserve _N,4,"bss",4 .align 4 .global _program_F .proc 020 _program_F: .stabn 68,0,11,LM1 LM1: !#PROLOGUE# 0 save %sp,-112,%sp !#PROLOGUE# 1 .stabn 68,0,11,LM2 LM2: LBB2: LBB3: .stabn 68,0,13,LM3 LM3: sethi %hi(_N),%o2 mov 3,%o3 st %o3,[%o2+%lo(_N)] .stabn 68,0,15,LM4 LM4: sethi %hi(_Lotto_1),%o2 sethi %hi(_N),%o3 ld [%o3+%lo(_N)],%o4 add %o4,-1,%o3 or %o2,%lo(_Lotto_1),%o4 add %o3,%o4,%o2 mov 1,%o3 stb %o3,[%o2] .stabn 68,0,16,LM5 LM5: mov 1,%o2 stb %o2,[%fp-9] sethi %hi(_N),%o2 ld [%o2+%lo(_N)],%o3 add %o3,-1,%o0 sra %o0,4,%o2 mov %o2,%o0 mov %o0,%o3 sll %o3,1,%o2 sethi %hi(_Lotto_2),%o4 or %o4,%lo(_Lotto_2),%o3 mov %o0,%o5 sll %o5,1,%o4 sethi %hi(_Lotto_2),%g2 or %g2,%lo(_Lotto_2),%o5 sethi %hi(_N),%g2 ld [%g2+%lo(_N)],%g3 add %g3,-1,%g2 and %g2,15,%g3 mov 1,%o7 sll %o7,%g3,%g2 mov %g2,%g3 xnor %g3,0,%g2 lduh [%o4+%o5],%o4 mov %g2,%o5 and %o4,%o5,%o4 sth %o4,[%o2+%o3] sethi %hi(_N),%o2 ld [%o2+%lo(_N)],%o3 add %o3,-1,%o1 sra %o1,4,%o2 mov %o2,%o1 mov %o1,%o3 sll %o3,1,%o2 sethi %hi(_Lotto_2),%o4 or %o4,%lo(_Lotto_2),%o3 mov %o1,%o5 sll %o5,1,%o4 sethi %hi(_Lotto_2),%g2 or %g2,%lo(_Lotto_2),%o5 ldub [%fp-9],%g2 and %g2,1,%g3 and %g3,0xff,%g2 sethi %hi(_N),%g3 ld [%g3+%lo(_N)],%o7 add %o7,-1,%g3 and %g3,15,%o7 sll %g2,%o7,%g2 lduh [%o4+%o5],%o4 mov %g2,%o5 or %o4,%o5,%o4 sth %o4,[%o2+%o3] sethi %hi(_N),%o2 ld [%o2+%lo(_N)],%o3 add %o3,-1,%o2 sra %o2,4,%o3 mov %o3,%o4 sll %o4,1,%o2 sethi %hi(_Lotto_2),%o4 or %o4,%lo(_Lotto_2),%o3 add %o2,%o3,%o2 sethi %hi(_N),%o3 ld [%o3+%lo(_N)],%o4 add %o4,-1,%o3 sra %o3,4,%o4 mov %o4,%o5 sll %o5,1,%o3 sethi %hi(_Lotto_2),%o5 or %o5,%lo(_Lotto_2),%o4 add %o3,%o4,%o3 sethi %hi(_N),%o4 ld [%o4+%lo(_N)],%o5 add %o5,-1,%o4 and %o4,15,%o5 mov 1,%g2 sll %g2,%o5,%o4 srl %o4,16,%o5 mov %o5,%o4 xnor %o4,0,%o5 lduh [%o3+2],%o3 mov %o5,%o4 and %o3,%o4,%o3 sth %o3,[%o2+2] sethi %hi(_N),%o2 ld [%o2+%lo(_N)],%o3 add %o3,-1,%o2 sra %o2,4,%o3 mov %o3,%o4 sll %o4,1,%o2 sethi %hi(_Lotto_2),%o4 or %o4,%lo(_Lotto_2),%o3 add %o2,%o3,%o2 sethi %hi(_N),%o3 ld [%o3+%lo(_N)],%o4 add %o4,-1,%o3 sra %o3,4,%o4 mov %o4,%o5 sll %o5,1,%o3 sethi %hi(_Lotto_2),%o5 or %o5,%lo(_Lotto_2),%o4 add %o3,%o4,%o3 ldub [%fp-9],%o4 and %o4,1,%o5 and %o5,0xff,%o4 sethi %hi(_N),%o5 ld [%o5+%lo(_N)],%g2 add %g2,-1,%o5 and %o5,15,%g2 sll %o4,%g2,%o4 srl %o4,16,%o5 lduh [%o3+2],%o3 mov %o5,%o4 or %o3,%o4,%o3 sth %o3,[%o2+2] .stabn 68,0,18,LM6 LM6: LBE3: LBE2: .stabn 68,0,18,LM7 LM7: L1: ret restore .stabs "program_F:F(0,32)",36,0,11,_program_F .stabn 192,0,0,LBB2 .stabs "assign_packed_0:(0,23)",128,0,16,-9 .stabn 192,0,0,LBB3 .stabn 224,0,0,LBE3 .stabn 224,0,0,LBE2 .align 4 .global ___init_program_F .proc 020 ___init_program_F: .stabn 68,0,18,LM8 LM8: !#PROLOGUE# 0 save %sp,-104,%sp !#PROLOGUE# 1 .stabn 68,0,18,LM9 LM9: LBB4: sethi %hi(__p_collect_flag),%o0 ld [%o0+%lo(__p_collect_flag)],%o1 cmp %o1,0 be L3 nop sethi %hi(___init_program_F),%o1 or %o1,%lo(___init_program_F),%o0 mov 0,%o1 call __p_collect,0 nop b L2 nop L3: LBE4: .stabn 68,0,18,LM10 LM10: L2: ret restore .stabs "__init_program_F:F(0,32)",36,0,18,___init_program_F .stabn 192,0,0,LBB4 .stabn 224,0,0,LBE4 .align 4 .global ___fini_program_F .proc 020 ___fini_program_F: .stabn 68,0,18,LM11 LM11: !#PROLOGUE# 0 save %sp,-104,%sp !#PROLOGUE# 1 .stabn 68,0,18,LM12 LM12: L4: ret restore .stabs "__fini_program_F:F(0,32)",36,0,18,___fini_program_F .align 4 .global _main .proc 04 _main: .stabn 68,0,18,LM13 LM13: !#PROLOGUE# 0 save %sp,-104,%sp !#PROLOGUE# 1 st %i0,[%fp+68] st %i1,[%fp+72] st %i2,[%fp+76] call ___main,0 nop ld [%fp+68],%o0 ld [%fp+72],%o1 ld [%fp+76],%o2 call __p_initialize,0 nop call _program_F,0 nop mov 0,%i0 b L5 nop .stabn 68,0,18,LM14 LM14: L5: ret restore .stabs "main:F(0,1)",36,0,18,_main .stabs "argc:p(0,1)",160,0,18,68 .stabs "argv:p(0,43)=*(0,37)",160,0,18,72 .stabs "envp:p(0,43)",160,0,18,76 .align 4 .global __GLOBAL_$I$program_F .proc 020 __GLOBAL_$I$program_F: .stabn 68,0,19,LM15 LM15: !#PROLOGUE# 0 save %sp,-104,%sp !#PROLOGUE# 1 call ___init_program_F,0 nop .stabn 68,0,19,LM16 LM16: L6: ret restore .stabs "_GLOBAL_$I$program_F:F(0,32)",36,0,19,__GLOBAL_$I$program_F .align 4 .global __GLOBAL_$D$program_F .proc 020 __GLOBAL_$D$program_F: .stabn 68,0,19,LM17 LM17: !#PROLOGUE# 0 save %sp,-104,%sp !#PROLOGUE# 1 call ___fini_program_F,0 nop .stabn 68,0,19,LM18 LM18: L7: ret restore .stabs "_GLOBAL_$D$program_F:F(0,32)",36,0,19,__GLOBAL_$D$program_F ------------------------------------------------------------------------

1 0

Re: Initialization of sets in a "var" statement inccorrect on the Sun.
by Frank Heckenbach 02 Jun '99

02 Jun '99

Richard Sharman wrote: > The example below shows that sets have the wrong value from the > initialization, but are ok if calcuated or if set in the code. > > var > vowels : letter_set := [ 'a', 'e', 'i', 'o', 'u' ] ; > > is inconrrect, > > vowels := [ 'a', 'e', 'i', 'o', 'u' ] ; > > works fine. > > I suspect it would work on a low-endian machine, but does not work > on a big-endian. [...] Your observation is correct. We recently discovered that there is a disagreement about the representation of sets (as fields consisting of bytes or words) betweem the frontend and backend. On little-endian machines, this doesn't matter, but on big-endian ones, it's a problem. Since I experienced the problem on a Sun as well, and currently no-one has the time to make a real solution, I made a quick patch (aka kludge)-: for 32-bit big-endian machines. It doesn't change anything on little-endian machines, but it still does not work on 64-bit big-endian machines. The following is for GCC-2.8.1, but might work with EGCS as well (to be applied in the gcc source directory, not the p subdirectory). This is an "unofficial" patch, but your test program works with this patch under sparc-sun-solaris2. --- tree.c.orig Fri Apr 30 04:08:09 1999 +++ tree.c Fri Apr 30 04:13:13 1999 @@ -4801,8 +4801,7 @@ tree vals = TREE_OPERAND (init, 1); int set_word_size = BITS_PER_UNIT; int bit_size = wd_size * set_word_size; - int bit_pos = 0; - unsigned char *bytep = buffer; + int bit_pos = 0, byte_index = 0; char *bit_buffer = (char *) alloca(bit_size); tree non_const_bits = get_set_constructor_bits (init, bit_buffer, bit_size); @@ -4813,14 +4812,18 @@ { if (bit_buffer[i]) { +/* @@@@@@@@@@@ THIS IS A KLUDGE FOR GPC SETS!!! + IT WORKS ONLY FOR 32 BIT BIG-ENDIAN SYSTEMS. + (On little-endian systems, it works correctly.) */ +#define BYTES_PER_WORD 4 if (BYTES_BIG_ENDIAN) - *bytep |= (1 << (set_word_size - 1 - bit_pos)); + buffer [byte_index + BYTES_PER_WORD - 1 - 2 * (byte_index % BYTES_PER_WORD)] |= 1 << bit_pos; else - *bytep |= 1 << bit_pos; + buffer [byte_index] |= 1 << bit_pos; } bit_pos++; if (bit_pos >= set_word_size) - bit_pos = 0, bytep++; + bit_pos = 0, byte_index++; } return non_const_bits; } Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: Virtual tables and GPC runtime?
by Frank Heckenbach 02 Jun '99

02 Jun '99

Jo Dillon wrote: > As I've said before on this list, I'm porting an Object Pascal application > to MacOS using a GPC cross-compiler. I've got a sort of minimal > runtime system on the Mac, which enables my application to run - however, > it explodes on (as far as I can see) the first call to a virtual function. > This may be because my implementation of GPC_New/_p_new just looks > like this: > > void * _p_new(int size) > { > return malloc(size); > } > > Whereas the proper one appears to do thinks like mark the object. My question > is, is it the case that I need to fix up the vtbl in _p_new, and if so where > do I do it? Where does marking fit into it? The "marking" mentioned in rts/heap.pas refers to the Mark/Release statements. If you don't use them, you could omit this for now. However, you should probalby check if the return value of malloc() is NULL, and cause a runtime error if so. Actually, can't you just take most of the code in rts/heap.pas (and the little bits in rts/rt0.c? AFAICS, they're essentially based on malloc()/free(), and therefore might work under MacOS as is. But all of this might not have anything to do with the problem you're experiencing... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: GPC BUG: String comparison with less or greater than does not work
by Frank Heckenbach 02 Jun '99

02 Jun '99

pdietrich(a)synstar.de wrote: > GPC cannot compare string with < or >. The following program shows this > fact: > > program test (output); > > var > str1 : string[10] := 'MODULE'; > str2 : string[10] := 'LABEL'; > > begin > writeln ('str1=str2: ', str1=str2); > writeln ('str1<str2: ', str1<str2); > writeln ('str1>str2: ', str1>str2); > end. > > The output of this program is: > > str1=str2: False > str1<str2: False > str1>str2: False There was a bug in the last beta release (only), in that the (non-trimming) '>' and '<=' string operators were mixed up. This will be fixed in the next release. Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Virtual tables and GPC runtime?
by Jo Dillon 02 Jun '99

02 Jun '99

As I've said before on this list, I'm porting an Object Pascal application to MacOS using a GPC cross-compiler. I've got a sort of minimal runtime system on the Mac, which enables my application to run - however, it explodes on (as far as I can see) the first call to a virtual function. This may be because my implementation of GPC_New/_p_new just looks like this: void * _p_new(int size) { return malloc(size); } Whereas the proper one appears to do thinks like mark the object. My question is, is it the case that I need to fix up the vtbl in _p_new, and if so where do I do it? Where does marking fit into it? -- Jo

2 1

GPC BUG: String comparison with less or greater than does not work
by pdietrich＠synstar.de 02 Jun '99

02 Jun '99

Hello, I found the following bug in the Beta version of GPC. Best regards, Peter Dietrich -------------------- GPC-Version (gpc -v): Reading specs from C:\usr\local\lib\gcc-lib\i386-mingw32\2.8.1\specs gpc version 19990118, based on gcc-2.8.1 System-Version: Windows NT 4.0 on i386 Problem description: GPC cannot compare string with < or >. The following program shows this fact: program test (output); var str1 : string[10] := 'MODULE'; str2 : string[10] := 'LABEL'; begin writeln ('str1=str2: ', str1=str2); writeln ('str1<str2: ', str1<str2); writeln ('str1>str2: ', str1>str2); end. The output of this program is: str1=str2: False str1<str2: False str1>str2: False

1 0

Initialization of sets in a "var" statement inccorrect on the Sun.
by Richard Sharman 01 Jun '99

01 Jun '99

The example below shows that sets have the wrong value from the initialization, but are ok if calcuated or if set in the code. var vowels : letter_set := [ 'a', 'e', 'i', 'o', 'u' ] ; is inconrrect, vowels := [ 'a', 'e', 'i', 'o', 'u' ] ; works fine. I suspect it would work on a low-endian machine, but does not work on a big-endian. Dumping the set of vowels shows 44 41 04 00 which I thnk means [ 10 16 22 26 30 ] or [ j p v z ??? ] , whears it should be (and if you read from left you right you get) [ 1 5 9 15 21 ] or [ a e i o u ] . >From the assembly file _Vowels: .ascii "DA\4\0" is incorrect here. For the assigment at line 22 there is inline code with specific ORs rather than moving constants. % cat e.pas program e(input, output) ; type small = 0..10 ; small_set = set of small ; letter = 'a' .. 'z' ; letter_set = set of letter ; var vowels : letter_set := [ 'a', 'e', 'i', 'o', 'u' ] ; smalls : small_set := [ 1, 3, 5, 7, 9 ] ; c : letter ; i : integer ; begin writeln('vowels #1:') ; for c := 'a' to 'z' do if c in vowels then writeln(c) ; writeln ; vowels := [ 'a', 'e', 'i', 'o', 'u' ] ; writeln('vowels #2 :') ; for c := 'a' to 'z' do if c in vowels then writeln(c) ; writeln ; writeln('smalls #1 :') ; for i := 0 to 10 do if i in smalls then write(i:1, ' ') ; writeln; smalls := [] ; for i := 0 to 10 do if odd(i) then smalls := smalls + [i] ; writeln('smalls #2:') ; for i := 0 to 10 do if i in smalls then write(i:1, ' ') ; writeln; end. % gpc -o e e.pas e.pas: In function `program_E': e.pas:38: warning: constructing limited integer set `0..255' % ./e vowels #1: j p v z vowels #2 : a e i o u smalls #1 : smalls #2: 1 3 5 7 9 % Richard

1 0

Re: can't compile crtc.c
by Frank Heckenbach 01 Jun '99

01 Jun '99

Russ Whitaker wrote: > Thanks > another small step forward > > Now when i compile and run > > program win; > uses CRT; > begin > end. > > i get: > Error opening terminal: linux. > Segmentation fault > > What did i overlook? Somehow the ncurses library doesn't find the Linux terminfo description. That seems quite strange to me on a Linux system... Do other ncurses programs (e.g. yast, vi) cause a similar problem? Did you download the ncurses binary from agnes, or do you use the one that came with your Linux distribution? I think, the latter is preferable, so if you downloaded the binary from agnes, you could try uninstalling it (if you didn't overwrite the other one with it). Can you check if the terminfo file is there and world-readable (on my system, it's /usr/lib/terminfo/l/linux, but it might be another directory, like share or lib/share instead of lib, or /usr/local instead of /usr)? You can also try putting the base directory (without the l, i.e. /usr/share/terminfo in this example) into the environment variable TERMINFO before starting the program. (The binary on agnes, searches in /usr/lib/terminfo, I think, so if it's elsewhere on your system and you have that binary, you might also be able to help it with a symlink.) The good news is that the next release will not segfault, but simply abort with an error status in this situation... :-/ Frank -- Frank Heckenbach, frank(a)fjf.gnu.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

1 0

Re: can't compile crtc.c
by Russ Whitaker 01 Jun '99

01 Jun '99

Thanks another small step forward Now when i compile and run program win; uses CRT; begin end. i get: Error opening terminal: linux. Segmentation fault What did i overlook? ---------- > From: Frank Heckenbach <frank(a)tim.gerwinski.de> > To: gpc(a)gnu.de > Subject: Re: can't compile crtc.c > Date: Monday, May 31, 1999 2:10 PM > > We are aware of this problem and are thinking about a "right" > solution. > > As a workaround, please insert the following line into crtc.c before > the first #include: > > #define _GNU_SOURCE

1 0

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 June 1999