mcgrath%paris.Berkeley.EDU@GINGER.BERKELEY.EDU (Roland McGrath) (05/26/89)
If a GCC built-in, such as __builtin_abs, is used in an address context, rather than a function context, as in: int (*foo)(int) = __builtin_abs; GCC treats this as if it were not a builtin function. What is should do, I think, is generate a static __builtin_abs function and use its address.
raeburn@ATHENA.MIT.EDU (Ken Raeburn) (05/29/89)
>If a GCC built-in, such as __builtin_abs, is used in an address context, >rather than a function context, as in: > int (*foo)(int) = __builtin_abs; >GCC treats this as if it were not a builtin function. > >What is should do, I think, is generate a static __builtin_abs function >and use its address. There are a couple of other solutions to this: 1) Only use __builtin_* in function contexts: #define abs(x) __builtin_abs(x) Thus, any non-function references get the true `abs' function. References of the form (abs)(x) will also get the library function. 2) Have address references to built-in functions generate references to other existing functions. Why generate a static `__builtin_abs' when the standard C (and UNIX) library `abs' will do just as well? I think the pANS has some restrictions along the lines of #1 for standard header files. Is there some reason you'd want to explicitly get the address of gcc-generated functions instead of their standard library versions? (Well, okay, I can see one or two possible ones; some slight advantage gained by locality of reference, and possibly faster code than a poorly-coded (or poorly-compiled) library version. The first is probably not much of a gain, and loses on overall code size, and the second should serve as incentive to fix your library.) -- Ken