release_33 branch: proposing r181620 and r183907

Benjamin Kramer benny.kra at gmail.com
Fri Jul 19 07:23:05 PDT 2013


On 19.07.2013, at 16:16, Tom Stellard <tom at stellard.net> wrote:

> On Mon, Jul 08, 2013 at 12:59:49PM -0700, Nadav Rotem wrote:
>> LGTM but I would double check with Chad and Ben.  
>> 
> 
> Hi Chad and Ben,
> 
> Any thoughts on merging these patches to the 3.3 branch?

r183907 should be safe for 3.3.

- Ben
> 
> -Tom
> 
>> On Jul 8, 2013, at 12:54 PM, Dimitry Andric <dimitry at andric.com> wrote:
>> 
>>> Hi,
>>> 
>>> For the 3.3 release branch, I would like to propose merging r181620 and r183907:
>>> 
>>> r181620 from llvm trunk (by Chad Rosier):
>>> 
>>>  [ms-inline asm] Fix a crasher when we fail on a direct match.
>>> 
>>>  The issue was that the MatchingInlineAsm and VariantID args to the
>>>  MatchInstructionImpl function weren't being set properly.  Specifically, when
>>>  parsing intel syntax, the parser thought it was parsing inline assembly in the
>>>  at&t dialect; that will never be the case.
>>> 
>>>  The crash was caused when the emitter tried to emit the instruction, but the
>>>  operands weren't set.  When parsing inline assembly we only set the opcode, not
>>>  the operands, which is used to lookup the instruction descriptor.
>>>  rdar://13854391 and PR15945
>>> 
>>>  Also, this commit reverts r176036.  Now that we're correctly parsing the intel
>>>  syntax the pushad/popad don't match properly.  I've reimplemented that fix using
>>>  a MnemonicAlias.
>>> 
>>> r183907 from llvm trunk (by Benjamin Kramer):
>>> 
>>>  X86: Make the cmov aliases work with intel syntax too.
>>> 
>>> Together, these commits make a number of Intel-style inline assembly mnemonics aliases (cmov variants, occurring in several FreeBSD ports) work properly, which could cause assertions (and crashes) otherwise.
>>> 
>>> These commits should apply to the release_33 branch without modification.
>>> 
>>> -Dimitry
>> 





More information about the llvm-commits mailing list