> -----Original Message----- > From: Eric Lemings > Sent: Thursday, March 27, 2008 2:05 PM > To: '[email protected]' > Subject: RE: [STDCXX-709] ContainerData ctor and > UserClass::from_char() > > > > > -----Original Message----- > > From: Martin Sebor [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 26, 2008 4:19 PM > > To: [email protected] > > Subject: Re: [STDCXX-709] ContainerData ctor and > > UserClass::from_char() > > > ... > > > > It seems pretty clear that somewhere between the call TO > > operator new and the return FROM the function the pointer > > gets bumped up by 8 on LP64 (and 4 on ILP32 according to > > your observation). The only thing in between these two > > steps is the call to the UserClass ctor. So unless the > > ctor manages to change its own this pointer we're looking > > as a compiler bug. Either way, we need a small, isolated > > test case to understand how to deal with it... > > > > Martin > > The pointer is being adjusted before the constructor is > called. > > I was looking yesterday at GCC's implementation of the > C++ ABI __cxa_vec_new2() function. There's a padding > argument that may be utilized in HP-UX aCC 6.x for some > unknown reason. > > Also, I thought the allocator in _rw_dispatch(), where > the ContainerTestCaseData object is being constructed, > could play some role in all this but looks like its > only used in the test function. > > Brad.
Does HP-UX IPF have any sort of memory alignment restrictions that anyone is aware of?
