<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 27, 2016 at 2:30 PM, Edward Diener via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I really appreciate your taking a look at this. If I report this issue to GCC I will need to reduce it to code which shows the bug. Since I am not a clang developer it is difficult for me to know which llvm/clang source illustrates this problem, so I can reduce it to a bug report.<br></blockquote><div><br></div><div>I went ahead and filed <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78936">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78936</a><br></div><div><br></div><div>Thanks for the offer, though. I linked the pre-processed source off of there, which could be further reduced.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You said that the problem goes away when you "disable frame pointer omission". Does this mean that compiling with "-fomit-frame-pointer" temporarily solves the problem ?</blockquote><div><br></div><div>Compiling with -fno-omit-frame-pointer hides the problem. Compiling with -O0 also hides the problem.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Also do you have any idea why the bug occurs for 32-bit generation and not 64-bit code generation ?<br></blockquote><div><br></div><div>It has to do with thiscall being the default C++ member function calling convention, which is 32-bit only.</div></div></div></div>