When I had this problem I had not built BPL using C++11, how would I instruct bjam to use gcc at a specific location and with the -std=c++0x flag?
-- Gabe Rives-Corbett Cell: (805) 570-8395 On Tuesday, May 22, 2012 at 10:43 AM, Niall Douglas wrote: > On 21 May 2012 at 18:43, Jonas Wielicki wrote: > > > On 21.05.2012 17:55, Niall Douglas wrote: > > > 1. Does the bug occur in non-optimised as well as optimised builds? > > > > It does. > > > > > Joy. > > > > 2. Does the bug occur when C++11 is turned off? > > It does not. > > > > > Not so much joy. It could, technically speaking, be a > misinterpretation of C++03 by either BPL or GCC. Still, at least it > narrows things down. > > > > 5. Are you using precompiled headers? If so, does the bug occur when > > > you turn those off? > > > > > > > I think I am not. I would know if I did, wouldn't I? At least I can > > browse through the header sources at /usr/include/boost/.. > > > > > Precompiled headers on GCC are basically a dump of state just after > processing the headers. As a result, the file is huge. That might > help you find out if they're on. I believe bjam defaults them to off. > > > > 6. Can you spot where in the assembly it's making a pointer > > > dereferencing mistake? > > > > > > > That is in the template, but the pointer value changes inside code which > > is compiled in the boost library. > > > > > Are you saying that the *offset* changes inside the code? > > So, class A has vtable at this[-8]. > > I access a->foo() which indexes this[-8] by 0x16 in the headers. > > But inside the compiland, a->foo() indexes this[-8] by 0x20, which is > wrong. > > > Within the function defined around inheritance.cpp:392, the value of the > > object pointer (I think it's called p) changes. I was yet unable to find > > the specific point where the value is changed, because a lot of > > subfunctions get called in there and, to be honest, I'm not that > > familiar with gcc yet. Also it seems as maybe the wrong value is only > > passed, while it is still intact on stack (gcc at least shows me > > differing values for the two stackframes), but that might be due to > > debug data or gcc magic? > > > > > Yeah the GCC ABI is a bit fusty. Got a lot better in 3.2 onwards > though. You might find > http://sourcery.mentor.com/public/cxx-abi/cxx-vtable-ex.html useful > as a reference for the C++03 ABI. > > Of course, almost certainly the bug you're seeing is related to the > ABI changes they're making for C++11, of which there are quite a few. > If I had to take a guess, your problems might have something to do > with fixing bugs in decltype support e.g. one of the changelog items > in 4.7 is "The representation of C++ virtual thunks and aliases (both > implicit and defined via the alias attribute) has been re-engineered. > Aliases no longer pose optimization barriers and calls to an alias > can be inlined and otherwise optimized." > > BTW - can I just clarify you ARE compiling the entire of BPL using > C++11 throughout? Linking C++11 to C++03 is *supposed* to work (but > not the other way round), but I can see nests of vipers in it. > > > > If you're *really* unlucky, the bug is that different assembler is > > > being generated in different compilands and the fact you're seeing a > > > problem is due to sheer chance because of the stochastic choice the > > > linker made :) > > > > > > > Actually, the problem is deterministic. I compiled the binary many times > > now and with gcc 4.7 I always get the segfault, at the same instruction, > > with the same surroundings (changed pointer value from one stack frame > > to the other). > > > > > Given the information so far, you have an excellent chance of getting > it fixed. > > Another thought - I once persuaded the GCC devs to accept a bug when > I demonstrated that ICC (Intel's compiler) got it right. ICC is free > on Linux, so that might be worth a shot too. > > Niall > > -- > Technology & Consulting Services - ned Productions Limited. > http://www.nedproductions.biz/. VAT reg: IE 9708311Q. > Work Portfolio: http://careers.stackoverflow.com/nialldouglas/ > > > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig@python.org (mailto:Cplusplus-sig@python.org) > http://mail.python.org/mailman/listinfo/cplusplus-sig > >
_______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
