threads branch: t/pmc/filehandle.t: test results differ between gcc and g++ builds

James E Keenan jkeen at verizon.net
Fri Sep 7 00:37:37 UTC 2012


On 9/4/12 1:49 PM, Reini Urban wrote:
> On Tue, Sep 4, 2012 at 8:21 AM, Andy Dougherty<doughera at lafayette.edu>  wrote:
>> On Tue, 4 Sep 2012, Nicholas Clark wrote:
>>
>>> On Mon, Sep 03, 2012 at 09:41:28PM -0400, James E Keenan wrote:
>>>
>>>> (These results were run at commit 5709835825; Sept 02 2012.  But I've
>>>> submitted dozens of smolders with the same results in recent months.)
>>>>
>>>> In my experience, it's really rare that we get consistently different
>>>> test results between all-gcc and all-g++ builds on our most heavily
>>>> tested platform.
>>>>
>>>> Any thoughts as to the cause of this discrepancy?
>>>

>>
>> Does this patch fix it?  I haven't tested this it, but it's exactly the
>> sort of thing that would give rise to sign extension errors, and, if I
>> recall correctly, the precise rules for sign extension are slightly
>> different in c and c++, which would explain your discrepancy.
>>
>> diff --git a/src/io/utilities.c b/src/io/utilities.c
>> index 08ed390..0acd4e9 100644
>> --- a/src/io/utilities.c
>> +++ b/src/io/utilities.c
>> @@ -551,7 +551,10 @@ io_sync_buffers_for_write(PARROT_INTERP, ARGMOD(PMC *handle),
>>       if (read_buffer&&  !BUFFER_IS_EMPTY(read_buffer)) {
>>           const size_t buffer_size = BUFFER_USED_SIZE(read_buffer);
>>           Parrot_io_buffer_clear(interp, read_buffer);
>> -        vtable->seek(interp, handle, -buffer_size, SEEK_CUR);
>> +       /* To avoid sign extension problems on 32-bit systems with 64-bit
>> +           file support, first cast the buffer_size to off_t, then change
>> +           the sign. */
>> +        vtable->seek(interp, handle, -((PIOOFF_T)buffer_size), SEEK_CUR);
>>       }
>>   }
>
> Yes, I remember reading Nick's earlier analysis, but I was away for 3 weeks.
> Thanks for the reminder, and Andy, yes, this was it. Confirmed and applied
> as 0cc54e6972ae830e7943a15c8db1e14fc9c3cb90
>

The problem I reported was on the threads branch. 
0cc54e6972ae830e7943a15c8db1e14fc9c3cb90 was applied to master.  So the 
gcc vs. g++ discrepancy persists on the threads branch (where HEAD is 
5709835825a49733fd5180aaf35462e230d486ed).

All gcc: error still present

not ok 28 - write after buffered read # TODO GH #811 Write error: No 
space left on device on swap fs
#   Failed (TODO) test 'write after buffered read'
#   at t/pmc/filehandle.t line 929.
#          got: '10
# abcdefghij
# '
#     expected: '10
# abcde#####klmno
# '
ok 29 - small reads and seeks

All g++:

ok 28 - write after buffered read # TODO GH #811 Write error: No space 
left on device on swap fs


Thank you very much.
Jim Keenan



More information about the parrot-dev mailing list