Adriaan van Os wrote:
Sorry, I am systematically trying out all available compiler options,
I know. ;-)
The --setlimit argument changes the upper limit of the sets ...
Yes, that's what it's supposed to do. (In general, it would be hard to guess if it's more reasonable to change the lower or upper limit, so we always change the upper one.)
However, there seems to be a problem with the implementation ...
[G4:~/gnu/testgpc/adriaan] adriaan% cat setlimit2.pas program setlimit2; type intset = set of integer; bigset = set of 0..100000; const i: intset = [ - 1]; b: bigset = [ 100000]; begin end.
This produces an internal compiler error when used with --setlimit ...
[G4:~/gnu/testgpc/adriaan] adriaan% gpc -o setlimit2 setlimit2.pas --setlimit=1000000000 setlimit2.pas:2: warning: constructing limited integer set `-2147483648 .. -1147483649'; setlimit2.pas:2: warning: use `--setlimit=NUMBER' to change the size limit at compile time. setlimit2.pas:5: internal compiler error: Segmentation fault
The problem is that the backend tries to allocate the memory for the set on the stack (several calls to `alloca' in varasm.c and at least one in tree.c). Since the backend doesn't seem to limit the size of set types to "small" types (at least tree.def doesn't seem to say so), this seems to be a backend bug (you might want to report it ...).
Anyway, even with it fixed, you might not get far. It seems the backend allocates in some situations at least one byte per set element, and there may be problems if you actually go to the full integer range. It's probably not so easy to fix (and possibly not worth it), that's why we have setlimit ...
Frank