[llvm-commits] [llvm] r125595 - in /llvm/trunk: lib/MC/MCParser/AsmParser.cpp test/MC/AsmParser/exprs.s test/MC/AsmParser/paren.s

[Joerg Sonnenberger]

On Wed, Feb 23, 2011 at 01:30:44PM -0800, Jim Grosbach wrote:
> I'm sorry that we've been unable to resolve this via discussion.
> Perhaps we simply have differing enough philosophical approaches that
> we simply weren't ever going to reach consensus.

Right, I am wrong and you are right. Please reopen the bug that this
triggers and provide a proper solution, since you don't care about
consistency or breaking things for other people.

> Be that as it may, I do feel strongly that it is inappropriate for
> this change to go in as it stands. It introduces ambiguities into the
> ARM syntax, as I previously documented, for an X86 extenstion.

There is no ambiguity as has been demonstrated. It is not an X86
extension, it is a standard functionality of GNU as on most platforms
for the expression language. The philosphical difference seems to be
that I consider a consistent approach that follows the behavior of the
primary assembler on Unix more useful than the whatever input the
assembler of a hardware vendor currently decides to reject.

> I have reverted the patch in r126336. If you would like to resubmit
> with the feature being conditional on X86/ELF, please do.
> 
> If you feel this is inappropriate or would otherwise like to escalate
> the issue, please contact the LLVM backend maintainer, Evan Cheng.
> I've CCed him on this message.

Yes, I consider this behavior inappropiate. I have offered making the
function virtual and overriding it. I don't really care if it is opt-in
or opt-out. You just broke valid input for the only reason to reject
invalid input on a platform that is accepted by other tools on that
platform.

Joerg