On Thu, Oct 29, 2015 at 6:49 PM, Steve Ellcey <sell...@imgtec.com> wrote:
>
> 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?
No. GCC should ensure libcalls (yes, they are speical for some non-obvious
reason) always adhere to the platform ABI at the caller side.
Not sure why the libcall path doesn't (well, I gues it doesn't) adhere
to FUNCTION_VALUE and friends. History maybe (or maybe the
idea to explicitely allow differing ABIs for those?)
Richard.
> 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
>
>
