4 ms·

So much wtf in this blog post! LLVM had multiple ABI conformance bugs in its implementation of int128, but clang had workarounds for these bugs that rustc lack

by fanf2 3y ago

So much wtf in this blog post! LLVM had multiple ABI conformance bugs in its implementation of int128, but clang had workarounds for these bugs that rustc lacked, causing interop problems. I wonder why they put workarounds in clang instead of fixing LLVM?! This is a great example of one of the criticisms of LLVM, that language front ends must still implement processor-specific details themselves – iirc another example is struct layout.

ajross 3y ago
> I wonder why they put workarounds in clang instead of fixing LLVM?! Among other things, because it would probably break rust (and other projects that had come to rely on the mistaken representation). Interoperability bugs like this often end up fundamentally unfixable in practice and the community ends up having to embrace bifurcated standards.
- dylnuge 3y ago
  Indeed, it looks like they even tried to fix it in LLVM (back in 2017) but wound up reverting it: https://reviews.llvm.org/D28990 https://reviews.llvm.org/D28990
  - fanf2 3y ago
    That’s one of the links in the original article, which postdates the workaround in clang. It doesn’t explain why the incorrect ABI was previously worked around in clang instead of fixed in LLVM.
- lamontcg 3y ago
  And this is the kind of convoluted situation that happens when you have software that can never, ever break backwards compatibility. It is probably entirely necessary to do it in this particular situation, but when people argue for no software ever breaking backward compatibility, they're arguing for more and more convoluted solutions like this. There's always a cost.
  - ajross 3y ago
    > And this is the kind of convoluted situation that happens when you have software that can never, ever break backwards compatibility. Toolchains are poster children for that genre, yeah. The ecosystems are too large and too interconnected to evolve in parallel. I mean, any one of LLVM, Rust and Clang are too large as a single project to implement a breaking change like this as a single event, trying to get them to do it in tandem just isn't going to happen. And even then there are uncounted other LLVM downstreams to worry about, all of whom need a story for how to migrate.
    - marcosdumay 3y ago
      What is the exact kind of thing semantic versioning was meant to solve.
  - remexre 3y ago
    LLVM breaks backwards compatibility all the time, though...
    - lamontcg 3y ago
      Not really my point though. I just want to get the people who scream on HN about how software should never ever break backcompat under any circumstance, in a room with the people on this issue who are stunned by how convoluted this situation is, and get them to fight it out. Bonus points for when those people are the same person on different days.
deleted 3y ago
[deleted]
codeflo 3y ago
Yes, LLVM has many bugs that Clang either doesn’t hit or has actively worked around, sometimes for years. There was never a huge push to fix that situation, which made using LLVM for other languages a disappointing experience. Rust has uncovered many of those bugs over time, and it seems like Rust is an important enough customer that those do get fixed now. Slowly. For example, I remember that for many years, Rust would have to throw away part of its aliasing analysis because its annotations were too precise and would confuse LLVM’s optimizer. And so on. But it’s getting better.

by fanf2 3y ago

ajross 3y ago

> I wonder why they put workarounds in clang instead of fixing LLVM?! Among other things, because it would probably break rust (and other projects that had come to rely on the mistaken representation). Interoperability bugs like this often end up fundamentally unfixable in practice and the community ends up having to embrace bifurcated standards.

dylnuge 3y ago
Indeed, it looks like they even tried to fix it in LLVM (back in 2017) but wound up reverting it: https://reviews.llvm.org/D28990 https://reviews.llvm.org/D28990
- fanf2 3y ago
  That’s one of the links in the original article, which postdates the workaround in clang. It doesn’t explain why the incorrect ABI was previously worked around in clang instead of fixed in LLVM.
lamontcg 3y ago
And this is the kind of convoluted situation that happens when you have software that can never, ever break backwards compatibility. It is probably entirely necessary to do it in this particular situation, but when people argue for no software ever breaking backward compatibility, they're arguing for more and more convoluted solutions like this. There's always a cost.
- ajross 3y ago
  > And this is the kind of convoluted situation that happens when you have software that can never, ever break backwards compatibility. Toolchains are poster children for that genre, yeah. The ecosystems are too large and too interconnected to evolve in parallel. I mean, any one of LLVM, Rust and Clang are too large as a single project to implement a breaking change like this as a single event, trying to get them to do it in tandem just isn't going to happen. And even then there are uncounted other LLVM downstreams to worry about, all of whom need a story for how to migrate.
  - marcosdumay 3y ago
    What is the exact kind of thing semantic versioning was meant to solve.
- remexre 3y ago
  LLVM breaks backwards compatibility all the time, though...
  - lamontcg 3y ago
    Not really my point though. I just want to get the people who scream on HN about how software should never ever break backcompat under any circumstance, in a room with the people on this issue who are stunned by how convoluted this situation is, and get them to fight it out. Bonus points for when those people are the same person on different days.

deleted 3y ago

[deleted]

codeflo 3y ago

Yes, LLVM has many bugs that Clang either doesn’t hit or has actively worked around, sometimes for years. There was never a huge push to fix that situation, which made using LLVM for other languages a disappointing experience. Rust has uncovered many of those bugs over time, and it seems like Rust is an important enough customer that those do get fixed now. Slowly. For example, I remember that for many years, Rust would have to throw away part of its aliasing analysis because its annotations were too precise and would confuse LLVM’s optimizer. And so on. But it’s getting better.