On Sat, Feb 19, 2005 at 03:03:56PM +0100, Frank Heckenbach wrote:
Waldek Hebisch wrote:
Frank Heckenbach wrote:
Waldek, many of these failure seem to be side-effects of the fjf1018 patch.
That is incompatible change. If we want fjf1018.pas to be accepted by default then: filehand.pas, fjf684.pas, fjf751k.pas, fjf751l.pas, fjf800.pas, random.pas are invalid.
Indeed, BP doesn't accept such programs.
Personally I woud prefer to accept fjf1018.pas only in BP mode.
OK.
If someone else wants to try it, use this patch and add `{$borland-pascal}' in test/fjf1018[acu.pas].
New test results on Linux/IA32:
=== gpc tests ===
Running target any Running testsuite ...
UNSUPPORTED: aregextest.pas FAIL: baby.pas
=== gpc Summary ===
# of tests 4537 # of expected passes 4535 # of unexpected failures 1 # of unsupported tests 1
TEST baby.pas: ./a.out: value out of range (error #300 at 804d70a)
Which means:
- The patch works.
- Failures of awindtes* and dostest* also went away.
- As for baby.pas: I found meanwhile that it is the same problem which I reported in another mail, i.e., inability to allocate more than about 128kB of memory. The offending range check happens after the increment in AddHeapRange in rts/heap.pas:
procedure AddHeapRange (p: Pointer; Size: SizeType); var Address: PtrCard; begin Address := PtrCard (p); if (HeapLow = 0) or (Address < HeapLow) then HeapLow := Address; Inc (Address, Size - 1); if Address > HeapHigh then HeapHigh := Address end;
Disassembling the code reveals:
Dump of assembler code for function AddHeapRange: 0x0804eef0 <AddHeapRange+0>: push %ebp 0x0804eef1 <AddHeapRange+1>: mov %esp,%ebp 0x0804eef3 <AddHeapRange+3>: sub $0x8,%esp 0x0804eef6 <AddHeapRange+6>: mov 0x80786a4,%eax 0x0804eefb <AddHeapRange+11>: mov 0x8(%ebp),%edx 0x0804eefe <AddHeapRange+14>: test %eax,%eax 0x0804ef00 <AddHeapRange+16>: je 0x804ef06 <AddHeapRange+22> 0x0804ef02 <AddHeapRange+18>: cmp %eax,%edx 0x0804ef04 <AddHeapRange+20>: jae 0x804ef0c <AddHeapRange+28> 0x0804ef06 <AddHeapRange+22>: mov %edx,0x80786a4 0x0804ef0c <AddHeapRange+28>: mov 0xc(%ebp),%eax 0x0804ef0f <AddHeapRange+31>: lea 0xffffffff(%eax,%edx,1),%eax 0x0804ef13 <AddHeapRange+35>: test %eax,%eax 0x0804ef15 <AddHeapRange+37>: js 0x804ef26 <AddHeapRange+54> ^^^^^^ 0x0804ef17 <AddHeapRange+39>: cmp 0x80786a8,%eax 0x0804ef1d <AddHeapRange+45>: jbe 0x804ef24 <AddHeapRange+52> 0x0804ef1f <AddHeapRange+47>: mov %eax,0x80786a8 0x0804ef24 <AddHeapRange+52>: leave 0x0804ef25 <AddHeapRange+53>: ret 0x0804ef26 <AddHeapRange+54>: call 0x8049fde <_p_RangeCheckError> End of assembler dump.
I.e., the range check fails if the result is negative, when interpreted as a signed integer. This is wrong, as all types involved are unsigned, and malloc() can easily return a pointer larger than $80000000. This also means that the 128kB threshold is rather random, and the test failure is heavily system dependent (thus hard to reproduce).
The test indeed passed when I put {$local R-} around "Inc (Address, Size - 1)".
Emil