Here are test results of gpc-20041218 with gcc-3.3.5 for DJGPP (I used recent CVS version DJGPP v2.04)
gpc 20041218, based on gcc-3.3.5, flags: -g -O3 -W -Wall -Wno-unused GPC-TEST-BEGIN ========================== TEST aregextest.pas: SKIPPED: librx not installed TEST fjf165a.pas: SKIPPED: German locale not installed TEST longr2.pas: SKIPPED: no LongReal math routines available TEST reset.pas: failed TEST y2k.pas: failed 2005 2005
========================== GPC-TEST-END
Additionally I had to patch test_run to avoid DJGPP port of bash crashing (both bash-2.0.4 from v2gnu and bash-2.0.5b):
--- test_run~1 2005-02-17 22:54:30.000000000 +0000 +++ test_run 2005-02-17 20:12:44.000000000 +0000 @@ -296,7 +296,8 @@ echo "failed" fi fi - return 0 # IRIX's shell wants this, otherwise it aborts after a failed command!? +true +# return 0 # IRIX's shell wants this, otherwise it aborts after a failed command!? }
n=0
It is perhaps a due to some problem with DJGPP port of bash.
Andris
Andris Pavenis wrote:
Here are test results of gpc-20041218 with gcc-3.3.5 for DJGPP (I used recent CVS version DJGPP v2.04)
gpc 20041218, based on gcc-3.3.5, flags: -g -O3 -W -Wall -Wno-unused GPC-TEST-BEGIN ========================== TEST aregextest.pas: SKIPPED: librx not installed TEST fjf165a.pas: SKIPPED: German locale not installed TEST longr2.pas: SKIPPED: no LongReal math routines available TEST reset.pas: failed TEST y2k.pas: failed 2005 2005
========================== GPC-TEST-END
reset.pas is a bit questionable (no idea what it was meant to test actually, seems to be quite old). I'm changing the test program.
Additionally I had to patch test_run to avoid DJGPP port of bash crashing (both bash-2.0.4 from v2gnu and bash-2.0.5b):
--- test_run~1 2005-02-17 22:54:30.000000000 +0000 +++ test_run 2005-02-17 20:12:44.000000000 +0000 @@ -296,7 +296,8 @@ echo "failed" fi fi
- return 0 # IRIX's shell wants this, otherwise it aborts after a failed command!?
+true +# return 0 # IRIX's shell wants this, otherwise it aborts after a failed command!? }
n=0
It is perhaps a due to some problem with DJGPP port of bash.
I hope this will work on IRIX as well. I'll find out when I test there next time. Otherwise I'll undo the change, and the DJGPP bash bug need to be fixed (well, it should be fixed anyway, of course, if it's really such a bug).
Frank
On Saturday 19 February 2005 16:00, Frank Heckenbach wrote:
Andris Pavenis wrote:
Here are test results of gpc-20041218 with gcc-3.3.5 for DJGPP (I used recent CVS version DJGPP v2.04)
gpc 20041218, based on gcc-3.3.5, flags: -g -O3 -W -Wall -Wno-unused GPC-TEST-BEGIN ========================== TEST aregextest.pas: SKIPPED: librx not installed TEST fjf165a.pas: SKIPPED: German locale not installed TEST longr2.pas: SKIPPED: no LongReal math routines available TEST reset.pas: failed TEST y2k.pas: failed 2005 2005
========================== GPC-TEST-END
reset.pas is a bit questionable (no idea what it was meant to test actually, seems to be quite old). I'm changing the test program.
It passed on other build, where I used DJGPP v2.03 patchlevel 2. y2k.pas failure still remained but no more appeared.
At this time DJGPP distribution has bad gcc-3.3.5 binaries (C++ broken, what I unfortunatelly didn't notice before uploading). So I'll going to reupload updated archives. Is it reasonable to put also GPC-20041218 in, when I upload archives for DJGPP distribution?
Andris
Andris Pavenis a écrit:
On Saturday 19 February 2005 16:00, Frank Heckenbach wrote:
Andris Pavenis wrote:
Here are test results of gpc-20041218 with gcc-3.3.5 for DJGPP (I used recent CVS version DJGPP v2.04)
gpc 20041218, based on gcc-3.3.5, flags: -g -O3 -W -Wall -Wno-unused GPC-TEST-BEGIN ========================== TEST aregextest.pas: SKIPPED: librx not installed TEST fjf165a.pas: SKIPPED: German locale not installed TEST longr2.pas: SKIPPED: no LongReal math routines available TEST reset.pas: failed TEST y2k.pas: failed 2005 2005
========================== GPC-TEST-END
reset.pas is a bit questionable (no idea what it was meant to test actually, seems to be quite old). I'm changing the test program.
It passed on other build, where I used DJGPP v2.03 patchlevel 2. y2k.pas failure still remained but no more appeared.
I had the same results with v2.03p2 (never tried v2.04) y2k.pas has random failures since long time, apparently due to trigger of a Window function to change between summer/winter time when the program changes date to some seconds before y2k to make the test: it appears more clearly, but still randomly, by increasing the time delay included in the test. I simply ignore it.
At this time DJGPP distribution has bad gcc-3.3.5 binaries (C++ broken, what I unfortunatelly didn't notice before uploading). So I'll going to reupload updated archives. Is it reasonable to put also GPC-20041218 in, when I upload archives for DJGPP distribution?
There is still the problem of CPP_PREDEFINES which are broken in gpc for gcc > 3.2.3. This is an anoyance for all DOS / windows backends which use them heavily, e.g. in crt, graph units. This is not seen in the test suite because a work around is used in it, but it appears in ordinary programs. I have not uploaded 3.3.x binaries in the gpc site for that reason. Apparently none of the user is able to contribute a solution, and main gpc maintainers (Franck and Walter) are too busy with important improvements of gpc (range checking and qualified imports are very important improvements for all of us). Do you think you can contribute to it ? You seem to have much more compiler experience than many of us.
Maurice
On Monday 21 February 2005 13:15, Maurice Lombardi wrote:
There is still the problem of CPP_PREDEFINES which are broken in gpc for gcc > 3.2.3. This is an anoyance for all DOS / windows backends which use them heavily, e.g. in crt, graph units. This is not seen in the test suite because a work around is used in it, but it appears in ordinary programs. I have not uploaded 3.3.x binaries in the gpc site for that reason. Apparently none of the user is able to contribute a solution, and main gpc maintainers (Franck and Walter) are too busy with important improvements of gpc (range checking and qualified imports are very important improvements for all of us). Do you think you can contribute to it ?
Unlikely.
You seem to have much more compiler experience than many of us.
Andris
Maurice Lombardi wrote:
I had the same results with v2.03p2 (never tried v2.04) y2k.pas has random failures since long time, apparently due to trigger of a Window function to change between summer/winter time when the program changes date to some seconds before y2k to make the test: it appears more clearly, but still randomly, by increasing the time delay included in the test. I simply ignore it.
Well, the test was written to test some "__BP_UNPORTABLE_ROUTINES__" as it clearly indicates. As far as I'm concerned, I don't have to keep this test if it now doesn't even work (reliably) on its "native" platform.
Alternatively, we could activate the work-around (simulate a changed time for the running program and leaving the system time alone) for DJGPP as well. If you prefer this, it's the conditional in dos.pas:741 (`{$ifdef __GO32__}'). Let me know if I should change it permanently.
At this time DJGPP distribution has bad gcc-3.3.5 binaries (C++ broken, what I unfortunatelly didn't notice before uploading). So I'll going to reupload updated archives. Is it reasonable to put also GPC-20041218 in, when I upload archives for DJGPP distribution?
There is still the problem of CPP_PREDEFINES which are broken in gpc for gcc > 3.2.3. This is an anoyance for all DOS / windows backends which use them heavily, e.g. in crt, graph units. This is not seen in the test suite because a work around is used in it, but it appears in ordinary programs. I have not uploaded 3.3.x binaries in the gpc site for that reason. Apparently none of the user is able to contribute a solution, and main gpc maintainers (Franck and Walter) are too busy with important improvements of gpc (range checking and qualified imports are very important improvements for all of us).
Yes, I was busy with them. But integrating the preprocessor (which will fix those issues) is still high on my list, I didn't forget about it.
Frank
Frank Heckenbach a écrit:
Maurice Lombardi wrote:
I had the same results with v2.03p2 (never tried v2.04) y2k.pas has random failures since long time, apparently due to trigger of a Window function to change between summer/winter time when the program changes date to some seconds before y2k to make the test: it appears more clearly, but still randomly, by increasing the time delay included in the test. I simply ignore it.
Well, the test was written to test some "__BP_UNPORTABLE_ROUTINES__" as it clearly indicates. As far as I'm concerned, I don't have to keep this test if it now doesn't even work (reliably) on its "native" platform.
Alternatively, we could activate the work-around (simulate a changed time for the running program and leaving the system time alone) for DJGPP as well. If you prefer this, it's the conditional in dos.pas:741 (`{$ifdef __GO32__}'). Let me know if I should change it permanently.
I had an other look to this bug. It is due to a strange bug when running the test in a W98se DOS window. When running it in bare DOS no error. When making your suggested replacement, no error. The problem is that the delay of 2 seconds which should be produced by sleep(2) is not realized (at the present time ...) when running this test in this DOS window: 2 seconds are felt by bare eye. I can produce it when running under debugger (with rhide), and then the result is correct. I will make some more investigations on sleep in a bare C program, but otherwise you can change the test freely.
Maurice
I wrote:
Andris Pavenis wrote:
Additionally I had to patch test_run to avoid DJGPP port of bash crashing (both bash-2.0.4 from v2gnu and bash-2.0.5b):
--- test_run~1 2005-02-17 22:54:30.000000000 +0000 +++ test_run 2005-02-17 20:12:44.000000000 +0000 @@ -296,7 +296,8 @@ echo "failed" fi fi
- return 0 # IRIX's shell wants this, otherwise it aborts after a failed command!?
+true +# return 0 # IRIX's shell wants this, otherwise it aborts after a failed command!? }
n=0
It is perhaps a due to some problem with DJGPP port of bash.
I hope this will work on IRIX as well. I'll find out when I test there next time. Otherwise I'll undo the change, and the DJGPP bash bug need to be fixed (well, it should be fixed anyway, of course, if it's really such a bug).
I tried it and it also works on IRIX (problem was with fjf967*.pas).
Frank
-
Andris Pavenis -
Frank Heckenbach -
Maurice Lombardi