develooper Front page | perl.perl5.porters | Postings from September 2012

Re: unhappy darwin -Dusemorebits (was Re: Smoke [5.17.4]v5.17.3-184-g699aa44 FAIL(F) darwin 12.1.0 (Intel Core 2 Duo/))

Thread Previous | Thread Next
From:
Tony Cook
Date:
September 1, 2012 15:50
Subject:
Re: unhappy darwin -Dusemorebits (was Re: Smoke [5.17.4]v5.17.3-184-g699aa44 FAIL(F) darwin 12.1.0 (Intel Core 2 Duo/))
Message ID:
20120901225032.GA20357@mars.tony.develop-help.com
On Sat, Sep 01, 2012 at 09:05:10PM +0100, Dave Mitchell wrote:
> > 
> > OK, thanks. I don't know any x86_64 assembler, nor do I know its alignment
> > constrains or whatnot, so I'm not able to work out from this what went
> > wrong. And whether it's us doing something dodgy or them.
> 
> See http://www.damtp.cam.ac.uk/cosmos/private/documentation/vtune/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/instruct32_hh/vc181.htm
> 
> (fond from google search).
> 
> movaps basically copies a 16-byte check to/from one of FPU registers; the
> data must be 16-byte aligned. From ther above, sv_any is only 8-byte
> alignegned
> 
> On my Linux system, the line
>     StructCopy(SvANY(sv), xpvmg, XPVMG);
> is expanded to 
>     (*((XPVMG*)(xpvmg)) = *((XPVMG*)((sv)->sv_any)));
> 
> So, struct xpvgv's are being allocated on 8-byte boundaries within the arena,
> yet the compiler assumes the structure is 16-byte aligned. After that I get
> confused.
> 
> PS the structure (xpvmg and xpvgv) expand as
> 
>     ptr
>     ptr/STRLEN
>     STRLEN/I32
>     ptr/IV/UV
>     NV/ptr/{U32,U32}/{I32,U8}
> 
> where the / show different elements of a union

The code is built with usemorebits, hence uselongdouble, so the NV
element would force 16-byte alignment.

So the compiler is correct to assume 16-byte alignment (assuming I
remember the x64 ABI correctly).

Tony

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About