Waldek Hebisch wrote:
The port should build without problems. There are extra test failures (compared to 3.4.6):
asmtest.pas, fjf395[ab].pas -- test programs expect to much
fjf1102.pas -- unimplemented feature (but works with older older backends)
fjf403b.pas, fjf779[abefg].pas, nicola4c.pas -- port does not detect error/unused variables
fjf395[ab].pas -- wrong tests
fjf322.pas, fjf587b.pas -- spurious warnings
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas UNSUPPORTED: fjf165a.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf998r.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: longr2.pas FAIL: nicola4c.pas FAIL: prep2p.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 5070 # of expected passes 5048 # of unexpected failures 15 # of unsupported tests 7
gpc version 20060325, based on gcc-4.1.0
Miraculously, fjf1062[a-c].pas no longer fail, although the C testprogram still does (http://gnu-pascal.de/crystal/gpc/en/mail13495.html).
The failure of fjf563e.pas is new. It doesn't fail at -O0. Various outputs are:
[g5:gcc/p/test] adriaan% gpc fjf563e.pas -O3 fjf563e.pas:7: warning: constructing limited integer set `0 .. 255'; fjf563e.pas:7: warning: use `--setlimit=NUMBER' to change the size limit at compile time. [g5:gcc/p/test] adriaan% gpc fjf563e.pas -O0 fjf563e.pas:7: warning: constructing limited integer set `0 .. 255'; fjf563e.pas:7: warning: use `--setlimit=NUMBER' to change the size limit at compile time. <tree_list 0x42471860 purpose <integer_cst 0x42471880 type <integer_type 0x4241f460 Integer> constant invariant tree_5 10000> value <integer_cst 0x424718a0 type <integer_type 0x4241f460 Integer> constant invariant tree_5 20000>> fjf563e.pas:7: error: invalid initializer for set <tree_list 0x42471860 purpose <integer_cst 0x42471880 type <integer_type 0x4241f460 Integer> constant invariant tree_5 10000> value <integer_cst 0x424718a0 type <integer_type 0x4241f460 Integer> constant invariant tree_5 20000>> fjf563e.pas:7: error: invalid initializer for set <tree_list 0x42471860 purpose <integer_cst 0x42471880 type <integer_type 0x4241f460 Integer> constant invariant tree_5 10000> value <integer_cst 0x424718a0 type <integer_type 0x4241f460 Integer> constant invariant tree_5 20000>> fjf563e.pas:7: error: invalid initializer for set [g5:gcc/p/test] adriaan% gpc fjf563e.pas -O1 fjf563e.pas:7: warning: constructing limited integer set `0 .. 255'; fjf563e.pas:7: warning: use `--setlimit=NUMBER' to change the size limit at compile time.
Ah, I think this was because of the temporary patch to locate the invalid initializer set problem !
All in all, experimental gcc-4.1 support looks quite good.
Regards,
Adriaan van Os
Adriaan van Os wrote:
UNSUPPORTED: agettext2test.pas UNSUPPORTED: agettexttest.pas UNSUPPORTED: aregextest.pas UNSUPPORTED: asmtest.pas UNSUPPORTED: fjf165a.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: fjf998r.pas UNSUPPORTED: gmptest.pas UNSUPPORTED: longr2.pas FAIL: nicola4c.pas FAIL: prep2p.pas FAIL: systemtest.pas
=== gpc Summary ===
# of tests 5070 # of expected passes 5048 # of unexpected failures 15 # of unsupported tests 7
gpc version 20060325, based on gcc-4.1.0
Miraculously, fjf1062[a-c].pas no longer fail, although the C testprogram still does (http://gnu-pascal.de/crystal/gpc/en/mail13495.html).
No miracles, the problematic code in fjf1062[a-c].pas was useless (just pure bloat), so now gpc does not generate it. The backend problem is still present, but ATM I do not know if it is possible to triger it from Pascal.
The failure of fjf563e.pas is new. It doesn't fail at -O0. Various outputs are:
This failure is expected. The test contains wrong initializer. ATM we do final check of initializer during code genration. With any optimizaton 4.x backend is smart enough to notice that the wrong declaration is useless, and gives us no chance to emit error message.