Re: _Fract types and conversion routines

[Steve Ellcey <sellcey at imgtec dot com>]

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
sellcey@imgtec.com