Go to the first, previous, next, last section, table of contents.
The GNU Pascal Compiler (GPC) does not yet implement the whole ISO 10206
Extended Pascal standard, not even the whole ISO 7185 Pascal standard.
It is only partially compatible to Borland Pascal and implements only
some isolated features from the PXSC standard. Furthermore, there are
some known bugs which will take a long time to be fixed. (Any help
welcome!) Please take this into account when you consider using GPC
for any purpose.
If you encounter a bug with GPC, please check whether it is one of the
known bugs. If not, report it to the GNU Pascal mailing list
gpc@hut.fi
. (But always report it if you solve the problem! ;-)
-
High optimization levels do not work properly on the Alpha. Some
conformance tests fail when compiled with `-O6' flag, which
means that the compiler generates invalid code. Don't use this flag in
the Alpha before the problem gets fixed. It might have something to do
with automatic inlining, but I have not yet looked at this. `-O'
flag should be ok. (Also take care when using explicit inline
functions.)
-
Run time errors are not checked in most cases.
-
For some reason the Pascal main program does not get lineno stabs, so it
is hard to debug it with `gdb' ...
-
The set code generated in the Alpha causes runtime errors
in the generated code.
-
There are some bugs with mathematical functions. GPC fails, for
example, the "Paranoia" test.
-
Type checking is mostly what C does, not what Pascal requires, so GPC
does not yet implement a strongly typed language. Although correct
programs compile, incorrect ones compile also. Please send us such
incorrect programs, so we can fix it!
See also: section From Borland Pascal to GNU PascalQuickStart Guide for Borland Pascal users.
-
Strings are implemented in a completely different way. They are
not limited to 255 characters with the length being in position
zero, but they are "Schema types" which is something more
complicated.
-
Most of Borland Pascal's System Unit is not implemented, e.g.
`move', `FillChar', `BlockRead', `BlockWrite',
`Assign', String-related functions, ...
Workaround:
Some of the missing procedures and functions are implemented in a
separate compatibility Unit. Check the
contrib
subdirectory of
your GPC distribution.
-
The inline assember does not understand Borland syntax.
-
There is no `private' directive for Objects yet.
-
There is no `Inline' in Borland sense.
-
The GNU debugger, `gdb', does not yet understand Pascal sets,
files or subranges. Now `gdb' allows you to debug these things,
even though it does not yet understand some stabs.
-
Files of integer subranges that would fit in a byte do not; instead they
are handled as files of integer. This is especially annoying with
`file of 0..255'.
-
Forward referencing pointers generate `dbx' style debugging symbols
by outputting the `.stabs' as an unknown pointer and later it just
outputs the same `.stabs' again, but this time it also tells what
type the pointer points to. This seems to work for `gdb'. As of
this writing I have not checked what happens with `sdb' type
debugging info. It might be that the pointer is left to be a
(void *)
pointer, so you have to cast it in order to output the
object the pointer points to.
Also, we have not tried any other debugger than `gdb'. If you do,
please let us know what happens.
I think that GDB does not yet support the kind of `.stabs'
that should be used to do this correctly:
.stabs ":tanumber=bnumber", whatever
where anumber is the unknown pointer type referenced earlier, and
the bnumber is the type which anumber actually is. This
construct is not required in C.
-
When debugging, please note that the Initial Letter In Each Identifier
Is In Upper Case And The Rest Are In Lower Case. If you wish to call
C-routines declare them with the "C" directive, as follows:
Procedure FooBAR(i:integer);c;
This makes the external name to be `_foobar'
(replace _
with you machine prefix).
Procedure FooBAR(i:Integer); External;
Uses external name _Foobar
.
Procedure FooBAR(i:Integer); AsmName 'FooBAR';
Uses external name _FooBAR
.
It is done like this to reduce name clashes
with `libc.a' and other possible libraries.
-
All visible GPC runtime system library routines are
named
_p_...
.
-
The main program name is preceeded by
program_
.
For example, Program FOO
yields the external name
program_Foo
for the main program. This is done
because ISO Standard wants to have the program name in a
separate name space.
Go to the first, previous, next, last section, table of contents.