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.