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