Hacker News new | ask | show | jobs
by schemescape 933 days ago
I didn't see it addressed here or in the article: this is a bug, right?

Edit: oddly, after searching LLVM bugs, I found a bug that sounds pretty much exactly like this issue... but it's from 2012 and is closed (although the final couple of comments make it sound like maybe it wasn't actually fixed--note: I only skimmed the comments and I probably misunderstood):

https://github.com/llvm/llvm-project/issues/13989

Edit again: I forgot about the comment at the end of the article that clarifies that explicitly passing the target results in a working program. In that case, it sounds like some sort of configuration bug--I would assume (but am not certain) that the default target would be the current processor, at least on Unix. That bug I linked was probably about producing incorrect code even when the target was set correctly which, thankfully, isn't happening today.

3 comments

Yes, your bug is about the compiler emitting armv7 instructions despite being told to target armv6. Rachel fixed her problem by telling the compiler to target armv6. So I assume your bug is indeed already fixed and not related to Rachel's problem.
Obviously it is a bug, but, apparently, author didn't bother to report it, opting to write a blogpost with a somewhat clickbait title and ending with "so weird" instead.
Yeah, this is not the behavior people expect.
I would expect a arm64 machine to not build a arm32 compatible binary by default, it's the same as running clang on a x86-64 host and expecting it to produce 386 compatible binaries without a -march=i386 somewhere.

The weird clang install on a fresh B+ install is more puzzling, unless there's some user error somewhere.