pavenis@lanet.lv wrote:
I did build build of gcc-2.95.3 together with gpc-20010409 (after fixing some small source problems, see gcc2953s2.zip for details) for DJGPP under Linux. Seems that it works Ok.
Output of tests http://www.ltn.lv/~pavenis/make.out
BTW, if you pipe these results through test_sum (which the default make target in test/ as well as dostest.bat should do automatically), you get quite a compact report:
: TEST daj13.pas: d:/Devel/gpc/test/a.out: error when writing to file `daj13.dat' (error #466 at 160f) : TEST fay.pas: e:\tmp\ccdaaaaa: Assembler messages: : e:\tmp\ccdaaaaa:934: Fatal error: C_EFCN symbol out of scope : failed : TEST fjf165a.pas: SKIPPED: only for German locale : TEST formattimetest.pas: failed (1990-3-25 3:3:45): : |Sun|Sunday|Mar|March|25|03|03|084|03|03|45|12|0|12|90|1990|%| : |Sun|Sunday|Mar|March|25|02|02|084|03|03|45|12|0|12|90|1990|%| : TEST gpctest.pas: warning: stange time zone -1193044.50 : 4294960096 : -4294960200 : 943841988 : True : True : 1999 1999 : 11 11 : 29 29 : 1 1 : 2 2 : 21 19 : 32 48 : 0 0 : Error in UnixTimeToTimeStamp: : TEST longr2.pas: SKIPPED: no LongReal math routines available : : # of GPC tests 1302 : # of GPC tests passed 1296 : # of GPC tests skipped 2 : # of GPC tests failed 4
The two skipped tests are expected (since there's no "long double" routines like sqrtl() and no locale support in DJGPP, AFAIK).
The failure in gpctest.pas seems to be a problem in the test program itself. I'll fix it.
The failure in formattimetest.pas is also a bug in the test program -- it generates some random times to check their formatting. Unfortunately, one of the times generated fell in the hour skipped at the beginning of DST. I avoided hour 2 for that reason (that's the hour we skip in MET), but as I see now, you (EET) seem to skip the 3rd hour, and it seems other time zones can skip even other hours. Even though it's only one hour in a year, it seems quite hard to find a general way to avoid it. I'm changing the test program now so it simply allows for one error per year and tries again with another hour in the same day. I hope that's safe ... ;-)
I don't understand the other two errors -- apparently they don't occur with Maurice and others, and I can't reproduce them. If you could do some more debugging, it would be nice ...
In your previous test report (forwarded by Maurice Lombardi), you also had the following errors in dialdef4.pas, fjf421l.pas and fjf421m.pas. I didn't understand them, and they didn't appear to occur now, so I suppose (hope ;-) it was some intermittent problem.
c:\djgpp\tmp\cceaaaaa: In function `pascal_main_program': fjf421m.pas:8: undefined reference to `_p_stdout' fjf421m.pas(.text+0x20): undefined reference to `_p_write' fjf421m.pas(.text+0x29): undefined reference to `_p_inoutres' fjf421m.pas(.text+0x31): undefined reference to `_p_check_inoutres' fjf421m.pas:9: undefined reference to `_p_atexit' fjf421m.pas(.text+0x82): undefined reference to `_p_initialize' fjf421m.pas(.text+0x91): undefined reference to `_p_finalize' collect2: ld returned 1 exit status failed
Frank