4 ms·
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 l
by schemescape 3y 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 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.
- deleted 3y ago[deleted]
- wmf 3y agoYeah, this is not the behavior people expect.
- NikkiA 3y agoI 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.
- deleted 3y ago[deleted]
- Arnavion 3y agoYes, 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.
- krick 3y agoObviously 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.