On Aug 31, 1999, Nick Burrett <nick(a)dsvr.net> wrote:
> Alexandre Oliva <oliva(a)dcc.unicamp.br> writes:
>> +++ gcc/p/rts/file.c Sun Aug 29 15:56:11 1999
>> @@ -887,7 +887,7 @@
>> _p_f_write (File, Buf, Size)
[snip]
>> - ssize_t result =
>> + size_t result =
[snip]
>> - if (result < 0)
>> + if (result == (size_t)-1)
> You cannot do this. size_t may be unsigned.
That's the reason why I'm explicitly casting -1 to that type.
…
[View More]> Also fwrite returned zero on error
That's not covered in the original code. Since I've never heard of
fwrite returning less than -1, I think it is as correct as the
original code.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva(a){dcc.unicamp.br,guarana.{org,com}} aoliva(a){acm.org,computer.org}
oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them
[View Less]
On Aug 30, 1999, Peter Gerwinski <peter(a)gerwinski.de> wrote:
> Yes. gpc-19990813 does not build correctly with gcc-2.95.1.
> This is work in progress.
Well, I only had trouble on alpha platforms: both DU4.0 and GNU/Linux
crash the same way. It built correctly (but I haven't tested it at
all) on Solaris 7/sparc and /x86 and GNU/Linux/sparc and /x86. It
also presented some problems on SunOS 4.1.3, and installed man-pages
in the wrong directory. These problems are fixed with …
[View More]the following
additional patch:
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva(a){dcc.unicamp.br,guarana.{org,com}} aoliva(a){acm.org,computer.org}
oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them
[View Less]
Alexandre Oliva <oliva(a)dcc.unicamp.br> writes:
> --=-=-=
>
> On Aug 30, 1999, Peter Gerwinski <peter(a)gerwinski.de> wrote:
>
> > Yes. gpc-19990813 does not build correctly with gcc-2.95.1.
> > This is work in progress.
>
>
> --- gcc/p/rts/file.c~ Mon Aug 2 05:44:13 1999
> +++ gcc/p/rts/file.c Sun Aug 29 15:56:11 1999
> @@ -887,7 +887,7 @@
> _p_f_write (File, Buf, Size)
> void *File; const char *Buf; size_t Size;
> {
> - …
[View More] ssize_t result =
> + size_t result =
> /*@@@@@@@@ fwrite() has a known bug (fh19990305.2), but using write()
> together with fread(), fseek() etc. causes bigger problems.
> We choose the lesser of two evils by default. */
> @@ -896,7 +896,7 @@
> #else
> fwrite (Buf, 1, Size, (FILE *) File);
> #endif
> - if (result < 0)
> + if (result == (size_t)-1)
You cannot do this. size_t may be unsigned. Also fwrite returned zero
on error or a positive integer (number of elements written) on success.
Cheers,
Nick.
[View Less]
Hi -
We just got the latest version of gpc:
GNU Pascal version 19990118, based on gcc-2.8.1, compiled Aug 25 1999 09:07:02.
and it is objecting to a line of code in one of my programs:
ftp://ftp.ncifcrf.gov/pub/delila/makelogo.p
I am compiling with:
gpc makelogo.p -o makelogo
The message I get is:
makelogo.p: In function `Themain':
makelogo.p:4093: cannot take address of bitfield `B'
Line 4093 is:
readln(symvec,map[b].b, map[b].n);
b is defined as:
b: integer; (* …
[View More]index to a symbol *)
map is defined as:
position = 0..mapmax;
place = packed record
b: char; (* the symbol *)
n: integer (* the number of symbols *)
end;
so is it getting confused about the "two" uses of b?
I changed b to 'bloop' and made a new variable,
but the other b was still around and it still yelled:
makelogo.p: In function `Themain':
makelogo.p:4094: cannot take address of bitfield `B'
I even changed the definition so that:
readln(symvec,map[bloop].bsymbol, map[bloop].n);
but *STILL* got:
makelogo.p: In function `Themain':
makelogo.p:4094: cannot take address of bitfield `Bsymbol'
since map is used in other places, there seems to be a bug in the
use here in the middle of a readln.
So I defined
c: char;
and separated it;
readln(symvec,c, map[bloop].n);
map[bloop].bsymbol := c;
and now it compiles.
This program compiles just fine with the Sun compiler and translates
into C with p2c and compiles with gcc.
Regards,
Tom
Dr. Thomas D. Schneider
National Cancer Institute
Laboratory of Experimental and Computational Biology
Frederick, Maryland 21702-1201
toms(a)ncifcrf.gov
permanent email: toms(a)alum.mit.edu
http://www.lecb.ncifcrf.gov/~toms/
[View Less]
Hi,
I'm having a problem where strings seem to get corrupted when
they are returned as a CString from a module.
It is certainly possible that this is a problem on my end as I may be
illegally modifying strings in someway, as I am mixing EP string()
type variables and CStrings, as well as using {$x+} features. Is
there a good guide on how to use/convert the different string
types? I know this code used to work with older versions of gpc --
trying to move my Pascal code from OS/2 to Linux (…
[View More]more on that in next
message) caused me to find this.
Anyways here is a sample run of the code included below:
Main Loop: Hello there.
In Module: Hello there.
In Module(2): Hello there.
After Module: x)@xY@ere.
I replaced the high ASCII with an x to avoid mailer mangling.
I'm using the latest version of gpc (compiled for gcc-2.95) available
as a Debian package. It claims to be 19990610, but someone said that
the latest snapshot misreports? -- so I think it is the latest version.
If I'm wrong, sorry.
The code follows below:
foo.pas:
Module FOO Interface;
Export
FOO = (twine);
function twine(foobar : CString): CString;
end. { Interface }
Module FOO Implementation;
type
String25 = String(25);
function twine;
{$x+}
var
local : String25;
begin
writeln('In Module: ', foobar);
writestr(local, foobar, chr(0));
writeln('In Module(2): ', local);
twine := local;
end; { twine }
end. { FOO }
test.pas:
program test(input, output);
import foo;
var
foobaz : Cstring;
begin
{$x+}
foobaz := "Hello there.";
writeln('Main Loop: ', foobaz);
writeln('After Module: ', twine(foobaz));
end.
Thanks,
-Kevin
--
Kevin A. Foss ---- kfoss(a)mint.net
[View Less]
Dear All
I'm having problems with multiple #include "filename" lines with gpc-19990813
in a program that worked with gpc-19990118 (and others).
Example program is:
--------- solver.p -----------
program SOLVER(input,output);
#include "TurboP.def"
#include "WinLib.def"
#include "PlotLib.def"
#include "MxFiler.def"
begin
writeln("Hello!");
end.
-------------------------
% gpc -I./modules solver.p
solver.p:5: WinLib.def: No such file or directory
solver.p:6: PlotLib.def: No such …
[View More]file or directory
solver.p:7: MxFiler.def: No such file or directory
% gpc -I./modules -I./modules -I./modules -I./modules solver.p
% ./a.out
Hello!
Actually gpc -v reports 19990610, by the way.
Thanks
Ian
--
Ian Thurlbeck http://www.stams.strath.ac.uk/
Statistics and Modelling Science, University of Strathclyde
Livingstone Tower, 26 Richmond Street, Glasgow, UK, G1 1XH
Tel: +44 (0)141 548 3667 Fax: +44 (0)141 552 2079
[View Less]
Hi,
I still can't seem to be able to build gpc for HP-UX 10.20.
I tried all three available versions 19990118, 19990409, 19990607
and for each I get the same error:
../../xgpc -B../../ -c -I. -Wall -Wpointer-arith -Wmissing-prototypes
-Wmissing-declarations -O2 -g -O2 -DBSD_RTS=0 `if [ x@with_shared@ = xyes ] ;
then echo -fPIC; fi` --unit-path=/ece2/eeof/egcs-1.1.2/gcc/p/rts --automake
/ece2/eeof/egcs-1.1.2/gcc/p/rts/files.pas
/ece2/eeof/egcs-1.1.2/gcc/p/rts/files.pas: In function `Ioselect':…
[View More]
/ece2/eeof/egcs-1.1.2/gcc/p/rts/files.pas:162: internal error--unrecognizable
insn:
(insn 288 285 290 (set (zero_extract:SI (reg:SI 223)
(const_int 32)
(const_int 0))
(reg:SI 222)) -1 (insn_list 285 (insn_list 287 (nil)))
(expr_list:REG_DEAD (reg:SI 222)
(nil)))
../../../egcs-1.1.2/gcc/p/../toplev.c:1385: Internal compiler error in function
fatal_insn
make[3]: *** [files.o] Error 1
make[3]: Leaving directory `/ece2/eeof/gcc/gcc/p/rts'
make[2]: *** [pascal.rts] Error 2
make[2]: Leaving directory `/ece2/eeof/gcc/gcc'
make[1]: *** [bootstrap] Error 2
make[1]: Leaving directory `/ece2/eeof/gcc/gcc'
make: *** [bootstrap] Error 2
Anyone else had this problem? Is it a known limitation? (I'm not saying bug...)
Has anyone successfully built gpc on HP-UX?
Please cc me,
Thanks,
Dimitrios.
[View Less]
In message <38919B7D.19990813155556.FOO-5D74.frank(a)g-n-u.de> Frank Heckenbach writes:
> Hello, folks,
>
> a new GPC snapshot is available:
>
> ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/gpc-19990813.tar.gz
>
Help!
I'm having lots of problems building the new snapshot under RedHat
Linux 6.0 (kernel 2.2.5-15 on i586) using EGCS (source RPM egcs-1.1.2-12,
appears to be version 2.91.66).
I unpacked the egcs source into a directory tree, moved the
…
[View More]snapshot's p directory into gcc, applied the gcc-egcs-2.91.66 patch
(after a bit of editing of directory names within the patch file),
did a ./configure, and am now trying make LANGUAGES=pascal.
Is this the correct sequence of actions? The INSTALL file in the
snapshot doesn't seem to cover building GPC under EGCS.
I guess my first question is: should I be using EGCS or would I be
better off with a plain gcc source, and if so what version?
Various things I've come across so far:
The p/gpc_release file contains 19990610, I think it should contain
19990813.
I think there is something strange about the way the contents of the
gpc_release file is accessed - at the point where I see the make
doing a cd p, I then see an error message from cat that it cannot
find the gpc_release file. It looks as if there is one too few "../"s
on the front of the path to the file.
In p/gpc-common.c at line 2893, TREU_OVERFLOW should be
TREE_OVERFLOW, I think.
(Not a GPC problem): In my gcc/flow.c at line 1493, the code says
REG_N_SEDS, it should be REG_N_SETS, I think.
Finally, I come to a halt with
make[1]: Entering directory `/home/david/egcs/objs/gcc'
gcc -DIN_GCC -g -O2 -DHAVE_CONFIG_H -o cc1 c-parse.o c-lang.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
make[1]: *** [cc1] Error 1
make: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/david/egcs/objs/gcc'
I think the GCC line has been truncated in copying it between
systems.
Has anyone succeeded in compiling this snapshot in a similar
environment?
--
David James
mailto:david@tcs01.demon.co.uk
Special Stage Rally results archive <URL:http://www.tcs01.demon.co.uk/>
[View Less]