develooper Front page | perl.perl5.porters | Postings from January 2008

Re: [perl #50386] GIMME_V broken with 5.10.0/GCC and XS?

Thread Previous | Thread Next
Robert May
January 30, 2008 08:54
Re: [perl #50386] GIMME_V broken with 5.10.0/GCC and XS?
Message ID:

Many thanks for the very quick analysis, and clear explanation.

Further research turns up the '-mms-bitfields' option for (mingw
only?) gcc, which causes it to use the same alignment as Microsoft's
compilers.  I can confirm that using this option at least fixes my
immediate problem[1].  It might be a better option for 5.10.x to patch
ActivePerl::Config to add this flag?  I'll generate a patch and attach
it to the ActiveState Bug report for this item.


[1] Although I have in the process discovered that
ExtUtils::CBuilder::Windows doesn't honour the extra_compiler_flags
option - patch forthcoming.

On 30/01/2008, Jan Dubois <> wrote:
> On Tue, 29 Jan 2008, Robert May (via RT) wrote:
> > -----------------------------------------------------------------
> > I'm building the following XS extension with
> > gcc 3.4.5 (mingw special) against ActiveState Perl 5.10.0
> > (builds 1001 and 1002)
> >
> > GIMME_V appears to always return G_VOID (128), regardless of the
> > context the XSUB is called in.
> >
> > The same code and compiler works fine when built against ActiveState
> > Perl 5.8.8 (build 822).  It is also fine when compiled with VC++ 6
> > for all 3 perl builds.
> This is not really a core Perl bug; the problem is that VC++ and GCC
> are incompatible as far as bit-fields are concerned.  In Perl 5.10
> the BASEOP structure contains bitfields:
>     unsigned    op_type:9;              \
>     unsigned    op_opt:1;               \
>     unsigned    op_latefree:1;          \
>     unsigned    op_latefreed:1;         \
>     unsigned    op_attached:1;          \
>     unsigned    op_spare:3;             \
> In VC++ the combined size of the fields above is 4 bytes, whereas
> in GCC it is only 2.  This also pushes the size of the complete
> structure from 20 to 24 bytes for VC++.
> The GIMME_V() function retrieves the context information from the
> op_flags byte.  Under GCC the op_flags member fetches one of the
> 2 filler bytes VC++ inserts into the structure and is therefore
> wrong.
> VC++ uses the base type (unsigned int, in this case) to determine
> the alignment requirements and total size of the combined bit-field.
> You can use the non-standard extension of using smaller integer sizes
> to force the fields into a smaller size and different alignment.
> In this case using "unsigned short" for the type of the bit-fields
> should work.
> I guess for Perl 5.12 we need a way to let us use the smaller base
> size for VC++ to keep the size of the OP structure down.  I'll create
> a patch for it eventually, when I get a bit more time.  I also need
> to check if there are other places where Perl is now using bit fields
> in its structure definitions.
> I would suggest to keep this bug report open until the size of
> the BASEOP structure in bleadperl has been reduced for VC++.
> For ActivePerl 5.10.x we will probably modify op.h to provide an
> alternate definition of BASEOP for GCC that contains 2 filler bytes to
> make everything align the same way as it does for VC++ (unless we decide
> to break binary compatibility between 5.10 and 5.10.1, which I would not
> be too fond of).
> I have not yet verified that otherwise the bit mapping between
> VC++ and GCC would be compatible though; many details of C bit-field
> implementation is really up for the compiler to decide.
> The ability to compile extensions with GCC for a Perl compiled
> with VC++ is really an ActivePerl feature and not guaranteed
> by core Perl.  You have also opened a corresponding ActivePerl bug
> that should be used to track that part of the issue:
> Cheers,
> -Jan

Please update your address book with my new email address:

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About