February 2005 - Gpc

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

How to patch (was: Cannot compile gpc-20041218 on MinGW/Windows 2000)
by Markus Gerwinski 21 Feb '05

21 Feb '05

Jan Ruzicka wrote: > b) there can be a problem with the line endings (CRLF vs CR / LF). > The file gcc.c on your system may have different line endings then the > used patch file. > The difference in line endings may prevent patch from matching the > surrounding blocks of code. > (dos2unix is your friend) The patch file really contained ^Ms. However, removing them didn't change things. I also doubt it has anything to do with the paths. What I did was this: - file to change: $MYPATH/gcc-3.2.3/gcc/gcc.c - path in the patch file: gcc/gcc/gcc.c So I did `cd $MYPATH/gcc-3.2.3' and then `patch -p1 < ../gcc.c.patch'. That should have done the trick, shouldn't it? Yours, Markus ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

2 2

Re: GPC ALPHA 20050217 released
by Waldek Hebisch 21 Feb '05

21 Feb '05

I have discovered code generation problem on AMD64. The patch below corrects code generation. It causes spurious warnings in some other tests (fjf1014.pas, fjf1021h.pas, fjf1021i.pas, fjf768c.pas, fjf768e.pas, fjf768f.pas) but those will require separate fix. In principle other platforms may be affected -- in particular the problem on Mac OSX looks related. diff -u p.orig/expressions.c p/expressions.c --- p.orig/expressions.c 2005-02-16 04:38:36.000000000 +0100 +++ p/expressions.c 2005-02-19 05:17:58.200156608 +0100 @@ -259,20 +259,23 @@ { tree cond, t; int side_effects = TREE_SIDE_EFFECTS (expr); - expr = save_expr (expr); - if (TREE_CODE (expr) == SAVE_EXPR) - TREE_SIDE_EFFECTS (expr) = side_effects; - cond = chklo ? build_implicit_pascal_binary_op (LT_EXPR, expr, min) : NULL_TREE; + tree tmpvar = make_new_variable("range_check", TREE_TYPE (expr)); + tree tv; + cond = chklo ? build_implicit_pascal_binary_op (LT_EXPR, tmpvar, min) : NULL_TREE; if (chkhi) { - tree cond2 = build_implicit_pascal_binary_op (GT_EXPR, expr, max); + tree cond2 = build_implicit_pascal_binary_op (GT_EXPR, tmpvar, max); cond = cond ? build_pascal_binary_op (TRUTH_ORIF_EXPR, cond, cond2) : cond2; } - t = save_expr (build (COND_EXPR, TREE_TYPE (expr), cond, build (COMPOUND_EXPR, - TREE_TYPE (expr), build_predef_call (co->range_checking > 1 ? p_IORangeCheckError : p_RangeCheckError, - NULL_TREE), expr), expr)); - if (TREE_CODE (t) == SAVE_EXPR) - TREE_SIDE_EFFECTS (t) = side_effects; + t = build (COMPOUND_EXPR, TREE_TYPE (expr), + build_predef_call (co->range_checking > 1 ? p_IORangeCheckError : p_RangeCheckError, + NULL_TREE), tmpvar); + t = build (COND_EXPR, TREE_TYPE (expr), cond, t, tmpvar); + tv = build (MODIFY_EXPR, TREE_TYPE (expr), tmpvar, expr); + PASCAL_VALUE_ASSIGNED (tmpvar) = 1; + TREE_SIDE_EFFECTS (tv) = 1; + t = build (COMPOUND_EXPR, TREE_TYPE (expr), tv, t); + TREE_SIDE_EFFECTS (t) = side_effects; return t; } } -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

4 12