Joerg Sonnenberger via llvm-dev
2020-Feb-06 23:13 UTC
[llvm-dev] compatibility with gnu binutils
On Thu, Feb 06, 2020 at 11:46:26AM -0800, Jordan Rupprecht via llvm-dev wrote:> > Where was this policy, which sounds like replicating their design > mistakes bug-for-bug, agreed upon and documented? > James responded already, but just to add my perspective: on the subject of > llvm vs gnu binutils compatibility, I've heard everything in the range from > "let's do our own completely separate thing" to "let's be byte-for-byte > compatible". The general consensus is closer towards the closer > compatibility side, so the happy medium we've tried to apply is "be gnu > compatible, except when it doesn't make sense" -- support for ancient > platforms, bugs, weird formatting, etc. We definitely take things on a case > by case basis, there's no firm policy that we replicate all the bugs.So given that we got around with this for years, how much use do non-lower case assembler pseudops actually see? Joerg
David Spickett via llvm-dev
2020-Feb-07 11:00 UTC
[llvm-dev] compatibility with gnu binutils
>> So given that we got around with this for years, how much use do >> non-lower case assembler pseudops actually see?The original issue was in newlib[0] and I also went through the GNU AS docs [1] and found a few targets that list directives as non lower case (ARC, MMIX, V850). However they would accept any case. ".ABORT" is called out specifically mostly as a compatibility note. Again, accepts any case. I'm not holding this up as a super high priority issue, the bug above is the only one I know of. I just happened across it and thought it would be good to make it consistent. [0] https://bugs.llvm.org/show_bug.cgi?id=39527 [1] https://sourceware.org/binutils/docs/as/ ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> Sent: 06 February 2020 23:13 To: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] compatibility with gnu binutils On Thu, Feb 06, 2020 at 11:46:26AM -0800, Jordan Rupprecht via llvm-dev wrote:> > Where was this policy, which sounds like replicating their design > mistakes bug-for-bug, agreed upon and documented? > James responded already, but just to add my perspective: on the subject of > llvm vs gnu binutils compatibility, I've heard everything in the range from > "let's do our own completely separate thing" to "let's be byte-for-byte > compatible". The general consensus is closer towards the closer > compatibility side, so the happy medium we've tried to apply is "be gnu > compatible, except when it doesn't make sense" -- support for ancient > platforms, bugs, weird formatting, etc. We definitely take things on a case > by case basis, there's no firm policy that we replicate all the bugs.So given that we got around with this for years, how much use do non-lower case assembler pseudops actually see? Joerg _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200207/c9af40aa/attachment.html>
Fangrui Song via llvm-dev
2020-Feb-10 05:38 UTC
[llvm-dev] compatibility with gnu binutils
>> Aside from the above query, case sensitive asm doesn't sound like a >> good feature to me either. >So given that we got around with this for years, how much use do >non-lower case assembler pseudops actually see? > >Joerg >>> So given that we got around with this for years, how much use do >>> non-lower case assembler pseudops actually see? > >The original issue was in newlib[0] and I also went through the GNU AS docs [1] and found a few targets that list directives as non lower case (ARC, MMIX, V850). However they would accept any case. ".ABORT" is called out specifically mostly as a compatibility note. Again, accepts any case. > >I'm not holding this up as a super high priority issue, the bug above is the only one I know of. I just happened across it and thought it would be good to make it consistent. > >[0] https://bugs.llvm.org/show_bug.cgi?id=39527 >[1] https://sourceware.org/binutils/docs/as/I agree with Joerg and Jon regarding case-insensitive assembly directives: they can be categorized as legacy cruft. The portability fix on the newlib side shouldn't be too difficult.