In D31603#712550, @dim wrote:

I know that when glibc changed something in this area they got complaints about programs breaking, if those should not have done the overlapping memcpy's.

Before this could be accepted I'd at least expect a full ports exp-run, and quite a bit of testing on the resulting packages, as changing the behavior of memcpy() as above will very likely lead to some failures. Strictly speaking you should never call memcpy() with overlapping arguments, but our traditional implementation has always allowed it. So how much fallout would this give? I know that when glibc changed something in this area they got complaints about programs breaking, if those should not have done the overlapping memcpy's.

causing the implicit ${CFLAGS.${.TARGET:T}} to be CFLAGS.clang, and thus pull in flags intended for when your compiler is Clang, not when linking Clang itself

Sure, that's OK then. Doing some spelunking shows that -fno-strict-aliasing got conditionalized for gcc here:

Are the strict aliasing violations in clang itself, or in llvm in general? If so, this flag addition should be added to llvm.build.mk instead. But it would maybe pessimize quite of lot of code...

I think this is OK. I was worried about the MK_LLDB=no in the cross-tools stage, but lldb isn't part of the toolchain, so it shouldn't matter.

While this is OK, I think we may even consider to avoid installing any of the tblgen tools *at all* in the base system. Other "extras" tools like llc, llvm-mc etc are usable by themselves, whereas the tblgen tools are really only needed for building llvm-project components.

LGTM

In D31057#699199, @emaste wrote:

Looks OK to me but will defer to @dim for questions about maintainability / expected impact on future clang/llvm updates

Note that the GNU coreutils sha256sum actually has support for reading BSD sha256(1) formatted lines, e.g.:

Yes, this would be very nice to have. But does this improve or worsen link performance? (I'm unsure if we'd need a toggle... yet more toggles)