gpc-20030323 testsuite

Adriaan van Os gpc at microbizz.nl
Sat Mar 29 01:42:17 CET 2003


Frank Heckenbach wrote:

> I see, a single array is too big already. Well, perhaps we should
> just declare types instead of variables, to leave the stack alone.
> It's a rather silly issue, anyway.
>
> --- p/test/fjf582.pas.orig	Thu Mar 27 18:35:06 2003
> +++ p/test/fjf582.pas	Thu Mar 27 18:35:32 2003
> @@ -16,11 +16,11 @@
>    can't make it a `for' loop counter or so. So we use a macro here. }
>  {$define PREPARETEST(n)
>  procedure TestProc##n;
> +type i = packed array [1 .. $8000] of Integer (n);
> +type c = packed array [1 .. $8000] of Cardinal (n);
> +type w = packed array [1 .. $8000] of Word (n);
> +type b = packed array [1 .. $8000] of Boolean (n);
>  begin
> -  var i: packed array [1 .. $8000] of Integer (n);
> -  var c: packed array [1 .. $8000] of Cardinal (n);
> -  var w: packed array [1 .. $8000] of Word (n);
> -  var b: packed array [1 .. $8000] of Boolean (n);
>    Check (SizeOf (i), $1000 * n, 'i', n);
>    Check (SizeOf (c), $1000 * n, 'c', n);
>    Check (SizeOf (w), $1000 * n, 'w', n);

OK, the fjf582.pas test is passed now (with the standard Mac OS X 
stacksize limit of 512 K).

>>>> fjf664.pas		Segmentation fault		stack overflow (solved with "limit
>>>> stacksize 2048")
>>>
>>> Try this one.
>>
>> TEST    fjf664.pas:     gpc: Internal error: Illegal instruction
>> (program gpc1)
>> TEST    fjf664.orig.pas:        gpc: Internal error: Illegal
>> instruction (program gpc1)
>>
>> Both produce a gpc internal error (not a Segmentation fault as I
>> reported earlier, I apologize).
>
> Just to be sure, this is also fixed with a bigger stack size? So
> it's the compiler's stack that overruns this time (in contrast to
> fjf582 where it was the compiled program's stack).

Yes, limit stacksize 2048 fixes it for the original fjf664.pas, limit 
stacksize 1024 for the later fjf664.pas.

> In this case, the test may just be too big (for the default stack
> size), and all I could do is to split it up.
>
> Does it make any difference if you remove some of the procedures t1,
> t2, t3, t4

No, each of t1, t2, t3, t4 alone crashes the compiler.

> or some of the lines in the CN macro?

With only these two lines left in the CN macro, the crash has gone, e.g.

{$define CN(NK, MK)
   CM (NK, MK, 1, 1);
   CM (NK, MK, 5, 4)
}

Regards,

Adriaan van Os




More information about the Gpc mailing list