This patch defines __HOS_AIX__ macro for AIX in case of a cross compiler implementation.
Tested with SPEC.
Differential D107242
[AIX] Define __HOS_AIX__ macro Jake-Egan on Aug 1 2021, 1:56 PM. Authored by
Details
Tested with SPEC.
Diff Detail
Event Timeline
Comment Actions I'm puzzled by this change. I don't think we have any case so far where the compiler behavior changes with the host OS and I don't think it should. What's the point / use case of this macro? Comment Actions I agree that this is strange. And strange things need good documentation. The documentation for this extremely strange behaviour is woefully inadequate both in the code and in the commit message. Of course, I am not certain why this is needed but I assume it has something to do with the fact that it is the OS on AIX that owns the headers so the compiler needs to know whether it is running on an AIX host due to some non-portable code in the headers. Of course, this can't be the full explanation as it brings up many questions. This needs to be very clear to the reader - both in the commit message and in the code. Another thing that I find extremely strange is that we set this only if we are on an AIX host and are targeting AIX. If this is truly something that has to do with the host (which I am not positive is the case as I'm not sure what HOS in the macro name means), then why is it not needed when cross-compiling? Comment Actions HOS_AIX is a macro defined by the XL C/C++ compilers on AIX. Although there was never an AIX cross compiler offering from IBM, the intention of the macro was to indicate that the host is AIX. HOS_AIX is being defined to minimize porting pain for existing code compiled with xlc/xlC. Given that LLVM has the infrastructure to be a cross-compiler, I consider it important to implement the macro to the original intention. Because the macro is a "legacy" AIX xlc macro I don't think it's relevant to define for non-AIX targets. If there's no objection to the change I can work with Jake to elaborate on the comments with an improved commit message. Comment Actions clang is fundamentally a cross-compiler only. I don't see any point for having host-specific branches in this case at all. Either the macro should be specified for the target all the time or not at all, but it should most definitely not depend on the host. That's actually breaking a number of existing use case for clang in subtle ways, e.g. partially preprocessed files (-frewrite-includes) should behave the same on any platform given the same command line. Comment Actions Given that we have a legacy XL macro with no legacy cross compiler I think it's fine if we set this according to the target only. It's fully redundant to _AIX but we'll define it for any working use-case with the current xlC compiler. If IBM has a compelling use case for a host-specific macro we can always revive this discussion. For now, you're probably making us from making a mistake ;) Comment Actions
follow up in https://reviews.llvm.org/D107825 |
suggest using a temp rather than unnecessarily declaring the local var:
if (Triple(sys::getProcessTriple()).isOSAIX() ...