In the German list, Roland Goretzki found a GPC bug (roland2). I've made a fix for older GPC versions (such as 20040516 he's using), which is attached.
However, in Waldek's newer GPC versions, the respective code is "#if 0"d, with the comment: "/* save_expr would cause problems */".
Unfortunately this comment is not very informative to me. I've built gpc-20060325 with the code back in ("#if 1") on i586-pc-linux-gnu (Debian 3.1) with gcc-3.4.4, and all tests passed (except roland2, of course). So I suppose the problems only affect gcc-4.x or other platforms, is this right?
Then I've applied my patch and all test passed, including roland2.
Anyway, the point is that in the original code, save_expr is only applied to the string length (which is used twice). However, the whole string expression may contain side-effects (as in roland2.pas), and is accessed for the length (once using save_expr, twice otherwise) and for the chars. So we need to save this. This is what my patch does, removing the (now useless) save_expr for the length.
Waldek's code still saves the length, in different way, so the problem still exists. Perhaps save_expr_string works with gcc-4/other platforms, so we don't need the new code. If not, can you change your code to save the whole string, or change save_expr_string if necessary (as you probably know what you'll have to test then; I don't).
Frank
Frank Heckenbach a écrit:
In the German list, Roland Goretzki found a GPC bug (roland2). I've made a fix for older GPC versions (such as 20040516 he's using), which is attached.
However, in Waldek's newer GPC versions, the respective code is "#if 0"d, with the comment: "/* save_expr would cause problems */".
Unfortunately this comment is not very informative to me. I've built gpc-20060325 with the code back in ("#if 1") on i586-pc-linux-gnu (Debian 3.1) with gcc-3.4.4, and all tests passed (except roland2, of course). So I suppose the problems only affect gcc-4.x or other platforms, is this right?
Then I've applied my patch and all test passed, including roland2.
Anyway, the point is that in the original code, save_expr is only applied to the string length (which is used twice). However, the whole string expression may contain side-effects (as in roland2.pas), and is accessed for the length (once using save_expr, twice otherwise) and for the chars. So we need to save this. This is what my patch does, removing the (now useless) save_expr for the length.
Waldek's code still saves the length, in different way, so the problem still exists. Perhaps save_expr_string works with gcc-4/other platforms, so we don't need the new code. If not, can you change your code to save the whole string, or change save_expr_string if necessary (as you probably know what you'll have to test then; I don't).
Not sure if this was intended for the whole list or for Waldek.
Anyway with my old compilation of gpc-20060325 with gcc-4.1.1 backend under djgpp (the one in the gpc site), Roland2.pas Fails. Recompiling with your patch and #if 1, Roland2 succeeeds and there remain the same errors, namely
-------------------------------old-------------------------------- === gpc tests ===
Running target any Running testsuite ...
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 UNSUPPORTED: longr2.pas FAIL: nicola4c.pas FAIL: y2k.pas
=== gpc Summary ===
# of tests 5070 # of expected passes 5055 # of unexpected failures 13 # of unsupported tests 2 -------------------------------patched--------------------------------- === gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: fjf165a.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf630e.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas UNSUPPORTED: longr2.pas FAIL: nicola4c.pas
=== gpc Summary ===
# of tests 5071 # of expected passes 5056 # of unexpected failures 13 # of unsupported tests 2 -------------------------------------------------------------------- The y2k failing is spurious
Maurice
Maurice Lombardi wrote:
Not sure if this was intended for the whole list or for Waldek.
Mainly for Waldek, but also for the list, so others can test it as well, as you did, thanks.
Frank
On Wed, 7 Mar 2007, Maurice Lombardi wrote:
[..]
Recompiling with your patch and #if 1, Roland2 succeeeds and there remain the same errors, namely
Using gcc-4.1.2, your patch, and #if 1, got like results:
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: aregextest.pas FAIL: fjf322.pas FAIL: fjf395a.pas FAIL: fjf395b.pas FAIL: fjf403b.pas FAIL: fjf563e.pas FAIL: fjf587b.pas FAIL: fjf630e.pas FAIL: fjf779a.pas FAIL: fjf779b.pas FAIL: fjf779e.pas FAIL: fjf779f.pas FAIL: fjf779g.pas FAIL: nicola4c.pas
=== gpc Summary ===
# of tests 5071 # of expected passes 5057 # of unexpected failures 13 # of unsupported tests 1
russ
-
Frank Heckenbach -
Maurice Lombardi -
Russ Whitaker