I did some work on updating gpc to newer gcc versions. You can find it at GitHub:
https://github.com/hebisch/gpc
This is experimental work. 4.2 and 4.3 ports (on "master" Git branch) are basically in "works for my purpose" state: on my machine compiler builds and passes test suite with small (but nonzero) number of failures. On 4.5.1 there is initial port to gcc-4.[45] -- this one is broken from user point of view and may be of some use only for people who want to seriously work on the compiler.
Note that this is _not_ a release. There are relatively easy to fix but non working things (in particular some features of Makefiles are broken). Testing was limited to running testsute just for one configuration. I estimate that fixing easily fixable stuff and polishing things would take me about a week -- unfortunately I am busy with other things. So I decided to make the code available "as is". If there will be bug reports, I will look at them and there is reasonable chance that I will fix them. But otherwise I do not plan to work on gpc in near future.
If you want to try the code note that there are changes to build process, look at toplevel README file.
Waldek Hebisch wrote:
I did some work on updating gpc to newer gcc versions. You can find it at GitHub:
Thanks a lot for the update !
I tried with gcc-4.3.5 on i386-apple-darwin9. Building gcc-4.3.5 on Mac OS X can be a bit problematic. First, gmp and mpfr must be built. The key point is that gmp and mpfr must be built 32-bit or 32-bit/64-bit "universal". Without appropriate configure switches, libgmp and libmpfr will be built for x86_64 only and subsequently the gcc-4.3.5 build will fail. See http://gmplib.org/list-archives/gmp-discuss/2010-September/004312.html for an explanation on how to build gmp"universal". An added difficulty is that building gmp on Mac OS X requires the right gcc version (gcc-4.2 or gcc-4.1.2).
Once gcc-4.3.5 itself builds, adding gpc is no problem.
[P18:~] adriaan% gpc -v Using built-in specs. Configured with: ../gcc-4.3.5/configure --enable-languages=c,pascal --enable-threads=posix --disable-nls --target=i386-apple-darwin9 --host=i386-apple-darwin9 --build=i386-apple-darwin9 --prefix=/Developer/Pascal/gpc435u1 --with-arch=pentium-m --with-tune=prescott --with-gmp=/usr/local --with-mpfr=/usr/local --disable-multilib --disable-mapped-location Thread model: posix gpc version 20070904, based on gcc-4.3.5
The testsuite results are as follows:
[P18:gcc/p/test] 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 GP= 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 2011-06-21 07:03:38 Native configuration is i386-apple-darwin9 (P18)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas FAIL: fjf1102.pas UNSUPPORTED: fjf165a.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf787.pas FAIL: fjf848a.pas FAIL: fjf848b.pas FAIL: fjf848c.pas FAIL: fjf998r.pas FAIL: prep2p.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 5111 # of expected passes 5097 # of unexpected failures 10 # of unsupported tests 4
gpc version 20070904, based on gcc-4.3.5
Regards,
Adriaan van Os
Waldek Hebisch wrote:
If you want to try the code note that there are changes to build process, look at toplevel README file.
Known problems:
- with gcc-4.y.z testsuite will fail if run immediately after build.
Either install before running testsuite or copy 'libgpc.a' from libgpc build directory to gcc subdirectory and copy rts-confing.inc from libgpc build directory to gcc/p/rts subdirectory (you need to create rts subdirectiry) 2) I did not try to build shared libgpc -- it is probably broken. You would need to fix Makefiles to build it. 3) -Wparenthesis does not work with gcc-4.3.z 4) Utilities (binobj and gpidump) are not build with gcc-4.y.z
I tried to build the shared libgpc on i386-apple-darwin9 and it doesn't appear to be broken there. Note the changed Pascal rts location in the gcc source tree.
[P18:~/gpc/gpc435u1] adriaan% cd build/i386-apple-darwin9/libgpc/p/rts [P18:libgpc/p/rts] adriaan% make GPCSOLIBNAME=libgpc-435u1.dylib WITH_SHARED=yes TARGET_MACHO=1 ..... [P18:libgpc/p/rts] adriaan% ls -l *dylib -rwxr-xr-x 1 adriaan admin 223228 21 jun 10:22 libgpc-435u1.dylib
My first impression is that the gcc-4.3.5 back-end on Mac OS X is a big improvement, because the default debug format is now dwarf-2 instead of stabs. I will also try out 64-bit.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Waldek Hebisch wrote:
If you want to try the code note that there are changes to build process, look at toplevel README file.
Known problems:
- with gcc-4.y.z testsuite will fail if run immediately after build.
Either install before running testsuite or copy 'libgpc.a' from libgpc build directory to gcc subdirectory and copy rts-confing.inc from libgpc build directory to gcc/p/rts subdirectory (you need to create rts subdirectiry) 2) I did not try to build shared libgpc -- it is probably broken. You would need to fix Makefiles to build it. 3) -Wparenthesis does not work with gcc-4.3.z 4) Utilities (binobj and gpidump) are not build with gcc-4.y.z
I tried to build the shared libgpc on i386-apple-darwin9 and it doesn't appear to be broken there. Note the changed Pascal rts location in the gcc source tree.
[P18:~/gpc/gpc435u1] adriaan% cd build/i386-apple-darwin9/libgpc/p/rts [P18:libgpc/p/rts] adriaan% make GPCSOLIBNAME=libgpc-435u1.dylib WITH_SHARED=yes TARGET_MACHO=1 ..... [P18:libgpc/p/rts] adriaan% ls -l *dylib -rwxr-xr-x 1 adriaan admin 223228 21 jun 10:22 libgpc-435u1.dylib
Thanks for information. Actually building shared libgpc "by hand" (that is by invoking make in libgpc subdirectory with appropriate arguments) should work. However, there is some support to trigger build of shared libgpc from configure and AFAICS this does not work. Also, it is now possible to build libgpc in "multilib" version, for example both 32 and 64 version in the same build, but the Makefile does not know where to install resulting shared libraries...
Waldek Hebisch wrote:
Thanks for information. Actually building shared libgpc "by hand" (that is by invoking make in libgpc subdirectory with appropriate arguments) should work. However, there is some support to trigger build of shared libgpc from configure and AFAICS this does not work. Also, it is now possible to build libgpc in "multilib" version, for example both 32 and 64 version in the same build, but the Makefile does not know where to install resulting shared libraries...
I built gcc-4.3.5 with multilibs enabled (the default on Mac OS X)
../gcc-4.3.5/configure --enable-languages=c,pascal --enable-threads=posix --disable-nls --target=i386-apple-darwin9 --host=i386-apple-darwin9 --build=i386-apple-darwin9 --prefix=/Developer/Pascal/gpc435u1 --disable-mapped-location
This does build and install 32-bit and 64-bit gcc.a and gpc.a. The 32-bit libs are installed in ....../lib/gcc/i386-apple-darwin9/4.3.5, the 64-bit libs in a subfolder ....../lib/gcc/i386-apple-darwin9/4.3.5/x86_64.
The gpc -m32 and -m64 now automatically work. Couldn't be better.
Regards,
Adriaan van Os
The gpc -m32 and -m64 now automatically work. Couldn't be better.
Running the 64-bit testsuite.
[P18:gcc/p/test] adriaan% make EXTRA_PFLAGS=-m64 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 GP= PC="gpc" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused -m64 " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused -m64 " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log | "./test_sum" -d Test Run By adriaan on 2011-06-23 20:56:49 Native configuration is i386-apple-darwin9 (P18)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas FAIL: fieldw.pas FAIL: fjf1102.pas UNSUPPORTED: fjf165a.pas FAIL: fjf23.pas FAIL: fjf30b.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf787.pas FAIL: fjf848a.pas FAIL: fjf848b.pas FAIL: fjf848c.pas UNSUPPORTED: gmptest.pas FAIL: mir047h.pas FAIL: prep2p.pas FAIL: systemtest.pas FAIL: writeb.pas FAIL: writec.pas FAIL: writee.pas FAIL: writeg.pas
=== gpc Summary ===
# of tests 5111 # of expected passes 5089 # of unexpected failures 17 # of unsupported tests 5
Failures specific for 64-bit are
FAIL: fieldw.pas failed (Foo)
FAIL: fjf23.pas ./a.out: value out of range (error #300 at 1000017be)
FAIL: fjf30b.pas failed 2
FAIL: mir047h.pas O./test_run: line 204: 35643 Segmentation fault ./"$A_OUT" "$1"
FAIL: writeb.pas Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #2: LongInt `-7890123456789012345' was not indented, but should be. Run #2: LongInt `12345678901234567890' was not indented, but should be. Run #3: LongInt `-7890123456789012345' was indented with field width 21, but should be with field width 44. (etcetera)
Regards,
Adriaan van Os
Waldek Hebisch wrote:
I did some work on updating gpc to newer gcc versions. You can find it at GitHub:
In your snapshot, I miss the patch you gave here http://www.g-n-u.de/pipermail/gpc/2007-November/014238.html,
and the patch given by Frank Heckenbach here http://www.g-n-u.de/pipermail/gpc/2008-April/014370.html.
By the way, the gpc mailing list archive seems to be changed. I preferred the old archive (and it breaks a lot of links).
Regards,
Adriaan van Os
Adriaan van Os wrote:
By the way, the gpc mailing list archive seems to be changed. I preferred the old archive
Well, thanks. It's always nice to hear so -- especially after it was decomissioned. ;-) While it was active, I rarely got positive feedback, only sometimes complaints. (BTW, I think it was you who complained that the old one displayed email addresses in clear -- the new one mangles them a bit at least.)
Anyway, the thing is, I wrote the old archive program (crystal) for a website for a specific project several years ago which is long done and its website taken offline. So my direct need to support this program exists no more.
Since crystal was written in GPC, it seemed appropriate to use it with the old GPC mailing list (majordomo) which didn't have an archive of its own.
But software is aging and maintenance effort was starting to increase. E.g., a major version upgrade of MySQL required some SQL syntax changes which Benedikt Wildenhain made (but the next upgrade may require further changes). Upgrades of the web server (apache) and email server (exim) so far haven't required changes to crystal, but it can't be ruled out that future upgrades will. And, of course, being written in GPC means that we can't even build it with a current GCC (not to depreciate Waldek's efforts, but I hope it's obvious that I wouldn't install a program on a public web site built with a compiler with major changes (for gcc-4.x) that haven't received much testing apart from running the test suite AFAIK, let alone security auditing).
Furthermore, we (at least me as well as Anja Gerwinski who maintains the mailing lists) have never been very happy with majordomo, so when the GPC web site was moved to a new server (hardware), we decided to take this opportunity to move all mailing lists to mailman. Since mailman has its own archives, it seems logical to use them now and get rid of the maintenance of crystal. As mailman is rather widespread, probably a number of users are used to its interface.
(and it breaks a lot of links).
Indeed, that's a problem, but perhaps we can solve it with redirects.
From the old crystal database, we can extract a mapping (fields "id"
and "msgid" in the "mail" table) between the numbers that appear in the links and Message-IDs (which should be unique). Hopefully, something similar can be done on the mailman side (I don't know its internals, but I suppose it can be found out).
So perhaps with a little scripting it should be possible to provide redirects from the old links to the corresponding mails in the mailman archive. If you, or someone else, would like to try this, please contact Peter (peter@gerwinski.de) first to check the details.
Regards, Frank
frank@fjf.gnu.de wrote:
Adriaan van Os wrote:
Well, thanks. It's always nice to hear so -- especially after it was decomissioned. ;-) While it was active, I rarely got positive feedback, only sometimes complaints. (BTW, I think it was you who complained that the old one displayed email addresses in clear -- the new one mangles them a bit at least.)
Did I ? I can't imagine I "complained" about that, as I have my email address unmangled at my own website. It may have been a general observation or a suggestion.
Regards,
Adriaan van Os
Waldek Hebisch wrote:
I did some work on updating gpc to newer gcc versions. You can find it at GitHub:
1. It looks like the snapshot is incompatible with bison-2.5
In file included from parse.c:70: ../../gcc-4.3.5/gcc/p/parse.h:163: error: redefinition of 'union YYSTYPE' parse.h:176: error: conflicting types for 'YYSTYPE' parse.h:176: error: previous declaration of 'YYSTYPE' was here parse.h:196: error: conflicting types for 'yylval' parse.h:196: error: previous declaration of 'yylval' was here parse.c:4399: error: conflicting types for 'yylval' parse.h:196: error: previous declaration of 'yylval' was here parse.y: In function 'locations': parse.y:2439: warning: assignment discards qualifiers from pointer target type parse.y:2448: warning: assignment discards qualifiers from pointer target type
2. A few compiler switches cause ICE's
[P18:~/gpc/testgpc/adriaan] adriaan% gpc --mudflap hello.pas hello.pas: In main program: hello.pas:7: internal compiler error: mudflap: this language is not supported Please submit a full bug report, with preprocessed source if appropriate. See unsupported for instructions.
[P18:~/gpc/testgpc/adriaan] adriaan% gpc --rtl-abstract-sequences hello.pas hello.pas: In main program: hello.pas:9: error: unrecognizable insn: (insn 58 0 0 (set (reg:SI 0 ax) (symbol_ref:SI ("*L4") [flags 0x2])) -1 (nil)) hello.pas:9: internal compiler error: in insn_default_length, at insn-attrtab.c:1374 Please submit a full bug report, with preprocessed source if appropriate. See unsupported for instructions.
[P18:~/gpc/testgpc/adriaan] adriaan% gpc -imultilib hello.pas gpc1: warning: command line option "-imultilib" is valid for C/C++/ObjC/ObjC++ but not for Pascal <built-in>:0: internal compiler error: in init_gpc_lex, at p/gpc-lex.c:245 Please submit a full bug report, with preprocessed source if appropriate. See unsupported for instructions.
Regards,
Adriaan van Os
Waldek Hebisch wrote:
Known problems:
- with gcc-4.y.z testsuite will fail if run immediately after build.
Either install before running testsuite or copy 'libgpc.a' from libgpc build directory to gcc subdirectory and copy rts-confing.inc from libgpc build directory to gcc/p/rts subdirectory (you need to create rts subdirectiry) 2) I did not try to build shared libgpc -- it is probably broken. You would need to fix Makefiles to build it. 3) -Wparenthesis does not work with gcc-4.3.z 4) Utilities (binobj and gpidump) are not build with gcc-4.y.z
I think another problems is that no files get installed into the doc folder.
Regards,
Adriaan van Os
Le 26/06/2011 22:50, Adriaan van Os a écrit :
Waldek Hebisch wrote:
Known problems:
I think another problems is that no files get installed into the doc folder.
same with djgpp
- It looks like the snapshot is incompatible with bison-2.5
d° with djgpp bison 2.4.1. I reverted to bison 2.3
In addition the file gpc-in-c.h is not installed into the directory C:\DJGPP\lib\gcc\djgpp\x.xx\include\ In fact looking to the logs, it is installed, but deleted afterwards during the installation of gcc, which deletes the whole "include" directory before installing it. I correct manually, but I do not know how to revert the order of installations of gcc and gpc.
Maurice
Waldek Hebisch wrote:
I did some work on updating gpc to newer gcc versions. You can find it at GitHub:
Building a native powerpc-apple-darwin8 or powerpc-apple-darwin9 compiler with the snapshot and gcc-4.3.6 results in an ICE at p/module.c:2395. This is (for me) line
2394: #ifdef GCC_4_0 2395: gcc_assert (class_done); 2396: #else 2397: gcc_assert (class_done && code != RTL_EXPR); 2398: #endif
/adriaan/build/./gcc/xgcc -B/adriaan/build/./gcc/ -B/Developer/Pascal/gpc436u1/powerpc-apple-darwin9/bin/ -B/Developer/Pascal/gpc436u1/powerpc-apple-darwin9/lib/ -isystem /Developer/Pascal/gpc436u1/powerpc-apple-darwin9/include -isystem /Developer/Pascal/gpc436u1/powerpc-apple-darwin9/sys-include -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -O2 -g -g -O2 -Wpointer-arith -Wwrite-strings "/adriaan/gcc-4.3.6/gcc/p/rts/rts.c" `echo /adriaan/build/./gcc/xgcc -B/adriaan/build/./gcc/ -B/Developer/Pascal/gpc436u1/powerpc-apple-darwin9/bin/ -B/Developer/Pascal/gpc436u1/powerpc-apple-darwin9/lib/ -isystem /Developer/Pascal/gpc436u1/powerpc-apple-darwin9/include -isystem /Developer/Pascal/gpc436u1/powerpc-apple-darwin9/sys-include | sed 's,^([^ ]*[/][^/]*)gcc,\1gpc,;s/^gcc$/gpc/' ` -c -g -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -O2 -g -g -O2 --unit-path=/adriaan/gcc-4.3.6/gcc/p/rts --automake -DRTS_RELEASE_STRING="'`cat /adriaan/gcc-4.3.6/gcc/p/rts/rts-version`'" -DGCC_VERSION="'unknown'" "/adriaan/gcc-4.3.6/gcc/p/rts/rtsc.pas" /adriaan/gcc-4.3.6/gcc/p/rts/rtsc.pas:0: internal compiler error: in store_node_fields, at p/module.c:2395 Please submit a full bug report, with preprocessed source if appropriate. See unsupported for instructions. make[4]: *** [rtsc.o] Error 1 make[3]: *** [pascal.rts] Error 2
and 64-bit
/adriaan/build/./gcc/xgcc -B/adriaan/build/./gcc/ -B/Developer/Pascal/gpc436u1/powerpc-apple-darwin9/bin/ -B/Developer/Pascal/gpc436u1/powerpc-apple-darwin9/lib/ -isystem /Developer/Pascal/gpc436u1/powerpc-apple-darwin9/include -isystem /Developer/Pascal/gpc436u1/powerpc-apple-darwin9/sys-include -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -O2 -g -g -O2 -m64 -Wpointer-arith -Wwrite-strings "/adriaan/gcc-4.3.6/gcc/p/rts/rts.c" `echo /adriaan/build/./gcc/xgcc -B/adriaan/build/./gcc/ -B/Developer/Pascal/gpc436u1/powerpc-apple-darwin9/bin/ -B/Developer/Pascal/gpc436u1/powerpc-apple-darwin9/lib/ -isystem /Developer/Pascal/gpc436u1/powerpc-apple-darwin9/include -isystem /Developer/Pascal/gpc436u1/powerpc-apple-darwin9/sys-include | sed 's,^([^ ]*[/][^/]*)gcc,\1gpc,;s/^gcc$/gpc/' ` -c -g -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -O2 -g -g -O2 -m64 --unit-path=/adriaan/gcc-4.3.6/gcc/p/rts --automake -DRTS_RELEASE_STRING="'`cat /adriaan/gcc-4.3.6/gcc/p/rts/rts-version`'" -DGCC_VERSION="'unknown'" "/adriaan/gcc-4.3.6/gcc/p/rts/rtsc.pas" /adriaan/gcc-4.3.6/gcc/p/rts/rtsc.pas:0: internal compiler error: in store_node_fields, at p/module.c:2395 Please submit a full bug report, with preprocessed source if appropriate. See unsupported for instructions. make[4]: *** [rtsc.o] Error 1 make[3]: *** [ppc64/pascal.rts] Error 2 make[2]: *** [do_multidirs] Error 2 make[1]: *** [all-target-libgpc] Error 2 make: *** [all] Error 2 logout
The i386-apple-darwin[9-10] to powerpc-apple-darwin[9-10] cross compiler does build, but packed arrays of booleans cause ICEÂ’s in the testsuite:
FAIL: az20.pas ./az20.pas: In main program: ./az20.pas:0: internal compiler error: in count_bits, at p/types.c:1598 Please submit a full bug report, with preprocessed source if appropriate. See unsupported for instructions. failed
The same problem occurs with
FAIL: confarr5.pas FAIL: fjf746.pas FAIL: fjf980b.pas FAIL: martin3.pas FAIL: pack10.pas FAIL: pack11.pas FAIL: pack2.pas FAIL: pack4.pas FAIL: pack5.pas
I think this needs to be fixed. Other testsuite failures look less serious.
Regards,
Adriaan van Os
Le 13/06/2011 20:48, Waldek Hebisch a écrit :
I did some work on updating gpc to newer gcc versions. You can find it at GitHub:
https://github.com/hebisch/gpc
This is experimental work. 4.2 and 4.3 ports (on "master" Git branch)
Native building of the gpc compiler with 4.23 backend for DJGPP 2.04 / winXP works well, when following recommendations of Andris Pavenis (recompiling stubify for 1024k default stack size, and 32k transfer buffer for sh and make) and those of Waldek for gpc 4.x.x. (plus a djgpp-only patch for libgpc mirrored from the equivalent in libobjc) Running the tests gives)
---------------------------------------------------- Test Run By maurice on 2011-06-28 12:12:42 Native configuration is djgpp (BOUVARDIE)
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas FAIL: fjf1042b.pas FAIL: fjf1042c.pas FAIL: fjf1102.pas UNSUPPORTED: fjf165a.pas FAIL: fjf403b.pas FAIL: fjf563e.pas UNSUPPORTED: longr2.pas FAIL: pcerroro.pas FAIL: reset.pas FAIL: y2k.pas
=== gpc Summary ===
# of tests 5111 # of expected passes 5100 # of unexpected failures 8 # of unsupported tests 3
c:/DJGPP/gnu/build.gcc/gcc/xgpc version 20070904, based on gcc-4.2.3 ---------------------------------------------------------------------
i.e. two failures _less_ than with the previous 20070904 with 4.1.2 backend.
When trying with gcc 4.3.2 it seems that we already stumble into the problems of djgpp limitations described recently by Andris
http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2011/0...
Native building of C and C++ compilers with gcc432s2 and FSF sources work as expected. But when trying to compile gpc, even starting whith the precompiled sources gcc432s, depending on the settings of transfer buffer compiling the gpc rts (string1.pas) fails with either ----------------------------------------------------------- `echo /dev/c/djgpp/gnu/build.gcc/./gcc/xgcc -B/dev/c/djgpp/gnu/build.gcc/./gcc/ -B/dev/env/DJDIR/djgpp/bin/ -B/dev/env/DJDIR/djgpp/lib/ -isystem /dev/env/DJDIR/djgpp/include -isystem /dev/env/DJDIR/djgpp/sys-include | sed 's,^([^ ]*[/][^/]*)gcc,\1gpc,;s/^gcc$/gpc/' ` -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -O2 -g -g -O2 --unit-path=/dev/c/djgpp/gnu/gcc-4.32/gcc/p/rts --automake -DRTS_RELEASE_STRING="'`cat /dev/c/djgpp/gnu/gcc-4.32/gcc/p/rts/rts-version`'" -DGCC_VERSION="'unknown'" "/dev/c/djgpp/gnu/gcc-4.32/gcc/p/rts/string1.pas" Load error: no DOS memory gpc1.exe: c:/djgpp/gnu/build.gcc/gcc/xgpc.exe exited with status 105 make.exe[4]: *** [string1.o] Error 1 make.exe[4]: Leaving directory `c:/djgpp/gnu/build.gcc/djgpp/libgpc/p/rts' make.exe[3]: *** [pascal.rts] Error 2 make.exe[3]: Leaving directory `c:/djgpp/gnu/build.gcc/djgpp/libgpc' make.exe[2]: *** [do_multidirs] Error 2 make.exe[2]: Leaving directory `c:/djgpp/gnu/build.gcc/djgpp/libgpc' make.exe[1]: *** [all-target-libgpc] Error 2 make.exe[1]: Leaving directory `c:/djgpp/gnu/build.gcc' make.exe: *** [all] Error 2 ------------------------------------------------------------------ or ------------------------------------------------------------ `echo /dev/c/djgpp/gnu/build.gcc/./gcc/xgcc -B/dev/c/djgpp/gnu/build.gcc/./gcc/ -B/dev/env/DJDIR/djgpp/bin/ -B/dev/env/DJDIR/djgpp/lib/ -isystem /dev/env/DJDIR/djgpp/include -isystem /dev/env/DJDIR/djgpp/sys-include | sed 's,^([^ ]*[/][^/]*)gcc,\1gpc,;s/^gcc$/gpc/' ` -c -I. -W -Wall -Wmissing-prototypes -Wmissing-declarations -O2 -g -g -O2 --unit-path=/dev/c/djgpp/gnu/gcc-4.32/gcc/p/rts --automake -DRTS_RELEASE_STRING="'`cat /dev/c/djgpp/gnu/gcc-4.32/gcc/p/rts/rts-version`'" -DGCC_VERSION="'unknown'" "/dev/c/djgpp/gnu/gcc-4.32/gcc/p/rts/string1.pas" <snip> /dev/c/djgpp/gnu/gcc-4.32/gcc/p/rts/string1.pas: In function `CStringLastPos': /dev/c/djgpp/gnu/gcc-4.32/gcc/p/rts/string1.pas:604: internal compiler error: in ggc_set_mark, at ggc-page.c:1285 Please submit a full bug report, with preprocessed source if appropriate. See unsupported for instructions. make.exe[4]: *** [string1.o] Error 1 make.exe[4]: Leaving directory `c:/djgpp/gnu/build.gcc/djgpp/libgpc/p/rts' make.exe[3]: *** [pascal.rts] Error 2 make.exe[3]: Leaving directory `c:/djgpp/gnu/build.gcc/djgpp/libgpc' make.exe[2]: *** [do_multidirs] Error 2 make.exe[2]: Leaving directory `c:/djgpp/gnu/build.gcc/djgpp/libgpc' make.exe[1]: *** [all-target-libgpc] Error 2 make.exe[1]: Leaving directory `c:/djgpp/gnu/build.gcc' make.exe: *** [all] Error 2 --------------------------------------------------------------------- I doubt the last message (a failed assertion) be really significant since compiler works with gcc423 Unless somebody have an idea, the only way out seems to follow the Andris route, i.e. cross compiling gpc. But I have no experience on that, so that it will take some time.
Maurice
Le 01/07/2011 14:17, Maurice Lombardi a écrit :
Le 13/06/2011 20:48, Waldek Hebisch a écrit :
I did some work on updating gpc to newer gcc versions. You can find it at GitHub:
https://github.com/hebisch/gpc
This is experimental work. 4.2 and 4.3 ports (on "master" Git branch)
Native building of the gpc compiler with 4.23 backend for DJGPP 2.04 / winXP works well,
Similarly native building with the "current" DJGPP 2.03r2 on a Win98 machine works even better with the following results for the 5000+ test suite ---------------------------------------------------------------------- Test Run By dosuser on 2011-07-18 23:08:25 Native configuration is djgpp (KNAUTIE)
=== gpc tests ===
Running target any Running testsuite ...
FAIL: fjf1102.pas UNSUPPORTED: fjf165a.pas FAIL: fjf403b.pas FAIL: fjf563e.pas UNSUPPORTED: longr2.pas FAIL: y2k.pas
=== gpc Summary ===
# of tests 5111 # of expected passes 5105 # of unexpected failures 4 # of unsupported tests 2
c:/djgpp/gnu/build.gcc/gcc/xgpc version 20070904, based on gcc-4.2.3 --------------------------------------------------------------------
I had to tweak two things to succeed:
- install old gcc 2.95.3 compiler to recompile stubify.exe with 1024k default stack size, as recommended by Andris.
- the latest bash bsh204br3 had a bug (not present in older bsh204b): it failed to delete temporary files in the TMPDIR directory with an EACCES error message, when bash uses a pipe | (which is used silently many times during a make). The compilation continued nevertheless, but it made the very long bootstrapped compilation of gpc to fail before the end. When running bash under gdb 7.2, I found that bash used bison.simple, which is no more present in modern bison (I had bison 2.3 installed when recompiling bsh204sr3 with debug information conserved), probably somewhat emulated now. Installing the old bison 1.28 which had a genuine bison.simple, I recompiled bsh204br3 from sources and the bug disappeared, enabling seamless compilation of gpc. May be others have not noticed that because they use more modern OSes than Win98. In that case it would be better to upload to djgpp a modified bsh204br3
Maurice
I found a new (small) bug in gpc compiled with gcc-4.3.5 backend following instructions of Waldek on github. hopefully it could be simply solved by who writed it
First compilation of GPC without problems on an old fedora 6 system to which I have full access and practice (same bug occurs on a recent cluster front end, but this needed more twiddlings to install it, which are irrelevant here)
$ gpc-4.3.5 -v Using built-in specs. Configured with: ../gcc-4.3.5/configure --prefix=/usr/local --program-suffix=-4.3.5 --disable-shared --enable-threads=posix --disable-nls --without-included-gettext --with-system-zlib --enable-__cxa_atexit --enable-languages=c,pascal --enable-multilib --disable-mapped-location --enable-bootstrap Thread model: posix gpc version 20070904, based on gcc-4.3.5
with only 23 "unexpected failures" for the 64 bits checks 17 32
the bug is displayed by the following minimal program
program test3;
const c = 9; n = 32- c mod 2;
begin if n = 31 then writeln('OK') else writeln('failed'); end.
$ gpc-4.3.5 test3.pas -o test3 test3.pas:0: error: constant has non-constant value
(no error or course with various older gcc-3.4.x based compilers)
The problem is not with the mod operator itself (it occurs at many places in the test suite). The bug disappear by putting c mod 2 between parentheses. For that reason, and because Waldek said on github
3) -Wparenthesis does not work with gcc-4.3.z
I tried $ gpc-4.3.5 test3.pas -o test3 -Wparentheses gpc1: warning: command line option "-Wparentheses" is valid for C/C++/ObjC/ObjC++ but not for Pascal test3.pas:0: error: constant has non-constant value
??? (My goal was to see on more complex programs if one can gain performances on the cluster with more recent gcc)
Maurice
-
Adriaan van Os -
frank＠fjf.gnu.de -
Maurice Lombardi -
Waldek Hebisch