I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work.
Waldek Hebisch and I are currently working on some larger changes, including qualified identifiers, range checking and support for gcc-3.4.0. An alpha version with these changes, which might be less stable, will probably be released in a few weeks.
BUILD NOTE: If you modify the GPC sources, you now need bison-1.875c and flex-2.5.27 (http://lex.sourceforge.net) to rebuild. These versions must be matched exactly. Newer flex versions, in particular 2.5.31, might work as well, but contain a known unportability, so I did not test them, and I recommend 2.5.27. (Other programs such as yacc and lex instead of bison and flex also will not do.) I have included the files generated by bison and flex in the distribution (also in the "minimal" distribution), so you should not need these tools when you only want to build GPC.
NOTE: The `Pipe' unit was renamed to `Pipes' because of a name conflict. Unfortunately, this requires a small change to all programs that use this unit.
New features:
* arithmetic expressions now work as lower array/subrange bounds (fjf248.pas, fjf293.pas, fjf336.pas, fjf346a.pas, fjf622.pas)
* records/objects with many fields are processed faster
* parameters of procedural types now support Standard Pascal procedural parameters, conformant/open arrays and `type of' inquiries (fjf939*.pas)
* empty parameter lists can be written as `()' (chief54*.pas, delphi6*.pas) (D)
* GMP unit: `mpf_sin', `mpf_cos'
* the test suite output is now by default stored in DejaGnu compatible files `gpc.log' and `gpc.sum' in the `p/test/' directory; other available test targets are `pascal.check-short' and `pascal.check-long' (@)
* new options `-W[no-]dynamic-arrays' (fjf931*.pas)
* new argument to `_p_initialize' (@)
* new function `UMask'
* new option `--no-debug-source'
* new lexer (no directly user-visible difference, but should allow for better handling of lexer-based problems in the future)
Fixed bugs:
* `pow' and `**' are really EP conformant now (in particular `x pow y' and `x ** y' are an error if x = 0 and y <= 0) (emil27*.pas)
* `protected var' parameters must only accept references (unlike `const' parameters) (gale5*.pas)
* `pack' must not pack the component type of arrays (fjf940[b-e].pas)
* in some circumstances packed fields were allowed as `var' parameters (fjf940a.pas)
* bugs with nonlocal gotos out of routines declaring file variables (nonloc*.pas) (fix involved a change in the internal representation of file variables)
* 'foo'#42 must not be rejected in `--borland-pascal' (chief53.pas)
* `--implementation-only' didn't work correctly (bo4-19.pas)
* messages referring to object methods now point to the method declaration rather than the end of the object type declaration
* initializers for types containing nested schemata now work (fjf914*.pas)
* various smaller bugs
Frank
Frank Heckenbach writes:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work.
../.././xgpc -B../.././ -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/home/packages/gcc/3.3/gcc-3.3-3.3.3ds7/src/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /home/packages/gcc/3.3/gcc-3.3-3.3.3ds7/src/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.3.3'" --no-automake /home/packages/gcc/3.3/gcc-3.3-3.3.3ds7/src/gcc/p/rts/heap.pas /home/packages/gcc/3.3/gcc-3.3-3.3.3ds7/src/gcc/p/rts/heap.pas:38: error: module/unit interface `Error' could not be imported make[5]: *** [heap.o] Error 1 make[5]: Leaving directory `/home/packages/gcc/3.3/gcc-3.3-3.3.3ds7/build/gcc/p/rts' make[4]: *** [pascal.rts] Error 2 make[4]: Leaving directory `/home/packages/gcc/3.3/gcc-3.3-3.3.3ds7/build/gcc' make[3]: *** [stage3_build] Error 2
based on the gcc-3.3.4 prerelease, i486-linux. Note this is in the stage3 compiler, the stage2 compiler successfully builds heap.pas.
Frank Heckenbach writes:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work.
../.././xgpc -B../.././ -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/home/packages/gcc/3.3/gcc-3.3-3.3.3ds7/src/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /home/packages/gcc/3.3/gcc-3.3-3.3.3ds7/src/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.3.3'" --no-automake /home/packages/gcc/3.3/gcc-3.3-3.3.3ds7/src/gcc/p/rts/heap.pas /home/packages/gcc/3.3/gcc-3.3-3.3.3ds7/src/gcc/p/rts/heap.pas:38: error: module/unit interface `Error' could not be imported make[5]: *** [heap.o] Error 1 make[5]: Leaving directory `/home/packages/gcc/3.3/gcc-3.3-3.3.3ds7/build/gcc/p/rts' make[4]: *** [pascal.rts] Error 2 make[4]: Leaving directory `/home/packages/gcc/3.3/gcc-3.3-3.3.3ds7/build/gcc' make[3]: *** [stage3_build] Error 2
based on the gcc-3.3.4 prerelease, i486-linux. Note this is in the stage3 compiler, the stage2 compiler successfully builds heap.pas.
That is a Makefile problem: I had to remove 'stamp-error-gpi' in RTS build directory after I modified 'error.pas'. The following should help :
--- gpc-20040516/p/Make-lang.in.bb Mon May 17 12:16:51 2004 +++ gpc-20040516/p/Make-lang.in Mon May 17 12:17:21 2004 @@ -1199,7 +1199,8 @@
RTSSTAGESTUFF=p/rts/*.o p/rts/*.lo p/rts/*.gpi p/rts/*.gpd \ p/rts/config.cache p/rts/config.log p/rts/config.status p/rts/Makefile \ - p/rts/rts-config.h p/rts/rts-config.inc p/rts/needed-options + p/rts/rts-config.h p/rts/rts-config.inc p/rts/needed-options \ + p/rts/stamp-error-gpi
pascal.stage1: $(srcdir)/p/script/mkdir-p stage1/p/rts
Waldek Hebisch wrote:
That is a Makefile problem: I had to remove 'stamp-error-gpi' in RTS build directory after I modified 'error.pas'. The following should help :
Yes, thanks. (I don't usually build stages, so I missed this one.)
Frank
On Mon, 17 May 2004, Waldek Hebisch wrote:
Frank Heckenbach writes:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work.
[..]
That is a Makefile problem: I had to remove 'stamp-error-gpi' in RTS build directory after I modified 'error.pas'. The following should help :
--- gpc-20040516/p/Make-lang.in.bb Mon May 17 12:16:51 2004 +++ gpc-20040516/p/Make-lang.in Mon May 17 12:17:21 2004 @@ -1199,7 +1199,8 @@
RTSSTAGESTUFF=p/rts/*.o p/rts/*.lo p/rts/*.gpi p/rts/*.gpd \ p/rts/config.cache p/rts/config.log p/rts/config.status p/rts/Makefile \
- p/rts/rts-config.h p/rts/rts-config.inc p/rts/needed-options
- p/rts/rts-config.h p/rts/rts-config.inc p/rts/needed-options \
- p/rts/stamp-error-gpi
pascal.stage1: $(srcdir)/p/script/mkdir-p stage1/p/rts
Applied above patch. went ok. However, using gcc-3.4.0 (it worked last time) ran into problems starting with config-lang.in. Tried deleteing a portion to get to the "make bootstrap". It started but quit on error so gave up.
Will take another look next week.
Russ
Russell Whitaker wrote:
However, using gcc-3.4.0 (it worked last time) ran into problems starting with config-lang.in. Tried deleteing a portion to get to the "make bootstrap". It started but quit on error so gave up.
Sorry, there is a conflict between changes that Frank made and my gcc-3.4.0 patch. Hopefully we will quickly sort out the problems, but ATM gpc-20040516 does not work with gcc-3.4.0.
On 16 May 2004 at 23:33, Frank Heckenbach wrote:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work.
[...]
1. Compiled without problem for Mingw (gcc-3.2.3). Passed the testsuite, with these exceptions (seems that "failed" is expected in these situations, so I guess it passed the whole testsuite):
"TEST pipetes2.pas: cc1.exe: warnings being treated as errors ../units/pipesc.c: In function `_p_CPipe': ../units/pipesc.c:151: warning: passing arg 3 of `spawnve' from incompatible pointer type ../units/pipesc.c:151: warning: passing arg 4 of `spawnve' from incompatible pointer type ../units/pipesc.c: In function `pexecute': ../units/pipesc.c:471: warning: passing arg 3 of pointer to function from incompatible pointer type gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 failed TEST pipetest.pas: cc1.exe: warnings being treated as errors ../units/pipesc.c: In function `_p_CPipe': ../units/pipesc.c:151: warning: passing arg 3 of `spawnve' from incompatible pointer type ../units/pipesc.c:151: warning: passing arg 4 of `spawnve' from incompatible pointer type ../units/pipesc.c: In function `pexecute': ../units/pipesc.c:471: warning: passing arg 3 of pointer to function from incompatible pointer type gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 gpc1.exe: d:\mingw\bin\gpc.exe exited with status 1 failed "
2. Compiled without problem for Mingw (gcc-3.3.3). However, the IFDEF bug is still there under gcc-3.3.3 (e.g., the compiler completely ignores {$IFDEF WIN32} - which should be defined under Mingw). So, I have gone back to gcc-3.2.3, and the binaries that I will soon release will be based on gcc-3.2.3.
Good work!
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku wrote:
- Compiled without problem for Mingw (gcc-3.3.3). However, the IFDEF
bug is still there under gcc-3.3.3 (e.g., the compiler completely ignores {$IFDEF WIN32} - which should be defined under Mingw). So, I have gone back to gcc-3.2.3, and the binaries that I will soon release will be based on gcc-3.2.3.
ATM as a workaround `--print-needed-options' will print you correct predefines which then should be given back to the compiler. Sounds silly, but in fact the compiler proper have the info, but it is not available in preprocessor, so one havwe to use options to pass the info back. For example on Linux:
gpc-build/gcc/xgpc -Bgpc-build/gcc/ --print-needed-options foo.pas
gives:
-D__x86_64 -D__x86_64__ -D__amd64 -D__amd64__ -D__tune_athlon__ -D__tune_athlon_sse__ -D__MMX__ -D__3dNOW__ -D__3dNOW_A__ -D__SSE__ -D__SSE2__ -D__SSE_MATH__ -D__SSE2_MATH__ -D__athlon -D__athlon__ -D__athlon_sse__ -Dlinux -D__linux -D__linux__ -Dunix -D__unix -D__unix__ -D__gnu_linux__ -D__ELF__ -D__LP64__ -D_LP64
Still, with 3.2.3 backend predefines are available without any additional effort.
Waldek Hebisch wrote:
ATM as a workaround `--print-needed-options' will print you correct predefines which then should be given back to the compiler. Sounds silly, but in fact the compiler proper have the info, but it is not available in preprocessor, so one havwe to use options to pass the info back.
Yes, until I write the new preprocessor, this will be the only way. (BTW, the same workaround was needed on some systems, in particular MIPS, for other reasons before. It will also be gone with the new preprocessor.)
The good news is that GP handles this automatically.
Frank
Hi
I have been trying Waldek's gcc-3.4.x patches and update* diffs under Mingw. There are problems when it comes to "pascal.bindist" and "pascal.install".
With "pascal.install", I get an error that there is no command called "- ranlib". As a quick fix, I copied "ranlib.exe" to "-ranlib.exe", and that was fine. I believe that the cause of this is the "-$(RANLIB)" that appears in a few places in update27h.diff. The Mingw version of ranlib is "GNU ranlib 2.15.90 20040222".
As far as "pascal.bindist" is concerned, I am not sure whether this has anything to do with Waldek's patches. I get an error when it is dealing with gpcpp.exe. Here is an extract from the error log:
tmp_base=`pwd`/tmp && \ tmp_prefix=$tmp_base//mingw && \ rm -rf $tmp_base && \ ../../gcc/p/script/mkdir-p -m a+rx $tmp_prefix && \ make pascal.install "exeext=.exe" "version=3.4.1" "target_alias=" "program_transform_name=s,y,y," "program_transform_cross_name=" "SYMLINK=ln -s" "GCC_FOR_TARGET= ./xgcc -B./ -B/mingw/mingw32/bin/ - isystem /mingw/mingw32/include -isystem /mingw/mingw32/sys-include - L/src/mingw/gcc-3.4.1-20040711-1/build/gcc/../ld" "GPC_FOR_TARGET=./xgpc -B./" "GPCSOLIBSHORTNAME=libgpc.so" "GPCSOLIBDIR=lib" "GPC_EXTRA_INSTALL_LIBS=" "WITH_SHARED=@with_shared@" "FLOAT_H=" "EXTRA_PARTS=crtbegin.o crtend.o" "real_prefix=/mingw" prefix=$tmp_prefix && \ version=`sed -ne 's/"[^"]*$//;s/^#define GPC_VERSION_STRING *"//p' ../../gcc/p/version.h` && (cd $tmp_base && tar czf ../gpc-$version.i386- pc-mingw32.tar.gz *) && \ cd ../../gcc && rm -rf $tmp_base make[1]: Entering directory `/src/mingw/gcc-3.4.1-20040711-1/build/gcc' ../../gcc/p/Make-lang.in:725: warning: overriding commands for target `p/version.o' ../../gcc/p/Make-lang.in:719: warning: ignoring old commands for target `p/version.o' for directory in /src/mingw/gcc-3.4.1-20040711-1/build/gcc/tmp//mingw /src/mingw/gcc-3.4.1-20040711-1/build/gcc/tmp//mingw/bin /src/mingw/gcc- 3.4.1-20040711-1/build/gcc/tmp//mingw/lib/gcc/mingw32/3.4.1/units /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/lib/gcc/mingw32/3.4.1/include \ /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/info /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/doc/gpc /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/doc/gpc/demos /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/doc/gpc/docdemos /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/man/man1; do \ ../../gcc/p/script/mkdir-p -m a+rx $directory || exit 1; \ done if [ -f gpc-cross.exe ]; then \ rm -f /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/bin/mingw32`t='s,y,y,'; echo gpc | sed $t`.exe; \ /usr/local/bin/install -c gpc-cross.exe /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/bin/mingw32`t='s,y,y,'; echo gpc | sed $t`.exe && \ chmod a+x /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/bin/mingw32`t='s,y,y,'; echo gpc | sed $t`.exe; \ else \ rm -f /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/bin/`t='s,y,y,'; echo gpc | sed $t`.exe; \ /usr/local/bin/install -c xgpc.exe /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/bin/`t='s,y,y,'; echo gpc | sed $t`.exe && \ chmod a+x /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/bin/`t='s,y,y,'; echo gpc | sed $t`.exe; \ fi rm -f /src/mingw/gcc-3.4.1-20040711-1/build/gcc/tmp//mingw/bin/gpc-run /usr/local/bin/install -c gpc-run /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/bin/gpc-run chmod a+x /src/mingw/gcc-3.4.1-20040711-1/build/gcc/tmp//mingw/bin/gpc- run rm -f /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/libexec/gcc/mingw32/3.4.1/gpcpp.exe /usr/local/bin/install -c gpcpp.exe /src/mingw/gcc-3.4.1-20040711- 1/build/gcc/tmp//mingw/libexec/gcc/mingw32/3.4.1/gpcpp.exe /usr/local/bin/install: cannot create regular file `/src/mingw/gcc- 3.4.1-20040711- 1/build/gcc/tmp//mingw/libexec/gcc/mingw32/3.4.1/gpcpp.exe': No such file or directory make[1]: *** [install-gpcpp34] Error 1 make[1]: Leaving directory `/src/mingw/gcc-3.4.1-20040711-1/build/gcc' make: *** [pascal.bindist] Error 2
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Finally
Waldek's patch seems to be capable of finding more duplicate declarations than before. For example, it has found that "Maxlongint" was declared both in the system and gpc units, with the result that a program that compiled before (i.e., without update27h.diff applied) does not compile anymore ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof. Abimbola A. Olowofoyeku wrote:
Finally
Waldek's patch seems to be capable of finding more duplicate declarations than before. For example, it has found that "Maxlongint" was declared both in the system and gpc units, with the result that a program that compiled before (i.e., without update27h.diff applied) does not compile anymore ...
This is known problem -- ISO import forbids redeclaration (you may import multiple declarations, but they must have the same meaning). In standard units (`dos.pas' ...) we do:
import GPC (MaxLongInt => Orig_GPC_Maxlongint); System;
the rename prevents the conflict.
Note that `uses' is BP compatible, so you have no conflict if you write:
uses GPC, System;
Theoretically, we could make the problem transparent for users of `GPC' and `System' units. One way is to remove `MaxLongInt' form `GPC' module and make it a builtion (builtins may be redeclared). Another way is to add special attribute to symbols, so that symbols with such attribute can be redeclared. However, I followed Frank opinion that such conflicts are rare, so adding renames should be enough.
Note, that if conflict appears in user modules, the user have to modify the sources to resolve the conflict anyway. We could add some extra magic to the compiler to make it easier, but the lack of checking in previous GPC versions was a bug...
On 22 Jul 2004 at 0:56, Waldek Hebisch wrote:
Prof. Abimbola A. Olowofoyeku wrote:
Finally
Waldek's patch seems to be capable of finding more duplicate declarations than before. For example, it has found that "Maxlongint" was declared both in the system and gpc units, with the result that a program that compiled before (i.e., without update27h.diff applied) does not compile anymore ...
This is known problem -- ISO import forbids redeclaration (you may import multiple declarations, but they must have the same meaning). In standard units (`dos.pas' ...) we do:
import GPC (MaxLongInt => Orig_GPC_Maxlongint); System;
the rename prevents the conflict.
Note that `uses' is BP compatible, so you have no conflict if you write:
uses GPC, System;
Theoretically, we could make the problem transparent for users of `GPC' and `System' units. One way is to remove `MaxLongInt' form `GPC' module and make it a builtion (builtins may be redeclared). Another way is to add special attribute to symbols, so that symbols with such attribute can be redeclared. However, I followed Frank opinion that such conflicts are rare, so adding renames should be enough.
Note, that if conflict appears in user modules, the user have to modify the sources to resolve the conflict anyway. We could add some extra magic to the compiler to make it easier, but the lack of checking in previous GPC versions was a bug...
Fair enough. This means that I have to convert one of my big units (Sysutils) from a module to a unit.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof. Abimbola A. Olowofoyeku wrote:
Fair enough. This means that I have to convert one of my big units (Sysutils) from a module to a unit.
To clarify rules that I have implemented: for redefinitions it does not matter if you have modules or units. The distinction is made only between `import' and `uses':
import GPC; System;
signals error, while
uses GPC; System;
gives no error. My resoning was that typically exporter can not predict conflicts. On the other hands in importing (`using') module/unit one can decide what is proper way to resolve conflicts. IMHO for new code preffered way is qualified import plus renames. For quick fix in existing code one can change `import' to `uses'.
To compile Sysutils I have applied the patch below.
diff -u spp/sysutils.pas sysutils/sysutils.pas --- spp/sysutils.pas 2004-02-03 19:30:34.000000000 +0100 +++ sysutils/sysutils.pas 2004-07-14 19:54:21.000000000 +0200 @@ -49,7 +49,7 @@
{$i sysutils.exp}
-import GPC; System; +import GPC (MaxLongInt => GPC_MaxLongInt); System;
{ * @@ * under Cygwin/Mingw, if you don't want to use WinAPI routines but
Frank Heckenbach a écrit:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
I have compiled djgpp versions for gcc-3.2.3 and gcc-3.3.3 no error, two tests skipped as usual (no long real in djgpp, no german locale on my machine) they are uploaded as usual into
http://www.gnu-pascal.de/contrib/maurice/
Still the same problem of CPP_PREDEFINES with gcc-3.3.3 so I recommend still the use of gcc-3.2.3 based gpc (as the Chief with mingw)
For reference I have also uploaded the files gcc323s2.zip and gpc333s2.zip modified for gpc compilation which I have used (all diffs are inside and instructions are on the top level readme.gpc)
The only problem was with gcc-3.3.3 in the TARGET_OS_CPP_BUILTINS() defined in gcc/config/i386/djgpp.h as modified for djgpp in gcc333s2.zip the hunk ----------------------------------------------- @@ -85,8 +92,13 @@ #define TARGET_OS_CPP_BUILTINS() \ do \ { \ + if (!flag_iso) \ + builtin_define_with_int_value ("DJGPP",2); \ + builtin_define_with_int_value ("__DJGPP",2); \ + builtin_define_with_int_value ("__DJGPP__",2); \ builtin_define_std ("MSDOS"); \ builtin_define_std ("GO32"); \ + builtin_define_std ("unix"); \ builtin_assert ("system=msdos"); \ } \ while (0) ------------------------------------------------------------- used the function builtin_define_with_int_value() which was unknown during gpc compilation and made it to fail In fact this function is prototyped and defined in c-common.c While compiling gcc, c-common.o is linked into, which makes success, but this is not the case for gpc. As a quick work around, I changed this hunk into ------------------------------------------------------------- @@ -85,8 +92,13 @@ #define TARGET_OS_CPP_BUILTINS() \ do \ { \ + if (!flag_iso) \ + builtin_define ("DJGPP=2"); \ + builtin_define ("__DJGPP=2"); \ + builtin_define ("__DJGPP__=2"); \ builtin_define_std ("MSDOS"); \ builtin_define_std ("GO32"); \ + builtin_define_std ("unix"); \ builtin_assert ("system=msdos"); \ } \ while (0) --------------------------------------------------------------- which works. I do not understand the difference, but I checked that this function builtin_define_with_int_value() is a gooddity used only inside c-common.c and called from inside the various config header files only by djgpp.h So probably for the time going you can ignore this issue, I will take care of it only for djgpp.
I made a quick look with the new gp.exe with 3.2.3 DJGPP and __DJGPP__ are defined (but not __DJGPP) with 3.3.3 __DJGPP and __DJGPP__ are defined (but not DJGPP) (this is what results from the above hunk since flag_iso=1 in p/lang.c).
but in a C program all three are defined, so there is a kwirk elsewhere in both cases
Maurice
Maurice Lombardi wrote:
used the function builtin_define_with_int_value()
which was unknown during gpc compilation and made it to fail In fact this function is prototyped and defined in c-common.c While compiling gcc, c-common.o is linked into, which makes success, but this is not the case for gpc.
Yes, the c-* files are the C frontend. The corresponding function for GPC is attached.
I made a quick look with the new gp.exe with 3.2.3 DJGPP and __DJGPP__ are defined (but not __DJGPP) with 3.3.3 __DJGPP and __DJGPP__ are defined (but not DJGPP)
(this is what results from the above hunk since flag_iso=1 in p/lang.c).
I don't know if we should set flag_iso. IMHO it's a backend bug since the target files use C specific flags which don't make much sense in Pascal.
But since in GPC macros are active by default, it may be better to leave it so, so `DJGPP' will not be defined (in gcc-3.3.3 and above) and will not "pollute the namespace" (since macros are outside of any scope). We should just remember to test `{$ifdef __DJGPP__}' etc. with underscores.
but in a C program all three are defined,
Perhaps flag_iso is not on by default. Something like `-std=c89' might turn it on.
Frank
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
used the function builtin_define_with_int_value()
which was unknown during gpc compilation and made it to fail In fact this function is prototyped and defined in c-common.c While compiling gcc, c-common.o is linked into, which makes success, but this is not the case for gpc.
Yes, the c-* files are the C frontend. The corresponding function for GPC is attached.
OK. I applied this diff and restored the djgpp.h provided in gcc333s2.zip all is now correct. I have uploaded the new binary and the new modifid gcc333s2.zip in the usual directory.
Maurice
Frank Heckenbach a écrit:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
To run the tests I changed from running in the source gcc/p/test directory to running in the build/gcc directory (with make pascal.check) there was a makefile problem because the standard units are in the source tree, not in the build tree. Applying the following patch
---------------------------------------------------------
--- Make-lang.in.orig 2003-08-28 01:12:52.000000000 +0000 +++ Make-lang.in 2004-02-07 19:25:44.000000000 +0000 @@ -1104,7 +1104,7 @@ echo ""; \ sed -e "s,^srcdir *=.*,srcdir=`cd $(srcdir)/p/test && pwd`,; \ s,^PC *=.*,PC=`pwd`/xgpc -B`pwd`/,; \ - s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=`pwd`/p/units," \ + s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=$(srcdir)/p/units," \ $(srcdir)/p/test/Makefile; \ } > p/test/Makefile || { rm -f p/test/Makefile; false; } $(STAMP) "$@"
----------------------------------------------------------------
solves the problem
Maurice
Maurice Lombardi wrote:
To run the tests I changed from running in the source gcc/p/test directory to running in the build/gcc directory (with make pascal.check) there was a makefile problem because the standard units are in the source tree, not in the build tree. Applying the following patch
--- Make-lang.in.orig 2003-08-28 01:12:52.000000000 +0000 +++ Make-lang.in 2004-02-07 19:25:44.000000000 +0000 @@ -1104,7 +1104,7 @@ echo ""; \ sed -e "s,^srcdir *=.*,srcdir=`cd $(srcdir)/p/test && pwd`,; \ s,^PC *=.*,PC=`pwd`/xgpc -B`pwd`/,; \
s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=`pwd`/p/units," \
s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=$(srcdir)/p/units," \ $(srcdir)/p/test/Makefile; \
solves the problem
OK, thanks. Does this line also work (in case srcdir is a relative directory)?
s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=`cd $(srcdir)/p/units && pwd`," \
Frank
Dixitur illum ih8mj@fjf.gnu.de scribere...
s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=`cd $(srcdir)/p/units && pwd`," \
Of course it should work ;-) But you ought to really use
s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=$$(cd $(srcdir)/p/units && pwd)," \
//Thorsten
Thorsten Glaser wrote:
Dixitur illum ih8mj@fjf.gnu.de scribere...
s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=`cd $(srcdir)/p/units && pwd`," \Of course it should work ;-) But you ought to really use
s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=$$(cd $(srcdir)/p/units && pwd)," \
Why?
Frank
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
To run the tests I changed from running in the source gcc/p/test directory to running in the build/gcc directory (with make pascal.check) there was a makefile problem because the standard units are in the source tree, not in the build tree. Applying the following patch
--- Make-lang.in.orig 2003-08-28 01:12:52.000000000 +0000 +++ Make-lang.in 2004-02-07 19:25:44.000000000 +0000 @@ -1104,7 +1104,7 @@ echo ""; \ sed -e "s,^srcdir *=.*,srcdir=`cd $(srcdir)/p/test && pwd`,; \ s,^PC *=.*,PC=`pwd`/xgpc -B`pwd`/,; \
s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=`pwd`/p/units," \
s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=$(srcdir)/p/units," \ $(srcdir)/p/test/Makefile; \
solves the problem
I wonder what is happening there. I always run tests from `build/gcc' directory and all tests run fine for me. AFAIKS the test script sets uses: --unit-path=$SRCDIR --unit-path=$SRCDIR/../rts \ --unit-path=$SRCDIR/../units --unit-path=$DEFAULT_UNIT_DIR \
and the `$SRCDIR/../units' part should find units from the source tree.
Waldek Hebisch a écrit:
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
To run the tests I changed from running in the source gcc/p/test directory to running in the build/gcc directory (with make pascal.check) there was a makefile problem because the standard units are in the source tree, not in the build tree. Applying the following patch
--- Make-lang.in.orig 2003-08-28 01:12:52.000000000 +0000 +++ Make-lang.in 2004-02-07 19:25:44.000000000 +0000 @@ -1104,7 +1104,7 @@ echo ""; \ sed -e "s,^srcdir *=.*,srcdir=`cd $(srcdir)/p/test && pwd`,; \ s,^PC *=.*,PC=`pwd`/xgpc -B`pwd`/,; \
s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=`pwd`/p/units," \
s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=$(srcdir)/p/units," \ $(srcdir)/p/test/Makefile; \
solves the problem
I wonder what is happening there. I always run tests from `build/gcc' directory and all tests run fine for me. AFAIKS the test script sets uses: --unit-path=$SRCDIR --unit-path=$SRCDIR/../rts \ --unit-path=$SRCDIR/../units --unit-path=$DEFAULT_UNIT_DIR \
and the `$SRCDIR/../units' part should find units from the source tree.
You are right. In fact I have made this change in one of the previous alphas, forgot to say this to you and kept the diff on Make-lang.in in my files. I noticed it because Franck sent a new diff (RTSSTAGESTUFF) on the same file, and I sent my old diff to you. Now I have suppressed this diff, the Makefile generated in build/gcc/p/test has a wrong --unit-path but the test runs successfully because the script test_run supplies a correct unit-path So you should correct Make-lang.in either by supplying the correct unit-path or by suppressing it Notice that the I ../rts is necessary to find the generated files build/gcc/p/rts/rts-config.[h inc] which are not in the source tree.
Since I do not keep track of all my old attempts I cannot find when precisely I have introduced this.
Sorry
Maurice
Maurice Lombardi wrote:
You are right. In fact I have made this change in one of the previous alphas, forgot to say this to you and kept the diff on Make-lang.in in my files. I noticed it because Franck sent a new diff (RTSSTAGESTUFF) on the same file, and I sent my old diff to you. Now I have suppressed this diff, the Makefile generated in build/gcc/p/test has a wrong --unit-path but the test runs successfully because the script test_run supplies a correct unit-path So you should correct Make-lang.in either by supplying the correct unit-path or by suppressing it
I agree that there's a bit of duplication (but it may be useful for running in the source test directory), but the original line in Makefile.in was definitely wrong, as you pointed out, and I'm replacing it with:
s,^TEST_PATHS *=.*,TEST_PATHS=-I ../rts --unit-path=`cd $(srcdir)/p/units && pwd`," \
Notice that the I ../rts is necessary to find the generated files build/gcc/p/rts/rts-config.[h inc] which are not in the source tree.
Indeed.
Frank
On Sun, May 16, 2004 at 11:33:01PM +0200, Frank Heckenbach wrote:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work.
Waldek Hebisch and I are currently working on some larger changes, including qualified identifiers, range checking and support for gcc-3.4.0. An alpha version with these changes, which might be less stable, will probably be released in a few weeks.
I've uploaded Fedora/i686 binaries on the WWW upload page.
Emil
Frank Heckenbach wrote:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
Thanks for the beta version. I finally found the time to give it a try.
Building gpc-20040516 with gcc-3.3.2 on powerpc-apple-darwin, make bootstrap dies with:
stage1/xgcc -Bstage1/ -B/Developer/Pascal/gpc332d6/powerpc-apple-darwin/bin/ -o p/lang.o -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -I. -Ip -I../../gpc-332d6/gcc -I../../gpc-332d6/gcc/p -I../../gpc-332d6/gcc/config -I../../gpc-332d6/gcc/../include -DGPC -I../../gpc-332d6/gcc/p ../../gpc-332d6/gcc/p/lang.c ../../gpc-332d6/gcc/p/lang.c: In function `lang_init': ../../gpc-332d6/gcc/p/lang.c:511: warning: implicit declaration of function `rs6000_cpu_cpp_builtins' ../../gpc-332d6/gcc/p/lang.c:511: error: `pfile' undeclared (first use in this function) ../../gpc-332d6/gcc/p/lang.c:511: error: (Each undeclared identifier is reported only once ../../gpc-332d6/gcc/p/lang.c:511: error: for each function it appears in.) ../../gpc-332d6/gcc/p/lang.c: At top level: ../../gpc-332d6/gcc/p/lang.c:425: warning: `builtin_define_with_value' defined but not used ../../gpc-332d6/gcc/p/lang.c:432: warning: `builtin_define_std' defined but not used make[2]: *** [p/lang.o] Error 1 make[1]: *** [stage2_build] Error 2 make: *** [bootstrap] Error 2
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
Thanks for the beta version. I finally found the time to give it a try.
Building gpc-20040516 with gcc-3.3.2 on powerpc-apple-darwin, make bootstrap dies with:
stage1/xgcc -Bstage1/ -B/Developer/Pascal/gpc332d6/powerpc-apple-darwin/bin/ -o p/lang.o -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -I. -Ip -I../../gpc-332d6/gcc -I../../gpc-332d6/gcc/p -I../../gpc-332d6/gcc/config -I../../gpc-332d6/gcc/../include -DGPC -I../../gpc-332d6/gcc/p ../../gpc-332d6/gcc/p/lang.c ../../gpc-332d6/gcc/p/lang.c: In function `lang_init': ../../gpc-332d6/gcc/p/lang.c:511: warning: implicit declaration of function `rs6000_cpu_cpp_builtins'
This looks like the problem reported by Matthias Klose on powerpc-linux. The following patch should fix the problem.
--- ../tst25/gpc-20040516/p/Make-lang.in 2004-05-18 20:01:22.000000000 +0200 +++ gpc-20040516/p/Make-lang.in 2004-05-20 20:19:42.000000000 +0200 @@ -587,7 +587,7 @@ p/typecheck.o p/types.o p/convert.o p/dbxout.o p/dwarf2out.o \ p/expr.o p/fold-const.o p/function.o p/integrate.o p/optabs.o \ p/stor-layout.o p/toplev.o p/tree.o p/stmt.o p/emit-rtl.o \ - p/version.o + p/version.o $(C_TARGET_OBJS)
# Exclude patched files from language-independent object file list. # Not necessary for gcc-3 since for a library (libbackend.a), the linker does this automatically. --- ../tst25/gpc-20040516/p/lang.c 2004-05-19 01:12:12.000000000 +0200 +++ gpc-20040516/p/lang.c 2004-05-20 20:40:07.000000000 +0200 @@ -402,6 +402,29 @@ fprintf (stderr, "-D%s -D__%s -D__%s__ ", s, s, s); }
+int +c_lex (t) + tree * t; +{ + return 0; +} + +void +cpp_define (r, s) + void * r; + const char * s; +{ + builtin_define_std (s); +} + +void +cpp_assert (pfile, str) + void *pfile; + const char *str; +{ +} + + #define preprocessing_asm_p() 0 #define preprocessing_trad_p() 0 #define c_language (-1) @@ -554,9 +577,12 @@ /* @@ Backend bug: TARGET_OS_CPP_BUILTINS on some targets uses it though it's a C specific flag. */ #define flag_iso 1 - - TARGET_CPU_CPP_BUILTINS (); - TARGET_OS_CPP_BUILTINS (); + { + extern void rs6000_cpu_cpp_builtins PARAMS ((void *)); + void * pfile = 0; + TARGET_CPU_CPP_BUILTINS (); + TARGET_OS_CPP_BUILTINS (); + } #endif /* The following is no joke! The difference between what the preprocessor and the compiler think of BYTES_BIG_ENDIAN is
Waldek Hebisch wrote:
This looks like the problem reported by Matthias Klose on powerpc-linux. The following patch should fix the problem.
Thanks, this solves the problem, gpc-20040516 now builds on Mac OS X.
[G4:~/gnu/testgpc/test-20040516] adriaan% make rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core PC="gpc" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log | "./test_sum" -d Test Run By adriaan on 2004-05-28 16:08:43 Native configuration is powerpc-apple-darwin (G4.local.)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: asmtest.pas UNSUPPORTED: bill5.pas UNSUPPORTED: fjf165a.pas UNSUPPORTED: fjf77.pas FAIL: fproc.pas UNSUPPORTED: gettexttest.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: jj5.pas UNSUPPORTED: longr2.pas FAIL: nlgpp2.pas FAIL: nonloc2goto.pas FAIL: nonloc4goto.pas UNSUPPORTED: regextest.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 3910 # of expected passes 3895 # of unexpected failures 5 # of unsupported tests 10
gpc version 20040516, based on gcc-3.3.2
The failures in fproc.pas and nlgpp2.pas disappear when passing EXTRA_PFLAGS=--longjmp-all-nonlocal-labels (as discussed before). The failures in nonloc2goto.pas and nonloc4goto.pas go away when increasing the stacksize limit. We might reduce the recursion depth somewhat in these tests, in order to run them in the default Mac OS X stacksize limit of 512 KB.
Regards,
Adriaan van Os
The failures in nonloc2goto.pas and nonloc4goto.pas go away when increasing the stacksize limit. We might reduce the recursion depth somewhat in these tests, in order to run them in the default Mac OS X stacksize limit of 512 KB.
The alternative is to specify the stacksize when linking, e.g.
[G4:~/gnu/testgpc] adriaan% gpc -o nonloc2goto nonloc2goto.pas [G4:~/gnu/testgpc] adriaan% ./nonloc2goto Segmentation fault [G4:~/gnu/testgpc] adriaan% gpc -o nonloc2goto nonloc2goto.pas -Wl,-stack_size,0x100000,-stack_addr,0xc0000000 [G4:~/gnu/testgpc] adriaan% ./nonloc2goto OK
Regards,
Adriaan van Os
Adriaan van Os wrote:
The failures in nonloc2goto.pas and nonloc4goto.pas go away when increasing the stacksize limit. We might reduce the recursion depth somewhat in these tests, in order to run them in the default Mac OS X stacksize limit of 512 KB.
I'm a bit surprised. Depth 10000 with only one integer parameter shouldn't take much stack -- 16 bytes per recursion on my system. Is the procedure call overhead (WRT stack usage) so big on the Mac?
Actually the point is to use up some amount of stack, something like 32-64 KB is more than sufficient.
So perhaps they should be rewritten to use fewer recursions with more parameters to reduce the overhead, so the minimum stack usage (as given by parameter sizes alone) is still >= 32 KB, and the usage on the Mac is acceptable. Feel free to experiment and send me the results.
Please note that nonloc4goto.pas does some useless computations in order to avoid tail call optimization. Also, make sure that all parameters are actually used (non-trivially), so they can't possibly be optimized away.
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
The failures in nonloc2goto.pas and nonloc4goto.pas go away when increasing the stacksize limit. We might reduce the recursion depth somewhat in these tests, in order to run them in the default Mac OS X stacksize limit of 512 KB.
I'm a bit surprised. Depth 10000 with only one integer parameter shouldn't take much stack -- 16 bytes per recursion on my system. Is the procedure call overhead (WRT stack usage) so big on the Mac?
This is probably due to register preservation, see <http://developer.apple.com/documentation/DeveloperTools/Conceptual/ MachORuntime/2rt_powerpc_abi/chapter_9_section_5.html>. With Mach-O PowerPC calling conventions GPR1, GPR13-31, FPR14-31, VRSAVE and CR2-CR4 are saved, that's 24 registers or 96 bytes ! A waste of stack space, of course, not to mention slow execution due to memory stalls on the stack !
Actually the point is to use up some amount of stack, something like 32-64 KB is more than sufficient.
With 16 bytes per recursion and a depth of 10000 that would be 160 Kbytes. Did you try on Linux (IA-32) ?
So perhaps they should be rewritten to use fewer recursions with more parameters to reduce the overhead, so the minimum stack usage (as given by parameter sizes alone) is still >= 32 KB, and the usage on the Mac is acceptable. Feel free to experiment and send me the results.
OK, I will look into it.
Please note that nonloc4goto.pas does some useless computations in order to avoid tail call optimization. Also, make sure that all parameters are actually used (non-trivially), so they can't possibly be optimized away.
OK.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
The failures in nonloc2goto.pas and nonloc4goto.pas go away when increasing the stacksize limit. We might reduce the recursion depth somewhat in these tests, in order to run them in the default Mac OS X stacksize limit of 512 KB.
I'm a bit surprised. Depth 10000 with only one integer parameter shouldn't take much stack -- 16 bytes per recursion on my system. Is the procedure call overhead (WRT stack usage) so big on the Mac?
This is probably due to register preservation, see <http://developer.apple.com/documentation/DeveloperTools/Conceptual/ MachORuntime/2rt_powerpc_abi/chapter_9_section_5.html>. With Mach-O PowerPC calling conventions GPR1, GPR13-31, FPR14-31, VRSAVE and CR2-CR4 are saved, that's 24 registers or 96 bytes ! A waste of stack space, of course, not to mention slow execution due to memory stalls on the stack !
Ouch! Well, I guess with, say, 4 integer parameters and 2048 recursions, you should be on the safe side.
Actually the point is to use up some amount of stack, something like 32-64 KB is more than sufficient.
With 16 bytes per recursion and a depth of 10000 that would be 160 Kbytes. Did you try on Linux (IA-32) ?
Yes. It takes already more than necessary. The minimum (on any platform) is given by the parameter sizes (10000 * 4 for 32 bit integer).
Frank
Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
The failures in nonloc2goto.pas and nonloc4goto.pas go away when increasing the stacksize limit. We might reduce the recursion depth somewhat in these tests, in order to run them in the default Mac OS X stacksize limit of 512 KB.
I'm a bit surprised. Depth 10000 with only one integer parameter shouldn't take much stack -- 16 bytes per recursion on my system. Is the procedure call overhead (WRT stack usage) so big on the Mac?
This is probably due to register preservation, see http://developer.apple.com/documentation/DeveloperTools/Conceptual/ MachORuntime/2rt_powerpc_abi/chapter_9_section_5.html. With Mach-O PowerPC calling conventions GPR1, GPR13-31, FPR14-31, VRSAVE and CR2-CR4 are saved, that's 24 registers or 96 bytes ! A waste of stack space, of course, not to mention slow execution due to memory stalls on the stack !
Adriaan, I believe you're referencing the wrong section. The registers you list are the non-volitle registers which must be saved and restored for those registers the callee actually uses. The "PowerPC Stack Structure" section, http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/2rt_powerpc_abi/chapter_9_section_4.html, is the more appropriate reference. I'll have to take a look a the disassembly for the two programs to know for sure, but the minimum stack frame possible for a recursive routine with one integer parameter is 32 bytes - the standard required 24 bytes for the linkage area plus 4 bytes for the parameter area rounded up to the next 16 byte boundary.
Notes: Even though the integer parameter is passed in a register, there still must be a slot allocated in the stack frame parameter area for it. The 16 byte boundary requirement for stack frames isn't documented very well.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
[snip]
Frank Heckenbach wrote:
Adriaan van Os wrote:
The failures in nonloc2goto.pas and nonloc4goto.pas go away when increasing the stacksize limit. We might reduce the recursion depth somewhat in these tests, in order to run them in the default Mac OS X stacksize limit of 512 KB.
I'm a bit surprised. Depth 10000 with only one integer parameter shouldn't take much stack -- 16 bytes per recursion on my system. Is the procedure call overhead (WRT stack usage) so big on the Mac?
[snip]
... I'll have to take a look a the disassembly for the two programs to know for sure, but the minimum stack frame possible for a recursive routine with one integer parameter is 32 bytes - the standard required 24 bytes for the linkage area plus 4 bytes for the parameter area rounded up to the next 16 byte boundary.
In looking at the actual generated PPC assembly code for the trash procedure in nonloc2goto.pas and the trash function in nonloc4goto.pas, both end up using an 80 byte stack frame.
I'm at a loss to explain why the stack frame is so large. There is nothing in the assembly code for those two routines which would require that large of a stack frame but that's what the compiler generates.
To see whether it is a Pascal front end issue or a generic PPC backend issue, I wrote C equivalents for those to routines. For the C analogue to the trash procedure, I got a tail call optimization which used no stack frame at all. For the C analogue to the trash function, the generated code is fairly similar to the code generated for the Pascal function and the C analogue also ended up using an 80 byte stack frame (for no discernable reason either).
So, contrary to the documented requirements for the Mac OS X Mach-O runtime PowerPC stack structure, the back end seems to be forcing an 80 byte minimum stack frame size for some unknown reason when a routine uses a stack frame.
Note: The assembly code was generated using the compiler in Adriaan's currently distributed, pre-build Mac OS X GPC package. The compiler specs are:
Reading specs from /Developer/Pascal/gpc332d1/lib/gcc-lib/powerpc-apple-darwin/3.3.2/specs Configured with: ../gpc-332d1/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc332d1 --enable-threads=posix --target=powerpc-apple-darwin Thread model: posix gpc version 20030830, based on gcc-3.3.2
The command line options used for all assembly code generations was:
gpc -S -O3 --automake
P.S. Frank and/or Waldek, it would be interesting to know the reason why the Pascal code from nonloc2goto.pas:
procedure trash(n: integer); begin if n>0 then trash(n-1) end;
doesn't get tail call optimized; whereas, the C analogue:
void trash(int n){
if (n>0) { trash(n-1); } }
does get tail call optimized. (Note: I'm not trying to imply that you folks should expend any effort in getting GPC to tail optimize what is in essense artificial test code. I'm just curious as to the reason behind the difference in optimizations applied between the C and Pascal versions.)
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
In looking at the actual generated PPC assembly code for the trash procedure in nonloc2goto.pas and the trash function in nonloc4goto.pas, both end up using an 80 byte stack frame.
I'm at a loss to explain why the stack frame is so large. There is nothing in the assembly code for those two routines which would require that large of a stack frame but that's what the compiler generates.
Thanks for your comments to my previous post. I am experimenting a bit now and I think it has something to do with the --inline-functions flag, that is turned on by -O3. Without the --inline-functions flag, there is no stack overflow.
To see whether it is a Pascal front end issue or a generic PPC backend issue, I wrote C equivalents for those to routines.
What are the specs of the C compiler or did you use gpc as the C compiler driver ?
Regards,
Adriaan van Os
Adriaan van Os wrote:
Gale Paeper wrote:
In looking at the actual generated PPC assembly code for the trash procedure in nonloc2goto.pas and the trash function in nonloc4goto.pas, both end up using an 80 byte stack frame.
I'm at a loss to explain why the stack frame is so large. There is nothing in the assembly code for those two routines which would require that large of a stack frame but that's what the compiler generates.
Thanks for your comments to my previous post. I am experimenting a bit now and I think it has something to do with the --inline-functions flag, that is turned on by -O3. Without the --inline-functions flag, there is no stack overflow.
I wouldn't rely up the lack of a OS stack overflow report as indicative of a small stack size. In one -O3 execution test I ran with 10000 levels of recursion, I got no problems reported; however, the trash stack frame size was still 80 bytes as the assembly code showed.
I also tried varying optimization levels from no optimatization, -O, -O2, and -O3 and all stack frame sizes for thr trash procedure and function was 80 bytes.
I also saw a range of errors (illegal instruction, bus error, malloc deallocation problems) during program termination indicating something was stomping on memory being referenced by the terminating code. (This was seen in some follow up testing with a reduced recursion level to keep the stack in the 512K bounds. With or without Frank's writeln suggestion, I got the expected Pascal output - the errors showed up during termination code execution after the main program code had finished ececuting.) But that may be just bugs in the older gpc version 20030830 I'm testing with and may have been fixed in the new gpc version 20040516.
To see whether it is a Pascal front end issue or a generic PPC backend issue, I wrote C equivalents for those to routines.
What are the specs of the C compiler or did you use gpc as the C compiler driver ?
As I indicated in my previous posting , I used GPC as the compiler driver for both Pascal and C tests. As a follow up, I also looked at the assembly code produced by Apple's gcc compiler for the C code. The gcc specs are:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)
I didn't see any difference between Apple's gcc generated assembly code and the GPC driven C compiler generated assembly code. For both compilers' generated assembly code, the trash procedure was tail call optimized with no stack frame and the trash function had a stack frame size of 80 bytes.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
I wouldn't rely up the lack of a OS stack overflow report as indicative of a small stack size. In one -O3 execution test I ran with 10000 levels of recursion, I got no problems reported; however, the trash stack frame size was still 80 bytes as the assembly code showed.
I am puzzled. I think this *should* be reliable, the way the kernel works. Are you sure ? The difference between our tests is (maybe) you run OS X 10.3, where I run 10.2. However, I do have noticed that (on 10.2) "limit stacksize" gets confused when called three or four times in the same terminal window (so I always open a new terminal window before calling "limit stacksize"). Did you try adding a __UNIXSTACK segment with the linker, e.g.
% gpc -o nonloc2goto nonloc2goto.pas -Wl,-stack_size,0x100000,-stack_addr,0xc0000000
I also tried varying optimization levels from no optimatization, -O, -O2, and -O3 and all stack frame sizes for thr trash procedure and function was 80 bytes.
Sorry, this is a misunderstanding, --no-inline reduces the stack frame size for "recursion.pas" (the simple testprogram in my previous post) and for "nonloc2goto.pas" but not for "nonloc4goto.pas".
I also saw a range of errors (illegal instruction, bus error, malloc deallocation problems) during program termination indicating something was stomping on memory being referenced by the terminating code. (This was seen in some follow up testing with a reduced recursion level to keep the stack in the 512K bounds. With or without Frank's writeln suggestion, I got the expected Pascal output - the errors showed up during termination code execution after the main program code had finished ececuting.) But that may be just bugs in the older gpc version 20030830 I'm testing with and may have been fixed in the new gpc version 20040516.
I tried and didn't witness any difference in behaviour between the various compilers. The problem is that when stack is low, you are no longer running in an environment where anything can be trusted. For example, the Darwin kernel raises SIGSEGV for a stack overflow, then it attempts to create a signal frame on the already-full stack. This sometimes results in SIGBUS being reported, rather than SIGSEGV (see http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00747.html).
The same problem is in the GPC runtime, see the comment on top of the "InstallDefaultSignalHandlers" procedure in error.pas. A solution is to use an alternative stack in the signal handler. I have included a post by Matt Watson on the darwin-development list, with an example signal handler that uses an alternative stack.
I didn't see any difference between Apple's gcc generated assembly code and the GPC driven C compiler generated assembly code. For both compilers' generated assembly code, the trash procedure was tail call optimized with no stack frame and the trash function had a stack frame size of 80 bytes.
OK, I were just asking to be sure when reporting this whole thing to the gcc back-end folks.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Gale Paeper wrote:
I wouldn't rely up the lack of a OS stack overflow report as indicative of a small stack size. In one -O3 execution test I ran with 10000 levels of recursion, I got no problems reported; however, the trash stack frame size was still 80 bytes as the assembly code showed.
I am puzzled. I think this *should* be reliable, the way the kernel works. Are you sure ? The difference between our tests is (maybe) you run OS X 10.3, where I run 10.2.
It turns out that it just a difference between Mac OS X 10.2 and 10.3.1 (the version I'm testing under). The default stack size with 10.3.1 according to ulimit is 8192 kbytes. Your recursion.pas and the GPC test programs nonloc2goto.pas and nonloc4goto.pas are well within that stack limit so there wouldn't be any stack overflow to detect. When I increased the number of recursions to 200000 (which should exceed the default stack size limit), I did get a "Segmentation fault".
However, I do have noticed that (on 10.2) "limit stacksize" gets confused when called three or four times in the same terminal window (so I always open a new terminal window before calling "limit stacksize").
Limit isn't a built-in command for bash (the default shell with Mac OS X 10.3). Eventually figured out ulimit was the command to use.
Did you try adding a __UNIXSTACK segment with the linker, e.g.
% gpc -o nonloc2goto nonloc2goto.pas -Wl,-stack_size,0x100000,-stack_addr,0xc0000000
Doesn't have any effect as far as I can tell. I tried that (with the number of recursions set to the original 10000) for both your recursion.pas and nonloc2goto.pas and no stack overflow was detected with the default ulimit stack size of 8192 kbytes.
I also tried varying optimization levels from no optimatization, -O, -O2, and -O3 and all stack frame sizes for thr trash procedure and function was 80 bytes.
Sorry, this is a misunderstanding, --no-inline reduces the stack frame size for "recursion.pas" (the simple testprogram in my previous post) and for "nonloc2goto.pas" but not for "nonloc4goto.pas".
That's interesting. With --no-inline and -O3, the trash procedure in both recursion.pas and nonloc2goto.pas gets tail call optimized with no stack frame at all - just like the C analogue compiled with -O3 (without --no-inline).
I also saw a range of errors (illegal instruction, bus error, malloc deallocation problems) during program termination indicating something was stomping on memory being referenced by the terminating code. (This was seen in some follow up testing with a reduced recursion level to keep the stack in the 512K bounds. With or without Frank's writeln suggestion, I got the expected Pascal output - the errors showed up during termination code execution after the main program code had finished ececuting.) But that may be just bugs in the older gpc version 20030830 I'm testing with and may have been fixed in the new gpc version 20040516.
I tried and didn't witness any difference in behaviour between the various compilers. The problem is that when stack is low, you are no longer running in an environment where anything can be trusted. For example, the Darwin kernel raises SIGSEGV for a stack overflow, then it attempts to create a signal frame on the already-full stack. This sometimes results in SIGBUS being reported, rather than SIGSEGV (see http://gcc.gnu.org/ml/gcc-patches/2003-02/msg00747.html).
As I mentioned above, there was no stack overflow running under Mac OS X 10.3.1 so the stack overflow problems you mention don't apply.
Of the various compilers you tried, was one of them the gpc version 20030830 compiler (with no further patches applied) that you're distributing in the GPC Mac OS X binary package? And did your trials include reducing the number of recursions so there wasn't any stack overflow?
As I noted, with no stack overflow and with the gpc version 20030830 compiler I see range of errors (illegal instruction, bus error, malloc deallocation problems) during program termination for nonloc2goto.pas and nonloc4goto.pas. (I don't see any of those with your recursion.pas so it is most likely a problem related to goto code generation in at least the gpc version 20030830 compiler.)
(I took more detailed notes [e.g., program code changes, outputs, command line used for compiling, etc.] on the errors I was seeing. I can send it to you in private e-mail if you're interested.)
Perhaps the difference in what we're seeing is due to differences in the compiler versions we're using.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
That's interesting. With --no-inline and -O3, the trash procedure in both recursion.pas and nonloc2goto.pas gets tail call optimized with no stack frame at all - just like the C analogue compiled with -O3 (without --no-inline).
Perhaps without `--no-inline' the compiler first inlines the call from the main program (or outer routine), and then it doesn't do tail recursion because it doesn't recurse into the current routine (which is now the one containing the call, e.g. the main program). Just a wild guess, I haven't debugged this further. If that's so, the behaviour is certainly not optimal in this case. Perhaps with these assumptions, you'll be able to reproduce it in C code, which would be easier for reporting it to the backend people.
As I noted, with no stack overflow and with the gpc version 20030830 compiler I see range of errors (illegal instruction, bus error, malloc deallocation problems) during program termination for nonloc2goto.pas and nonloc4goto.pas. (I don't see any of those with your recursion.pas so it is most likely a problem related to goto code generation in at least the gpc version 20030830 compiler.)
It actually wasn't the `goto' code, but the local file variables were not properly cleaned up, then trashed on the stack, so the RTS which later tried to clean them up got confused. Since the internal structures contain function pointers, it's no surprise that a trashed structure can cause all kinds of strange errors.
Frank
Frank Heckenbach wrote:
Gale Paeper wrote:
That's interesting. With --no-inline and -O3, the trash procedure in both recursion.pas and nonloc2goto.pas gets tail call optimized with no stack frame at all - just like the C analogue compiled with -O3 (without --no-inline).
Perhaps without `--no-inline' the compiler first inlines the call from the main program (or outer routine), and then it doesn't do tail recursion because it doesn't recurse into the current routine (which is now the one containing the call, e.g. the main program). Just a wild guess, I haven't debugged this further. If that's so, the behaviour is certainly not optimal in this case. Perhaps with these assumptions, you'll be able to reproduce it in C code, which would be easier for reporting it to the backend people.
There seems to be something special in the case of a non-global/static linkage non-nested Pascal procedure that precludes recreating the same "--no-inline and -O3 versus -O3" tail call optimization effect in C.
For several variations of the following C program code:
#include <stdlib.h> #include <stdio.h> void trash(int n); int indirect();
int main(void){ if (indirect() != 0){ printf("Not zero"); } else{ printf("Zero"); } return 0; }
int indirect(){ trash(10000); return rand(); }
void trash(int n){ if (n>0) { trash(n-1); } }
everything I tried ended up with trash being tail call optimized. The options '-finline-functions' and '--no-inline' had no discernable effect.
The only case I could find that prevented tail call optimization in C was with gcc's C nested functions extension, i.e.,
#include <stdlib.h> #include <stdio.h>
int indirect();
int main(void){
void trash(int n){
if (n>0) { trash(n-1); } }
trash(10000); if (indirect() != 0){ printf("Not zero"); } else{ printf("Zero"); } return 0; }
int indirect(){
return rand(); }
However, with or without the '--no-inline' option (in combination with '-O3'), I couldn't get a tail call optimization on the nested C trash function.
As a further data point, I looked at the behavior of the trash procedure in a non-main program unit:
unit TrashTest; interface procedure trash(n: integer);
implementation
procedure trash(n: integer); begin if n>0 then trash(n-1) end; end.
In this configuration, the trash procedure gets tail call optimized by '-O3' without needing the '--no-inline' option.
Changing it so that trash is a nested procedure:
unit TrashTest; interface procedure outer(i: integer);
implementation
procedure outer(i: integer);
procedure trash(n: integer); begin if n>0 then trash(n-1) end; begin trash(i); end; end.
prevented the trash procedure from being tail call optimized even with the '--no-inline' option.
However, the unit variation of:
unit TrashTest; interface procedure outer(i: integer);
implementation
procedure trash(n: integer); begin if n>0 then trash(n-1) end;
procedure outer(i: integer);
begin trash(i); end; end.
end up duplicating the optimization behavior of the main program trash. With just '-O3' no tail call optimization, but with '-O3 --no-inline' you get tail optimization.
In looking at the generated assembly code, it looks like the main program trash procedure isn't being treated by the backend as a nested routine. Both C and Pascal nested routines get a ".0" label suffix which non-nested routines don't get. Since the main program trash doesn't get the ".0" label suffix, it appears that the backend is handling it as a non-nested routine.
So, it appears that for Pascal the behavioral effects depend upon whether or not a non-nested procedure has global or non-global linkage (or in C terminalogy external or static/non-external linkage).
Given that, I tried giving the C non-nested trash static linkage. No effect - it was tail call optimized with '-O3' regardless the usage of '-finline-functions' and '--no-inline'.
To summarize, for Pascal the "--no-inline and -O3 versus -O3" tail call optimization effect seems to depended upon the routine being treated as a non-nested routine with non-global/static linkage; however, for C the effect doesn't exist with non-nested routine with non-global/static linkage.
Frank, any ideas about what might be going on with this and if it is a backend problem how to duplicated the effect in C?
Gale Paeper gpaepeer@empirenet.com
Gale Paeper wrote:
In looking at the generated assembly code, it looks like the main program trash procedure isn't being treated by the backend as a nested routine. Both C and Pascal nested routines get a ".0" label suffix which non-nested routines don't get. Since the main program trash doesn't get the ".0" label suffix, it appears that the backend is handling it as a non-nested routine.
In fact the frontend does that -- deliberately (local routines need trampolines for routine pointers and all that stuff, and we don't want that for global (local to the main program, if you will) routines).
So, it appears that for Pascal the behavioral effects depend upon whether or not a non-nested procedure has global or non-global linkage (or in C terminalogy external or static/non-external linkage).
Static/external doesn't seem to make a difference AFAICS (neither in C nor Pascal), and I'm only considering global (i.e., non-nested) routines.
The difference really seems to be the call (from the same module), according to some debuggin I did, but I can't reproduce it in C.
Even stranger, in both compilers, optimize_tail_recursion() is called once and returns 1, according to the comment this means "the call was optimized into a goto." If that's true, it must be somehow un-optimized later!? I don't really understand this, it seems to require some deeper backend debugging for which I don't have the time now, I'm afraid.
Frank
Gale Paeper wrote:
I also saw a range of errors (illegal instruction, bus error, malloc deallocation problems) during program termination indicating something was stomping on memory being referenced by the terminating code. (This was seen in some follow up testing with a reduced recursion level to keep the stack in the 512K bounds. With or without Frank's writeln suggestion, I got the expected Pascal output - the errors showed up during termination code execution after the main program code had finished ececuting.) But that may be just bugs in the older gpc version 20030830 I'm testing with and may have been fixed in the new gpc version 20040516.
Probably, as that's what these tests are meant to verify. (Actually, they're just worked around for now, but this bug doesn't appear anymore, anyway.)
Frank
Gale Paeper wrote:
In looking at the actual generated PPC assembly code for the trash procedure in nonloc2goto.pas and the trash function in nonloc4goto.pas, both end up using an 80 byte stack frame.
I'm at a loss to explain why the stack frame is so large. There is nothing in the assembly code for those two routines which would require that large of a stack frame but that's what the compiler generates.
Thanks for your comments to my previous post. I am experimenting a bit now and I think it has something to do with the --inline-functions flag, that is turned on by -O3. Without the --inline-functions flag, there is no stack overflow.
Just to be sure that this is a possible powerpc code generation problem - how much stack does the following program eat on other platforms, with -O3 optimizations ? To find out, use the shell's setlimit command, or is there a better method ?.
program test(output);
procedure trash(n: integer); begin if n>0 then trash(n-1) end;
begin trash(10000); writeln('OK') end.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Just to be sure that this is a possible powerpc code generation problem
- how much stack does the following program eat on other platforms,
with -O3 optimizations ? To find out, use the shell's setlimit command, or is there a better method ?.
If you put this into the recursive routine:
WriteLn (PtrCard (@n));
the difference between successive numbers is the stack frame size. It's 16 on Linux/IA32 without optimization, 12 with `-O1' and above, same on DJGPP.
Frank
On 16 May 2004 at 23:33, Frank Heckenbach wrote:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work.
[...]
Did something change in the OOP handling? (particular relating to polymorphism). A test program for my OOP framework is broken. The symptom is that a particular (virtual) method call doesn't reach the most proximate object - rather, the method that is called seems to be from an ancestor object. If I reinstall 20030830 and use it to compile the program, it works fine (as it should). The same program also works fine when compiled with FPC and Delphi.
I am trying very hard to narrow it down to a short program, but without success so far. Every small test program works as expected. It may of course be the result of a hidden bug in the OOP framework that 20030830 allowed and now is not allowed anymore - but I doubt it.
I am really not sure how to proceed, so I thought I'd better ask anyway, whether Frank or Waldek have changed anything in the OOP handling that could have broken the polymorphism. I will, of course, keep trying. I realise that I am not giving you much useful information to work on, but it is because I currently don't have any ...
In the meantime, is there a low-level hack that I can use to force the correct method (and not one from a remote parent) to be called? That may give a clue as to whether the problem is in my code or elsewhere. The actual method call is done somewhere in a remote parent - but the method that is called is virtual, and therefore the call should trickle down the line if the method has been overridden in a descendant object.
Sorry if all this sounds like gibberish - it's been a long day ...
Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
On 28 May 2004 at 14:56, I (The African Chief) wrote:
Did something change in the OOP handling? (particular relating to polymorphism). A test program for my OOP framework is broken. The symptom is that a particular (virtual) method call doesn't reach the most proximate object - rather, the method that is called seems to be from an ancestor object.
[....] A new twist. The same program when compiled with 20040516 for Cygwin works okay. So the problem is not a GPC problem. It seems to be Mingw- specific, so please ignore my earlier mail.
I thought it could have been related to the gcc backend version, but it is not. It seems that the issue is the runtime (unless there is indeed a hidden bug in my code). I can't even imagine how I would begin to debug this one :-(
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
On 28 May 2004 at 14:56, Prof A Olowofoyeku (The African Chief) wrote:
Did something change in the OOP handling? (particular relating to polymorphism). A test program for my OOP framework is broken.
[...] I have found a temporary solution - using a static object rather than a pointer to an object.
This raises some questions about the correct use of the extended "New" - e.g., pmyobject := new (pmyobjecttype, init (...));
When I have understood the problem properly and I can formulate a short test program, I will report back ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Hi all
I have released Mingw binaries for gpc-20040516. You can get them here: http://gnu-pascal.de/contrib/chief/win32/gcc-3.x/gpc-20040516.i386-pc-mingw3...
If you want a copy of gp-0.55 (and a version of collect2.exe that allows the linking of Win32 binary resources (.res)), get this: http://gnu-pascal.de/contrib/chief/win32/gcc-3.x/gpc-20040516-mingw- extra.tar.gz
To see other Mingw GPC goodies, look here: http://www.gnu-pascal.de/contrib/chief/win32/mingw32/
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Hi all
I have released a new version of the Dev Pascal IDE+GPC for Mingw bundle. This version has been updated with gpc-20040516 and the latest versions of the Mingw runtime. There are also a number of bug fixes and enhancements.
You can download it here: http://www.gnu-pascal.de/contrib/chief/win32/dev_gnu_pascal-1.9.4.2.exe
Dev+GPC is a full GPLed Win32 programming environment and IDE. It uses the Mingw GPC compiler but can also use the FreePascal compiler.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof. Abimbola A. Olowofoyeku (The African Chief) wrote:
On 16 May 2004 at 23:33, Frank Heckenbach wrote:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work.
[...]
Did something change in the OOP handling? (particular relating to polymorphism). A test program for my OOP framework is broken. The symptom is that a particular (virtual) method call doesn't reach the most proximate object - rather, the method that is called seems to be from an ancestor object. If I reinstall 20030830 and use it to compile the program, it works fine (as it should). The same program also works fine when compiled with FPC and Delphi.
The only regression I found in gpc-20040516 are wrong line numbers in debug info. I noticed that becouse apparently when single-stepping wrong function was called. However breakpoints on function names work as expected.
Waldek Hebisch wrote:
Prof. Abimbola A. Olowofoyeku (The African Chief) wrote:
On 16 May 2004 at 23:33, Frank Heckenbach wrote:
I have uploaded a new beta version of GPC to http://www.gnu-pascal.de/beta/.
This version contains mostly bugfixes and only few and smaller new features. Therefore, if no serious bugs will be found in the next fews days, it can be recommended for production work.
[...]
Did something change in the OOP handling? (particular relating to polymorphism). A test program for my OOP framework is broken. The symptom is that a particular (virtual) method call doesn't reach the most proximate object - rather, the method that is called seems to be from an ancestor object. If I reinstall 20030830 and use it to compile the program, it works fine (as it should). The same program also works fine when compiled with FPC and Delphi.
The only regression I found in gpc-20040516 are wrong line numbers in debug info. I noticed that becouse apparently when single-stepping wrong function was called. However breakpoints on function names work as expected.
Yes, that's a known problem. (That's the bison issues I mentioned before.) I hope to fix it soon, but since it'll probably require working on bison itself, I'll have to see when I can do it ...
Frank
-
Adriaan van Os -
Emil Jerabek -
Frank Heckenbach -
Frank Heckenbach -
Gale Paeper -
Matthias Klose -
Maurice Lombardi -
Prof A Olowofoyeku (The African Chief) -
Russell Whitaker -
Thorsten Glaser -
Waldek Hebisch