<div dir="ltr">I've tracked down the trigger; it's the line<div><font face="monospace">lea rdx, QWORD PTR [rax*8+16]</font><br></div><div><a href="https://github.com/llvm/llvm-project/blob/d480f968ad8b56d3ee4a6b6df5532d485b0ad01e/openmp/runtime/src/z_Windows_NT-586_asm.asm#L1243" target="_blank">https://github.com/llvm/llvm-project/blob/d480f968ad8b56d3ee4a6b6df5532d485b0ad01e/openmp/runtime/src/z_Windows_NT-586_asm.asm#L1243</a><br></div><div><br></div><div>The issue is that LLVM-ML64 generally assumes that (if unspecified) the base register of a memory reference is RIP. Our attempt to mimic this ends up with us trying to assemble the instruction</div><div><font face="monospace">lea      rdx, [rip + 8*rax + 16]</font><br></div><div>... and the X86 code emitter rightly complains that that's not a valid memory reference.</div><div><br></div><div>This was introduced in an attempt to mimic ML64.EXE in <a href="https://reviews.llvm.org/D73227" target="_blank">https://reviews.llvm.org/D73227</a> - and it looks like I got it wrong! (And didn't test against ML64.EXE nearly enough.) If I've got it right now, this was only supposed to apply to references to symbols... and irritatingly enough, only to symbols defined using MASM's syntax for named variables in memory.</div><div><br></div><div>v0 of <a href="https://reviews.llvm.org/D105372" target="_blank">https://reviews.llvm.org/D105372</a> restricts it to symbols, at least, and avoids this misassembly. I'll see about getting another commit up (or patching that one) to restrict further to named variables specifically, and not apply to labels.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 1, 2021 at 4:26 PM Martin Storsjö <<a href="mailto:martin@martin.st" target="_blank">martin@martin.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 1 Jul 2021, Eric Astor wrote:<br>
<br>
> Martin,<br>
> I haven't actually seen the -win64 option for ML(64).EXE documented anywhere<br>
> - have you? If we can find evidence of what it does for those, we'll of<br>
> course match it.<br>
<br>
Oh, sorry about that, it turns out that this was a flag I added myself in <br>
my CMake configuration. ml(64).exe doesn't support it, but it's a uasm <br>
flag (which is the tool I use for masm today) - I had forgotten about <br>
setting that flag... Then it's trivial for me to change that flag into <br>
-m64, or use tool name based switching like you suggested.<br>
<br>
Sorry for the noise about this aspect.<br>
<br>
> Back to the 64-bit build issues, though - I'll get back to checking on that<br>
> soon, and see if I can track down the line in the .asm file that triggers<br>
> that bug. Hopefully it won't be too tricky a fix!<br>
<br>
Thanks!<br>
<br>
// Martin<br>
<br>
</blockquote></div>