OK, I think I understand what is happening with the MIPS failure when
converting 'signed char' to '_Sat unsigned _Fract' after I removed
the TARGET_PROMOTE_PROTOTYPES macro.
This bug is a combination of two factors, one is that calls to library
functions (like __satfractqiuhq) don't necessarily get the right type
promotion (specifically with regards to signedness) of their arguments
and the other is that __satfractqiuhq doesn't deal with that problem
correctly, though I think it is supposed to.
Reading emit_library_call_value_1 I see comments like:
/* Todo, choose the correct decl type of orgfun. Sadly this information
isn't present here, so we default to native calling abi here. */
So I think that when calling a library function like '__satfractqiuhq'
which takes a signed char argument or calling a library function like
__satfractunsqiuhq which takes an unsigned char argument
emit_library_call_value_1 cannot ensure that the right type of extension
(signed vs unsigned) is done on the argument when it is put in the
argument register. Does this sound like a correct understanding of the
limitation in emit_library_call_value_1?
I don't see this issue on regular non-library calls, presumably because
the compiler has all the information needed to do correct explicit
conversions.
When I look at the preprocessed __satfractqiuhq code I see:
unsigned short _Fract
__satfractqiuhq (signed char a) {
signed char x = a;
low = (short) x;
When TARGET_PROMOTE_PROTOTYPES was defined this triggered explicit
code truncate/sign extend code that took care of the problem I am
seeing but when I removed it, GCC assumed the caller had taken care
of the truncate/sign extension and, because this is a library function,
that wasn't done correctly and I don't think it can be done correctly
because emit_library_call_value_1 doesn't have the necessary
information.
So should __satfractqiuhq be dealing with the fact that the argument 'a'
may not have been sign extend in the correct way?
I have tried a few code changes in fixed-bit.c (to no avail) but this
code is so heavily macro-ized it is tough to figure out what it should
be doing.
Steve Ellcey
sell...@imgtec.com
