<div dir="ltr">I spent some time debugging this, and it's either a GCC miscompile or instance of UB in tablegen that I can't identify. The 'this' pointer is corrupted in this call sequence:<div><div>    llvm::errs() << "this before EmitProcessorProp: " << (void *)this << '\n';</div><div>    EmitProcessorProp(OS, PM.ModelDef, "IssueWidth", ',');</div><div>    EmitProcessorProp(OS, PM.ModelDef, "MicroOpBufferSize", ',');</div><div>    EmitProcessorProp(OS, PM.ModelDef, "LoopMicroOpBufferSize", ',');</div><div>    EmitProcessorProp(OS, PM.ModelDef, "LoadLatency", ',');</div><div>    EmitProcessorProp(OS, PM.ModelDef, "HighLatency", ',');</div><div>    EmitProcessorProp(OS, PM.ModelDef, "MispredictPenalty", ',');</div><div>    llvm::errs() << "this after EmitProcessorProp: " << (void *)this << '\n';</div></div><div><br></div><div>I suspect a GCC miscompile. The problem goes away when I disable frame pointer omission, and GCC is doing some interesting IPO transformation, based on the mangled name of this function: __ZN12_GLOBAL__N_116SubtargetEmitter17EmitProcessorPropERN4llvm11raw_ostreamEPKNS1_6RecordENS1_9StringRefEc.constprop.549 (note the .constprop)</div><div><br></div><div>I think this GCC getting the thiscall calling convention confused. Here's here it calls EmitProcessorProp:</div><div><div>    7c06:<span class="gmail-Apple-tab-span" style="white-space:pre">       </span>e8 15 97 ff ff       <span class="gmail-Apple-tab-span" style="white-space:pre">      </span>call   1320 <__ZN12_....constprop.549></div><div>    7c0b:<span class="gmail-Apple-tab-span" style="white-space:pre">       </span>8b 53 1c             <span class="gmail-Apple-tab-span" style="white-space:pre">   </span>mov    0x1c(%ebx),%edx</div><div>    7c0e:<span class="gmail-Apple-tab-span" style="white-space:pre">    </span>83 ec 08             <span class="gmail-Apple-tab-span" style="white-space:pre">   </span>sub    $0x8,%esp</div></div><div><br></div><div>Note the subtraction from ESP. This usually indicates that the callee is expected to pop 8 bytes off the stack. However, the epilogue of EmitProcessorProp doesn't do that:</div><div><div>    13c3:<span class="gmail-Apple-tab-span" style="white-space:pre">    </span>8d 65 f4             <span class="gmail-Apple-tab-span" style="white-space:pre">   </span>lea    -0xc(%ebp),%esp</div><div>    13c6:<span class="gmail-Apple-tab-span" style="white-space:pre">    </span>5b                   <span class="gmail-Apple-tab-span" style="white-space:pre">        </span>pop    %ebx</div><div>    13c7:<span class="gmail-Apple-tab-span" style="white-space:pre">       </span>5e                   <span class="gmail-Apple-tab-span" style="white-space:pre">        </span>pop    %esi</div><div>    13c8:<span class="gmail-Apple-tab-span" style="white-space:pre">       </span>5f                   <span class="gmail-Apple-tab-span" style="white-space:pre">        </span>pop    %edi</div><div>    13c9:<span class="gmail-Apple-tab-span" style="white-space:pre">       </span>5d                   <span class="gmail-Apple-tab-span" style="white-space:pre">        </span>pop    %ebp</div><div>    13ca:<span class="gmail-Apple-tab-span" style="white-space:pre">       </span>c3                   <span class="gmail-Apple-tab-span" style="white-space:pre">        </span>ret    </div></div><div><br></div><div>Note that it doesn't say "ret $0x8".</div><div><br></div><div>Do you want to follow up filing this issue with upstream GCC?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 23, 2016 at 7:04 AM, 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:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am building clang from source on Windows using CMake, Ninja, and mingw-64/gcc-6.2. I am building in Release mode ( CMAKE_BUILD_TYPE = Release ).<br>
<br>
When I build with the x64 version of mingw-64/gcc-6.2 with a triple of x86_64-w64-mingw32 ( LLVM_DEFAULT_TARGET_TRIPLE = x86_64-w64-mingw32 ),<br>
everything builds fine and I can produce clang that works properly with a 64-bit compilation using the 64-bit version of mingw-64/gcc-6.2.<br>
<br>
When I build with the x32 version of mingw-64/gcc-6.2 with a triple of i686-pc-mingw32  ( LLVM_DEFAULT_TARGET_TRIPLE = i686-pc-mingw32 ),<br>
the build fails with:<br>
<br>
[8/1856] Building AArch64GenSubtargetInfo.inc...<br>
FAILED: lib/Target/AArch64/AArch64GenS<wbr>ubtargetInfo.inc.tmp<br>
cmd.exe /C "cd /D C:\Programming\VersionControl\<wbr>bninja_clang\lib\Target\AArch6<wbr>4<br>
&& C:\Programming\VersionControl\<wbr>bninja_clang\bin\llvm-tblgen.e<wbr>xe -gen-subtarget<br>
-I E:/Programming/VersionControl/<wbr>llvm/lib/Target/AArch64 -I E:/Programming/VersionControl/<wbr>llvm/include<br>
-I E:/Programming/VersionControl/<wbr>llvm/lib/Target E:/Programming/VersionControl/<wbr>llvm/lib/Target/AArch64/AArch6<wbr><a href="http://4.td">4.td</a><br>
-o C:/Programming/VersionControl/<wbr>bninja_clang/lib/Target/AArch6<wbr>4/AArch64GenSubtargetInfo.inc.<wbr>tmp"<br>
Wrote crash dump file "C:\Users\eldiener\AppData\Loc<wbr>al\Temp\llvm-tblgen.exe-0c060b<wbr>.dmp"<br>
0x004EFB0A (0x0166FA48 0x00000007 0x63724141 0x00343668)<br>
0x03172858 (0x77CEE172 0x769B0100 0x00000000 0x00000008) <unknown module><br>
0x77CEE40C (0x001F9A18 0x004F51D0 0x005F40CC 0x00000000), RtlInitUnicodeString() + 0x164 bytes(s)<br>
0x005CD6B1 (0x0000000B 0x001F99E0 0x001F2B50 0x00000000)<br>
0x004013E2 (0x7EFDE000 0x0166FFD4 0x77CF9902 0x7EFDE000)<br>
0x768E336A (0x7EFDE000 0x73B4F3DA 0x00000000 0x00000000), BaseThreadInitThunk()+ 0x12 bytes(s)<br>
0x77CF9902 (0x004014E0 0x7EFDE000 0x00000000 0x00000000), RtlInitializeExceptionChain() + 0x63 bytes(s)<br>
0x77CF98D5 (0x004014E0 0x7EFDE000 0x00000000 0x00000000), RtlInitializeExceptionChain() + 0x36 bytes(s)<br>
[9/1856] Building AMDGPUGenMCPseudoLowering.inc.<wbr>..<br>
ninja: build stopped: subcommand failed.<br>
<br>
I notice that AArch64 is listed as a target type even when building with a 32-bit compiler and am guessing that this is what is causing the build to fail.<br>
<br>
Is this an LLVM problem or a clang problem ?<br>
<br>
How can I get someone to correct this in the CMake files in the LLVM/clang project ?<br>
<br>
Is there some way I myself can tell CMake to not build for the AArch64 target ?<br>
<br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>