Gpc

gpc@gnu.de

5400 discussions

Variant record constants
by Frank Heckenbach 27 Feb '05

27 Feb '05

I noticed that GPC allows non-constants in variant record lists which neither EP nor BP support. As it would cause additional difficulties when fixing Emil's test program and perhaps elsewhere, and I can't see much use for it, the attached patch forbids it. program fjf1028a (Output); var a: Integer value 1; type t = record case Integer of a: (b: Integer) { WRONG } end; begin end. program fjf1028b (Output); type t (a: Integer) = record case Integer of a: (b: Integer) { WRONG } end; begin end. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

1 0

warning: Operand with side-effects is not evaluated.
by Igor Marnat 25 Feb '05

25 Feb '05

Hello List! I've successfully built latest version with the same results of test suite like other people already have written. Range-checking is a really cool (great thanks to developers:))! It appears now new warning that I didn't see before (warning: Operand with side-effects is not evaluated). It isn't described in the documentation. It points to strings that look like: LocalVariable := GlobalVariable mod GlobalConst; Can I do something to avoid it? What does it mean? It means that the value evaluated will not be assigned to LocalVariable? Or it means that Global variable will not change its value as a result of this activity? Best regards, Igor Marnat mailto:marny@rambler.ru

2 1

Compile prob. with gpc20050217
by Wood David 25 Feb '05

25 Feb '05

I'm getting a new compile time error (error: arithmetical overflow ) with this previously ok bit of code: FOR I := -Clutter_max_width TO Clutter_max_width DO Spectral_purity[I] := Spec_purity_level / (1 + (SQR(I) / Width_sqrd)); Spectral_purity[0] := 1; All the variables and arrays use type double, except i which is an integer. The error is reported at the last code line, but I guess it may stem from the previous line. I don't understand why gpc should report an arithmetic overflow error at compile-time. This is normally a run-time error! Any ideas? Regards David Wood The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored. Calls to QinetiQ may be recorded for quality control, regulatory and monitoring purposes.

2 1

Test results og gpc-20041218 with gcc-3.3.5 for DJGPP
by Andris Pavenis 25 Feb '05

25 Feb '05

Here are test results of gpc-20041218 with gcc-3.3.5 for DJGPP (I used recent CVS version DJGPP v2.04) gpc 20041218, based on gcc-3.3.5, flags: -g -O3 -W -Wall -Wno-unused GPC-TEST-BEGIN ========================== TEST aregextest.pas: SKIPPED: librx not installed TEST fjf165a.pas: SKIPPED: German locale not installed TEST longr2.pas: SKIPPED: no LongReal math routines available TEST reset.pas: failed TEST y2k.pas: failed 2005 2005 ========================== GPC-TEST-END Additionally I had to patch test_run to avoid DJGPP port of bash crashing (both bash-2.0.4 from v2gnu and bash-2.0.5b): --- test_run~1 2005-02-17 22:54:30.000000000 +0000 +++ test_run 2005-02-17 20:12:44.000000000 +0000 @@ -296,7 +296,8 @@ echo "failed" fi fi - return 0 # IRIX's shell wants this, otherwise it aborts after a failed command!? +true +# return 0 # IRIX's shell wants this, otherwise it aborts after a failed command!? } n=0 It is perhaps a due to some problem with DJGPP port of bash. Andris

3 7

Bug report for gpc 20050217
by Wood David 25 Feb '05

25 Feb '05

Following on from my earlier runtime arithmetical error report, see attached code. It appears that gpc20050217 doesn't like the use of a constant index in an array assignment within a procedure. It's fine when the same assignment is done with a constant index in the main program. I'm running gpc20050217 (patched with gpc.diff-uc) under gcc.3.4.2 in FC3 Linux on a P4 processor. Regards David. The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored. Calls to QinetiQ may be recorded for quality control, regulatory and monitoring purposes.

3 2

Re: Compile prob. with gpc20050217
by Wood David 24 Feb '05

24 Feb '05

Apologies for the limited code detail earlier. It appears the offending bit is the use of a constant array index. Here is a short program which reproduces the bug: PROGRAM arr_test(input,output); TYPE arrtype = ARRAY [-10..10] OF double; VAR test : arrtype; PROCEDURE init(VAR arr: arrtype); VAR i : integer; BEGIN FOR i:= -10 TO 10 DO arr[i]:= i*2.0; i:= 0; arr[i]:= 1.0; { This is OK, using i for the index } arr[0]:= 1.0; { This causes an arithmetical error at compile time } END; BEGIN init(test); END. > -----Original Message----- > From: Waldek Hebisch [mailto:hebisch@math.uni.wroc.pl] > Sent: 19 February 2005 04:50 > To: Wood David > Subject: Re: Compile prob. with gpc20050217 > > > I'm getting a new compile time error (error: arithmetical overflow ) > with > > this previously ok bit of code: > > > > > > > > FOR I := -Clutter_max_width TO Clutter_max_width DO > > > > Spectral_purity[I] := Spec_purity_level / (1 + (SQR(I) / > > Width_sqrd)); > > > > > > > > Spectral_purity[0] := 1; > > > > > > > > All the variables and arrays use type double, except i which is an > integer. > > > > The error is reported at the last code line, but I guess it may stem > from > > the previous line. > > > > I don't understand why gpc should report an arithmetic overflow error at > > compile-time. This is normally a run-time error! > > > > That is too little detail to reproduce the problem. gpc computes many > constant expressions at compile-time and signals error in case of > overflow. So in particular values of your constants are crucial. > In general you should make sure that you give a _complete_ program > which reproduces the problem. > > -- > Waldek Hebisch > hebisch(a)math.uni.wroc.pl The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored. Calls to QinetiQ may be recorded for quality control, regulatory and monitoring purposes.

1 0

Re: gpc-20050217 failing this test
by Wood David 24 Feb '05

24 Feb '05

Thanks Frank. I can confirm that this patch (gpc.diff-uc) fixed the out of range error. David. > -----Original Message----- > From: gpc-owner(a)gnu.de [mailto:gpc-owner@gnu.de <mailto:gpc-owner@gnu.de> ] On Behalf Of Frank > Heckenbach > Sent: 22 February 2005 15:59 > To: gpc(a)gnu.de > Subject: Re: gpc-20050217 failing this test > > Wood David wrote: > > > Here is a very short program which now fails with a value out of range > > error: > > I don't get a failure, but since the type size is near 128 KB, this > looks like the bug found by Emil Jerabek. You might want to try my > patch (gpc.diff-uc). You'll need to rebuild the RTS after applying > it. > > Frank The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored. Calls to QinetiQ may be recorded for quality control, regulatory and monitoring purposes.

1 0

where could I get latest patches for gpc
by Igor Marnat 24 Feb '05

24 Feb '05

Hi, List! Latest version of GPC has some bugs and there are some patches available already. Does there exists any url to get these patches (or the latest one, "cumulative")? Sometimes it's not very comfortly to search them in the mailing list. Am I missed something and such a place already exists at www.gnu-pascal.de? If no, it would be nice to have such a place nearby GPC release. Regards, Igor Marnat marny(a)rambler.ru

1 0

Building on Mac OS X
by Adriaan van Os 24 Feb '05

24 Feb '05

Frank Heckenbach wrote: > - Bison (building GPC) > > Bison version 2.0 has been released. It can be obtained at > <ftp://ftp.gnu.org/gnu/bison/bison-2.0.tar.gz>. This is now the > recommended version for all GPC compilations. Fortunately, we now > don't depend on changing alpha/beta versions of bison anymore. > Bison is required when building a minimal distribution of GPC > (which now doesn't include the Bison generated files anymore, as > it did temporarily); when building a full source distribution and > not modifying the bison input files (*.y), bison is not strictly > needed, but in case of doubt, it can't hurt to install the new > bison version. I am adding a few notes about building on Mac OS X. The following tools may be needed: - bison 2.0 a too old version is installed with XCode or OS X <ftp://ftp.gnu.org/gnu/bison/bison-2.0.tar.gz> - sed 4.0.x a too old version is installed with XCode or OS X (I use 4.0.5, but I assume later versions work also) <ftp://ftp.gnu.org/gnu/sed/> - flex 2.5.27 a too old version is installed with XCode or OS X <http://sourceforge.net/project/showfiles.php?group_id=72099> - help2man 1.35 not installed with XCode or OS X <ftp://ftp.gnu.org/gnu/help2man/help2man-1.35.1.tar.gz> Configure these tools with --prefix=/usr, configure help2man with --prefix=/usr --enable-nls=no There is a bug in Mac OS X that causes problems when configuring flex and other tools (see e.g.<http://lists.gnu.org/archive/html/bug-coreutils/2004-08/ msg00039.html>). The system call sysctl ((int[]) {CTL_HW, HW_MACHINE_ARCH}, 2, buffer, &bufsize, 0, 0) returns a negative number, which causes the coreutils command "uname -p" to report "unknown". This confuses config.guess. To solve the flex configure problem, apply the following patch to the flex 2.5.27 sources: --- config.guess.orig Fri Feb 18 21:22:32 2005 +++ config.guess Fri Feb 18 21:25:28 2005 @@ -1098,7 +1098,7 @@ EOF echo ${UNAME_MACHINE}-apple-rhapsody${UNAME_RELEASE} exit 0 ;; *:Darwin:*:*) - echo `uname -p`-apple-darwin${UNAME_RELEASE} + echo powerpc-apple-darwin${UNAME_RELEASE} exit 0 ;; *:procnto*:*:* | *:QNX:[0123456789]*:*) UNAME_PROCESSOR=`uname -p` WIth the right tools in place, build the gpc compiler with "make bootstrap" instead of "make". This is necessary because of peculiarities of the apple-gcc system compiler. The alternative is to bootstrap an fsf-gcc compiler on your system first and then use that fsf-gcc compiler for successive builds of gpc (and other gnu packages). Then, successive builds will be faster, because a bootstrap is not needed. Regards, Adriaan van Os

8 20

gpc-20050217 failing this test
by Wood David 22 Feb '05

22 Feb '05

Here is a very short program which now fails with a value out of range error: PROGRAM dyn_arr_test(input,output); TYPE Dyn_arr2( Max_index1, Max_index2 : INTEGER ) = ARRAY [1..Max_index1, 1..Max_index2] OF single; Ptr_to_dyn_arr2 = ^Dyn_arr2; VAR test2 : Ptr_to_dyn_arr2; BEGIN new(test2, 181, 181); writeln('This works'); new(test2, 182, 182); writeln('This works'); new(test2, 183, 183); writeln('This fails'); dispose(test2); END. Turning off range-checking doesn't seem to work! $ gpc --no-range-checking -o dyn_arr_test dyn_arr_test.pas I'm aware there are problems in this area. I hope this helps. I'm using gpc-20050217 with gcc-3.4.2 under Fedora Core 3. Regards David Wood The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful. Emails and other electronic communication with QinetiQ may be monitored. Calls to QinetiQ may be recorded for quality control, regulatory and monitoring purposes.

3 2

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