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

Andy Dougherty doughera at lafayette.edu
Fri Sep 7 01:09:40 UTC 2012


On Thu, 6 Sep 2012, James E Keenan wrote:

> 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

It should be ok; the same patch works on either branch -- master or 
threads.  You can either re-apply it, or merge from master or cherry pick 
it or whatever one usually does.

-- 
    Andy Dougherty		doughera at lafayette.edu


More information about the parrot-dev mailing list