https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83885
--- Comment #2 from dave.anglin at bell dot net --- On 2018-01-17 3:54 AM, ebotcazou at gcc dot gnu.org wrote: > IIRC HP-UX uses descriptors for functions so > TARGET_CUSTOM_FUNCTION_DESCRIPTORS should be defined to 0. If Linux > doesn't, then the macro should be defined to 1. That was my understanding from the documentation. I also read s390 bug report on the issue. 32-bit HP-UX and linux are the same. Usually, a function descriptor is used but not always. In a function pointer, the second least significant bit is used to determine whether the pointer is direct or points to a function descriptor. The millicall routine $$dyncall checks this bit in an indirect call and takes appropriate action. There may also be a variety of stubs in the call path. As noted, defining to 1 fixes the test failure on linux. I don't know current status on hpux due a poly_int breakage that's now fixed.
