In message 19990512012516.B1546@esmeralda.gerwinski.de Peter Gerwinski writes:
The problem is at compile-time, attached is a small module which exhibits this behaviour. My system is Red Hat Linux release 5.2 (Apollo) running kernel 2.0.36 on an i586. I've built gcc-2.8.1 and gpc 19990118.
gpc -v gives the following output
Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/specs gpc version 19990118, based on gcc-2.8.1
Thanks for the detailed information. :-)
Below is a version of your test program that is ready for our test suite.
To work around the bug, you can drop the first `protected'.
I now have a significantly bigger module (which also imports from several other modules) which is exhibiting the same behaviour "prior parameter's size depends on `foo'" where `foo' is a protected string parameter in the function/procedure declaration.
In this case if I drop all the `protected' in the procedure/function declarations in the interface, I get "gpc: Internal compiler error: program gpc1 got fatal signal 6".
Any suggestions about more general work-arounds for this problem with string parameters in extended Pascal modules?
Converting the extended Pascal module to a unit seems to be a work-around, but having to do that is going to make this migration much more difficult than staying with the extended Pascal modules that the system currently uses.
David James wrote:
I now have a significantly bigger module (which also imports from several other modules) which is exhibiting the same behaviour "prior parameter's size depends on `foo'" where `foo' is a protected string parameter in the function/procedure declaration.
In this case if I drop all the `protected' in the procedure/function declarations in the interface, I get "gpc: Internal compiler error: program gpc1 got fatal signal 6".
Any suggestions about more general work-arounds for this problem with string parameters in extended Pascal modules?
I am currently experiencing the same in a big project and working on just this problem.
Converting the extended Pascal module to a unit seems to be a work-around, but having to do that is going to make this migration much more difficult than staying with the extended Pascal modules that the system currently uses.
Since my project uses units I am not at all sure that the conversion would really be a workaround.
Good luck, and watch out for the next snapshot,
Peter
Hello again,
I just wrote:
Any suggestions about more general work-arounds for this problem with string parameters in extended Pascal modules?
I am currently experiencing the same in a big project and working on just this problem.
I have found a workaround that works for me: Instead of undiscriminated string parameters use parameters of a fixed maximum capacity.
Anyway I hope to find and fix the real problem soon.
Peter