We recently enabled clang as default compiler for chrome on linux. It mostly went well. One problem we ran into was that chrome 38 crashed on old debians. rnk explained this to me, and from what I understand (I probably got some of it wrong) it was due to clang using aligned SSE instructions.
gcc changed their alignment abi on linux a while ago, and the current abi does guarantee alignment. The old one doesn't, and I suppose on debian system libraries still use the old abi. gcc emits unaligned SSE loads on 32bit linux, clang should too.
As is, every provider of binary-distributed binaries on linux will run into this and then work around it somehow. We ended up adding tons of stack adjustments, which bloats binary size, is bad for the icache, etc. Unaligned SSE reads are almost as fast as aligned ones, so clang should do the thing that Just Works instead of giving a bad user experience to its users.
See comment 0. Binaries built with old gccs don't conform to this abi, so
gcc uses unaligned reads to be abi compatible with old versions of itself.
I think it's a little more nuanced than that, here's the history as I understand it:
Long ago (2006?) gcc increased the "preferred" stack alignment to 16.
They waited a while with this setting
In the next release, they began assuming the stack was 16 byte aligned.
Users reported bugs, and their compromise solution was "we'll keep assuming 16 byte alignment, but we'll use unaligned loads and stores so that users stop filing bugs on us"
I don't consider it correct to say that they are ABI-compatible with old GCC binaries. It's just that they have made an engineering tradeoff to avoid the most obvious forms of breakage for people on systems that aren't using the new ABI.
I think, in retrospect, we should probably also make this compromise. It's the practical thing to do.