[PATCH] D133405: [Linux] Hack around Linux/sparc <bits/stdio-ldbl.h>

Thu Sep 8 04:30:28 PDT 2022

ro added a comment.

In D133405#3776096 <https://reviews.llvm.org/D133405#3776096>, @MaskRay wrote:

> It's not a compiler's job to define this workaround...

Yes and no: GCC successfully does it via its `fixincludes` mechanism.  Unfortunately, LLVM doesn't provide something similar and doesn't even known about the GCC `include-fixed` directory, which could be used as a fallback.  Sometimes OS headers **are** broken and remain so for a long time.  While one can throw hands up in disgust, this doesn't make the problem go away.  If I own the machine, I can patch/hack system headers as need be, but that's not an option on shared systems where I have to live with what's installed.

> If a platform want to provide a built-in macro, you can use https://clang.llvm.org/docs/UsersManual.html#configuration-files and add `-D__NO_INLINE__` there.
> To avoid magic behaviors, `${triple}-clang` loads `${triple}.cfg` while `clang` doesn't (see https://discourse.llvm.org/t/configuration-files/42529/24)

That's nice in some controlled circumstances where I can control e.g. the `clang` command used, but doesn't help in others like a release build with `test-release.sh` where I don't have that control.  I fully understand Jörg's argument in that thread that implicit changes from some hidden config file/environment variable are a maintenance nightmare and to be avoided at all cost.

> See also https://discourse.llvm.org/t/rfc-adding-a-default-file-location-to-config-file-support/63606 (I am somewhat concerned with `clang` loading a config).
> But if you make `clang` a shell script that executes `sparc64-pc-linux-gnu-clang` or the like, I think it should be fine.

Again, that would be ok for an installed `clang`, but while doing a release build, such a script wouldn't be used at all.

On top of all that, defining `__NO_INLINE__` globally to hack around a header bug is way too large a hammer: it has more effects than it should, which is why I called it a hack to allow making some progess at all, nothing to be included upstream.  I merely wanted to document what I'd changed in the Linux/sparc64 release builds rather than only vaguely referring to my hack.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133405/new/

https://reviews.llvm.org/D133405