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