Another memory management bugfix, thanks to Waldek Hebisch. (I've updated the archives on the server again.)
Those who've seen memory problems with the new GPC, please try again with this and the other patches applied.
Frank
Frank Heckenbach wrote:
Another memory management bugfix, thanks to Waldek Hebisch. (I've updated the archives on the server again.)
Those who've seen memory problems with the new GPC, please try again with this and the other patches applied.
Frank, you changed the patch and it does not work. One have to apply the following patch AFTER the patch that Frank posted. I advise also to do `touch parse.c' -- otherwise make may want to rebuild it and it is tricky to get correct version of bison. I fetched bison-1.875b from http://multivac.cwru.edu/mirror/packages/bison-1.875b.tar.bz2 I had to modify parse.c by hand to undefine `abort', after that it worked. Other versions of bison gave me non-working compiler.
And now the patch:
diff -ru gpc-20030830.orig/p/options.c gpc-20030830/p/options.c --- gpc-20030830.orig/p/options.c Sun Sep 14 02:15:08 2003 +++ gpc-20030830/p/options.c Sun Sep 14 02:16:25 2003 @@ -609,7 +609,9 @@ return; #define BO(NAME) co->NAME = NAME; if (save_current) - BACKEND_OPTIONS + { + BACKEND_OPTIONS + } #undef BO co = options; #define BO(NAME) NAME = co->NAME;
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Another memory management bugfix, thanks to Waldek Hebisch. (I've updated the archives on the server again.)
Those who've seen memory problems with the new GPC, please try again with this and the other patches applied.
Frank, you changed the patch and it does not work. One have to apply the following patch AFTER the patch that Frank posted. I advise also to do `touch parse.c' -- otherwise make may want to rebuild it and it is tricky to get correct version of bison. I fetched bison-1.875b from http://multivac.cwru.edu/mirror/packages/bison-1.875b.tar.bz2 I had to modify parse.c by hand to undefine `abort', after that it worked. Other versions of bison gave me non-working compiler.
And now the patch:
diff -ru gpc-20030830.orig/p/options.c gpc-20030830/p/options.c --- gpc-20030830.orig/p/options.c Sun Sep 14 02:15:08 2003 +++ gpc-20030830/p/options.c Sun Sep 14 02:16:25 2003 @@ -609,7 +609,9 @@ return; #define BO(NAME) co->NAME = NAME; if (save_current)
- BACKEND_OPTIONS
- {
BACKEND_OPTIONS- }
#undef BO co = options; #define BO(NAME) NAME = co->NAME;
Thanks for the server update and the patch.
The compiler build now passes string.pas and error.pas, but stops at math.pas as follows:
../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/Users/adriaan/gnu/gpc-331d4/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc-331d4/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.3.1'" /Users/adriaan/gnu/gpc-331d4/gcc/p/rts/math.pas /var/tmp//ccCnNWaU.s:1871:FATAL:Symbol L__p_Complex_Ln$stub already defined.
The build is on Darwin with gcc-3.3.1, the latest gpc-20030830 and the above patch.
Regards,
Adriaan van Os
Adriaan van Os wrote:
The compiler build now passes string.pas and error.pas, but stops at math.pas as follows:
../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/Users/adriaan/gnu/gpc-331d4/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /Users/adriaan/gnu/gpc-331d4/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.3.1'" /Users/adriaan/gnu/gpc-331d4/gcc/p/rts/math.pas /var/tmp//ccCnNWaU.s:1871:FATAL:Symbol L__p_Complex_Ln$stub already defined.
Hmm, perhaps the assembler doesn't like `_p_Complex_Ln' to be an external symbol (for complex `Ln' internally) and an asmname of an function.
Does it help if you replace `Ln' by `Complex_Ln' in Complex_ArcSin, Complex_ArcCos and Complex_Power? Or if you move the implementation of Complex_ArcSin and Complex_ArcCos after that of Complex_Ln? (Please try both.)
Frank
Frank Heckenbach wrote:
Hmm, perhaps the assembler doesn't like `_p_Complex_Ln' to be an external symbol (for complex `Ln' internally) and an asmname of an function.
Does it help if you replace `Ln' by `Complex_Ln' in Complex_ArcSin, Complex_ArcCos and Complex_Power?
It does, thanks, the compiler now builds.
Or if you move the implementation of Complex_ArcSin and Complex_ArcCos after that of Complex_Ln? (Please try both.)
This doesn't help.
Regards,
Adriaan van Os
Waldek Hebisch wrote:
Frank, you changed the patch and it does not work. One have to apply the following patch AFTER the patch that Frank posted.
Oh yeah, thanks.
I advise also to do `touch parse.c' -- otherwise make may
Actually I think `touch parse.h'. parse.c is modified in the patch as well, but if parse.h remains older, the Makefile wants to run bison.
Frank
Frank Heckenbach a écrit:
Another memory management bugfix, thanks to Waldek Hebisch. (I've updated the archives on the server again.)
I have downloaded today the new version of gpc-20030830, touched parse.h It compiles under DJGPP with gcc-3.3.1 Running the test suite with EXTRA_TEST_PFLAGS="-gstabs -DMSDOS -DGO32 -D__GO32__" results in the following errors
TEST dialec3.pas: c:/djgpp/b-331-20030830/gnu/gcc-3.31/gcc/p/test/a.out: cannot open file `prn' for writing (No such file or directory (ENOENT)) (error #443 at 177a4) TEST dialec5.pas: c:/djgpp/b-331-20030830/gnu/gcc-3.31/gcc/p/test/a.out: cannot open file `prn' for writing (No such file or directory (ENOENT)) (error #443 at 16b3) TEST dialec6.pas: c:/djgpp/b-331-20030830/gnu/gcc-3.31/gcc/p/test/a.out: cannot open file `prn' for writing (No such file or directory (ENOENT)) (error #443 at 17893) TEST fjf401.pas: failed 1: /etc/a.conf (expected: c:/djgpp/b-331-20030830/gnu/gcc-3.31/gcc/p/test/c:/djgpp/b-331-20030830/gnu/gcc-3.31/gcc/p/test/a.ini) TEST fjf687.pas: failed `foo\' TEST gpctest.pas: Error in RemoveDirSeparator
They were already present in the first version of gpc-20030830, but hidden amongst the many error messages coming from the absence of default defines I have reported. They are not present with gcc-3.2.x
Running the test suite with in addition "-DDJGPP" results in a lot of error messages, each time GPC calls CC1 to compile a C program, e.g.
TEST crttest.pas: <command line>:5:1: warning: "DJGPP" redefined <built-in>:59:1: warning: this is the location of the previous definition OK
As in this case it results frequently (not always) only in a warning.
This confirms that there is a problem with the built-in's in gpc compiled with gcc-3.3.x
gcc knows the default defines DJGPP MSDOS GO32, while gpc do not
Maurice
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
Another memory management bugfix, thanks to Waldek Hebisch. (I've updated the archives on the server again.)
I have downloaded today the new version of gpc-20030830, touched parse.h It compiles under DJGPP with gcc-3.3.1 Running the test suite with EXTRA_TEST_PFLAGS="-gstabs -DMSDOS -DGO32 -D__GO32__" results in the following errors
TEST dialec3.pas: c:/djgpp/b-331-20030830/gnu/gcc-3.31/gcc/p/test/a.out: cannot open file `prn' for writing (No such file or directory (ENOENT)) (error #443 at 177a4) TEST fjf401.pas: failed 1: /etc/a.conf (expected: c:/djgpp/b-331-20030830/gnu/gcc-3.31/gcc/p/test/c:/djgpp/b-331-20030830/gnu/gcc-3.31/gcc/p/test/a.ini) TEST fjf687.pas: failed `foo\' TEST gpctest.pas: Error in RemoveDirSeparator
They were already present in the first version of gpc-20030830, but hidden amongst the many error messages coming from the absence of default defines I have reported. They are not present with gcc-3.2.x
You might have to add `-D__OS_DOS__' as well (since the built-in definition, inferred from a built-in `-DMSDOS', is probably broken as well).
(As a temporary work-around, of course.)
Running the test suite with in addition "-DDJGPP" results in a lot of error messages, each time GPC calls CC1 to compile a C program, e.g.
TEST crttest.pas: <command line>:5:1: warning: "DJGPP" redefined <built-in>:59:1: warning: this is the location of the previous definition OK
As in this case it results frequently (not always) only in a warning.
Perhaps `-DDJGPP=2' will avoid the warning. But it might not be necessary to define `DJGPP' at all.
Frank
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
You might have to add `-D__OS_DOS__' as well (since the built-in definition, inferred from a built-in `-DMSDOS', is probably broken as well).
<snip>
Perhaps `-DDJGPP=2' will avoid the warning. But it might not be necessary to define `DJGPP' at all.
Indeed but the others remain. With make EXTRA_TEST_PFLAGS="-gstabs -DMSDOS -D__MSDOS__ -DGO32 -D__GO32__ -DDJGPP=2 -D__DJGPP__=2 -D__OS_DOS__"
I obtain (test_summary).
TEST dialec3.pas: c:/djgpp/b-331-20030830/gnu/gcc-3.31/gcc/p/test/a.out: cannot open file `prn' for writing (No such file or directory (ENOENT)) (error #443 at 17863) TEST dialec5.pas: c:/djgpp/b-331-20030830/gnu/gcc-3.31/gcc/p/test/a.out: cannot open file `prn' for writing (No such file or directory (ENOENT)) (error #443 at 16b3) TEST dialec6.pas: c:/djgpp/b-331-20030830/gnu/gcc-3.31/gcc/p/test/a.out: cannot open file `prn' for writing (No such file or directory (ENOENT)) (error #443 at 17893) TEST fjf165a.pas: SKIPPED: German locale not installed TEST fjf401.pas: failed 1: /etc/a.conf (expected: c:/djgpp/b-331-20030830/gnu/gcc-3.31/gcc/p/test/c:/djgpp/b-331-20030830/gnu/gcc-3.31/gcc/p/test/a.ini) TEST fjf687.pas: failed `foo\' TEST gpctest.pas: Error in RemoveDirSeparator TEST longr2.pas: SKIPPED: no LongReal math routines available TEST y2k.pas: failed 1999 1999
# of GPC tests 3794 # of GPC tests passed 3785 # of GPC tests skipped 2 # of GPC tests failed 7
To check that this is not a DJGPP bug I have compiled with mingw32:
Program Test; begin WriteLn('WIN32 ',{$ifndef WIN32} 'NOT ', {$endif}'defined '); WriteLn('_WIN32 ',{$ifndef _WIN32} 'NOT ', {$endif}'defined '); WriteLn('__WIN32 ',{$ifndef __WIN32} 'NOT ', {$endif}'defined '); WriteLn('__WIN32__ ',{$ifndef __WIN32__} 'NOT ', {$endif}'defined '); WriteLn('__MINGW32__ ',{$ifndef __MINGW32__} 'NOT ', {$endif}'defined '); WriteLn('__MSVCRT__ ',{$ifndef __MSVCRT__} 'NOT ', {$endif}'defined '); WriteLn('WINNT ',{$ifndef WINNT} 'NOT ', {$endif}'defined '); WriteLn('_X86_ ',{$ifndef _X86_} 'NOT ', {$endif}'defined '); end.
I obtain
WIN32 NOT defined _WIN32 NOT defined __WIN32 NOT defined __WIN32__ NOT defined __MINGW32__ NOT defined __MSVCRT__ NOT defined WINNT NOT defined _X86_ NOT defined
All are defined with gcc-3.2.2 based gpc-20030507
Hope this helps
Maurice
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
You might have to add `-D__OS_DOS__' as well (since the built-in definition, inferred from a built-in `-DMSDOS', is probably broken as well).
<snip> > Perhaps `-DDJGPP=2' will avoid the warning. But it might not be > necessary to define `DJGPP' at all.
Indeed but the others remain. With make EXTRA_TEST_PFLAGS="-gstabs -DMSDOS -D__MSDOS__ -DGO32 -D__GO32__ -DDJGPP=2 -D__DJGPP__=2 -D__OS_DOS__"
I obtain (test_summary).
Ah, OK. You should probably also set them when (re)building the RTS.
Frank
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
Frank Heckenbach a écrit:
You might have to add `-D__OS_DOS__' as well (since the built-in definition, inferred from a built-in `-DMSDOS', is probably broken as well).
<snip>
Perhaps `-DDJGPP=2' will avoid the warning. But it might not be necessary to define `DJGPP' at all.
Indeed but the others remain. With make EXTRA_TEST_PFLAGS="-gstabs -DMSDOS -D__MSDOS__ -DGO32 -D__GO32__ -DDJGPP=2 -D__DJGPP__=2 -D__OS_DOS__"
I obtain (test_summary).
Ah, OK. You should probably also set them when (re)building the RTS.
OK. With this I obtain zero error when running the test suite. So all those errors which appeared between 3.2.3 and 3.3.1 seem to be due to this different way of dealing with predefines.
Maurice
-
Adriaan van Os -
Frank Heckenbach -
Maurice Lombardi -
Waldek Hebisch