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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
