No integral promotions when calling library function?
We are trying to add a 16bit integer division library function for
bfin port. I just found GCC didn't do integral promotions when calling
library function.
For example, in function foo, I can assume both arguments are zero
extended from unsigned short to unsigned int.
extern unsigned short foo (unsigned short, unsigned short);
unsigned int a;
unsigned int b;
unsigned short bar ()
{
return foo ((unsigned short) a, (unsigned short) b);
}
But with the following code, I can't assume that the high halves of R0
and R1, which are the first two registers for argument passing, are
all zeros.
unsigned int a;
unsigned int b;
unsigned short bar ()
{
return (unsigned short) a / (unsigned short) b;
}
Is this expected?
Thanks,
Jie
Re: No integral promotions when calling library function?
On 18/02/2010 07:17, Jie Zhang wrote: > We are trying to add a 16bit integer division library function for > bfin port. I just found GCC didn't do integral promotions when calling > library function. > Is this expected? I wasn't aware of this myself, but it kind-of makes sense given the way that macros such as FUNCTION_ARG and INIT_CUMULATIVE_ARGS don't get passed any type info in the case of libcalls; I'm guessing here, but that would imply to me that all libcalls are effectively using unnamed stdargs-style arg passing. Not sure how to check this theory without extensively reading the source though. I imagine it's done for efficiency, and there should always be libcall functions existing for the precise types you're passing? cheers, DaveK
Re: No integral promotions when calling library function?
On Fri, Feb 19, 2010 at 12:03 AM, Dave Korn wrote: > On 18/02/2010 07:17, Jie Zhang wrote: >> We are trying to add a 16bit integer division library function for >> bfin port. I just found GCC didn't do integral promotions when calling >> library function. > >> Is this expected? > > I wasn't aware of this myself, but it kind-of makes sense given the way that > macros such as FUNCTION_ARG and INIT_CUMULATIVE_ARGS don't get passed any type > info in the case of libcalls; I'm guessing here, but that would imply to me > that all libcalls are effectively using unnamed stdargs-style arg passing. > Not sure how to check this theory without extensively reading the source > though. I imagine it's done for efficiency, and there should always be > libcall functions existing for the precise types you're passing? > I'm trying to use an existing division function as a library function. This existing function does unsigned 16bit integral division and expects both arguments have been zero extended to 32bit. It's a little surprise for me that GCC does not do the promotion when calling library function even TARGET_PROMOTE_PROTOTYPES is defined. I can adjust the division function accordingly. But before I do that, I'd like to know if library functions should follow the same convention as the normal ones or not. Jie
