[AIX] Define __HOS_AIX__ macro

[Jake-Egan]

Summary

This patch defines __HOS_AIX__ macro for AIX in case of a cross compiler implementation.

Tested with SPEC.

[cebowleratibm]

clang/lib/Basic/Targets/OSTargets.h

679

HOS_AIX should only be defined if both the host and the target OS are AIX.

[Jake-Egan]

Only define if AIX is the target and host.

[cebowleratibm]

clang/test/Preprocessor/not-host-aix.c

2 ↗

(On Diff #364685)

this should specify an aix triple. The test doesn't run on an aix host and any other host should not define the macro even with an aix target.

[cebowleratibm]

clang/lib/Basic/Targets/PPC.cpp

306 ↗

(On Diff #364685)

suggest using a temp rather than unnecessarily declaring the local var:

if (Triple(sys::getProcessTriple()).isOSAIX() ...

[Jake-Egan]

Use a temp rather than a local var.

[cebowleratibm]

LGTM

[joerg]

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?

[nemanjai]

In D107242#2932289, @joerg wrote:

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?

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?

[cebowleratibm]

In D107242#2932289, @joerg wrote:

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?

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.

[joerg]

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.

[cebowleratibm]

In D107242#2934611, @joerg wrote:

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.

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 ;)

[cebowleratibm]

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 ;)

follow up in https://reviews.llvm.org/D107825

clang/lib/Basic/Targets/OSTargets.h

protected:
   void getOSDefines(const LangOptions &Opts, const llvm::Triple &Triple,
                     MacroBuilder &Builder) const override {
     DefineStd(Builder, "unix", Opts);
     Builder.defineMacro("_IBMR2");
     Builder.defineMacro("_POWER");
 
     Builder.defineMacro("_AIX");
     Builder.defineMacro("__TOS_AIX__");
+    Builder.defineMacro("__HOS_AIX__");
 
     if (Opts.C11) {
       Builder.defineMacro("__STDC_NO_ATOMICS__");
       Builder.defineMacro("__STDC_NO_THREADS__");
     }
 
     if (Opts.EnableAIXExtendedAltivecABI)
       Builder.defineMacro("__EXTABI__");

clang/test/Preprocessor/init-ppc.c

 // PPC-AIX:#define __FLT_MANT_DIG__ 24
 // PPC-AIX:#define __FLT_MAX_10_EXP__ 38
 // PPC-AIX:#define __FLT_MAX_EXP__ 128
 // PPC-AIX:#define __FLT_MAX__ 3.40282347e+38F
 // PPC-AIX:#define __FLT_MIN_10_EXP__ (-37)
 // PPC-AIX:#define __FLT_MIN_EXP__ (-125)
 // PPC-AIX:#define __FLT_MIN__ 1.17549435e-38F
 // PPC-AIX:#define __FLT_RADIX__ 2
+// PPC-AIX:#define __HOS_AIX__ 1
 // PPC-AIX:#define __INT16_C_SUFFIX__
 // PPC-AIX:#define __INT16_FMTd__ "hd"
 // PPC-AIX:#define __INT16_FMTi__ "hi"
 // PPC-AIX:#define __INT16_MAX__ 32767
 // PPC-AIX:#define __INT16_TYPE__ short
 // PPC-AIX:#define __INT32_C_SUFFIX__
 // PPC-AIX:#define __INT32_FMTd__ "d"
 // PPC-AIX:#define __INT32_FMTi__ "i"