[parrot-tickets] [Parrot] #254: t/native_pbc/number.t: New failure on some platforms

[Andy Dougherty]

On Mon, 2 Feb 2009, Reini Urban wrote:
 
> 2009/2/1 Parrot <parrot-tickets at lists.parrot.org>:
> > #254: t/native_pbc/number.t:  New failure on some platforms
> > ---------------------+------------------------------------------------------
> >  Reporter:  jkeenan  |       Owner:  rurban
> >     Type:  bug      |      Status:  assigned
> >  Priority:  normal   |   Milestone:
> > Component:  core     |     Version:
> >  Severity:  high     |    Keywords:
> >     Lang:           |       Patch:
> >  Platform:  darwin   |
> > ---------------------+------------------------------------------------------
> >


> I've found the root-cause for the x86-64 problem loading 32-bit pbc's.
> This is with any compiler, gcc, sunpro cc or intel ICC on 64-bit.
 
> The problem is the ALIGN_16 macro, but even with staring at it for hours,
> it doesn't make sense to my why it fails on 64bit and works on 32bit.

Huh?  What, specifically, do you mean by "it fails"?  I don't see how it 
could fail either, which means that there's probably something else going 
on.

It's been quite a while since I looked at that code, and I'm not sure I 
understand what you're trying to do here, but I'll take a couple of 
quick guesses.

I'll assume you're taking a packfile written with a 32-bit opcode_t and 
trying to read it on a system with a 64-bit opcode_t.  The writer code 
assumes you walk through the packfile with steps of sizeof(opcode_t), i.e. 
steps of 4.  The ALIGN_16 macro assumes that the two arguments passed to 
it differ by an integral multiple of sizeof(opcode_t).

When reading that packfile with a 64-bit opcode_t, that same macro assumes 
that the two arguments given differ by an integral multiple of 8.  Is that 
always true?  Do you now walk through that same packfile always in steps 
of 8?  That might be worth verifying before each call to ALIGN_16.

Sorry to be so vague; it's been years since I looked at the packfile 
stuff and I don't know specifically what's failing where.

-- 
    Andy Dougherty		doughera at lafayette.edu