- Gpc - gnu.de

IEEE 754 in GPC
by lanceboyle＠qwest.net 19 Apr '06

19 Apr '06

What is the relationship between GPC and IEEE 754 floating point? THINK and CW (both Mac dialects) allowed e.g. a := Inf; a := -Inf; a := NaN; but these are rejected by GPC as undeclared identifiers. I can get the same effect by e.g. a := MaxReal * 2.0; {inf} a := 0.0 / 0.0; {nan} but this seems like a hack. Also, the old SANE (Apple's most excellent 754 implementation from way back--I think the guru Kaplan was involved, as he was with the also-most-excellent HP-15c pocket calculator) allowed returning specific numeric codes to allow determining what caused a NaN. I remember writing an arctan2 function and in the case of arctan2(0.0, 0.0), I assigned a returm value of something like NaN(85), which was somehow a NaN even though the construct looks like a function. I _think_ I could then query that particular NaN to get a clue about where it arose. I lost this when porting to CW, however. Anyway, just wondering. Jerry

3 2

StringOf empty string
by Peter Schorn 19 Apr '06

19 Apr '06

Dear all, is the following a bug or might I have made a mistake in building gpc 20060325? program strof; begin writeln(StringOf('')); end. compiles but execution terminates with invalid subrange size (error #301 at 1992b) Trace/BPT trap Best regards, Peter

3 2

Re: Dropping gcc-3.2.x (was: -m64 on powerpc-apple-darwin8)
by cbfalconer＠att.net 18 Apr '06

18 Apr '06

Frank Heckenbach <ih8mj(a)fjf.gnu.de> wrote: > ... snip ... > > I'm still testing with 3.2.3 too, but I also thought about dropping > it recently. Since the external preprocessor was the last obstacle > in adopting 3.3 and 3.4, I think we can drop 3.2.x officially (i.e., > remove the 3.2.x diffs in the next release). Objections anyone? > (If 3.3 turns out problematic, I wouldn't mind dropping it also.) The problem with that is that DJGPP available issues are rather limited. I have no objections as long as whatever is supported is also available for djgpp. I have asked several times for things to be sent to me at: cbfalconer(a)maineline.net with no response whatsoever. This periodic web access is not good. -- Chuck F (cbfalconer@yahoo.com)(cbfalconer@maineline.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE maineline address!

4 3

Experimental 4.1 port
by Waldek Hebisch 16 Apr '06

16 Apr '06

I have now "almost ready" experimental gcc-4.1.0 port. There are some minor problems but basically 4.1.0 port should be now as good (or as bad...) as 4.0.3 port. I would like to fix some extra problems (most of them not related to port) and add some feature before I make a new snapshot, so ATM I have made port available as patches: http://www.math.uni.wroc.pl/~hebisch/gpc/gpc-4.1-4.diff.gz and http://www.math.uni.wroc.pl/~hebisch/gpc/gcc-4.1-4.diff.gz The patches are relative to gpc-20060325. gpc diff contains parser diffs. To avoid needless regeneration of parser file touch p/parse.[ch] after patching. The port should build without problems. There are extra test failures (compared to 3.4.6): asmtest.pas, fjf395[ab].pas -- test programs expect to much fjf1102.pas -- unimplemented feature (but works with older older backends) fjf403b.pas, fjf779[abefg].pas, nicola4c.pas -- port does not detect error/unused variables fjf395[ab].pas -- wrong tests fjf322.pas, fjf587b.pas -- spurious warnings -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

3 2

Re: Experimental 4.1 port
by Adriaan van Os 12 Apr '06

12 Apr '06

Waldek Hebisch wrote: > The port should build without problems. There are extra test failures > (compared to 3.4.6): > > asmtest.pas, fjf395[ab].pas -- test programs expect to much > > fjf1102.pas -- unimplemented feature (but works with older older backends) > > fjf403b.pas, fjf779[abefg].pas, nicola4c.pas -- port does not detect > error/unused variables > > fjf395[ab].pas -- wrong tests > > fjf322.pas, fjf587b.pas -- spurious warnings === gpc tests === Running target any Running testsuite ... UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas UNSUPPORTED: fjf165a.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf998r.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: longr2.pas FAIL: nicola4c.pas FAIL: prep2p.pas FAIL: systemtest.pas === gpc Summary === # of tests 5070 # of expected passes 5048 # of unexpected failures 15 # of unsupported tests 7 gpc version 20060325, based on gcc-4.1.0 Miraculously, fjf1062[a-c].pas no longer fail, although the C testprogram still does (<http://gnu-pascal.de/crystal/gpc/en/mail13495.html>). The failure of fjf563e.pas is new. It doesn't fail at -O0. Various outputs are: [g5:gcc/p/test] adriaan% gpc fjf563e.pas -O3 fjf563e.pas:7: warning: constructing limited integer set `0 .. 255'; fjf563e.pas:7: warning: use `--setlimit=NUMBER' to change the size limit at compile time. [g5:gcc/p/test] adriaan% gpc fjf563e.pas -O0 fjf563e.pas:7: warning: constructing limited integer set `0 .. 255'; fjf563e.pas:7: warning: use `--setlimit=NUMBER' to change the size limit at compile time. <tree_list 0x42471860 purpose <integer_cst 0x42471880 type <integer_type 0x4241f460 Integer> constant invariant tree_5 10000> value <integer_cst 0x424718a0 type <integer_type 0x4241f460 Integer> constant invariant tree_5 20000>> fjf563e.pas:7: error: invalid initializer for set <tree_list 0x42471860 purpose <integer_cst 0x42471880 type <integer_type 0x4241f460 Integer> constant invariant tree_5 10000> value <integer_cst 0x424718a0 type <integer_type 0x4241f460 Integer> constant invariant tree_5 20000>> fjf563e.pas:7: error: invalid initializer for set <tree_list 0x42471860 purpose <integer_cst 0x42471880 type <integer_type 0x4241f460 Integer> constant invariant tree_5 10000> value <integer_cst 0x424718a0 type <integer_type 0x4241f460 Integer> constant invariant tree_5 20000>> fjf563e.pas:7: error: invalid initializer for set [g5:gcc/p/test] adriaan% gpc fjf563e.pas -O1 fjf563e.pas:7: warning: constructing limited integer set `0 .. 255'; fjf563e.pas:7: warning: use `--setlimit=NUMBER' to change the size limit at compile time. Ah, I think this was because of the temporary patch to locate the invalid initializer set problem ! All in all, experimental gcc-4.1 support looks quite good. Regards, Adriaan van Os

2 1

Re: Experimental 4.1 port
by Adriaan van Os 12 Apr '06

12 Apr '06

Waldek Hebisch wrote: > I have now "almost ready" experimental gcc-4.1.0 port. There are some minor problems but basically 4.1.0 port should be now as good (or as bad...) as 4.0.3 port. I would > like to fix some extra problems (most of them not related to port) and add some feature before I make a new snapshot, so ATM I have made port available as patches: Thanks for the new diffs for gcc-4.1.0 ! I tried them, but the build dies with: ../.././xgpc -B../.././ -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -DHAVE_DESIGNATED_INITIALIZERS=0 -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING --unit-path=/Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts --automake -DRTS_RELEASE_STRING="'`cat /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/rts-version`'" -DGCC_VERSION="''" "/Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas" /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas: In function `CanRead': /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas:1878: error: invalid initializer for set /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas:1878: error: invalid initializer for set /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas: In function `CanWrite': /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas:1884: error: invalid initializer for set /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas:1884: error: invalid initializer for set /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas: In procedure `GPC_BlockRead': /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas:1894: error: invalid initializer for set /Users/adriaan/gpc/gpc-20060325/gcc-41/gcc-4.1.0/gcc/p/rts/files.pas:1893: error: invalid initializer for set make[3]: *** [files.o] Error 1 make[2]: *** [pascal.rts] Error 2 make[1]: *** [stage1_build] Error 2 make: *** [bootstrap] Error 2 Regards, Adriaan van Os

2 4

Re: Out of range values in
by Bart van den Broek 10 Apr '06

10 Apr '06

----- Original Message ----- From: "Frank Heckenbach" <ih8mj(a)fjf.gnu.de> To: <gpc(a)gnu.de> Sent: Thursday, April 06, 2006 18:25 Subject: Re: Out of range values in > Bart van den Broek wrote: > >> >> > > If I (as an inactive observer) may comment / make a suggestion; >> > > when a constant of ByteBoole, WordBoole or LongBoole is evaluated, >> > > presumably at compile time, convert it to a value of type Boolean. >> > > As a consequence: >> > > type VeryTrue = ByteBool (10) .. ByteBool (42); >> > > means >> > > type VeryTrue = True..True; >> > > Also, in the test program fjf1102, (Ord (a) = 1) and (Ord (b) = 1) >> > > and >> >(Ord >> > > (c) = 1) holds, and more specifically Ord( ByteBool(42) ) = 1. >> > >> >Interesting idea, but if done only for constants (as I understand >> >your suggestion), it would also lead to strange effects: >> > >> >program foo; >> > >> >var >> > n: Integer = 42; >> > >> >begin >> > WriteLn (ByteBool (n) = ByteBool (42)) { => False } >> >end. >> >> Since the Borland Delphi 3 Object Pascal Language Guide mentions: >> "....Whenever a ByteBool, WordBool or LongBool value is used in a >> context >> where a Boolean value is expected, the compiler will automatically >> generate >> code that converts any nonzero value to the value True." >> If i interpret the expression ByteBool(n) = ByteBool(42) as "a context >> where >> a Boolean value is expected" then it is equivalent to (ByteBool(n) <> 0) >> = >> (ByteBool(42) <> 0), or (ByteBool(n) <> 0) = True, and foo would print >> True. > > I don't think so (BTW, what does Delphi do?). The context here is > `=' Since ByteBool is an ordinal type, and `=' allows the same > ordinal type (among others) on both sides, ByteBool is valid. I.e., > it's a context where Boolean is allowed, but not required. Contexts > that require Boolean include the conditions in if, while, until, or > assignments to Boolean variables, or Boolean value parameters. > >> >Besides, it probably wouldn't be 100% Delphi compatible, as Delphi >> >documentation (as quoted by Adriaan) states that Ord of "True" of >> >such types can be any value <> 0. >> >> Well, 1 is such a value <> 0, so how do u think it is incompatible? > > OK, but if it were always 1, then they'd probably say so, and not > write: > > : Boolean ByteBool, WordBool, LongBool > : Ord( True) = 1 Ord( True) = any non-zero value > >> I dont have Delphi available right now, but i vaguely remember Delphi >> does >> the following: >> ByteBool(True) = $FF >> WordBool(True) = $FFFF >> LongBool(True) = $FFFFFF >> If so (will check later) then this means my suggestion is different and >> maybe incompatible. > > I don't either, but someone who does might want to check this (and > the behaviour of my program above under Delphi). If really > ByteBool(True) = $FF (I assume you mean Ord (ByteBool (True)) = $FF, > or can you compare ByteBool and integers in Delphi?) that would > complicate things, as normally (in BP and GPC) value type casts > preserve ordinal values ... > > 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 > > Indeed I meant Ord(ByteBool(True)) = $FF and so on. When I run this program in Delphi v7.1 (7.0 + patch) program Project1; {$APPTYPE CONSOLE} procedure RunTest; var n : Integer; m : Integer; begin n := 42; m := 43; Writeln(ByteBool(n) = ByteBool(m)); Writeln(ByteBool(n) = ByteBool(42)); Writeln(ByteBool(n) = True); Writeln(Ord(ByteBool(True))); Writeln(WordBool(n) = WordBool(m)); Writeln(WordBool(n) = WordBool(42)); Writeln(WordBool(n) = True); Writeln(Ord(WordBool(True))); Writeln(LongBool(n) = LongBool(m)); Writeln(LongBool(n) = LongBool(42)); Writeln(LongBool(n) = True); Writeln(Ord(LongBool(True))); Writeln(Pred(Boolean(False))); Writeln(Pred(ByteBool(False))); Writeln(Pred(WordBool(False))); Writeln(Pred(LongBool(False))); end; begin RunTest; end. I get this output (ignore extra empty lines i put in): TRUE TRUE TRUE 255 TRUE TRUE TRUE 65535 TRUE TRUE TRUE -1 <gibberish> <gibberish> TRUE TRUE Note the signedness of the Ord(LongBool(True)), probably due to the fact that Ord function is 32 bits integer. I guess being completely compatible here is not simple. Bart

3 2

Re: [MacPascal] GPC: // comments and line endings
by Adriaan van Os 09 Apr '06

09 Apr '06

Forwarding from the MacPascal mailing list: Erling Johansen wrote: > Adriaan van Os wrote: > >> Erling Johansen wrote: >> >>> GPC rejects code with // comments when the source has Macintosh line >>> endings, but not when the source has Unix or DOS line endings. >>> >>> Is this a bug or a feature? >> A bug. To be reported on the gpc mailing list (but I can do that if >> you are not suscribed). > > I'm not subscribed, so please report it. Regards, Adriaan van Os

1 0

Re: Out of range values in
by Frank Heckenbach 06 Apr '06

06 Apr '06

Waldek wrote (in private mail, but I hope you don't mind me forwarding it to the list, as it concerns the current discussion about bitsizes): > I have noticed that fjf395[ab].pas expects to be able to compute > on out of range values. Both of them fail with 4.1 backend. > According to recent discussion on GCC list using out of range > values is illegal (if we consider such values legal the type should > have bigger bounds). > > I would prefer to declare fjf395[ab].pas illegal and remove them from > the testsuite. And say that user programs expecting such behaviour > should be fixed. Yes, the test programs are currently wrong as they put ordinal values > 1 in `Boolean attribute (Size = n)' variables. I wrote them at a time when semantics of `Boolean (n)' (as they were called back then) were not very clearly defined ... > The other solution is "double accounting", when we have types > with loose bounds for backend use, but we separatly track ranges > in the front end. I'd prefer to avoid this, as it'd surely add quite some effort for probably little gain. In fact, as integer ranges can be freely declared, and we don't (yet) support bitsizes for types other than integers and Booleans, it seems to affect only Booleans with specified bitsize, which is a very special case. So we have the choice either to leave the range at False {0} .. True {1}, and forbid other values, and change the test programs, or to really declare the range according to the bitsize (e.g. False {0} and 255 values of True for an 8 bit type). The former would seem more Pascalish. OTOH, such types are probably often used for C interfaces, and what will happen if C routines put values > 1 in them? Probably undefined stuff (e.g., the backend would be free to check only bit 0 or byte 0), so we'd have to declare this invalid, which limits the use of these types. With the latter, we'd get some strange semantics (such as `Ord (High (...))' of such types not yielding 1) -- or rather, we'd retain them, as some strange semantics are already there: program Foo; type t = Boolean attribute (Size = 8); var a, b: t; begin a := t (5); b := t (2); WriteLn (a); WriteLn (b); WriteLn (a = b) end. Says: True True False And contrary to Adriaan's previous suggestion we'd actually need a pseudo-schema then, as `Boolean attribute (BitSize = 8)' according to his proposal would yield a 0 .. 1 range. But still, the latter seems the lesser evil to me ATM, as otherwise these types might not be very useful at all ... Or can/should we drop them altogether? Are they needed for Delphi compatibility? Or does someone seriously need them (where they can't just be replaced with bitsize-Integers, adding `<> 0' and `Ord' where necessary)? Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

4 11

An other gdb useful patch
by Pascal Viandier 05 Apr '06

05 Apr '06

When debugging gpc programs, I often get a gdb coredump when printing the value of string which is not -yet- initialized. This happens even more often when using ddd on top of gdb since the value is displayed as soon as you move the mouse pointer over the variable name. This problem occurs because gdb uses the value of the 'length' field of the string type schema to print the string contents. If the string is not initialized, this field may contain any value -even negative- so it crashes gdb. I solved this bug (IMHO this is one) by getting the Capacity field too. This field is always initialized for gpc strings - this is an assumption -. When printing a string, I compare the value of the actual length and the value of the capacity of the string. If the length is either negative or greater than the capacity, the capacity is used to print out the value. This modification has no impact on other Pascal string types (BP, etc). I put the patches (4) for gdb 6.4 in attachment. If someone estimates these patches are interesting enough to transmit them to the gdb maintainers, feel free to do so. I am not a member of the gdb mailing list and I do not know how to submit patches to them. Hope this will help someone. Kind regards Pascal

3 9