Gpc November 1998

gpc@gnu.de

18 participants
47 discussions

Tests
by Miklos Cserzo 05 Nov '98

05 Nov '98

Hi Folks, I am testing the 0830 alpha distribution on different systems. The compilation is OK but the a number of sample codes in p/test are failed. Is there a system where ALL the tests are OK? Cheers, miklos

2 1

GPC enumerations bug?
by Jo Dillon 05 Nov '98

05 Nov '98

Hi, I have a small test program which doesn't compile: (file babyunit.pas) unit babyunit; interface type bug=(beetle, ant); procedure printbug(b : bug); implementation procedure printbug(b : bug); begin case b of beetle : writeln('beetle'); ant : writeln('ant') end end; end. (file baby.pas) program baby; uses babyunit; var lp : bug; type insect=(beetle, ant); begin {for lp:=bug(beetle) to bug(ant) do} { this compiles! } for lp:=beetle to ant do printbug(lp); end. Compiler error: gpc -g -c -w babyunit.pas gpc -g -c -w baby.pas baby.pas: In function `program_Baby': baby.pas:10: incompatible types in assignment It looks to be a problem with having the same identifier used in two enumerations; if those two enumerations are in the same unit a more informative error message results, such as: baby.pas:7: conflicting types for `Beetle' baby.pas:6: previous declaration of `Beetle' baby.pas:7: conflicting types for `Ant' baby.pas:6: previous declaration of `Ant' baby.pas: In function `program_Baby': baby.pas:11: incompatible types in assignment (when type foo=(beetle,ant); is added immediately after type insect in baby.pas). This is the most recent gpc beta snapshot compiled against the gcc 2.8.1 backend on intel/linux. Any ideas? Is this a compiler bug? -- Jo Harmony - the project to create an LGPL Qt clone http://harmony.ruhr.de

2 1

libgcc.a
by Thamm, Russell 05 Nov '98

05 Nov '98

I always wondered why the GPC distribution contained a different libgcc.a than the GCC distribution. I assumed that the GPC version had some extra stuff in it. However, it appears that the latest GPC version is incompatible with GNU C++. I've just spent all morning trying to make the GAWS package. Every time I tried to make any examples, I got heaps of linker errors. Eventually, in desparation, I replaced libgcc.a with the copy in GCC281b.ZIP. Suddenly all my linker errors dissappeared. I also note that the libgcc.a in the latest beta version of GPC is considerably shorter than the ones in previous versions. So what is the story with the GPC version of libgcc.a? thanks Russell BTW. I'm finally subscribed to this mailing list.

3 3

compiling grx20.pas
by Robert P. Ewing 04 Nov '98

04 Nov '98

Hi, all. I'm having trouble getting the grx20.pas unit to compile. If I just do a compile (gpc -g-c grx20.pas -o grx20.o), there are no errors. But when I attempt to Make it (this is in RHIDE), I see: compiling: c:\gpc\pascal\grx20.pas crt0.s: undefined reference to 'main' crt1.c: undefined reference to 'main' there were some errors Now I can't find any crt0.s or crt1.c files anywhere on the hard drive, so I don't think that's the problem... Is this a compiler bug, or can I get around it by changing some compiler flags or a few lines in the code? By the way, I'm using RHIDE 1.4, and the new beta gpc binary downloaded just a month ago. Any help would be appreciated. Toby Ewing ewing(a)iastate.edu

2 1

Re: corrections for GPC 19980830 (SunOS|BSD)
by Frank Heckenbach 02 Nov '98

02 Nov '98

Kevin A. Foss wrote: > Yes, it is hard to say what would be "correct" for the system. The C > standard however does require a minimum of 32767, so setting it to that > should be safe or you could even set it to INT_MAX I suppose (which > -should- be defined in limits.h.) Not in general. Under Solaris, INT_MAX is $7fffffff, but RAND_MAX is only 32767. But when you say 32767 is the required minimum, I can use that if RAND_MAX isn't defined. This gives 15 random bits with one rand() call, so a 64 bit random number requires 5 rand() calls which is at least not *terribly* inefficient... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: corrections for GPC 19980830 (SunOS|BSD)
by Kevin A. Foss 01 Nov '98

01 Nov '98

On Sun, 1 Nov 1998 18:30:46 +0100, Frank Heckenbach wrote: >Harald A. Irmer wrote: >> 3.RAND_MAX (p/rts/random.c) is not known to SunOS, neither to gcc, set for my >> purpose #define RAND_MAX 32767 > >Hmmm... according to my rand() manpage, it's part of ISO, but anyway... The problem here stems from the fact that SunOS does not normally come with an ANSI C compiler. (I ran into these problems several years ago back when I used a SunOS in college -- although not with gpc which I never tried as Sun's Pascal compiler isn't too bad.) On some systems there are compliant headers in /usr/5include but not in /usr/include. Basically the latter is for the "BSD environment" [icky.] and the former is for the "SysV environment" [the ANSI C we all love.] Unfortunately I never played around enough to figure out how to get SysV as the default :( The original poster put "BSD" in the header so if he wants that environment he should be prepared for the problem that this is going to cause trying to compile ANSI C code. To be honest I thought gcc came with scripts to 'fix' the SunOS headers -- but I don't have a source tree handy to check the READMEs. A Sun FAQ I found on dejanews recommends running 'fixincludes' after installing GCC but that is with the precompiled binaries. >Or to say it differently: how do you know that 32767 is correct for >SunOS? Does SunOS document it? (As a general fact or only for SunOS?) Or >is it written in some header in some way? Yes, it is hard to say what would be "correct" for the system. The C standard however does require a minimum of 32767, so setting it to that should be safe or you could even set it to INT_MAX I suppose (which -should- be defined in limits.h.) -Kevin -- Kevin A. Foss --- kfoss(a)mint.net

1 0

Re: corrections for GPC 19980830 (SunOS|BSD)
by Frank Heckenbach 01 Nov '98

01 Nov '98

Harald A. Irmer wrote: > 2.`memmove' in run-time-system is Sys5ish, replace by memcpy (in memory.h), at > least please set conditions, #ifdef Sys5 memmove ... > memmove is in GNU C++ The run time system already uses memcpy, not memmove (memmove was still mentioned in a comment and a #define, but it wasn't used anymore, so I removed it). memmove is used in rts.c which is actually part of the compiler, not the RTS, for the Move function. But using memcpy here would be wrong, because according to the memcpy manpage, the source and destination areas may not overlap, but they may overlap for Move. So, I implemented _p_move in rts/move.pas. Peter, can you use that in rts.c instead of memmove? > 3.RAND_MAX (p/rts/random.c) is not known to SunOS, neither to gcc, set for my > purpose #define RAND_MAX 32767 Hmmm... according to my rand() manpage, it's part of ISO, but anyway... I inserted: #ifndef RAND_MAX #define RAND_MAX 32767 #endif But is that safe? I'm applying a modulo (RAND_MAX + 1) to the numbers returned by rand(), so it wouldn't hurt much if RAND_MAX is chosen too small. (Theoretically I could set it to 1, to be safe, but that would be quite inefficient, because then rand() would be called for every bit needed.) Or to say it differently: how do you know that 32767 is correct for SunOS? Does SunOS document it? (As a general fact or only for SunOS?) Or is it written in some header in some way? Peter Gerwinski wrote: > > 5.p/gpi-hash.c needs <sys/stdtypes.h> (size_t) > > I do not have <sys/stdtypes.h> here (under Linux). Is there any > portable way to include it? (AutoConf experts around here?) Perhaps <sys/stdtypes.h> is included in some other, more common, system header in SunOS, so we can include that one? Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

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 November 1998