<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Dec 18, 2012, at 11:06 , Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 17, 2012, at 5:10 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This patch should handle all of this, but I'm seeing a failure in the X86 disassembly tests. This confuses me because I didn't think the disassembler used SMRange.</div></blockquote><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div><div style="margin: 0px 0px 0px 12px; text-indent: -12px; font-size: 11px; font-family: Menlo; "></div></div><blockquote type="cite"><div style="margin: 0px 0px 0px 12px; text-indent: -12px; font-size: 11px; font-family: Menlo; ">/Volumes/Lore/llvm-public/llvm/test/MC/Disassembler/X86/enhanced.txt:5:10: error: expected string not found in input</div><div style="margin: 0px 0px 0px 12px; text-indent: -12px; font-size: 11px; font-family: Menlo; "># CHECK: [o:movq][w: ][1-r:%gs=r{{[0-9]+}}][1-p::][1-l:8=8][p:,][w: ][0-r:%rcx=r{{[0-9]+}}] <mov> 0:[RCX/{{[0-9]+}}]=0 1:[GS/{{[0-9]+}}]=8</div><div style="margin: 0px 0px 0px 12px; text-indent: -12px; font-size: 11px; font-family: Menlo; "> ^</div><div style="margin: 0px 0px 0px 12px; text-indent: -12px; font-size: 11px; font-family: Menlo; "><stdin>:2:1: note: scanning from here</div><div style="margin: 0px 0px 0px 12px; text-indent: -12px; font-size: 11px; font-family: Menlo; ">[o:movq][w: ][1-r:%gs=r64][1-p::][1-l:8=8][1-p:,][w: ][0-r:%rcx=r109] <mov> 0:[RCX/109]=0 1:[GS/64]=8 </div><div style="margin: 0px 0px 0px 12px; text-indent: -12px; font-size: 11px; font-family: Menlo; ">^</div></blockquote><div><br></div><div>I'm usually up on the Clang side (all of this is trying to get a new warning into Clang TableGen, with a fixit), so I'm not sure how to debug this one. Does anyone have any ideas why this test would start failing?</div></div></blockquote><div><br></div><div>This is exercising the "edis" disassembler functionality, which annotates the disassembly with range information about operands, to allow UI tools to put annotations on the disassembled text. This was originally implemented for LLDB, but as it turns out, LLDB just removed their last use of EDIS (afaik), so all the edis code in llvm is dead and should now be removed.</div></div></div></blockquote><div><br></div><div>Thanks, Chris. The only difference I see is that [p:,] has become [1-p:,]. Does that just means there is better range information than before, or is there actually a semantic difference? I don't want to silently break something else even if the edis tests will be going away.</div><div><br></div><div>Jordan</div></div></body></html>