According to Frank Heckenbach:

[...] However, the following still doesn't work (if it's already/still on the bug list, please ignore):

PROGRAM x; CONST n:1..16=6; {"subrange bounds are not of the same type"} BEGIN END.

Is this really a bug??? Extended Pascal allows expressions as the upper bound of a subrange. In this case, the expresson "16 = 6" (with the Boolean value "false") is the upper bound - which is indeed not of the same type as the lower bound "1". This is a known shift/reduce conflict in the parser. In principle it should be possible to tell bison to shift it rather than to reduce it - just like with the "dangling else" problem. Since I am a complete beginner with parsers (no theoretical knowledge; my only experience with bison relates to GPC) I would be glad if somebody could help me with this.

{The same with "var ...=...", ok with "var ... value ..."}

Strange. On my box, it works with `value'.

Then, a very small problem:

I have a Pascal program (let's say foo.pas) that uses some units. [...] If I compile it with "gpc foo.pas bar.c", it works fine. But if I do "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions).

I think that's intended: The GNU linker is a one-pass linker which needs the "lowest" unit in the most right position of the command line. (I think. I don't really know.;-)

In the latter situation also the file foo.gpc is left.

That's indeed a bug. Thanks for the report. Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125]